[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [xmppwg] Last Call: 'XMPP Core' to Proposed Standard

Kurt D. Zeilenga wrote:

At 01:28 PM 10/8/2003, Eric Rescorla wrote:


"Kurt D. Zeilenga" <Kurt@OpenLDAP.org> writes:


I concur with Alexey's recent comments regarding XMPP's SASL
Profile.  I have a few addition concerns regarding this profile.
The scope of my review was, due to time constraints, was limited
to the profile.

I not sure why the documents says that SASL and TLS security
layers SHOULD NOT be enabled simultaneously (Section 6.2, rule 2),
but this recommendation is, I believe, flawed. There are numerous use
cases where implementations SHOULD establish additional layers.
For example, establishing additional SASL layers may prevent
certain kinds of tunneling man-in-the-middle attacks.


Could you describe some of them?



XMPP's TLS profile allows establishment of TLS even though the
implementation's certificate verification has failed:
 If the above methods fail, the certificate SHOULD be presented
 to a human (e.g., an end user or server administrator) for
 approval; if presented, the receiver MUST deliver the entire
 certificate chain to the human, who SHOULD be given the option
 to store the Root CA certificate (not the service or End Entity
 certificate) and to not be queried again regarding acceptance of
 the certificate for some reasonable period of time.

Given the likelihood that the end user will inappropriately
accept the certificate, attackers can easily insert a
TLS-protected machine in the middle.  Given this, it is quite
reasonable for implementors to offer (and deployers to demand)
additional safeguards.

Kurt 

If the policy requirement of the deployers is to not accept the risk
that the end user will accept certificate chains which cannot be verified
by algorithmic means, then the policy should fail the certificate validation
without presenting the certificates to the end user.  The TLS session at
that point must be aborted.  At this point the TCP session must be closed.

When XMPP attempts to reconnect, it must not attempt to establish a TLS session
and in turn must attempt to negotiate a SASL mechanism which provides
encryption/integrity protection. 

There is zero benefit to negotiating both TLS and SASL encryption/integrity
protection.

Btw, if it is possible for SASL to validate the TLS Client and Server Finished
messages as computed by both the client and server, this can be performed during
SASL authentication to detect a man-in-the-middle attack. This is the process
which is used in TELNET START-TLS when combined with TELNET AUTH.

Jeffrey Altman


Attachment: smime.p7s
Description: S/MIME Cryptographic Signature