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

[Peter Saint-Andre <[e-mail]>]

On Tue, Oct 07, 2003 at 10:49:33PM +0100, Alexey Melnikov wrote:

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

No apologies necessary -- your feedback is appreciated.

> 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.

My understanding from an earlier thread on the XMPP WG list was that
providing the authorization identity in this manner was the approach
preferred by the SASL community. I think the fundamental issue here is
that for XMPP clients, the authorization identity is a "full JID" (i.e.,
node@host/resource) that is asserted by the connecting client, not
derived by the server. Perhaps this usage is not consistent with the
definition of authorization identity in RFC 2222? We'd have to look at
the implications of this for client assertion of a full JID (perhaps
this should be defined only in draft-ietf-xmpp-im).

> 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.

This seems reasonable. I think we were attempting to ensure that the
connecting entity could not abuse the opened TCP connection for an
unspecified period of time.

> 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).

OK, I'll look at what those other protocols require, and how they word
the requirement. It seems good to have this check in place. 

> 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.

Thanks for the suggested text.

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

I see no strong reason to relax the requirement just for XMPP.

> 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?

It could be invalid base64 encoding, but we were thinking especially
that the decoded response is not consistent with the challenge format
required by the selected SASL mechanism.

> 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.

I've fixed these in my working copy.

> 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.

Fixed in my working copy.

Peter

-- 
Peter Saint-Andre
Jabber Software Foundation
http://www.jabber.org/people/stpeter.php