[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