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
