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

From: ken at oceana.com (Ken Murchison)
Date: Tue Sep 28 13:17:48 2004

I just submitted the -04 revision of AUTHINFO which can be previewed here:

http://www.oceana.com/ftp/drafts/draft-ietf-nntpext-authinfo-04.txt

I *think* this draft addresses all of the issues discussed on the list. 
  The cryptic list of changes from -03 are:

revision 1.47
date: 2004/09/28 20:06:41;  author: ken;  state: Exp;  lines: +29 -31
- clarified AUTHINFO SASL: advertisement after successful SASL with
   security layer
- clarified description of zero length SASL challenge/response
----------------------------
revision 1.46
date: 2004/09/21 16:26:20;  author: ken;  state: Exp;  lines: +54 -47
- split text in section 2 into two sections describing AUTHINFO 
capability (2.1)  and AUTHINFO authentication (2.2)
- reworded deprecation of AUTHINFO GENERIC in section 2.4 (per Clives 
request)
----------------------------
revision 1.45
date: 2004/09/16 14:44:52;  author: ken;  state: Exp;  lines: +19 -17
nits from Clive
----------------------------

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

---

From: rra at stanford.edu (Russ Allbery)
Date: Tue Sep 28 13:25:38 2004

> http://www.oceana.com/ftp/drafts/draft-ietf-nntpext-authinfo-04.txt

Excellent!  Please, everyone, look this over and see if there are any
major issues left.  If no one objects, I will advance this to IETF Last
Call on Thursday or Friday.

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

---

From: clive at demon.net (Clive D.W. Feather)
Date: Wed Sep 29 01:23:21 2004

> Call on Thursday or Friday.

Not a major issue, but I don't think the last two paragraphs of 2.2
correctly reflect the discussions we've had.

Since you can only ever do one successful AUTHINFO, the capability isn't
available *at all* afterwards. Therefore the options are either:
* don't show AUTHINFO, matching reality
* show AUTHINFO, matching [SASL].
Since we've already agreed on the latter, let's require the entire AUTHINFO
capability to be the same as before authorisation - that way, if the
information *is* of use in detecting attacks, it's there.

So replace these two paragraphs with:

    Note that a successful AUTHINFO command MAY cause the output of
    the LIST EXTENSIONS command to change. However, the AUTHINFO
    capability MUST continue to be listed with the same arguments as
    immediately before the authentication, notwithstanding the fact
    that no further AUTHINFO commands may be issued (this is a superset
    of the recommendation in [SASL] and can help in detecting an active
    down-negotiation attack).

Possibly this can be merged with the previous paragraph ("After an AUTHINFO
command ... 502 response.").

[Note I've deleted the reference to 2.4.2; I can't see any need for it.]

2.4.2 "When both TLS ..."; I said in a previous message that this could be
re-read, and suggested other wording for it.

2.4.3 third and fourth examples: change "base64-encoded data is sent" to
"base64-encoded data is actually sent".

-- 
Clive D.W. Feather  | Work:  <[email-masked]>   | Tel:    +44 20 8495 6138
Internet Expert     | Home:  <[email-masked]>  | Fax:    +44 870 051 9937
Demon Internet      | WWW: http://www.davros.org | Mobile: +44 7973 377646
Thus plc            |                            |

---

From: ken at oceana.com (Ken Murchison)
Date: Wed Sep 29 07:15:52 2004

> information *is* of use in detecting attacks, it's there.

Actually, since this is a SASL-only issue I didn't feel that it made any 
sense to continue to list USER.  That being said, I won't argue strongly 
either way.  Opinions?

> [Note I've deleted the reference to 2.4.2; I can't see any need for it.]

Actually, I intended to remove the last paragraph entirely and 
apparently didn't.  Would removing it be sufficient, or do you still 
want to address this in some way?

> re-read, and suggested other wording for it.

Sorry, I missed that.  I just found and read your previous comments on 
this.  I agree with your text which further clarifies the ordering of 
the TLS and SASL security layers and I've added it.  As for your other 
point, I'm going to take this to a separate post.

> "base64-encoded data is actually sent".

Done.

---

From: ken at oceana.com (Ken Murchison)
Date: Wed Sep 29 07:44:10 2004

Ken Murchison wrote:

> the TLS and SASL security layers and I've added it.

Actually, I left the original wording (taken verbatim from RFC 2554bis 
and RFC 1734bis) which IMHO is pretty clear, but added my own parenthetical:

"When both TLS [NNTP-TLS] and SASL security layers are in effect, the
TLS encoding MUST be applied after the SASL encoding (the cleartext
data is always SASL encoded first and then the resultant data is TLS
encoded)."

---

From: rra at stanford.edu (Russ Allbery)
Date: Wed Sep 29 11:56:48 2004

>> Possibly this can be merged with the previous paragraph ("After an
>> AUTHINFO command ... 502 response.").

> want to address this in some way?

Removing it entirely would imply that LIST EXTENSIONS should not change
following a successful AUTHINFO command, yes?  That seems to fine to me; I
don't have any trouble requiring that even extensions only usable while
authenticated should be advertised in the unauthenticated state and just
return the appropriate error code if used unauthenticated.

---

From: ken at oceana.com (Ken Murchison)
Date: Wed Sep 29 12:19:37 2004

Russ Allbery wrote:

> following a successful AUTHINFO command, yes?

Ugh!  You're right, and I think that we *do* want to allow the 
extensions to change after auth.  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).

>  That seems to fine to me; I

---

From: rra at stanford.edu (Russ Allbery)
Date: Wed Sep 29 12:26:04 2004

Ken Murchison <[email-masked]> writes:

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

---

From: jeff at litech.org (Jeffrey M. Vinocur)
Date: Wed Sep 29 19:18:04 2004

On Sep 29, 2004, at 3:19 PM, Ken Murchison wrote:

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

One quick question -- are there any standalone encryption-via-SASL 
utilities, along the lines of stunnel for TLS?

(If so, I can contrive a case where somebody might want to use AUTHINFO 
USER after a SASL security layer is established.  For practical 
purposes, I think we can probably ignore this case.)

-- 
Jeffrey M. Vinocur
[email-masked]

---

From: rra at stanford.edu (Russ Allbery)
Date: Wed Sep 29 19:44:30 2004

> utilities, along the lines of stunnel for TLS?

There is something that comes with Cyrus that I think can do SASL
authentication and possibly also negotiate a privacy layer, but I believe
that it works similar to telnet in that you can escape out and tell it to
start at any point.  I've not used it personally, though.

> purposes, I think we can probably ignore this case.)

Yeah, I think so, since they really should have just used SASL
authentication at that point, plus that would constitute
re-authentication, which I believe we decided to punt on.

---

From: ken at oceana.com (Ken Murchison)
Date: Wed Sep 29 20:11:40 2004

> start at any point.  I've not used it personally, though.

Yes, Cyrus has an imtest utility which speaks all messages protocols and 
can handle both SASL and TLS.  The authentication piece is automatic 
other than asking for a password and you can't force it to do another 
authentication unless you do it by hand.

>>purposes, I think we can probably ignore this case.)

I don't understand how this would be useful other than trying to 
reauthenicate.

> re-authentication, which I believe we decided to punt on.

Are you under the assumption that you can get a SASL security layer 
*without* also authenticating?  That's certainly *not* the case.  A SASL 
exchange *always* performs an authentication and in the process 
optionally negotiates an integrity and/or privacy layer.  You can *not* 
get either of the latter without the former.

---

From: ken at oceana.com (Ken Murchison)
Date: Thu Sep 30 08:51:19 2004

> I don't really care one way or the other.  I agree that there's no real

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