m.getKey() and RFC 4137

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

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

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

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