[ietf-nntp] I-D ACTION:draft-ietf-nntpext-authinfo-00.txt

[Russ Allbery]

Charles Lindsey <chl at clerew.man.ac.uk> writes:

> 1. Interim arrangements.

> Currently, use of AUTHINFO USER/PASS in the clear is widespread, and is
> likely to continue for some time. Is the following understanding
> correct?

> a) A server wishes to continue accepting USER/PASS in the clear during
> some (longish) changeover period.

> b) It does not intend to implement STARTTLS *ever* (on the grounds that
> it is only serving publicly available Usenet articles, and so encrypting
> the whole stream is a waste of time).

> c) Therefore, it MUST provide at least the DIGEST-MD5 SASL method so
> that its clients have _something_ to migrate to.

Right.

> d) It MAY then deconfigure the default whereby USER/PASS is switched off.

Sure.

> e) This then enables it to respond with 381/281/482/502 in the usual
> way.  Without that deconfiguration it would have been obliged to respond
> with 483 regardless (BTW, why is 483 not listed as a response in 2.1.1).

Unless it needs to support legacy clients, yes.  There's an exception in
there for legacy support.

> 2. I see no mention of "AUTHINFO SIMPLE username password" which some
> servers (e.g. uni-berlin) offer. Is that commonly used or not?

It's not commonly used and it doesn't really offer anything useful over
USER/PASS.  I think we can leave NNTP-COMMON as sufficient for that one.

> 5. Perhaps the service name for this SASL profile should be "netnews",
> rather than "news".

It should be "nntp".

> 6. I have tried reading the new SASL draft, and find it moderately
> confusing, especially as to the distinction between "authentication
> identity" and "authorization identity". My impression is that the first
> is who the user "is" and the second is "who the user want to be seen
> as", and that they are usually the same except when doing strange proxy
> things. Is that more or less correct?

That's correct except for describing the proxy things as strange.  It's
fairly typical, in servers with real authentication mechanisms (which NNTP
is about to become), to have a concept of a login account with an ACL that
contains multiple authentication identities.  For example, it's routine
for professors at Stanford to give their secretaries access to read their
e-mail, while authenticating, with GSSAPI, as themselves.

So, for Professor White (white at example.edu) and his secretary, Mr. Green
(green at example.edu), if Mr. Green reads his e-mail for him, the
authentication identity would be green at example.edu and the authorization
identity would be white at example.edu.

> Anyway, I see that both are used in section 3 of the proposed draft. In
> particular, when the server is acting as an injecting agent (POST
> command), it is encouraged to include the "authentication identity" (why
> not the "authorization identity") in some suitable header in the article
> (modulo some privacy concerns that are mentioned).

Or in a log.

The authentication identity is generally considered to be closer to the
person and therefore better identification.  You can think of the
authentication identity as the person and the authorization identity as
the role.

Of course, ideally you log both.

-- 
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>