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

[Charles Lindsey]

In <ylznrdixy1.fsf at windlord.stanford.edu> Russ Allbery <rra at stanford.edu> writes:

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

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

>Depends on who you mean by "we."

I mean whatever we write, or might write, into an NNTP standard.

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

I am surprised that NNTP servers should think it necessary to engage in
chained authentication, but if they do then that is their problem and I
don't think any NNTP standard wants to know about it (though it must
clearly not hinder it).


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

Looks like an important feature missing from SASL.


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

Yes, a Diffie-Helleman key exchange, for example. A bit of a sledgehammer
just to encode a password (or maybe to encode a longish handshake) but
that is what is needed. For sure one doesn't want to encrypt the rest of
the session, though I suppose NNTP over ssh could be made to work if one
applied one's mind to it.

So how much resources would a Diffie-Helleman exchange consume? I am not
impressed by the stories I hear of the time taken by an ssh handshake.

And is anybody working on such a beast to fit within the SASL framework as
a plugin replacement for PLAIN?

-- 
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 clw.cs.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