[NNTP] draft-ietf-nntpext-authinfo-04

[Ken Murchison]

Russ Allbery wrote:

> Ken Murchison <ken at oceana.com> writes:
> 
> 
>>Ugh!  You're right, and I think that we *do* want to allow the
>>extensions to change after auth.
> 
> 
> Okay.  I'm ambivalent on that.  :)
> 
> 
>>I'll go ahead and add wording similar to Clive's, but I'll note that
>>continuing to advertise AUTHINFO SASL: is only required id a security
>>layer is in place.  Any thoughts on whether we should continue to
>>advertise AUTHINFO USER in this case?  (For the record, I don't see the
>>point).
> 
> 
> I don't really care one way or the other.  I agree that there's no real
> point in doing so.

Here's what I've come up with.  I realize its not perfect, so I'm open 
to any wordsmithing.


*** nntpauth.ms.~1.54.~	2004-09-30 11:05:28.000000000 -0400
--- nntpauth.ms	2004-09-30 11:50:21.000000000 -0400
***************
*** 279,309 ****
   that a resource is unavailable now but may become available after
   authentication).

- After a successful authentication, the client may retry the original
- command (if any) to which the server replied with the 480 response, or
- continue with some other command (for example, the client may wish to
- re-fetch the list of newsgroups).
-
   A server MUST NOT under any circumstances reply to an AUTHINFO command
   with a 480 response.

! After an AUTHINFO command has been successfully completed, no more
! AUTHINFO commands may be issued in the same session and a server MUST
! reject any further AUTHINFO commands with a 502 response.
!
! In agreement with [SASL], after a security layer is established the
! server MUST continue to advertise the AUTHINFO capability and "SASL:"
! argument with the same mechanism list as before authentication.
!
! Note that a successful AUTHINFO command may cause the output of the LIST
! EXTENSIONS command to change.  Any successful authentication MAY
! result in the server listing different arguments (perhaps listing zero
! arguments) for AUTHINFO, but MUST NOT result in the AUTHINFO
! capability being removed entirely from LIST EXTENSIONS (as this might
! falsely indicate to clients that they were dealing with a
! non-compliant server).  Additionally, after a successful AUTHINFO
! SASL, the SASL: capability MUST continue to be advertised as described
! in section 2.4.2.
   .LP
   .ne 3
   2.3. AUTHINFO USER/PASS Command
--- 279,308 ----
   that a resource is unavailable now but may become available after
   authentication).

   A server MUST NOT under any circumstances reply to an AUTHINFO command
   with a 480 response.

! After a successful authentication, the client MUST NOT issue another
! AUTHINFO command in the same session and a server MUST reject any
! further AUTHINFO commands with a 502 response.  The client SHOULD send
! a LIST EXTENSIONS command as the first command after a successful
! authentication.
!
! The extensions returned in response to a LIST EXTENSIONS command
! received after authentication MAY be different that the list returned
! before authentication.  For example an NNTP server may not to
! advertise support for a specific extension unless a client has been
! authenticated.
!
! A server MUST NOT return the AUTHINFO extension label in response to a
! LIST EXTENSIONS command received after authentication (since no
! further AUTHINFO commands may be issued), unless a SASL security layer
! was negotiated as part of the authentication.  Per [SASL], if a security
! layer has been established the server MUST continue to advertise the
! AUTHINFO extension label and SASL: argument with the same mechanism
! list as before authentication so that the client may be able to detect
! a possible active down-negotiation attack (note that clients still
! MUST NOT issue further AUTHINFO commands).
   .LP
   .ne 3
   2.3. AUTHINFO USER/PASS Command


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