Subject: Re: [eap] About use of EMSK

From: Jari Arkko <[email-masked]>
Date: Sun, 05 Mar 2006 23:12:09 +0200

Rafa Marin Lopez wrote:

>>
>> [Joe] The EMSK MUST NOT be exported to the lower layer.   
>>
> Clarified this point. In your answer you specify "only" lower layer. 
> Did you forget to include AAA layer ? Or do you think AAA layer might 
> receive EMSK?.

Ignoring the definition problems with layers for a while.
I think we know the external behaviour we want. We
want

- Avoid L2 design, implementation, or node compromise problems
  causing the compromise of other L2 networks. Or compromise
  of one application of EAP keys leading to the compromise of
  others.

- Allow crypto-agility for the function used in the key
  derivation.

- Allow different keys to be used for different attachments,
  without keys 2, 3, ... to be based on key 1, which is what
  we would have to do with MSK

- Make it possible to use existing EAP methods.

One way of approaching this is to have the EAP server/AAA server
keep the EMSK, and provide AMSKs for various purposes. Another
is giving the EMSK to the lower layer, but dictating something about
its use.

--Jari

_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/eap

Arhives: http://lists.frascone.com/pipermail/eap

---

From: Jari Arkko <[email-masked]>
Date: Mon, 06 Mar 2006 11:36:24 +0200

Here's some analysis of the server vs. lower-layer based
EMSK processing approaches.

(1) In the server based approach we keep the
EMSK in the server (perhaps just for a moment)
and generate the AMSKs, which are given to the the
different applications, such as fast handoff mechanisms.
The use of these applications goes via AAA, e.g., some kind
of key requests or fast re-auth requests can be sent from
NASes to the server. The AMSKs are derived using a KDF
which is decided either (a) by a default plus optional negotiation
in methods or (b) by lower layer negotiation and having AAA
tell the server which KDF to use.

(2) In the lower-layer based EMSK processing approach, the
EMSK is delivered to the authenticator along with the MSK.
KDF is selected either (a) by a default in EAP plus optional
negotiation in methods, choice is communicated to the
lower layer via AAA or (b) by lower layer negotiation alone.
The lower layer is responsible for all use of the AMSKs
in a local context. That is, no AAA key requests are needed
or possible.

Discussion about the chosen approach for EMSK use has
so far appeared to assume 1a vs. 2b. Based on the above,
it seems that the KDF negotiation may be a separate
issue from who maintains the EMSK and calculates AMSKs.
In the following I'll try to analyze these issues.

The KDF negotiation is indeed problematic almost no
matter what we do. Requiring new funtionality in methods
is in practice often a non-starter; while we can develop
new methods and update old ones, it is expected that
most of current usage will continue to use the existing
methods. Having a default does not help much either,
if the default becomes broken in the near future.
But requiring new functionality in link layers it not
always easy either. It would be easy when we are developing
a new link layer and including some EMSK usage as a part
of that. But if we were to use EMSK for some new function
over 802.11, for instance, would there be enough incentive
to extend 802.11 just to make this possible?

The choices and their implications are:

  (a) Specified default, optional negotiation in EAP methods.

       This implies an interface either from methods to the AAA/EAP server
       code (for solution 1) or AAA protocol extensions for solution 2.

       Changes in peers, servers, methods, possibly AAA protocols.

  (b) Lower layer negotiation.

       If used together with solution 1, implies AAA protocol extensions
       to communicate the KDF. If used with solution 2, implies AAA
       protocol extensions to carry the EMSK.
      
       Changes in lower layers, AAA protocol. No changes in EAP or methods.

Based on this my current preference is (b). I'd be willing
to accept (a), too.

The choice between server or lower-layer based EMSK processing
depends on security implications and ease of use for different purposes.
The choices are:

  (1) Derive AMSKs at the EAP/AAA server.

       Implies a AAA protocol extension to retrieve AMSKs.

       Changes at the EAP/AAA server, authenticator. New, stateful
       nature of the EAP/AAA server.

  (2) Derive AMSKs at the lower layer.

       Implies a AAA protocol extension to carry EMSK to the
       authenticator.

       Small changes at the EAP/AAA server, main functionality in
       the authenticator.

       Hard to see how other nodes than the authenticator would
       actually use the AMSKs. Traditionally, NAS -> NAS communication
       has not been easy compared to NAS -> AAA communication.

Based on this my current preference is (1). But its a close
call.

--Jari

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 17 Mar 2006 15:23:36 -0500

One thing we might discuss is whether (a) and (b) provide the same
level of security or not.  Since (b) is not end-to-end, negotiation
bidding down attack may be possible by passthrough authenticator.

Yoshihiro Ohba