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

From: rra at stanford.edu (Russ Allbery)
Date: Fri Oct 1 11:28:04 2004

Ken Murchison <[email-masked]> writes:

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

This text looks great to me.

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

---

From: clive at demon.net (Clive D.W. Feather)
Date: Mon Oct 4 02:49:26 2004

Ken Murchison said:
>> 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.
> 
> 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?

Well, if this defence works at all it might work for other mechanisms than
SASL. So better to keep the line the same rather than just show the SASL
stuff.

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

I think there are benefits in retaining the text I proposed.

-- 
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: clive at demon.net (Clive D.W. Feather)
Date: Mon Oct 4 02:49:53 2004

Ken Murchison said:
> 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)."

That's fine with me.

---

From: clive at demon.net (Clive D.W. Feather)
Date: Mon Oct 4 02:53:42 2004

Russ Allbery said:
> Removing it entirely would imply that LIST EXTENSIONS should not change
> following a successful AUTHINFO command, yes?

No, it says nothing either way.

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

I disagree violently.

The description of LIST EXTENSIONS talks about the list altering as
internal state changes. For example, if a command

    is only available before or after a MODE READER command, the LIST
    EXTENSIONS command MUST only include the extension in that situation.

Note that "MUST".

A server might not want to advertise a private capability to clients that
haven't authenticated themselves, and it seems more than reasonable that
they should be allowed not to do so.

---

From: clive at demon.net (Clive D.W. Feather)
Date: Mon Oct 4 02:58:15 2004

> SASL. So better to keep the line the same rather than just show the SASL

Let me clarify my point.

Suppose somebody invents an authentication and security mechanism based on
PGP rather than SASL. We might then see:

    AUTHINFO USER SASL:CRAM-MD5,GSSAPI PGP:SHA-1,WEB-OF-TRUST,3DES

(never mind what this means for now). The argument about detecting a
down-negotiation attack applies equally well here, so we'd want this
capability to be shown as well.

So simplest just to require the line to stay the same as before
authentication in all situations. If we're going to change it at all, let's
add the "not available" flag I mentioned before.

---

From: rra at stanford.edu (Russ Allbery)
Date: Mon Oct 4 12:35:44 2004

> A server might not want to advertise a private capability to clients
> that haven't authenticated themselves, and it seems more than reasonable
> that they should be allowed not to do so.

Yeah, never mind.  That was a bad idea on my part.