ietf-nntp Re: WG Review: Simple Authentication and Security Layer (sasl)

[Russ Allbery]

Charles Lindsey <chl at clw.cs.man.ac.uk> writes:
> Ken Murchison <ken at oceana.com> writes:

>> Yes, this is a well known problem with infrastrctures which are based
>> around a plaintext methodology.  I guess your alternatives are to
>> switch to something like Kereberos or try resurrecting Newman's DSS
>> effort (or something similar) ietf-sasl.  If the WG likes the idea,
>> I'll volunteer to write the plugin for CMU SASL.

> Then why are we basing anything around a plaintext methodology?

Depends on who you mean by "we."

The reason why someone in Andrew's position is stuck with plaintext
passwords is that only plaintext passwords are portable to arbitrary
external authentication domains that one has no control over.  And in
particular, if you want to authenticate against a RADIUS server, you need
the plaintext password.  That's how the RADIUS protocol works.

(The password isn't sent plaintext to the RADIUS server, but you have to
have the password in order to form the message that is.)

This is a specific instance of the generalized problem of chained
authentication, on which there has been some work but no really good
solutions that cross authentication domains.  Many of the standard
security protocols are based around authentication to a service with which
one shares a secret.  In the chained case, one is attempting to
authenticate to a service with which one does *not* share a secret, but
which trusts a source of authentication data with which the end user
shares a secret; in other words, an additional middleman is introduced.

Kerberos can do this, but only if the user, the service, and the
authentication server are all in the same Kerberos realm (or, more
accurately, only if the user's realm and the service's realm have shared
trust; you can do this with cross-realm authentication).  In Andrew's
case, though, Kerberos is a non-starter because the ISPs by and large
aren't running Kerberos.

RADIUS is an example of a protocol that simply cannot handle chained
authentication.  So are many of the standard SASL protocols.

> My ignorance of SASL is profound, but I had always assumed that it
> incorporated a mechanism whereby the server could confirm that the
> client knew a secret without actually passing that secret in
> plaintext.

SASL itself doesn't.  SASL is solely a mechanism for negotiating and then
encapsulating an authentication interchange with a client.  The properties
of that authentication interchange are left entirely to the discretion of
the SASL mechanism.

Nothing about SASL itself either helps or hurts what Andrew wants to do.
The problem that Andrew is encountering is that the only existing SASL
mechanism capable of doing chained authentication to a RADIUS server is
PLAIN, which obviously is not recommended over an unencrypted channel.

> Maybe it stores it itself (it should know who its paying customers are)
> or maybe it outsources it, but why should NNTP care about that part of
> it?

NNTP shouldn't be involved, IMO; this is a problem that can be solved with
a new SASL mechanism that encrypts the password but still sends it to the
server so that the server can use it to authenticate to other external
authentication servers, without requiring that the entire session be
encrypted.

(Presumably such a mechanism would use some sort of public key approach so
that the client and the server don't have to share a secret.)

If you want to read more information than you ever wanted to see about
this problem, do a Google search for Shibboleth.  This is the sort of
stuff I work on as part of my day job.  :)

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