SASL exchanges (Was: [ietf-nntp] I-D ACTION:draft-ietf-nntpext-authinfo-00.txt)

[Ken Murchison]

Charles Lindsey wrote:

 > 3. I see that the SASL exchanges consist of long streams of BASE64
 > characters, which may easily exceed 512 charactyers in length; and it is
 > proposed to send these as a single line.
 >
 > Would it not be better to send them (in both directions) as multiline
 > responses (terminated by CFLF.CRLF)? I see that no whitespace 
character is
 > meaningful within BASE64, and other protocols that use BASE64 (e.g. PGP)
 > allow splitting of long lines in this way. This makes it much easier to
 > handle them (e.g. for cutting and pasting) when they need to appear in
 > editing or terminal emulation windows,


After thinking about this some more last night, I like this idea even 
less for several reasons:

1. [NNTP-BASE] only limits the length of client commands, not server 
responses, or intra-command data.  Do we really want an extension to 
limit itself in this regard?

2. The SASL exchanges are *single* blobs of data.  The multi-line format 
is currently used for article content, which typically consists of many 
CRLF separated lines, or for lists of items (which we separate with 
CRLF).  Use of the multi-line format to break up a *single* data blob 
into smaller pieces would be unprecedented in NNTP.

3. The SASL exchanges can be longer than 512 bytes, but they won't be 
*arbitrarily* large.  An upper limit can be determined based on the size 
of the largest blob used by any one mechanism.  Currently, I believe 
that the largest known SASL blob can be up to 16K (I don't recall which 
mech or if any blob actually reaches this limit).  If you include the 
base64 overhead, this works out to be 21848 bytes.  Any reasonable 
implementation should be able to handle this amount of data while 
processing the AUTHINFO SASL command.

4. POP3 and SMTP are very similar (if not almost identical) to NNTP in 
syntax, line length limits (255 and 512 respectively) and SASL profile 
and haven't experienced any major problems implementing SASL in either 
the client or server.  In fact Sendmail, like INN, is ancient code which 
was never designed with SASL in mind, but it was almost trivial to add 
SASL support.  I can't believe that existing NNTP implementations are so 
unique in their design that adding SASL support in the manner proposed 
would pose a hardship.

If the sole reason for breaking up the SASL blob is to make it more 
readable or to ease cut-n-paste, I don't think this is a compelling 
enough reason.  There are existing utilities (or a new one could be 
written) to help in this regard.

If one of the reasons for breaking up the SASL blob is to work around 
limitations in current NNTP implementations, I'd suggest that this is a 
new and different command, and it should be treated as such, not 
wedged/hacked into an existing framework.

FWIW, it only took me about 2 hours to get SASL authentication working 
in INN.  Most of my time was spent understanding the INN code and how it 
handles I/O.  It took me a little longer to get security layers working 
because I had to reorganize/consolidate a lot of the INN I/O code to 
make it easier to handle SASL security layers, TLS and plaintext data. 
Overall, I probably spent less than a day's worth of coding.  Granted, I 
was able to work quickly because of my knowledge of the Cyrus SASL 
library, but the bottom line is that any developer that has intimate 
knowledge of their own code should find no big technical hurdles 
implementing SASL if they follow the Cyrus SASL developer notes and 
sample code.  In fact, once my INN SASL code is complete and gets 
committed, it can be used as a reference implementation.

-- 
Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     21 Princeton Place
716-662-8973 x26      Orchard Park, NY 14127
--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp