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

["Narayanan, Vidya" <vidyan@xxxxxxxxxxxx>]

Hi Pasi, Lakshminath, 

<snip>

> >
> >Currently, it makes no sense to cache the MSK, since RFC4306 
> does not 
> >include any functionality that would use it (e.g. 
> establishing another 
> >IKE_SA using the same MSK).
> >
> >So I guess you're asking that if someone would write an 
> Intenet- Draft 
> >"establishing multiple IKE_SAs without re-running EAP" (or 
> something), 
> >would that be an acceptable extension to RFC4306, or un unacceptable 
> >violation of the "MUST NOT be used..." requirement?
> >
> >That's a difficult question. I think such a draft could be 
> written in a 
> >way that would be reasonable secure (and would not be very long 
> >document, except maybe the security considerations text), but being 
> >somehow "secure" has not usually been a sufficient criterion 
> for being 
> >an acceptable use of EAP :-)
> 

I wonder what you mean by "reasonably secure" - I am not sure why using
the MSK for establishing muultiple IKE_SAs without re-running EAP would
be any less secure than the use of a PSK for the same purpose. If
anything, I expect the MSKs to be stronger (depending on the EAP method
used) and bound by lifetimes, making it more secure than a configured
PSK. 

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

I agree. Also, I don't see why this would not be an acceptable use of
EAP, since there are lower layers already that use the same MSK (without
re-running EAP) for multiple TSK generations (i.e., TSK re-keying can be
done today without re-running EAP). 

Vidya

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