Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP
Browse files

added security consideration on SASL downgrade attacks, suggested by …

…Kurt Zeilenga

git-svn-id: svn://svn.xmpp.org:7938/xmpp/trunk@2519 4b5297f7-1745-476d-ba37-a9c6900126ab
  • Loading branch information...
commit 8e2b12427c310a72d92d9a402f9fd85f06cd86af 1 parent 839bc52
@stpeter stpeter authored
Showing with 9 additions and 6 deletions.
  1. +9 −6 internet-drafts/draft-saintandre-rfc3920bis-09.xml
View
15 internet-drafts/draft-saintandre-rfc3920bis-09.xml
@@ -16,7 +16,7 @@
<uri>https://stpeter.im/</uri>
</address>
</author>
- <date year="2008" month="October" day="16"/>
+ <date year="2008" month="November" day="20"/>
<area>Applications</area>
<keyword>Extensible Messaging and Presence Protocol</keyword>
<keyword>XMPP</keyword>
@@ -3898,9 +3898,6 @@ XmppAddr ::= UTF8String
</list></t>
<t>The rationale for this order is that <xref target="TCP"/> is the base connection layer used by all of the protocols stacked on top of TCP, <xref target="TLS"/> is often provided at the operating system layer, <xref target="SASL"/> is often provided at the application layer, and XMPP is the application itself.</t>
</section>
- <section title="Lack of SASL Channel Binding to TLS" anchor="security-channel">
- <t>The SASL framework itself does not provide a method for binding SASL authentication to a security layer providing confidentiality and integrity protection that was negotiated at a lower layer. Such a binding is known as a "channel binding" (see <xref target='CHANNEL'/>). Some SASL mechanisms provide channel bindings. However, if a SASL mechanism does not provide a channel binding, then the mechanism cannot provide a way to verify that the source and destination end points to which the lower layer's security is bound are equivalent to the end points that SASL is authenticating; furthermore, if the end points are not identical, then the lower layer's security cannot be trusted to protect data transmitted between the SASL-authenticated entities. In such a situation, a SASL security layer SHOULD be negotiated that effectively ignores the presence of the lower-layer security.</t>
- </section>
<section title="Mandatory-to-Implement Technologies" anchor="security-mandatory">
<t>At a minimum, all implementations MUST support the following mechanisms:</t>
<t><list style='hanging'>
@@ -3910,8 +3907,11 @@ XmppAddr ::= UTF8String
<t>Naturally, implementations MAY support other ciphers with TLS and MAY support other SASL mechanisms.</t>
<t><list style='empty'><t>Note: The use of TLS plus SASL PLAIN replaces the SASL DIGEST-MD5 mechanism as XMPP's mandatory-to-implement password-based method for authentication. For backward-compatibility, implementations are encouraged to continue supporting the SASL DIGEST-MD5 mechanism as specified in <xref target='DIGEST-MD5'/>. Refer to <xref target='PLAIN'/> for important security considerations related to the SASL PLAIN mechanism.</t></list></t>
</section>
- <section title="Firewalls" anchor="security-firewalls">
- <t>Communication using XMPP normally occurs over TCP connections on port 5222 (client-to-server) or port 5269 (server-to-server), as registered with the IANA (see <xref target="iana"/>). Use of these well-known ports allows administrators to easily enable or disable XMPP activity through existing and commonly-deployed firewalls.</t>
+ <section title="SASL Downgrade Attacks" anchor="security-downgrade">
+ <t>Because the initiating entity chooses an acceptable SASL mechanism from the list presented by the receiving entity, the initiating entity depends on the receiving entity's list for authentication. This dependency introduces the possibility of a downgrade attack if an attacker can gain control of the channel and therefore present a weak list of mechanisms. To prevent this attack, the parties SHOULD protect the channel using TLS before attempting SASL negotiation.</t>
+ </section>
+ <section title="Lack of SASL Channel Binding to TLS" anchor="security-channel">
+ <t>The SASL framework itself does not provide a method for binding SASL authentication to a security layer providing confidentiality and integrity protection that was negotiated at a lower layer. Such a binding is known as a "channel binding" (see <xref target='CHANNEL'/>). Some SASL mechanisms provide channel bindings. However, if a SASL mechanism does not provide a channel binding, then the mechanism cannot provide a way to verify that the source and destination end points to which the lower layer's security is bound are equivalent to the end points that SASL is authenticating; furthermore, if the end points are not identical, then the lower layer's security cannot be trusted to protect data transmitted between the SASL-authenticated entities. In such a situation, a SASL security layer SHOULD be negotiated that effectively ignores the presence of the lower-layer security.</t>
</section>
<section title="Use of base64 in SASL" anchor="security-base64">
<t>Both the client and the server MUST verify any base64 data received during <xref target='sasl'>SASL negotiation</xref>. An implementation MUST reject (not ignore) any characters that are not explicitly allowed by the base64 alphabet; this helps to guard against creation of a covert channel that could be used to "leak" information.</t>
@@ -3939,6 +3939,9 @@ XmppAddr ::= UTF8String
<t>For more detailed recommendations regarding prevention of address mimicking in XMPP systems, refer to <xref target='XEP-0165'/>.</t>
</section>
</section>
+ <section title="Firewalls" anchor="security-firewalls">
+ <t>Communication using XMPP normally occurs over TCP connections on port 5222 (client-to-server) or port 5269 (server-to-server), as registered with the IANA (see <xref target="iana"/>). Use of these well-known ports allows administrators to easily enable or disable XMPP activity through existing and commonly-deployed firewalls.</t>
+ </section>
<section title="Denial of Service" anchor="security-dos">
<t><xref target='DOS'/> defines denial of service as follows:</t>
<t>
Please sign in to comment.
Something went wrong with that request. Please try again.