Re: Strawman -10/EMSK deletion requirement?
From: Rafa Marin Lopez (rafadif.um.es)
Date: Tue, 14 Mar 2006 19:55:38 -0800 (PST)
Jari Arkko wrote:

It seems that we have converged on this issue. Is there
anyone who would like to suggest specific text changes?


Hi Jari

As I commented in a previous e-mail, I think this paragraph in section 2.2 (page 14) should be relaxed if we consider EAP peer / EAP authenticator layer or EAP layer could be in charge of creating AMSK and also if we consider EMSK could be cached in those layers.

"The EAP peer and authenticator layers MUST NOT modify or cache keying
  material or parameters (including Channel Bindings) passing in either
  direction between the EAP method layer and the EAP layer.  The EAP
  layer also MUST NOT cache keying material or parameters (including
  Channel Bindings) passed to it, whether by the EAP peer/authenticator
layer, the lower layer or the AAA layer."

Additionally, that paragraph seems a bit contradictory with this in page 15.

"The EMSK is reserved for future use and MUST remain on the EAP
     peer and EAP server where it is derived; it MUST NOT be
     transported to, or shared with, additional parties, or used to
     derive any other keys.  (This restriction will be relaxed in a
     future document that specifies how the EMSK can be used.)"

Could we say ...

"The EMSK is reserved for future use and MUST remain on the EAP
     peer and EAP server where it is derived; it MUST NOT be
     transported to, or shared with, additional parties." ?



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

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






--
------------------------------------------------------
Rafael Marin Lopez
Faculty of Computer Science-University of Murcia
30071 Murcia - Spain
Telf: +34968367645    e-mail: rafa [at] dif.um.es
------------------------------------------------------


Results generated by Tiger Technologies using MHonArc.