ietf-nntp AUTHINFO SASL protocol choices

Mon Oct 21 10:57:29 PDT 2002

Trying to revive an old thread.  Hopefully this will get to the list,
since it appears to be dead from my end.

After just having implemented draft-newman-nntpext-auth-01 (Jeff's
option 5) in a NNTP server that I'm writing for Cyrus IMAP, I figured
that I'd offer my $.02.  I'm not sure how/why the discussion ever
deviated from Chris' original work, but I feel that this is the correct
way to implement AUTHINFO SASL.  For those who haven't seen it or can't
find it (its about 4 years old), here is the relevent text:

     AUTHINFO SASL mechanism [initial-response]

     The AUTHINFO SASL command permits NNTP clients to authenticate
     using SASL [SASL] mechanisms such as CRAM-MD5 [CRAM-MD5],
     KERBEROS_V4, GSSAPI or EXTERNAL.  This profile of SASL uses the
     service name "news" for Kerberos and GSSAPI mechanisms.

     If AUTHINFO is implemented, then AUTHINFO SASL and the DIGEST-MD5
     [DIGEST-MD5] mechanism MUST be implemented.  This is necessary to
     ensure that any two compliant clients and servers can be configured
     to authenticate without using unencrypted clear-text passwords.
     [NOTE:  CRAM-MD5 is an expedient alternative choice as it's already
     standards track.]

     The optional initial-response argument is a base64-encoded string
     of the initial client response for SASL mechanisms with no initial
     server challenge.

     The server MAY continue the authentication exchange with a 351
     response containing a base64-encoded server-challenge.  The client
     replies with a line containing a base64-encoded client-response
     followed by CRLF, or with a "*" followed by CRLF to cancel the
     exchange.  The server responds to "*" with a 501 response.

     The server indicates successful completion with either a 250
     success response, or a 251 success response which contains a
     base64-encoded token with final server challenge data.  The server
     indicates failure with a 452, 501, 503 error.

     If a security layer is negotiated, the server begins with the octet
     immediately after the CRLF at the end of a 250 or 251 success
     response, and the client begins with the octet immediately after
     the CRLF of the last client-response in the SASL exchange.  In
     addition, after a security layer is negotiated, the client SHOULD
     re-issue the LIST EXTENSIONS command to reduce the impact of active
     attacks prior to authentication.

It seems that most of the previous discussion in this thread has been
centered around the format of the command(s) and the line length(s). 
I'll address these points individually.

- Challenge/response data length.  Section 5, requirement #3 in
draft-myers-saslrev-02 already stipulates that a profile MUST be able to
support unencoded tokens of up to 16K octets.  When using base64
encoding (as NNTP will use), then this bumps the requirement up to
21848.  So like it or not, a buffer at least this large will be required
for the SASL exchanges.  Since (by my reading) neither RFC 977 nor
draft-ietf-nntpext-base-15 limit the length of data lines or server
responses, this shouldn't be an issue.  Note that this does NOT have to
impact the length of the AUTHINFO SASL command (see next point).

- Initial client response length.  Section 6.4 of draft-myers-saslrev-02
allows a profile to limit the length of the initial token in order to
meet the command line length restrictions of the underlying protocol. 
So, if the length of the initial response for the given mechanism will
cause the AUTHINFO SASL command to be too long, then it doesn't have to
be sent as an initial response (ie, the client can wait for the server
to ask for it).  This being said, I'm not sure that this will ever come
into play, since the current NNTP command line length of 512 allows an
initial client response of somewhere around 484 chars (+/- depending on
length of mechanism name).  No existing SASL mechanism that I'm aware of
has a first client response anywhere near that limit.

- Command syntax.  AUTHINFO SASL is a single command with special
semantics and should be treated that way.  Trying to use multiple
commands to execute a SASL exchange or trying to mold it to look like
other NNTP commands doesn't seem to make much sense to me.  If I had to
describe AUTHINFO SASL in terms of an existing NNTP command, I'd say
that it is very similar to POST/IHAVE with the caveat that instead of
sending all of the lines of the data (client responses) at once, the
server prompts for each line (with a challenge) individually.  And since
the server knows how many lines will be sent for a given mechanism, no
".\r\n" sequence is necessary.

I also believe that because of the close similarities between NNTP and
SMTP, that it would make sense for their respective SASL commands to be
similar.  SMTP AUTH has already been widely deployed using the syntax
that I'm endorsing (its very similar to IMAP and POP3 as well).  Also,
having similar syntax makes it a lot easier to have one parameterized
function perform the exchanges for multiple protocols (I have one
function in Cyrus to perform SASL for IMAP, POP3, LMTP and NNTP).

FWIW, here are some working examples against the Cyrus NNTP server where
the userid and password are both 'test'.  Note that any line breaks
between return code and challenge data are being done by the mail
client.

TLS connection established: TLSv1 with cipher DES-CBC3-SHA (168/168
bits)
S: 200 eagle.oceana.com Cyrus NNTP v2.2.prealpha server ready, posting
allowed
C: LIST EXTENSIONS
S: 202 Extensions supported:
S: AUTHINFO USER
S: SASL LOGIN ANONYMOUS SECURID SRP OTP DIGEST-MD5 CRAM-MD5 PLAIN NTLM
S: LISTGROUP
S: OVER
S: .
C: AUTHINFO SASL PLAIN dGVzdAB0ZXN0AHRlc3Q=
S: 250 Success (tls protection)

C: AUTHINFO SASL DIGEST-MD5
S: 351
bm9uY2U9InhyREw4UlR5SWJRa2FEV1lhVSt5R2NQVWUrUW5WaXJkKzd5dDk4L2lzbmM9IixyZWFsbT0iZWFnbGUub2NlYW5hLmNvbSIscW9wPSJhdXRoLGF1dGgtaW50LGF1dGgtY29uZiIsY2lwaGVyPSJyYzQtNDAscmM0LTU2LHJjNCxkZXMsM2RlcyIsbWF4YnVmPTQwOTYsY2hhcnNldD11dGYtOCxhbGdvcml0aG09bWQ1LXNlc3M=
C:
dXNlcm5hbWU9InRlc3QiLHJlYWxtPSJlYWdsZS5vY2VhbmEuY29tIixub25jZT0ieHJETDhSVHlJYlFrYURXWWFVK3lHY1BVZStRblZpcmQrN3l0OTgvaXNuYz0iLGNub25jZT0iTXF5UERiY2RzeUJseEtORzNpVUkyaFUveVBzODZMZU9pT3VydWZZdnNFbz0iLG5jPTAwMDAwMDAxLHFvcD1hdXRoLWNvbmYsY2lwaGVyPSJyYzQiLG1heGJ1Zj0xMDI0LGRpZ2VzdC11cmk9Im5udHAvZWFnbGUub2NlYW5hLmNvbSIscmVzcG9uc2U9YzM2NmUwYjRlMjU1ZjAxNjM0MWVhZmVhY2JlMmZmMjY=
S: 251 cnNwYXV0aD03Mzg4MzMxOGEyNTM3MGFiMzI5MGRkZDJhZjMwYTg2Mg==

C: AUTHINFO SASL SRP AAAADAAEdGVzdAAEdGVzdA==
S: 351
AAAB5wEArGvbQTJKmpvxZt5eE4lYL69ytmUZh+4H/DGSlD21YFCjcynLtKCZ7YGT4HV3Z6E91SMSq0sDMQ3Nf0ip2gT9UOgIOWntt2ewz2CVF5oWOrNmGgX71fqq6CkYqZYvC5O4Vfl5k+yXXuqoDXQK2/T/dHNZ0EHVwz6nHSgeRGsUdzvKl7Q6I/uAFna9IHpDbGSB8dK5B4cXRhpbnTLmiPh3SFRFI7UksNV9Xqd6J3XS7PoDLPvb9S+zeGFgJ5AE5Xrmr4dOcwPOUymczAQce8MI2CpWmPOo0MOCca41+Onb+7aUtcgD2J965DXeI21SX1R1m2XjcvzWjvIPpxEfnkr/cwABAhBkMDaFdh2JGCreC6e8dQW+AM9tZGE9UklQRU1ELTE2MCxyZXBsYXkgZGV0ZWN0aW9uLGludGVncml0eT1ITUFDLVNIQS0xLGludGVncml0eT1ITUFDLVJJUEVNRC0xNjAsaW50ZWdyaXR5PUhNQUMtTUQ1LGNvbmZpZGVudGlhbGl0eT1ERVMsY29uZmlkZW50aWFsaXR5PTNERVMsY29uZmlkZW50aWFsaXR5PUJsb3dmaXNoLGNvbmZpZGVudGlhbGl0eT1DQVNULTEyOCxtYXhidWZmZXJzaXplPTQwOTY=
C:
AAABZAEAayEaZu8smDv9XkPFpCrtVuqm4xgHtwXcbCdLrlt5Bx2H4tCXO7JCJ6VuhN/puwosByLj36ZVMzPN0mNWDduig20NvLA3oY9lOnWZUe2nmEY4kYu+hA7D2pC6kk7B1VDoYQzYBg4E30UHcwNsIXn98kNHf+Wu1D2i+YDdu3eHybFRXZTRD2ZJlTDnU4hNnQL9B2bVHjyP++SzW99O4et18MxyF/nrcfOkqxC7dQrDcpqvSFcTc6p40FXwpHui1tcgRN4ZQC+CJpXNRGAivGfc1a6UqRVuMkE7mfq8n+AHjlZcpQhgydRxp77ebak99qens/2H/u7KYcoez0PBkYWmMwBgbWRhPVJJUEVNRC0xNjAscmVwbGF5IGRldGVjdGlvbixpbnRlZ3JpdHk9SE1BQy1TSEEtMSxjb25maWRlbnRpYWxpdHk9Qmxvd2Zpc2gsbWF4YnVmZmVyc2l6ZT0xMDI0
S: 351
AAABAgEAB3JMSktfqF4wLr1gs//we+qh+TxRFbhFkRks79ZNOppyeLr5EftTEmXGdm9jOJfTKaSlCna31U2mWrEpSKVkpWnX4vVubmokMvGdF3i5yGPn7MRgxqPGqt6Zx4H4jbdUlGCxQHc92z9ZbPkerTyQmT5hIjr92oUg/bBQwQN8UVnOsCtgUcUjIyirLGbLuDRan9QiYmH70AOXAUgiHP7k6EdUllIApiWIxs7aexdU5yUXmhvoXFHLQJLPSnmd2aotyOCKpHZq1/1HbGN4yAmyX2WPIiMTjRhqldxsT57EC75TyWTcvlKDTjgzA+dMtIOjU6NmcwBqejzM1h2KyRXXtQ==
C: AAAAFRTBYPg0aw6V3DVwRLctTeNHscHOYg==
S: 250 Success (privacy protection)

C: AUTHINFO SASL NTLM TlRMTVNTUAABAAAAB4IAAAAAAAAgAAAAAAAAACAAAAA=
S: 351
TlRMTVNTUAACAAAAIAAgADAAAAAFggIA2anJ0cI8VZMAAAAAAAAAAAAAAAAAAAAARQBBAEcATABFAC4ATwBDAEUAQQBOAEEALgBDAE8ATQA=
C:
TlRMTVNTUAADAAAAGAAYAEAAAAAYABgAWAAAACAAIABwAAAACAAIAJAAAAAAAAAAmAAAAAAAAACYAAAABYIAABZ8a1f5rdyODhVEPgbYGf4AhKDZN1dhOl3XV1TsAwZ5hAJpbDMsR0FZgu6BTYWaBUUAQQBHAEwARQAuAE8AQwBFAEEATgBBAC4AQwBPAE0AdABlAHMAdAA=
S: 452 authentication failure

C: AUTHINFO SASL CRAM-MD5
S: 351 PDM2MDgzODQ5MzcuMTE4MTAxMzlAZWFnbGUub2NlYW5hLmNvbT4=
C: *
S: 501 Client canceled authentication

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