| Eap keying review: use of MSK/ EMSK for AMSK creation | <– Date –> <– Thread –> |
|
From: Nakhjiri Madjid-MNAKHJI1 (Madjid.Nakhjiri |
|
| Date: Tue, 1 Nov 2005 12:50:48 -0500 (EST) | |
Hi Bernard,
I did some more reading in the 08 doc, and I am trying to put all the
pieces of the puzzle together.
Section 2.2. of EAP keying 08 prohibits sending EMSK down to the lower
layer (section 2.2).
I assume "lower layer" includes AAA layer (even though 3748 section 2.2.
does not include AAA as a lower layer, even though 3579 is dated before
3748).
So this prohibits the AAA server to take EMSK and create new keys
(AMSKs) for new applications or services. This means the EAP layer must
itself authorize each service application and calculate any AMSK that
are needed for that application. Not only we are including a role of
authorization into an EAP server, but also we are saying the EAP layer
must anticipate all applications that need to derive their keys based on
the EAP keying process. Should not be the AAA server to make
authorization decisions and generate keys for the services accordingly
(say a master key for an access technology or a master key to provide
handover support)?
Furthermore in section 2.3 under AAA, a "AAA layer" is mentioned and it
says, the AAA layer must delete an MSK that has been transported to the
authenticator. Problems:
1) The EAP RFC does not distinguish between authenticator and
authentication server (the EAP server).
2) The EAP RFC does not specify an MSK transport process. It says that
AAA key and MSK are a lot of times the same, but it also says:
"This specification does not provide detailed guidance on how EAP
methods derive the MSK and EMSK, how the AAA-Key is derived from the
MSK and/or EMSK, or how the TSKs are derived from the AAA-Key."
It only talks about an optional process of AAA transport
"[d] A AAA-Key derived from the MSK and/or EMSK negotiated between the
peer and authentication server MAY be transmitted to the
authenticator. Therefore, a mechanism needs to be provided to
transmit the AAA-Key from the authentication server to the
authenticator that needs it. The specification of the AAA-key
derivation, transport, and wrapping mechanisms is outside the
scope of this document. Further details on AAA-Key Derivation
are provided within [KEYFRAME]."
So EAP RFC does not really talk about MSK transport. We are now saying
MSK and AAA key are the same and then lets pass (MSK instead of AAA-key)
to the authenticator (which btw is not recognized in 3748) and then dump
MSK both at the EAP server and AAA server. The EMSK does not go down to
AAA layer either. So I am really trying to figure out how we can have a
practical way of creating AMSKs for applications that EAP layer should
really not care about (AAA should deal with that)?
It seems that even when we are talking about method independence,
algorithm independence and lower layer independence, we are building an
application dependence in the EAP layer.
Regards,
Madjid
<Snips for Bernard's email: >
The definitions are copied from [RFC3748] without modification. Note
that [RFC3748] does include the term "export". See Section 1.2:
Master Session Key (MSK)
Keying material that is derived between the EAP peer and server
and exported by the EAP method. The MSK is at least 64 octets in
length. In existing implementations, a AAA server acting as an
EAP server transports the MSK to the authenticator.
Extended Master Session Key (EMSK)
Additional keying material derived between the EAP client and
server that is exported by the EAP method. The EMSK is at least
64 octets in length. The EMSK is not shared with the
authenticator or any other third party. The EMSK is reserved for
future uses that are not defined yet.
Given the above definition, the lower layer does not "create" the
AAA-Key; it is passed down to it from the EAP Method. There has been
some discussion as to whether the lower layer "creates" AMSKs after
receiving the EMSK from the EAP layer, or whether the EAP layer keeps
the EMSK secret from the lower layer and calculates AMSKs from the EMSK
based on a request from the lower layer
-
Eap keying review: use of MSK/ EMSK for AMSK creation Nakhjiri Madjid-MNAKHJI1, November 1 2005
-
RE: Eap keying review: use of MSK/ EMSK for AMSK creation Bernard Aboba, November 1 2005
-
Issue: AAA Key Caching effectively prohibited? Bernard Aboba, November 1 2005
- Re: Issue: AAA Key Caching effectively prohibited? Jari Arkko, November 1 2005
- Re: Issue: AAA Key Caching effectively prohibited? Bernard Aboba, November 1 2005
-
Issue: AAA Key Caching effectively prohibited? Bernard Aboba, November 1 2005
-
RE: Eap keying review: use of MSK/ EMSK for AMSK creation Bernard Aboba, November 1 2005
Results generated by Tiger Technologies using MHonArc.