Subject: RE: [eap] About use of EMSK

From: "Narayanan, Vidya" <[email-masked]>
Date: Fri, 17 Mar 2006 12:59:34 -0800

Hi Dorothy,
I don't think the keying framework document would still discuss this. I
think there is consensus that the text about EMSK will be in a separate
document. The issue was discussed in the context of the EAP keying
framework, since there are parts of that document that specifically say
that the EMSK MUST NOT be transported and MUST be deleted - question is
whether we can change that wording and leave any other explanation on
EMSK usage or AMSK derivation to a future spec. 
 
Thanks,
Vidya

________________________________

	From: Dorothy Stanley [mailto:[email-masked]] 
	Sent: Friday, March 17, 2006 12:11 PM
	To: Narayanan, Vidya
	Cc: Jari Arkko; Bernard Aboba; [email-masked]
	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 <[email-masked]> wrote: 

		Hi Jari,
		Thanks for the much needed analysis on this topic.
Please see some
		comments below.
		
		> 
		>
		> 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.
		
		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.

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

_________________________________________________________________
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: Tue, 28 Mar 2006 10:19:37 -0800

Narayanan, Vidya wrote:

> I don't think the keying framework document would still discuss this.
> I think there is consensus that the text about EMSK will be in a
> separate document. The issue was discussed in the context of the EAP
> keying framework, since there are parts of that document that
> specifically say that the EMSK MUST NOT be transported and MUST be
> deleted - question is whether we can change that wording and leave any
> other explanation on EMSK usage or AMSK derivation to a future spec. 

What we intend to do, I think, is to set the high-level requirements for
EMSK in
the keying framework (e.g., MUST NOT be transported).

But the derivation of AMSKs from the EMSK, and the specific proposals
for specific uses of the AMSKs in applications need to be in other
documents.

In any case, I'm hoping that what we say in the keying framework document
holds and does not have to be changed in these other documents.

--Jari