RE: [Ipsec] Clarification on EAP MSK usage in IKEv2

[<Pasi.Eronen@xxxxxxxxx>]

Lakshminath Dondeti wrote:
> I am curious about the security implications here.  Let's dig a bit 
> further.  From the first IKEv2-EAP exchange, the Responder would have 
> received an MSK and a lifetime.  The EAP keying draft says the 
> following about that lifetime:
> 
>       IKEv2 as specified in [RFC4306] does not cache EAP keying
>       material or parameters; once IKEv2 authentication completes it
>       is assumed that EAP keying material and parameters are
>       discarded.  The Session-Timeout attribute is therefore
>       interpreted as a limit on the VPN session time, rather than an
>       indication of the MSK key lifetime.
> 
> I am sure saving the MSK for re-use as a PSK makes sense, if the VPN 
> session happens to drop due to non-security reasons and the two 
> parties need to authenticate each other.  What security issues do you 
> see here, Pasi?  I can think of some, but the lifetime parameter is 
> very effective here.  As long as the resultant IPsec SAs are deleted 
> by the IPsec GW pursuant to the Session-Timeout rules, I don't see a 
> problem.  Sure, we need further specification (and an edit of the 
> eap-keying draft), but that can be done.

We don't necessarily need an edit for the eap-keying draft, because it
is correct: IKEv2 as specified in [RFC4306] doesn't cache the MSK.  An
extension to IKEv2 (not part of RFC4306) could to it, though.

The extension would need to specify e.g. how to indicate in IKEv2 that
you want to re-use the same MSK, identify the right MSK (which just
username doesn't do), handle lifetime issues (the initiator doesn't
know what the Session-Timeout attribute was), ensure that single MSK
is used only with single PRF algorithm, and so on.

I also agree that all this can be done; whether it should be done is a
somewhat different question (e.g., as for any optimization, are the
benefits worth the added complexity?).

Best regards,
Pasi

_______________________________________________
Ipsec mailing list
Ipsec@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ipsec