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

Ken Murchison ken at oceana.com
Wed Dec 11 09:45:42 PST 2002


Charles Lindsey wrote:
> 
> 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).

I agree.  This is an implementation problem, not an NNTP/SASL problem.


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

Just to clarify, this isn't a problem with SASL.  The problem is with
Andrew's requirements and the lack of a documented/implemented SASL
mechanism which satifies those requirements.  SASL itself is not the
cause of the problem any more than AUTHINFO USER/PASS is.


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

Exactly.


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

No.  The only one close is the one that Jeff noted:
http://www.alternic.org/drafts/drafts-n-o/draft-newman-sasl-passdss-01.txt

If Jeff is still working with Chris on the NNTP security draft, maybe he
can ask him why this mechanism never moved forward.  My guess is because
of the presence of PLAIN and STARTTLS.

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



More information about the ietf-nntp mailing list