[standards-jig] SSL/TLS and feature negotiation

Robert Norris rob at cataclysm.cx
Wed Mar 20 00:04:29 UTC 2002


I've been thinking about implementing SSL/TLS for jadc2s (part of the
jabberd 1.5 development, see
    http://jabberstudio.org/projects/view.php?id=13 ).

There's two ways to implement it, as I see it. One would be to simply
put SSL on a different port, ala HTTPS, IMAPS, whateverelseS. In this
case, we need to decide on a standard port to use for this, and,
depending on how far we want to go, get that port assigned to us by
IANA.

The other option, and IMO the better one, is to let the client begin a
SSL session over the normal client port. This is the way that the
STARTTLS mechanism works for things like secure SMTP.

Here's an example of a secure SMTP session, for those who don't know:

S: 220 localhost ESMTP postfix
C: EHLO localhost
S: 250-localhost
S: 250-PIPELINING
S: 250-SIZE 10240000
S: 250-ETRN
S: 250-STARTTLS
S: 250-XVERP
S: 250 8BITMIME
C: STARTTLS
S: 220 Ready to start TLS

At this point, the client begins a normal SSL/TLS negotiation, and once
a secure channel is established, the session is restarted.

Doing things this way is nice, because we don't have to use another
port. However, feature negotiation is necessary, because the client
needs to know if the server supports SSL.

This can be made to be backwards-compatible, in the same way that HELO
is used by SMTP clients that aren't aware of the ESMTP EHLO command.

I imagine that this would be done as an extension to the actual XML
stream. It would not be trivial, as we now need a way to query stream
features, and set stream options.

So, the entire client negotiation might look like this:

(Note that this is all straight off the top of my head).

C: <stream:stream
       to='host'
       xmlns='jabber:client'
       xmlns:stream='http://etherx.jabber.org/streams'>
S: <stream:stream
       from='host'
       id='id_123456789'
       xmlns='jabber:client'
       xmlns:stream='http://etherx.jabber.org/streams'>
C: <stream:get-features to='host'/>
S: <stream:features from='host'>
       <ssl/>
   </stream:features>
C: <stream:set-feature to='host'>
       <ssl/>
   </stream:set-feature>
S: <stream:feature from='host'>
       <ssl/>
   </stream:feature>
[ Client begins SSL negotiation ]
[ Secure channel established, server resets state ]
C: <stream:stream
       to='host'
       xmlns='jabber:client'
       xmlns:stream='http://etherx.jabber.org/streams'>
S: <stream:stream
       from='host'
       id='id_123456789'
       xmlns='jabber:client'
       xmlns:stream='http://etherx.jabber.org/streams'>
C: <iq id='j0' type='get'>
     <query xmlns='jabber:iq:auth'>
       <username>user</username>
     </query>
   </iq>
[...]

A system like this would also allow us to add other stream features
later in a relatively benign way. Off the top of my head, I can think of
things like rate limiting, character set selection, or server
redirection.

Something like this could also be applied to server-to-server
connections.

Obviously, this needs more fleshing out. I'd be interested to see what
thoughts people have about this. When/if we get some consensus about
this, I'll submit a JEP.

Regards,
Rob.

-- 
Robert Norris                                       GPG: 1024D/FC18E6C2
Email+Jabber: rob at cataclysm.cx                Web: http://cataclysm.cx/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 232 bytes
Desc: not available
URL: <http://mail.jabber.org/pipermail/standards/attachments/20020320/3e561485/attachment.sig>


More information about the Standards mailing list