eap Mailing List: RE: Eap keying review: use of MSK/ EMSK for AMSK creation

[Bernard Aboba (bernard_aboba]

> Section 2.2. of EAP keying 08 prohibits sending EMSK down to the lower
> layer (section 2.2).

Right.  This restriction was added in response to a comment which pointed 
out that sending the EMSK to the lower layer violated the principle of Mode 
Independence, since this would mean that the authenticator lower layer could 
obtain the EMSK in "stand alone" mode, but not in "pass-through" mode (since 
the EMSK cannot be transported).

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

RFC 3748, Figure 2 includes a diagram in which AAA operates as an EAP lower 
layer.

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

The implication is that the EAP layer is creating AMSKs in response to 
requests from lower layers (including AAA).  Also note that the EAP layer is 
transforming the Method-ID into a Session-ID.  So the document is outlining 
a role for the EAP layer as something of a "security policeman", something 
which is not described in RFC 3748.

However, I don't think this necessarily extends to adding authorization to 
the EAP layer.  My understanding was the the EAP layer does not examine the 
AMSK request, it just honors it.

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

Well, that is what the document had said prior to the change being applied 
in response to the comment.  In some ways leaving AMSK generation to the 
lower layer is cleaner, because it does not add functionality to the EAP 
layer, which is typically just thought of as a "switch" in RFC 3748 and RFC 
4317.  However, there is the issue that this violates "Mode Independence".

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

The requirement is actually that *any* transported key be deleted.  This 
would apply to more than just the MSK -- if an AMSK were transported, it 
also would need to be deleted.  This is required in order to fulfill the 
basic security goal, which is that the TSKs are known only to the EAP peer 
and authenticator.  If transported keys are left on the AAA server, then the 
AAA server also has knowledge of the TSKs.

Problems:
> 1) The EAP RFC does not distinguish between authenticator and
> authentication server (the EAP server).

The way to read this is that the document is specifying the behavior of the 
AAA layer with respect to key  handling.  This is not inherently a violation 
of the principle of "Mode Independence".   For example, it is not 
incompatible to say that existing AAA servers don't cache keys while 
reviewing key caching behavior of IEEE 802.11i.

> So EAP RFC does not really talk about MSK transport. We are now saying MSK 
> and AAA key are >the same

In RFC 4072 (an IETF Proposed Standard) the keying attribute is called 
"EAP-Master-Session-Key" rather than "AAA-Key" This choice (which I think 
was quite wise) was made in order to make sure it is very clear what key is 
being referred to.  Going forward, there may be more than one key involved 
(MSK, AMSKs, etc.), so that talking about a "AAA-Key" is very problematic.  
If it is necessary to transport AMSKs, it is probably best if a specific 
attribute is created for this purpose (e.g. 
EAP-Application-Master-Session-Key), so as to be able to distinguish 
different kinds of keys and keep confusion to a minimum.

> to the authenticator (which btw is not recognized in 3748)

The term "authenticator" is both defined and used in RFC 3748.

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

It would indeed be unfortunate to create an "application dependence" in the 
EAP layer.  However, I'm not sure that AMSK proposal does that,  
necessarily.  If all the EAP layer does it take parameters from the lower 
layer to create AMSKs, and then unconditionally carry out the lower layer's 
instructions, then I think the mechanism could be quite general.