ietf-nntp AUTHINFO SASL protocol choices

Charles Lindsey chl at clw.cs.man.ac.uk
Tue Apr 2 03:54:22 PST 2002


In <Pine.LNX.4.33.0203302127330.24120-100000 at marduk.litech.org> "Jeffrey M. Vinocur" <jeff at litech.org> writes:

>1.  Do we want to instruct/permit servers to limit the amount of data
>    sent in this fashion?  (Chris is concerned with denial of service,
>    as the clients are completely unauthenticated at this point; we
>    certainly can't expect servers to buffer an arbitrary amount of
>    data from anybody who opens a connection.  If we don't address
>    the issue here, we'll have to expect programmers to hardcode some
>    limit and just close the connection, I think.)

If a server sees a command line longer than it cares to handle (512 or
whatever) then I suppose it can ignore the excess and return a suitable
5xx response, giving the client an opportunity to try a more sensible
approach. Or else it can drop the connection (I think it is the server's
choice). But if the server receives more than it cares to accept during a
multiline command, then dropping the connection is its only real option
(it is no different than when the client tries to POST a 200MB article
which exceeds whatever limit the server accepts).

>    It sounds like the SASL spec will put a hard limit on this, which
>    is great.  Then for AUTHINFO SASL we just have to decide what the
>    appropriate action when that limit (with base64 expansion) is
>    reached.

Then one hopes it will be a smallish limit. If you can do an unforgeable
PGP signature in 1024 octets, then it should not be beyond the wit of man
to devise a satisfactory SASL negotiation in a similar amount.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: chl at clw.cs.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5



More information about the ietf-nntp mailing list