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