draft-ietf-nntpext-base-03.txt some comments

[Chris Newman]

On Thu, 22 Jan 1998, Chris Lewis wrote:
> I'm probably missing something, but I'm not sure that requiring SASL
> mechanisms makes any difference here, unless SASL lists all
> authentication mechanisms. 

All SASL does is say what the Authenticate command in a protocol has to
look like and add a few requirements for authentication mechanisms.  SASL
authentication mechanisms have a particular structure (basically an
exchange of opaque singleton blobs sent between client and server until
done, with a defined format for a simple security layer if the mechanism
activates one). 

Designing good authentcation mechanisms is hard work.  If every protocol
has its own custom way of authenticating then each mechanism has to be
individually profiled for each protocol.  That's a lot of wasted effort.
SASL allows all application protocols to share a common set of
authentication mechanisms.  If I design a mechanism for IMAP, it can
automatically be used for POP, ACAP, LDAPv3 and other SASL-enabled
protocols.  This way the community effort is shared and the authentication
mechanisms are protocol independent.

Look at what's happened to Telnet and HTTP with their custom
authentication frameworks.  Telnet's framework is almost exclusively used
for Kerberos V4 since that's the only published mechanism after four
years.  HTTP 1.1's framework has been ignored and plaintext passphrases
are still used to authenticate (usually unprotected or under a
"protection" level breakable by the average CS student).

Meanwhile, there are 6 standards track SASL mechanisms, a couple with
multiple interoperable implementations demonstrated.  Both Netscape and 
Microsoft are using SASL for authentication in IMAP, POP and SMTP.  They'd
like to share the code with their NNTP code I suspect.

> I remember having this thought when I looked at SASL in this connection long
> ago.  Could you provide me a URL to the full spec?  Diffs for the NNTP draft
> won't indicate why this is necessary.

The SASL Proposed Standard is: <ftp://ds.internic.net/rfc/rfc2222.txt>

> > In addition, if you fail to REQUIRE implementation of a non-plaintext
> > authentication mechanism, you will get an LDAPv3-style disclaimer (see
> > IESG Note in RFC 2251).  Personally, I don't want a news standard which
> > includes an IESG warning that POST and IHAVE won't interoperate!
> 
> I'm not sure what you're getting here.  Won't interoperate with what?  The
> intent behind AUTHINFO GENERIC is that the person inventing a custom
> authentication mechanism has to supply the hook for the client.

If you pick out a random client implementation and a random server
implementation, they should be able to use all mandatory to implement
services in a protocol -- otherwise the protocol spec is broken.  If there
is any service which needs security then they have to have an
authentication mechanism in common, or they don't interoperate. 

So the IESG requires that new protocols include a mandatory to implement
authentication mechanism better than plaintext passwords.  The LDAPv3 IESG
warning states:

   Readers are hereby warned that until mandatory authentication
   mechanisms are standardized, clients and servers written according to
   this specification which make use of update functionality are
   UNLIKELY TO INTEROPERATE, or MAY INTEROPERATE ONLY IF AUTHENTICATION
   IS REDUCED TO AN UNACCEPTABLY WEAK LEVEL.
 
   Implementors are hereby discouraged from deploying LDAPv3 clients or
   servers which implement the update functionality, until a Proposed
   Standard for mandatory authentication in LDAPv3 has been approved and
   published as an RFC.

> I'd much rather see something that specifies how to encrypt the whole NNTP
> session, which protects the authentication as well, rather than an ad-hoc
> glue-in that only applies to authentication.  In which case, we'd probably
> want to standardize on snews:// (which is NNTP over SSL, no?)

Some SASL mechanisms, such as Kerberos include encryption for the
remainder of the session.  SASL makes this easy to specify.

Note that TLS (formerly known as SSL) is not really an authentication
mechanism, so it doesn't belong in the AUTHINFO command.  In fact, TLS
client certificates are rarely used in my experience -- most people use
TLS and a plaintext password.  If you want a full service SSL-like
encryption layer, then define a STARTTLS command like:
  <ftp://ds.internic.net/internet-drafts/draft-newman-tls-imappop-0?.txt>

I'm not convinced requiring all NNTP clients and servers to implement TLS
and the TLS_DHE_DSS_3DES_EDE_CBC_SHA cipher suite is a good idea.  That's
an awful lot of very complex code and can add several seconds to the
connection establishment time.  (It's also not exportable from the US, but
that's not a legitimate technical reason to avoid making it mandatory).

BTW, I wasn't aware there was already ad-hoc usage of AUTHINFO GENERIC.
It might be better to document it as an non-interoperable legacy practice
and replace it with an AUTHINFO SASL command.

		- Chris