[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Secure legacy authentication for IKEv2

At 7:18 PM -0500 12/20/02, David Jablon wrote:
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.

that approach complicates the analysis of the security provided by the system, not a path that this WG is likely to find appealing in this era of simplicity.


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

We need to be able to make statement about the security of the key material used for packet confidentiality and packet integrity irrespective of the peer authentication mechanism chosen. To do otherwise would unduly complicate the overall system. That's why the current separation is desirable.

Steve