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

[Lakshminath Dondeti <[e-mail]>]

At 01:15 AM 10/2/2006, Pasi Eronen wrote:
>Vidya Narayanan wrote:
> >
> > All,
> > RFC4306, in section 2.16, states:
> >
> > "For EAP methods that create a shared key as a side effect of
> > authentication, that shared key MUST be used by both the
> > initiator and responder to generate AUTH payloads in messages 7
> > and 8 using the syntax for shared secrets specified in section
> > 2.15.  The shared key from EAP is the field from the EAP
> > specification named MSK.  The shared key generated during an IKE
> > exchange MUST NOT be used for any other purpose."
> >
> > This seems to be a bit ambiguous in what constitutes "other
> > purposes".  For instance, let's consider two entities A & B
> > running IKEv2-EAP and establishing an IKE_SA between themselves,
> > using the MSK for authentication of the IKE_SA. If A & B were to
> > subsequently run IKEv2 again and establish another IKE_SA, could
> > the same MSK be then used for authentication here as well?
> >
> > In other words, it seems confusing whether "other purposes" also
> > means "for other IKEv2 runs between the same initiator and responder".
>
>I believe the intent was that MSK is used once to calculate/verify
>the AUTH payload, and not used for anything else afterwards.
>
> > If we drew an analogy from the MSK usage on other EAP lower
> > layers (e.g., IEEE 802.11i), the same MSK can be used to re-key
> > TSKs between the same peer and authenticator until expiry of that
> > MSK. By the same argument, I don't see a reason why the MSK
> > cannot be used again for the authentication of a subsequent
> > IKE_SA between the IKEv2 initiator and responder. I can see some
> > exceptions (e.g., where the IKEv2 entity acting as the EAP peer
> > actually wishes to use different identity/credentials for the two
> > exchanges, requiring a separate EAP run for those), but, in
> > general, it seems like we should be able to use the same MSK for
> > the multiple exchanges.
> >
> > One potential concern is perhaps due to the fact that the MSK is
> > used directly in the generation of the AUTH payload and if the
> > multiple IKEv2 runs used different prf's for generating the AUTH
> > payload, that could result in a bad use of the MSK. But, if the
> > same algorithm is used in the multiple runs, is there still
> > something to be concerned about? And, would it be a violation of
> > RFC4306?
> >
> > I'd appreciate any clarification on the above. Also, if someone
> > can provide clarity on what implementations do (e.g., is the MSK
> > deleted after authenticating the IKE_SA or is it cached for a
> > certain duration, etc.), that would be very helpful.
>
>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 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.

thanks,
Lakshminath



>Best regards,
>Pasi
>
>
>_______________________________________________
>Ipsec mailing list
>[e-mail]
>https://www1.ietf.org/mailman/listinfo/ipsec


_______________________________________________
Ipsec mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ipsec