Re: [IPsec] Proposal for the secure password authentication method problem

[Nico Williams <[e-mail]>]

On Tue, Apr 12, 2011 at 8:29 AM, Yoav Nir <[e-mail]> wrote:
> I have mixed feelings about this. It's better than all four of those drafts advancing separately. OTOH this plug-innable architecture is pretty much admitting defeat. It sets us up to have a situation like EAP, with lots of different methods, and no guide to implementers as to which methods to implement.

Plugin architecture != no guidance as to required to implement
mechanisms/methods.  Besides, one of the nice things about plugin
architectures is that third parties can fill in voids when specific
methods/mechanisms go unimplemented.

> But I guess it's the lesser evil.

I don't get the hostility to pluggable authentication architectures.
Why on Earth should any of us dictate to users what kinds of
authentication infrastructures they must have?

For far too long we've had too many protocols with completely disjoint
authentication technology support, leading to customers having to
deploy many authentication infrastructures.  Some protocols only
handle PKIX well.  Others only handle Kerberos well.  Others only
handle AAA well.  Yet others have ad-hoc authentication systems.

Forcing customers to deploy multiple authentication infrastructures
means forcing them to setup expensive synchronization for expensive
systems that they shouldn't need.  How is that a good thing?

The *only* way to put a stop to this madness is to make all these
protocols pluggable.  Some of us have been trying to do so for a
while.  We have the following successes to point to:

 - SASL/GS2 -- a new bridge for using GSS-API mechanisms in SASL applications.
 - SSHv2 support for GSS-API-based authentication.
 - Channel binding (RFCs 5056 and 5929), which allows for composition
of security technologies.
 - IKEv2 and KINK (which altogether allow IPsec to support the use of
PKIX, Kerberos and EAP for end-point authentication).
 - ABFAB WG -- a WG working on standardizing an EAP-based,
federation-capable GSS-API mechanism.  I count this as a success
because ABFAB is quite far along.

Other work items in progress that should help round up this picture:

 - PKU2U (a PKIX-based GSS-API mechanism).
 - Additional GSS mechanisms being proposed at ABFAB and/or KITTEN
(there's a SAML-based one and an OAuth-based one).
 - draft-williams-tls-sasl-opt.

We have quite a few protocols that support SASL or the GSS-API straight out:

 - SASL application protocols: LDAP, IMAP, SMTP/SUBMIT, ...
 - GSS application protocols: RPCSEC_GSS/NFSv4, DNS (GSS-TSIG), SSHv2, FTP, ...

We also have protocols that only support PKIX well and everything else
in a half-hearted way, if at all (TLS, I'm looking at you).

Please, let's put an end to the madness and adopt a pluggable approach
to authentication (being careful to ensure channel binding to the
actual security layers whenever the authentication facility's security
layers are not used or when it lacks them).

Nico

PS: "Security layer" is a term from SASL meaning "the layer that
provides integrity and, optionally, confidentiality protection to
application data.