Ralph Meijer wrote:
On Fri, Dec 30, 2005 at 08:57:38AM -0700, Peter Saint-Andre wrote:12. If the TLS negotiation is successful, the initiating entity MUST continue with SASL negotiation.So I infer from the above that any entity that would specify its version to be 1.0 would have support for TLS as well. And if TLS is done successfully, SASL MUST be done as well.That is correct.I want to note here that JEP-0138, Stream Compression, should be done after TLS negotiation. The JEP does not mention that it should also go before SASL but that seems fairly logical. As we may come up with more and more stream features, it might be good to think about how to do the ordering of steps correctly, before actual XML Stanzas can start to be communicated.
You raise a good point. We need do a better job of defining the order of any stream feature negotiations, and defining exactly what stream feature negotiation is and what it should look like (e.g., one of the implicit rules seems to be "don't use stanzas to negotiate stream features" since stream feature negotiation is seen as a preliminary to sending stanzas).
http://www.jabber.org/registrar/stream-features.html currently lists 8 stream features. The RFCs define an ordering for the features defined therein, namely:
1. TLS 2. SASL 3. Resource binding 4. IM session establishment
And we also seem to have at least one stream feature that works with XML Stanzas themselves, jabber:iq:auth.
Although non-SASL authentication (jabber:iq:auth) is a stream feature, it uses IQ stanzas for the negotiation and essentially it is an older way of doing what the RFCs define in SASL + bind + session. So the following order seems appropriate:
1. TLS 2. jabber:iq:authNormally, however, if channel encryption is desired then clients connect on an old-fashioned SSL port (normally 5223) and do jabber:iq:auth there, rather than doing the TLS upgrade on 5222 and then iq:auth. Though I suppose that nothing really forbids that (except RFC 3920 says to use SASL!).
Similarly, in-band registration (jabber:iq:register) uses IQ stanzas. When it is used to establish an account, it would definitely be completed before SASL because you can't auth if you don't have an account (leaving aside SASL ANONYMOUS for now). So the order would be:
1. TLS 2. jabber:iq:register 3. SASL etc. (or jabber:iq:auth)Advanced message processing is advertised as a stream feature but its use is not negotiated and does not really need to be before sending stanzas (e.g., support for it could be discovered via service discovery and we added the stream feature to JEP-0079 mainly for purposes of potential efficiency). So we don't need to define an order here. (Indeed it could be argued that we don't need a stream feature for this.)
Stream compression is negotiated when you can't set the TLS compression bit for whatever reason. I'd agree with Ralph that negotiating this after TLS and before SASL (or jabber:iq:auth) makes the most sense. So:
1. TLS 2. Stream compression 3. SASL etc. (or jabber:iq:auth) What if you want to do in-band registration and stream compression? I'd say: 1. TLS 2. Stream compression 3. jabber:iq:register 4. SASL etc. (or jabber:iq:auth)The more stream features we add, the more complex this all becomes. That's one good reason to not define more stream features than we absolutely need. :-)
Perhaps we need a little JEP that specifies the recommended order of negotiation for the stream features in the registry, and we update that JEP whenever we define a new stream feature?
Peter -- Peter Saint-Andre Jabber Software Foundation http://www.jabber.org/people/stpeter.shtml
smime.p7s
Description: S/MIME Cryptographic Signature
