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

From: "Pasi Eronen" <[email-masked]>
Date: Mon, 2 Oct 2006 11:15:38 +0300

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 :-)

Best regards,
Pasi

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

---

From: Lakshminath Dondeti <[email-masked]>
Date: Mon, 02 Oct 2006 09:49:31 -0700

>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

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Mon, 2 Oct 2006 10:37:03 -0700

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

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

---

From: <[email-masked]>
Date: Tue, 3 Oct 2006 11:37:00 +0300

Lakshminath Dondeti wrote:
>       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.
> 

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

---

From: <[email-masked]>
Date: Tue, 3 Oct 2006 11:40:06 +0300

Vidya Narayanan wrote:

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

Well, re-using the MSK is probably not more secure than re-running EAP
for each IKE_SA (but might save some roundtrips and other resources). 
But by "reasonably secure", I meant that this can be made "secure 
enough", provided that the details are right.

Best regards,
Pasi