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

Re: Last Call: 'XMPP Core' to Proposed Standard

Kurt D. Zeilenga wrote:

To the IESG,

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.


The "security" is specific to the SASL encryption and integrity protection; not authentication. Clearly, SASL authentication might be used to help detect a man-in-the-middle attack. If you are arguing that SASL encryption/integrity protection should be used on top of TLS encryption/integrity protection, the only reason for doing so is that you do not trust the TLS encryption/integrity protection. I do not see where the man-in-the-middle attack would be coming from?

The requirement that initiating receiving entity drop all knowledge
it learned before negotiating SASL layers (rule 5) is too broad.
This could be viewed as requiring the implement to forget knowledge
it gained previously in a secure manner (such as an externally
established lower level (IPSEC or TLS) identity information).
Likewise for rule 6.


Rules 5 and 6 are specific to the use of SASL mechanisms which are actively providing encryption/integrity protection. In this situation, it is known that TLS is not in use. I doubt it is known whether or not IPSec is in use for the entire communication path. Therefore, all information obtained prior to the establishment of encryption/integrity protection must be considered suspect.

I believe the problem is one of language. Can we replace all references to "security layer" to read "data protection layer"?

I am also concerned by the use of the term "stream encryption"
in the document as this doesn't imply, in my eyes, "stream
integrity". It's unclear to me which imperatives imply when
encryption, integrity, and/or in combination with other security
services which TLS provides.



I agree. We are not concerned with Stream Encryption but Data Protection. Replace "Stream Encryption" with "Data Protection" throughout.

I have not completed a security review of these documents as yet. I am simply responding to Kurt's comments.

Jeffrey Altman

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