Subject: RE: [eap] Authenticator versus AAA client

From: "Nakhjiri Madjid-MNAKHJI1" <[email-masked]>
Date: Mon, 5 Dec 2005 18:29:58 -0500

Hi Yoshiro,

Ok, thanks for the clarification. Agreed.

EAP pass-through authenticator does understand EAP Requests and
Responses for matching the Requests with Responses.  But EAP
path-through authenticator does not need to understand the content of
the Data field of the Requests and Responses.

AAA client receives the master keys from AAA server, but it just passes
the received keys to the EAP pass-through authenticator and never caches
the keys.  So I think the pass-through authenticator is the final
receiver of the master keys.

Madjid>> I can understand that this is a logical deduction, but is there
anywhere it is stated that AAA client cannot cache the keys, but
authenticator can?

Madjid

Yoshihiro Ohba

> 
> Any guidance?
> 
> Thanks,
> 
> Madjid Nakhjiri
> 
> _________________________________________________________________
> 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: Yoshihiro Ohba <[email-masked]>
Date: Tue, 06 Dec 2005 07:56:56 -0500

Hi Madjid,

The following text in section 2.3 of eap-keying draft talks about not
caching the keys at AAA layer, but mostly in terms of AAA servers.  I
think the text should be revised so that any AAA layer entity
including AAA client and AAA proxy does not cache the keys.  (Note: I
explicitly mention that AAA proxy does not cache the keys as well.
This might be related to the ongoing hokey discussion where KDC in the
visiting domain is going to be introduced.  Having said that, I think
that the KDC, which is expected to cache the keys, should be defined
outside the AAA layer.)

"
AAA  Existing AAA servers supporting RADIUS/EAP [RFC3579] or Diameter
     EAP [RFC4207] do not support caching of EAP keying material or
     parameters.  In existing AAA server implementations, exported EAP
     keying material (MSK, EMSK and IV) as well as parameters and
     derived keys are not cached and MUST be presumed lost after the AAA
     exchange completes.

     In order to avoid key reuse, the AAA layer MUST delete transported
     keys once they are sent.  The AAA layer MUST NOT retain keys that
     it has previously sent to the authenticator.  For example, a AAA
     layer that has transported the MSK MUST delete it, and keys MUST
     NOT be derived from the MSK from that point forward.
"

Taking a close look at EAP pass-through authenticator, the EAP
authenticator *layer* and the EAP *layer* on the pass-through
authenticator do not cache the keys as well, according to the the
following text in section 2.2 of eap-keying draft:

"
   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 by the EAP peer/authenticator layer or
   the lower layer.
"

Yoshihiro Ohba