About use of EMSK

---

From: Dorothy Stanley [mailto:dstanley1389gmail.com]
Sent: Friday, March 17, 2006 12:11 PM
To: Narayanan, Vidya
Cc: Jari Arkko; Bernard Aboba; eapfrascone.com
Subject: Re: [eap] About use of EMSK

Vidya, Jari,

 

>Given how many
>egacy methods are still in use, I'd strongly vote for (b) here. It is
>mpractical to make changes to methods to accommodate the use of
>EMSK/AMSK.
 

I strongly agree with Vidya here. The usage of EAP keys by

existing methods, such as EAP-TLS which are widely used, particularly in 802.11 systems should be described and accommodated in the document.

It is impractical and extremely undesirable to make these existing methods non-compliant with the framework document.

 

My understanding was that the keying framework document would largely describe EAP keying usage as implemented today,

while specification of EMSK and AMSK usage ;would be in a separate document, such as an EAP key extensions document. Why is this changing,

particularly in WGLC?

 

Thanks,

 

Dorothy Stanley

 

On 3/6/06, Narayanan, Vidya <qualcomm.com">vidyanqualcomm.com> wrote:

Hi Jari,
Thanks for the much needed analysis on this topic. Please see some
comments below.

&gt;
>
> 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
&gt; 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.
&gt; Having a default does not help much either, if the default
&gt; becomes broken in the near future.
&gt; 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,
&gt; for instance, would there be enough incentive to extend
> 802.11 just to make this possible?
>
> The choices and their implications are:
>
> &nbsp; (a) Specified default, optional negotiation in EAP methods.
&gt;
>&nbsp; &nbsp; &nbsp;   ;This implies an interface either from methods to the
> AAA/EAP server
>; &nbsp; &nbsp; &nbsp; &nbsp;code (for solution 1) or AAA protocol extensions for
> solution 2.
>
&gt; &nbsp; &nbsp; &nbsp;  Changes in peers, servers, methods, possibly AAA protocols.
>
>&nbsp;  (b) Lower layer negotiation.
>
>  ; &nbsp; &nbsp; &nbsp;If used together with solution 1, implies AAA protocol
&gt; extensions
>   ; &nbsp; &nbsp; to communicate the KDF. If used with solution 2, implies AAA
>&nbsp; &nbsp;   ; &nbsp;protocol extensions to carry the EMSK.
>
>  ; &nbsp; &nbsp; &nbsp;Changes in lower layers, AAA protocol. No changes in
> EAP or methods.
&gt;
> Based on this my current preference is (b). I'd be willing to
> accept (a), too.
>

I am surprised that you are willing to accept (a) Given how many
legacy methods are still in use, I'd strongly vote for (b) here. It is
impractical to make changes to methods to accommodate the use of
EMSK/AMSK. As you point out, what we pick here may depend on whether we
pick (1) or (2) below - and (1) makes much more sense to me for reasons
stated below.


&gt; The choice between server or lower-layer based EMSK
> processing depends on security implications and ease of use
> for different purposes.
> The choices are:
>
> &nbsp; (1) Derive AMSKs at the EAP/AAA server.
&gt;
>&nbsp; &nbsp; &nbsp; &nbsp; Implies a AAA protocol extension to retrieve AMSKs.
>;
> ; &nbsp; &nbsp; &nbsp; Changes at the EAP/AAA server, authenticator. New, stateful
> ; &nbsp; &nbsp; &nbsp; nature of the EAP/AAA server.
&gt;
>&nbsp;  (2) Derive AMSKs at the lower layer.
>;
> ; &nbsp; &nbsp; &nbsp; Implies a AAA protocol extension to carry EMSK to the
>&nbsp; &nbsp;   ; &nbsp;authenticator.
>
> &nbsp;   ; &nbsp; Small changes at the EAP/AAA server, main functionality in
> ; &nbsp; &nbsp; &nbsp; the authenticator.
>
&gt; &nbsp; &nbsp;   ; Hard to see how other nodes than the authenticator would
>  ; &nbsp; &nbsp; &nbsp;actually use the AMSKs. Traditionally, NAS -> NAS communication
>&nbsp; &nbsp; &nbsp;   ;has not been easy compared to NAS -> AAA communication.
>
> Based on this my current preference is (1). But its a close call.

I agree that (1) makes more sense. In many cases, the AMSKs are slated
for use to bootstrap protocols such as Mobile IP (actually, that seems
to the most pressing practical need so far). So, if the EAP
authenticator were to derive the AMSK, I can't envision an interface
between, say a Mobile IP HA and an EAP authenticator to transport the
AMSK. One can imagine a solution here, but this certainly complicates
the model a whole lot more. It makes much more sense to me to have this
in the EAP server so that the use of AMSKs could be more
straightforward.

Also, it makes complete sense that an EAP-based means of bootstrapping
other protocols such as Mobile IP are only used in AAA-based systems.
So, having an SA between an arbitrary entity X (such as a MIP HA) and
the AAA server for transport of keys makes sense (and this is a model
that exists today). I don't see how (2) would be an option for the same
case. I don't see a use for AMSKs (at least not yet) for the EAP
authenticator itself.

If we took Mobile IP as an example, one could envision the peer seeking
MIP bootstrapping as part of the EAP authentication, in reaction to
which the EAP server may derive an AMSK. Whether this AMSK gets sent to
the HA right away or gets cached in the EAP server (actually AAA server)
until the HA asks for it is a separate question that needs to be
answered. But, you already noted potential new stateful nature of the
EAP/AAA server in (1) above - so, that would take care of the needs
here.

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

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