Re: Secure legacy authentication for IKEv2

[David Jablon <dpj@theworld.com>]

Regarding extensibility of SLA ...

>At 2:06 PM -0500 12/19/02, I wrote:
>>Perhaps "extensibility" should include the ability to take advantage
>>of keys generated by methods that use legacy credentials. [...]

At 05:39 PM 12/20/02 -0500, Stephen Kent wrote:
>Use of keys [in] what way? ...

A key generated by a client authentication method could be blended
with the presumably-server-authenticated DH key, say using a
standard key derivation function (HMAC-SHA, etc.), to produce a
resulting key with the qualities of both.

>... IKE v2 has introduced a clean separation of key material generation via DH exchange from authentication processes. I don't see how a legacy authentication system would contribute keys for IPsec, and I would rather not see it enter into the key generation process now that we have a clean  separation.

The "clean separation" to which you refer merely insures that the quality
of the initial DH key can *never* be improved or strengthened by the quality
of the client authentication method.  Got a password-authenticated key?
Just throw it away.  Yep, it's clean all right.

But it is awfully limiting, and does not seem in the best interests of security.
To mandate that any keying material generated by any method that
uses legacy credentials must discard such valuable material when
used with IKE v2 seems something more than just "clean".

I presume people mentioned EAP because it appears to be the
first IETF authentication framework to allow one to take advantage of
keying material derived from a legacy credential method.
Anyway, whether or not EAP is the right way to go for IPSEC, I was
wondering if other simple constructions might fit just fine.

-- David