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

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

Hi Bernard,

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

Are you saying then that in accordance with 4137, the EMSK will also be
delivered to the AAA layer on the EAP server? 

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

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

---

From: "Bernard Aboba" <[email-masked]>
Date: Fri, 17 Mar 2006 11:03:37 -0800

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

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.   
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/eap

---

From: Jari Arkko <[email-masked]>
Date: Wed, 22 Mar 2006 06:44:08 -0600

>the same.  So the AAA layer could receive the EMSK, but not pass it to the

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

--Jari

---

From: "Bernard Aboba" <[email-masked]>
Date: Wed, 22 Mar 2006 07:49:09 -0800

>inside the box, as long as the value doesn't leave the box...

Right. I think we only care about externally observable behavior.