[Security] XTLS
Mridul
mridul at sun.com
Wed Mar 21 15:08:35 CDT 2007
Message got posted before I could edit it, apologies.
Mridul wrote:
>
>
> 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) :
(kind of link inband link local streams) -> (kind of like 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.
packets -> stanza's, jso calls it packets, and this escapes into my
conversations :-)
Regards,
Mridul
> This would require some jugglery on part of the clients, though
> definitely no something which cant be done.
>
>
> Mridul
>
>
> 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
>>>>>> all.
>>>>> Sure we'd have things like:
>>>>>
>>>>> <iq>
>>>>> <xtls xmlns='urn:xmpp:xtls'>base64</xtls>
>>>>> </iq>
>>>>>
>>>>> 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 stanzas.
>>
>> <stream:stream ...>
>> <message> .... </message>
>> <message> .... </message>
>> </stream>
>>
>> No authentication would be needed (akin to link-local).
>>
>> -Justin
>
More information about the Security
mailing list