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

[Alexey Melnikov <Alexey.Melnikov@isode.com>]

Peter Saint-Andre wrote:

> > 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.
Closing connection or refusing to perform any tasks after a certain 
number of failures are two common implementation practice in SMTP and 
other protocols.
I think you should mention them, but don't require everyone to implement 
them.

> > 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. 
I don't have a strong feeling about this. I am just emphasizing the 
difference between other protocols and XMPP in this case.

A security person should comment on this.

> > 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:
> > ...
> >
> > (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.
This is fine. I was just thinking about a base64 encoder that enforces a 
line length limit and will insert CRLF automatically.

> > 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.
>  
Challenge format is specific to a SASL mechanism. As far as the protocol 
using SASL is concerned, invalid SASL mechanism format is not different 
from "authentication failure".
An error from a SASL mechanism is different from an error resulting in 
inability to decode base64 data.
These errors happen at different layers, so they should have different 
error tags.

Regards,
Alexey
__________________________________________
Isode Limited, http://www.isode.com

Cell: +44 7753759732

IETF standard related pages:
http://orthanc.ab.ca/mel/devel/Links.html

Personal Home Page: http://orthanc.ab.ca/mel
__________________________________________