mridul at sun.com
Wed Mar 21 15:01:36 CDT 2007
Thinking more, we are going to end up with one xmpp client stream impl
riding on top of another (kind of link inband link local streams) : take
stream of bytes from ibb xtls, construct packets out of it, associate it
with underlying xmpp stream and use it : reverse for writes.
This would require some jugglery on part of the clients, though
definitely no something which cant be done.
Justin Karneges wrote:
> On Wednesday 21 March 2007 9:34 am, Peter Saint-Andre wrote:
>> Justin Karneges wrote:
>>> On Friday 16 March 2007 8:17 pm, Peter Saint-Andre wrote:
>>>> Justin Karneges wrote:
>>>>> If by XTLS you mean you want to define a usage of TLS (e.g. base64
>>>>> encoding segments of a TLS stream), then that shouldn't be scary at
>>>> Sure we'd have things like:
>>>> <xtls xmlns='urn:xmpp:xtls'>base64</xtls>
>>>> The TLS stuff would all be base64-encoded, just hand it off to OpenSSL
>>>> and you're done. Sort of. :) We'd need to bubble the results up to the
>>>> XMPP application layer so the client knows when the negotiation is done.
>>>> And I'm sure there are subtleties. But that is the basic idea AFAICS.
>>> I think you're done. :) Running TLS over an IBB (or similar) stream is
>>> not any different from running TLS over TCP, provided you don't have to
>>> fight your TLS library very much. The client knows when the TLS
>>> negotiation is completed because the TLS library says so.
>> I don't know if we need IBB for that, why not put it in a dedicated
>> namespace? IBB is general, xtls is more specific.
> TLS protects a bytestream of data. We haven't defined what would be inside of
> this stream, but anyway this stream needs to be transported over XMPP as a
> series of stanzas. I only suggest IBB as the transport because you'll end up
> reinventing it anyway. E.g. the difference wouldn't amount to much more than
> changing the element & namespace.
>>> If we went this route, I'd suggest simply starting an XML stream over the
>>> TLS channel, and using that for stanza exchange. Voila, e2e.
>> What exactly is the TLS channel? My understanding is that you'd exchange
>> these <message><xtls>base64</xtls></message> stanzas to do the
>> negotiation and then you'd have a TLS channel over XMPP, so all your
>> comms with the other person would now be included in those <xtls/>
>> elements. But probably I'm missing something -- would we use <xtls/>
>> only for the negotiation? If so, then what?
> We'd use <xtls/> elements the whole time, for negotiation and after. However,
> the important thing to keep in mind is that the application generally doesn't
> (and isn't supposed to) know what are in these packets. A piece of TLS
> stream data could include negotiation bits, a partial stanza, several
> stanzas, etc. The application doesn't care what the contents are; the
> results are simply fed into a TLS library. It is the TLS library that says
> to the application, "the negotiation finished", or "here is some nice decoded
> data". The abstraction is similar to TCP: the application isn't supposed
> care how the underlying transmission actually packetizes, the application
> simply knows that it has a bytestream to operate on.
> As noted above, we still have to define what should go into the bytestream. I
> suggest a c2s-like session. This would be similar in usage to the legacy
> 5223 SSL, where a stream is established with the other party (via IBB), TLS
> is immediately negotiated, and then you open a <stream> and start sending
> <stream:stream ...>
> <message> .... </message>
> <message> .... </message>
> No authentication would be needed (akin to link-local).
More information about the Security