Hi all, noone can answer me? :-( I don't really need the answer, but I think I pointed out some usage issue in some implementation or server configuration (at least here on gmail.com and jabber.org), don't you think?
And if they are bugs in the server implementation, maybe I could make some bug report. But I wanted confirmation from others, because I may be the one slow to understand. ;-) Regards, Jehan Jehan;5939 Wrote: > Hi, > > I have questions about the mechanisms presented in <stream:features>. > Note that I am not at all an expert in Internet security protocols and > technics... All these questions are just because I am improving an > implementation and tries to understand all these authentication stuffs > and logical better. > > 1/ First, when starttls is mandatory (with <required /> sub-element), > why are the available mechanisms listed anyway, as it is not useable > then: there will be the tls negotiation first; then when it is > aknowledged, the mechanisms are sent again in a new <stream:features> > (moreover first time, both entities are supposed to "forget" everything > before tls)? The first time is just useless information here, isn't it? > > 2/ If you aknowledge these features, ok, but then can the features sent > again in the second stream:features (after tls negotiation) be different > than the first ones? And if so, why? > > I say this, because on tests on gmail.com, I noticed that at first the > only mechanism is X-GOOGLE-TOKEN, then once tls is negotiated, you have > also PLAIN: > > > Code: -------------------- > > > <?xml version="1.0" encoding="UTF-8"?> > <stream:stream from="gmail.com" id="B9F66C137D4145A7" version="1.0" xmlns:stream="http://etherx.jabber.org/streams"; xmlns="jabber:client"> > <stream:features> > <starttls xmlns="urn:ietf:params:xml:ns:xmpp-tls"> > <required/> > </starttls> > <mechanisms xmlns="urn:ietf:params:xml:ns:xmpp-sasl"> > <mechanism>X-GOOGLE-TOKEN</mechanism> > </mechanisms> > </stream:features> > > <starttls xmlns="urn:ietf:params:xml:ns:xmpp-tls"/> > > <proceed xmlns="urn:ietf:params:xml:ns:xmpp-tls"/> > > <?xml version='1.0'?> > <stream:stream xmlns="jabber:client" to="gmail.com" version="1.0" xmlns:stream="http://etherx.jabber.org/streams"; > > > <?xml version="1.0" encoding="UTF-8"?> > <stream:stream from="gmail.com" id="89DB57B98D501720" version="1.0" xmlns:stream="http://etherx.jabber.org/streams"; xmlns="jabber:client"> > > <stream:features> > <mechanisms xmlns="urn:ietf:params:xml:ns:xmpp-sasl"> > <MECHANISM>PLAIN</MECHANISM> > <mechanism>X-GOOGLE-TOKEN</mechanism> > </mechanisms> > </stream:features> > -------------------- > > > > Any reason for this? I could guess that maybe if tls was not > mandatory, there may be case that you have some new available features > only when you negotiate tls... but here tls is mandatory, so it is > strange that you add new info after tls... > > 3/ Also strange is when you have less features after tls negotiation > (except for the <starttls /> which is removed of course). > > This is strange because any information received before tls must not > be taken into account, cf. section 5.1 or RFC3920: > > Code: -------------------- > > > # If the TLS negotiation is successful, the receiving entity MUST discard any knowledge obtained in an insecure manner from the initiating entity before TLS takes effect. > # If the TLS negotiation is successful, the initiating entity MUST discard any knowledge obtained in an insecure manner from the receiving entity before TLS takes effect. > -------------------- > > > > Yet for instance, if I connect to jabber.org: > > > Code: -------------------- > > > <stream:features> > <starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'/> > *<compression xmlns='http://jabber.org/features/compress'> > <method>zlib</method> > </compression> > *<mechanisms xmlns='urn:ietf:params:xml:ns:xmpp-sasl'> > <mechanism>DIGEST-MD5</mechanism> > <mechanism>PLAIN</mechanism> > </mechanisms> > <register xmlns='http://jabber.org/features/iq-register'/> > </stream:features> > > <starttls xmlns="urn:ietf:params:xml:ns:xmpp-tls"/> > > <proceed xmlns='urn:ietf:params:xml:ns:xmpp-tls'/> > > <?xml version='1.0'?> > <stream:stream xmlns="jabber:client" to="jabber.org" version="1.0" xmlns:stream="http://etherx.jabber.org/streams"; > > > <?xml version='1.0'?> > <stream:stream xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams' id='4146130133' from='jabber.org' version='1.0' xml:lang='en'> > > <stream:features> > <mechanisms xmlns='urn:ietf:params:xml:ns:xmpp-sasl'> > <mechanism>DIGEST-MD5</mechanism> > <mechanism>PLAIN</mechanism> > </mechanisms> > <register xmlns='http://jabber.org/features/iq-register'/> > </stream:features> > -------------------- > > > > One can notice we "lost" the <compression /> feature. Of course we > could think this is something that must be negotiated before tls. So I > checked and I saw that it was the opposite. In XEP-0138, section "3. > Business Rules", one reads: > > > Code: -------------------- > > > If both TLS (whether including TLS compression or not) and stream compression are used, then TLS MUST be negotiated first, followed by negotiation of stream compression. > -------------------- > > > > But as the knowledge of stream compression possibility is supposed be > discarded after tls negotiation and the feature is not sent again in > the new <stream:features/>, then this compression feature can never be > used! > > So is there something I missed? A bug in ejabberd? An administration > issue in jabber.org? Other? > Thanks... > > Jehan -- Jehan ------------------------------------------------------------------------ Jehan's Profile: http://www.jabberforum.org/member.php?userid=16911 View this thread: http://www.jabberforum.org/showthread.php?t=1308
