[ietf-nntp] Re: SASL exchanges

[Russ Allbery]

Ken Murchison <ken at oceana.com> writes:
> 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:

I agree.  I think it's a bad idea.  They should be returned as single
lines, and clients are going to have to be recoded to be able to handle
that.

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

It's because of limitations in existing implementations.  A lot of people
allocate a buffer of NNTP_STRLEN and then just use it for everything.

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

Thank you very much for that, btw.  I hope to be able to look at it fairly
soon.  I wanted to catch up here first, though.

-- 
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>