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

[Ken Murchison]

Charles Lindsey wrote:

> Various thought on the draft (this is my first detailed encounter with
> SASL, so some of my remarks may be way off target).
> 
> 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.
> 
> d) It MAY then deconfigure the default whereby USER/PASS is switched off.
> 
> 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).

If the server wishes to serve USER/PASS w/o TLS for its migration 
period, then it obviously won't respond with 483.

It doesn't list 483 because its a generic response defined in 
[NNTP-BASE].  Based on Clive's comments, we're probably going to remove 
the other generic responses.

> 
> f) It is now under a moral obligation to educate its clients to use at
> least DIGEST-MD5. When (and if) it succeeds in that endeavour, it should
> undeconfigure the aforementioned default.
> 
> Is that all OK?

Yes, I think you understand it perfectly.


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

I can't answer that.  *If* we do need to document it, it would be for 
legacy purposes only.  Actually, isn't its documentation in 
[NNTP-COMMON] good enough?


> 
> 
> 3. I see that the SASL exchanges consist of long streams of BASE64
> characters, which may easily exceed 512 charactyers in length; and it is
> proposed to send these as a single line.

Its proposed this way because every other SASL profile for messaging 
that I'm aware of sends them as single lines (SMTP, POP3, IMAP).  Since 
NNTP is syntactically equivalent to SMTP+POP3, I see no reason why 
NNTP's SASL profile should be any different that the other two.

> Would it not be better to send them (in both directions) as multiline
> responses (terminated by CFLF.CRLF)? I see that no whitespace character is
> meaningful within BASE64, and other protocols that use BASE64 (e.g. PGP)
> allow splitting of long lines in this way. This makes it much easier to
> handle them (e.g. for cutting and pasting) when they need to appear in
> editing or terminal emulation windows,

Using multi-line would probably work, but [NNTP-BASE] doesn't limit the 
length of single line responses, so I don't understand why we need to 
change this.

I've never had any problem cutting and pasting them in an xterm or Win32 
  telnet window.

> 
> 4. Which brings me to my major gripe.
> 
> Currently, it is very easy and convenient, if you want to interact with
> some NNTP server in some manner not provided by your newsreader, to telnet
> to port 119 on your server and issue specific commands for what you want
> (e.g. to find whether some group is available, or how many articles are in
> it, or to retrieve some specific article for which you happen to have the
> message-id). If the server wants you to authinticate yourself first, then
> typing in your username and password is easy.
> 
> Now under SASL this is going to be an absolute pain. For sure, reading a
> challenge in BASE64 and responding to it in BASE64 is a theoretical
> possibility, but not one I would like to undertake :-( . So the best I can
> think of is to have some separate SASL utility running in a separate
> window and to cut and paste the BASE64 strings to and from my telnet
> (hence the interest in having the BASE64 split into manageable lines as
> mentioned above). Or maybe someone will write a telnet-like application
> that can perform these SASL interactions on demand.
> 
> So do such telnet-like applications or such separate SASL utilities
> exist, and how do people currently manage when telnetting to port 25 in
> order to interact manually with some SMTP server (e.g. to see why it is
> rejecting some particular RCPT)?

Cyrus IMAP has a utility which does SASL authentication and TLS for all 
the protocols that it uses (6?), one of which is NNTP.  I use it for 
testing the NNTP server that I wrote for Cyrus and I'm currently using 
it for the SASL implementation I'm writing for INN.

The Cyrus SASL library includes a sample client/server implementation in 
which you cut and paste the exchanges from one to the other.  It also 
includes an smtptest client which performs SASL auth.

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

I have no argument either way.  Actually, "nntp" would seem to make the 
most sense.


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

Any SASL protocol profile (which this draft is) is intended be be read 
along with RFC 2222 (or RFC 2222bis), which describes these concepts 
along with initial response processing, server success data, etc.


> In USEFOR terms, this would mean putting it in some suitable field of the
> Injection-Info header (most likely the posting-account-parameter) - again
> modulo privacy concerns which are already discussed in USEFOR.
> 
> So maybe I ought to take this to the USEFOR group to see whether the
> posting-account-parameter is the proper one, or whether some
> "sasl-identity-parameter" should be invented for the purpose. But first I
> need to check whether I have understood correctly what the draft is
> proposing.

I tend to agree that the authorization id might make the most sense, but 
I could see uses for both.  This is probably something that needs 
discussion by the group.

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