[Top] [All Lists]

Re: line lengths for AUTH

2006-12-11 05:56:06

--On Monday, 11 December, 2006 10:07 +0000 Alexey Melnikov
<alexey(_dot_)melnikov(_at_)isode(_dot_)com> wrote:

Arnt Gulbrandsen wrote:

Alexey Melnikov writes:

It is, but I would rather avoid specifying any limit in the
document,  because it is likely to be exceeded in the future.

If it's big enough, I'm sure you can say "may be exceeded,
although  unlikely".

But I guess the document can specify an absolute minimum and
allow  implementations to support bigger line lengths.

Isn't that what RFC 1869 section 4.1.2 does?

I would like to see text saying something like "no
implementations are  known to support line lengths greater
than 12288

That is not true, Isode's implementation allows for 98304 :-)

and it is thought unlikely that any SASL mechanisms will ever
require  longer line lengths".

I've just reread the text already in the document:

          Note that these [BASE64] strings can be much longer
          normal SMTP commands.  Clients and servers MUST be
able to
          handle the maximum encoded size of challenges and
          generated by their supported authentication
mechanisms.  This
          requirement is independent of any line length
limitations the
          client or server may have in other parts of its

and I think it is good enough. If an implementation only
supports CRAM-MD5, there is no reason to have 12K buffer for
it, 1K would be sufficient.


This works for me iff,

(i) The description of every SASL method describes the maximum
length string that can be used.

(ii) We agree (presumably with the Security Area) that, when the
base SASL document is next revised, it contain an explicit
requirement that new SASL methods document the maximum possible
string length.

If people insist, I can add something like the following:

         At the time of writing of this document, 12288 is
considered to be
         sufficiently big line length limit for handling of
deployed authentication

I think this would be useful in addition to the above.  The
combination of a long history of SMTP implementations truncating
at some implementation-specific limit and, as others have
pointed out, attacks based on buffer overflows, make me very
uncomfortable about text that implies "try to make the buffer as
long as possible (or as long as you think sensible)".



<Prev in Thread] Current Thread [Next in Thread>