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

Major SASL issues (was Re: Last Call: 'XMPP Core' to Proposed Standard)

The IESG wrote:

The IESG has received a request from the Extensible Messaging and Presence Protocol WG to consider the following document:

- 'XMPP Core '
  <draft-ietf-xmpp-core-18.txt> as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send any comments to the
iesg@ietf.org or ietf@ietf.org mailing lists by 2003-10-09.
The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-xmpp-core-18.txt

I would like to raise several SASL related issues in XMPP document.
(Sorry for crosspost and sorry for being late with reviewing this.)

1).
>   7.  The initiating entity MUST provide an authzid during SASL
>       negotiation. The authzid-value MUST be a valid JID of the form
>       <domain> (i.e., a domain identifier only) for servers and of the
>       form <user@domain/resource> (i.e., node identifier, domain
>       identifier, and resource identifier) for clients. The initiating
>       entity MAY process the authzid-value in accordance with the rules
>       defined in Addressing Scheme (Section 3) before providing it to
>       the receiving entity, but is NOT REQUIRED to do so; however, the
>       receiving entity MUST verify that the authzid-value provided by
>       the initiating entity conforms to the rules defined therein.

Not all SASL mechanisms are capable of transmitting authorization identity, so this requirement might be problematic.

Also, the revision of RFC 2222 says that the client must not specify authorization-id unless it wants to impersonate some other entity:

  As a client might not have the same information as the server,
  clients SHOULD NOT themselves try to derive authorization identities
  from authentication identities when clients could instead transmit an
  authorization identity of the empty string.

So, the text should be reworded reflect that an authorization identity is optional and that if one is provided, it is in the form described above.

2).

>   This series of challenge/response pairs continues until one of three
>   things happens:
>
>   1.  The initiating entity aborts the handshake by sending an <abort/>
>       element qualified by the 'urn:ietf:params:xml:ns:xmpp-sasl'
>       namespace to the receiving entity. Upon receiving the <abort/>
>       element, the receiving entity MUST terminate the TCP connection.

I think the requirement to drop TCP connection is unreasonable here.
There are several valid reasons why the client may retry failed authentication:
1). User typed in a wrong password, the client should retry the same SASL mechanism a reasonable number of times.
2). The client invoked a SASL mechanism that reported that it can't be used because of misconfiguration (e.g. kerberos configuration file is missing). The client than sends <abort/> to the server and tries another mechanism.

3).

>   3.  The receiving entity reports success of the handshake by sending
>       a <success/> element qualified by the
>       'urn:ietf:params:xml:ns:xmpp-sasl' namespace to the initiating
>       entity; this element MAY optionally contain character data (in
>       SASL terminology "additional data with success"). Upon receiving
>       the <success/> element, the initiating entity MUST initiate a new
>       stream by sending an opening XML stream header to the receiving
>       entity (it is not necessary to send a closing </stream:stream>
>       element first, since the receiving entity and initiating entity
>       MUST consider the original stream to be closed upon sending or
>       receiving the <success/> element). Upon receiving the new stream
>       header from the initiating entity, the receiving entity MUST
>       respond by sending a new XML stream header to the initiating
>       entity, along with any remaining available features (but NOT
>       including the STARTTLS feature or any authentication mechanisms)
>       or an empty features element (to signify that no additional
>       features are available); note that any such additional features
>       are not defined herein, and MUST be defined by the relevant
>       extension to XMPP.

Other protocols (IMAP/SMTP/POP) list available SASL mechanisms after a successful SASL authentication.
Some of them require that the client compares the list of the advertised mechanism with the one before the authentication.
This is done to prevent man-in-the-middle attacks when an attacker removes strong SASL mechanisms from the list of supported mechanisms.
(Whether this check is useful in practice is another matter. I am not sure whether anybody implements it).

4). There was a recent discussion on the bugtraq mailing list about handling invalid base64 data. It turned out that different implementations handle
this differently, for example:
1). Ignore invalid characters
2). Treat an invalid character as the end of the base64 encoded data (and ignore the rest)
3). Truncate base64 encoded data before the invalid character.

In particular there was a discussion regarding the padding character ('=') in the middle of a base64 data.

I suggest that some text about this be added to the Security considerations sections. For example:

Both the client and the server should verify the received base64 data and reject (and not ignore) any characters not explicitly allowed by the base64 alphabet
[BASE64] and should reject any sequence of base64 characters that contains the pad ('=') character not as the last
character of the (e.g. "=AAA" or "BBBB=CCC").

[BASE64] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 3548, July 2003.


(You might decide to relax this for XMPP and to allow spaces and/or CRLFs anywhere in the data.)

5).
>6.3 SASL Errors
>
>   o  <bad-protocol/> -- The data provided by the initiating entity
>      could not be processed, e.g. because does not adhere to the
>      protocol for the requested mechanism; sent in response to the
>      <response/> element.

Do you mean invalid base64 encoding here or something else?

6).

>6.3 SASL Errors
>
>   The following SASL-related error conditions are defined:
>
>   o  <aborted/> -- The receiving entity acknowledges an <abort/>
>      element sent by the initiating entity; sent in response to the
>      <abort/> element.
>
>   o  <bad-protocol/> -- The data provided by the initiating entity
>      could not be processed, e.g. because does not adhere to the
>      protocol for the requested mechanism; sent in response to the
>      <response/> element.

or <auth/> with initial challenge data. Example: SASL PLAIN mechanism.

>   o  <encryption-required/> -- The mechanism chosen by the initiating
>      entity may be used only if the stream is already encrypted; sent
>      in response to the <auth/> element.
>
>   o  <invalid-authzid/> -- The authzid provided by the initiating
>      entity is invalid, either because it is incorrectly formatted or
>      because the initiating entity does not have permissions to
>      authorize that ID; sent in response to a <response/> element.

or <auth/> with initial challenge data.

>   o  <invalid-mechanism/> -- The initiating entity did not provide a
>      mechanism or requested a mechanism that is not supported by the
>      receiving entity; sent in response to the <auth/> element.
>
>   o  <invalid-realm/> -- The realm provided by the initiating entity
>      (in mechanisms that support the concept of a realm) does not match
>      one of the hostnames served by the receiving entity; sent in
>      response to a <response/> element.

or <auth/> with initial challenge data.

>   o  <mechanism-too-weak/> -- The mechanism requested by the initiating
>      entity is weaker than server policy permits for that initiating
>      entity; sent in response to the <response/> element.

or <auth/> with initial challenge data.

> o <not-authorized/> -- The authentication failed because the
> initiating entity did not provide valid credentials (this includes
> the case of an unknown username); sent in response to a <response/> element.

or <auth/> with initial challenge data.

7).

>12.4 Order of Layers
>
>   The order of layers in which protocols MUST be stacked is as follows:
>
>   1.  TCP
>
>   2.  TLS
>
>   3.  SASL
>
>   4.  XMPP
>
>   The rationale for this order is that TCP is the base connection layer
>   used by all of the protocols stacked on top of TCP, TLS is often
>   provided at the operating system layer, SASL is often provided at the
>   application layer, and XMPP is the application itself.

This should be referenced in "6.4 SASL Definition" section, because it is related to the XMPP profile of SASL.

Cheers,
Alexey