Re: [IPsec] Beginning the PAKE selection process

[Nicolas Williams <[e-mail]>]

On Mon, May 24, 2010 at 04:41:59PM -0700, Dan Harkins wrote:
>   We discussed this in the WG. The non-PKIX authentication mechanism
> using EAP entails pointless encapsulation, twice as many messages,
> unnecessary code bloat from implementation of both client and server
> EAP state machines (where it had been the case, in RFC 4306, that an
> implementation only needed to do one), and the introduction of problems
> that didn't use to exist (like the "lying NAS" problem). The WG added
> this work item for a very good reason.

Allow me to quote myself:

> On Mon, May 24, 2010 2:54 pm, Nicolas Williams wrote:
> > Personally I'd much rather that the WG add non-PKIX authentication
> > mechanism options to IKEv2 via existing frameworks: either EAP or the
> > GSS-API.

I didn't say it has to be EAP; I named an alternative.  The GSS-API is
far, far simpler.  For an example see SCRAM (draft-ietf-sasl-scram)
(specifically see the section on SCRAM as a GSS-API mechanism).  (Plus
a GSS->EAP mechanism bridge is certainly feasible as well.)

For your mechanism it'd be even simpler because you'd not be trying to
describe in two different ways at the same time.  SCRAM was designed as
both, a GSS-API mechanism, and as a SASL mechanism that is functionally
equivalent to SCRAM-the-GSS-API- mech-used-as-a-SASL-"GS2"-mech ("GS2"
is a framework for adapting GSS-API mechanisms as SASL mechanisms).

Of course, I'd also point out that SCRAM is the way it is precisely
because we had two camps: one that thought the GSS-API overly complex
and one that thought it pointless to define SCRAM as a SASL mechanism
but not as a GSS-API mechanism.  We found a very happy medium by
constructing a GSS->SASL mechanism bridge that was simple, added no
round-trips and which allowed us to describe SCRAM in two equivalent
ways.  You might find the same is possible here, both with regard to EAP
and with regard to the GSS-API.

You might also find our logic in the SASL WG appealing here as well:
surely you want your mechanism to be useable in more than just this one
context (IKEv2)!, and surely you don't want to have to define new
bindings for it to every application protocol!  By defining your
mechanism as a GSS-API mechanism, for example, you'd get support for the
same mechanism in SSHv2, NFSv4, etcetera, almost for free.

>   So how do you think the work item should be solved given that the WG
> already decided to solve it? What do you think of my draft?

I've not read it yet.  I don't think it'd make much difference to the
matter at hand.

Nico
--