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

[Charles Lindsey]

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

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?


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


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.

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,


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


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


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

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.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: chl at clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5