Subject: [eap] Re: m.getKey() and RFC 4137

From: "Bernard Aboba" <[email-masked]>
Date: Thu, 16 Mar 2006 20:30:24 -0800

Narayanan, Vidya said:

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

I agree with this.  Changing EAP methods to negotiate KDFs would in practice
be very difficult -- even if the industry were willing to do the upgrades
(which they probably wouldn't be).  In practice, TLS (on which many methods
are based) does not support KDF negotiation for its own use, let alone
negotiation of KDFs to be used to generate AMSKs.  Attempting to convince
the TLS WG to add support for cryptographic negotiation for ancillary
purposes would be an uphill battle that seems unlikely to succeed.

Jari said:

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

I've just re-read RFC 4137, and it seems to me that choice 2 is fairly
well ingrained in that document.

RFC 4137 describes the state machine interface between EAP and lower layers. 
  This includes the
transfer of keys from the EAP layer to the lower layer, via the eapKeyData 
structure.
Various functions are defined that provide support for this structure for 
use in EAP key management.
This includes eapKeyData (EAP key) (set during METHOD state),  
eapKeyAvailable (boolean),
and m.getKey(), the method procedure used to obtain keying material for the 
lower layer.
Therefore RFC 4137 provides the structures, state machine and functions for 
transference of
EAP keying material and parameters from the EAP method to the lower layer.

The state machines described in RFC 4137 make no distinctions relating to 
availability of
individual elements.  The keying material is provided as a unit (the EAP Key 
structure) to the lower
layer, and the state machine transitions reflect this.  There is no notion 
of "partial
completion" with respect to key transfer, and in fact this is not possible.  
In RFC 4137,
the key structure is available, or it isn't.  eapKeyAvailable is defined as 
a boolean, and
therefore if the keys are only partially available, then all variables and 
functions which
depend on this variable become undefined.

So from what I can tell, RFC 4137 requires that all keying parameters be 
transferred as
a unit.  This assumption permeates the entire document, as well as lower 
layer standards
that are based on it.

Given this, I wonder whether the horse hasn't already left the barn.

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

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

---

From: "Salowey, Joe" <[email-masked]>
Date: Fri, 17 Mar 2006 10:55:53 -0800

> -----Original Message-----
> From: Bernard Aboba [mailto:[email-masked]] 
> Sent: Thursday, March 16, 2006 8:30 PM
> To: [email-masked]
> Subject: [eap] Re: m.getKey() and RFC 4137
> 
> Narayanan, Vidya said:
> 

[Joe] If anything, this statement argues for the method to define the
KDF based on the cryptographic operations it supports.   

> well ingrained in that document.
<snip>

> Given this, I wonder whether the horse hasn't already left the barn.
[Joe] RFC 4137 did not consider the usage of the EMSK, therefore I don't
think the horse was ever in that barn.

---

From: "Salowey, Joe" <[email-masked]>
Date: Fri, 17 Mar 2006 14:14:21 -0800

> From: Bernard Aboba [mailto:[email-masked]] 
> Sent: Friday, March 17, 2006 1:42 PM
> To: 'Narayanan, Vidya'; [email-masked]
> Subject: RE: [eap] Re: m.getKey() and RFC 4137
> 
> Vidya said:
> 
> "I wonder if we are restricted in defining the behavior of 
> the EMSK based
> on a spec that did not consider EMSKs to begin with? It may be that we
> would conclude it is okay to pass the EMSK to the AAA layer - but,
> should we be constrained by 4137 though?" 
> 
> RFC 4137 treats keying material as a *structure* not a single 
> variable, so
> that all the keying material and parameters are passed to the 
> lower layer at
> the same time.  This would not have been necessary if the 
> document only
> meant to deal with the MSK. Since RFC 4137 references the key 
> frame work
> document as well as RFC 3748, it cannot be claimed that it 
> was unaware of
> the key management document, which until -09 included passing 
> of the EMSK to
> the lower layer. 
> 
[Joe] Awareness and having a good understanding of it are two different
things.  I think we have made much progress in understanding in
discussions since RFC 3748 (which reserves the EMSK for future use) and
RFC 4137 (which doesn't mention the EMSK at all). Basing a decision on
what is loosely captured in RFC 4137 would be short sighted.  I don't
think these documents should be interpreted as encourage or discourage
passing the EMSK to various places. 
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/eap

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Fri, 17 Mar 2006 14:42:24 -0800

> > Vidya said:
> > 
> > "I wonder if we are restricted in defining the behavior of the EMSK 
> > based on a spec that did not consider EMSKs to begin with? 
> It may be 
> > that we would conclude it is okay to pass the EMSK to the 
> AAA layer - 
> > but, should we be constrained by 4137 though?"
> > 
> > variable, so that all the keying material and parameters 
> are passed to 
> > the lower layer at the same time.  This would not have been 
> necessary 
> > if the document only meant to deal with the MSK. Since RFC 4137 
> > references the key frame work document as well as RFC 3748, 
> it cannot 
> > be claimed that it was unaware of the key management 
> document, which 
> > until -09 included passing of the EMSK to the lower layer.
> > 
> [Joe] Awareness and having a good understanding of it are two 
> different things.  I think we have made much progress in 
> understanding in discussions since RFC 3748 (which reserves 
> the EMSK for future use) and RFC 4137 (which doesn't mention 
> the EMSK at all). 

Well, for that matter, RFC 4137 doesn't mention the MSK either :) 

> Basing a decision on what is loosely 
> captured in RFC 4137 would be short sighted.  I don't think 
> these documents should be interpreted as encourage or 
> discourage passing the EMSK to various places. 
> 

I agree with this though. If 4137 captured a snapshot that has been
revisited and evolved further, it doesn't seem reasonable to use that as
a baseline. What are the implications on existing implementations
because of this? Do we have a sense of that? 

Vidya

---

From: "Ryan Hurst" <[email-masked]>
Date: Fri, 17 Mar 2006 16:32:07 -0800

Vidya - RFC 4137 has been out of last call for nearly 18 months and we (Microsoft) have completed a implementation based on it, we already have partners integrating with it.
 
We are not the only ones, it has also been integrated with other link layers such as IEEE 802.1X-2004, IEEE 802.11i, etc.
 
I even understand UNH is also going to be building a test sure around 4137 (http://www.iol.unh.edu/).
 
Simply put proposed changes would result in significant changes to these existing standards, that would not only would negate the progress that has been achieved through this working group it would also create confusion in the market and likely cost the industry billions of dollars.

If there is in-fact a need for these new capabilities the existing standards are not the place to incorporate them.

Ryan M. Hurst

---

From: "Salowey, Joe" <[email-masked]>
Date: Fri, 17 Mar 2006 17:43:57 -0800

> because of this? Do we have a sense of that? 
[Joe] There are no existing implementations that use the EMSK because we
have not defined how to use the EMSK yet.  
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/eap

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Fri, 17 Mar 2006 17:47:23 -0800

> > 
> [Joe] There are no existing implementations that use the EMSK 
> because we have not defined how to use the EMSK yet.  
> 

There aren't implementations that "use" it, but there must be
implementations that derive it (given that the MSK and EMSK are really
parts of the same longer key) - no? 

And, if it is derived and passed to the lower layer today, we still have
issues, regardless of the fact that the lower layer does nothing with it
today. 

Vidya

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Fri, 17 Mar 2006 18:15:02 -0800

Ryan,
This is valuable input. This unfortunately, is a practical limitation. 
 
Re-reading RFC 3748, I guess it really says "it (the EMSK) MUST NOT be
transported to, or shared with, additional parties, or used to derive
any other keys." So, it doesn't say anywhere that the EMSK MUST NOT be
transported to a lower layer per say. 
 
I guess we cannot really blame RFC 4137 alone for what it says then :) 
 
We could go down the path that RFC 4137 is an informational RFC and must
technically not have a bearing on a standards track document - but,
practical problems supercede that anyway. 
 
It does make the specification a bit sticky with respect to EMSKs now -
it should be the EAP layer keeping the EMSK (caching if needed) and
generating the AMSKs out of it. If the EMSK is transported to the AAA
layer, it doesn't seem to make sense that the AAA layer would be
deriving any AMSKs. 
 
We could say that the EMSK is transported along with the MSK to the AAA
layer in today's implementations, but the EAP layer must maintain a copy
of the EMSK in order to derive AMSKs from it - but, then, this obviously
violates the fact that transported keys must be deleted. If we are
willing to relax that requirement (and add text about the fact that the
AAA layer MUST delete the EMSK immediately), there may be a way forward.
But, I'm not convinced that this is the right approach. 
 
Vidya

________________________________

	From: Ryan Hurst [mailto:[email-masked]] 
	Sent: Friday, March 17, 2006 4:32 PM
	To: [email-masked]
	Subject: [eap] Re: m.getKey() and RFC 4137

	Vidya - RFC 4137 has been out of last call for nearly 18 months
and we (Microsoft) have completed a implementation based on it, we
already have partners integrating with it.
	 
	We are not the only ones, it has also been integrated with other
link layers such as IEEE 802.1X-2004, IEEE 802.11i, etc.
	 
	I even understand UNH is also going to be building a test sure
around 4137 (http://www.iol.unh.edu/).
	 
	Simply put proposed changes would result in significant changes
to these existing standards, that would not only would negate the
progress that has been achieved through this working group it would also
create confusion in the market and likely cost the industry billions of
dollars.

	If there is in-fact a need for these new capabilities the
existing standards are not the place to incorporate them.

	Ryan M. Hurst

---

From: "Salowey, Joe" <[email-masked]>
Date: Wed, 22 Mar 2006 05:36:57 -0800

> From: Jari Arkko [mailto:[email-masked]] 
> Sent: Wednesday, March 22, 2006 4:44 AM
> To: Bernard Aboba
> Cc: [email-masked]
> Subject: Re: [eap] Re: m.getKey() and RFC 4137
> 
> Bernard Aboba wrote:
> 
> >Vidya said:
> >
> >"Are you saying then that in accordance with 4137, the EMSK 
> will also be
> >delivered to the AAA layer on the EAP server? "
> >
> >That's how I read it, yes.  The keying material and 
> parameters are passed
> >via the eapKeyData structure to the lower layer (which would 
> be the AAA
> >layer on the EAP server when in passthrough mode), via the m.getKey()
> >function.  The AAA layer then fills in the aaaEapKeyData 
> structure and
> >passes this to the authenticator.  While both eapKeyData and 
> aaaEapKeyData
> >are of type "EAP Key" there doesn't appear to be a 
> presumption that they are
> >the same.  So the AAA layer could receive the EMSK, but not 
> pass it to the
> >authenticator.
> >  
> >
> 
> So -- we are still talking only about what happens "inside the box",
> not about the delivery of the EMSK to the access point on the
> coffee shop wall? I'm not sure I care much about what happens
> inside the box, as long as the value doesn't leave the box...
> 

[Joe] I agree what happens within a peer or within a combined
authenticator and EAP server is not really a big concern from an
external view.  It's more what happens when we have separed the EAP
server and EAP authenticator that these details become observable
aspects of the system.  

> --Jari