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

[Tony Hansen <tony@att.com>]

White space and CRLFs were specifically allowed in the original MIME base64 
specification because of:

	line length limitations in the underlying protocols

	gateways that would add or subtract white space willy-nilly

	it was useful being able to work with base64 data in small chunks when
	doing development and debugging

The first two issues don't apply here, but the last one certainly still does.

So I'd recommend that whitespace and CRLFs be ignored.

	Tony Hansen
	tony@att.com

Alexey Melnikov wrote:
> 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
>
> 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.)