Subject: [eap] Issue: Use of term lower layer

From: "Salowey, Joe" <[email-masked]>
Date: Thu, 1 Dec 2005 15:05:49 -0800

Submitter name: Joe Salowey
Submitter email address: [email-masked]
Date first submitted: 12/1/2005
Reference: 
Document: Keying Framework
Comment type: E
Priority: '1' Should fix 
Section: 2 
Rationale/Explanation of issue:

The term lower layer is used inconsistently in the document. 

Lower layer should refer to the protocol between the EAP Peer and the
EAP Authenticator.  It is between these entities that the security
association protocol is typically run.  The MSK is transported to the
lower layer. 

AAA is not an EAP lower layer except in the special case where the AAA
client and server are acting as the EAP Peer and EAP Authenticator for
some reason (an example of this could was in EUSM).  Entities other than
the lower layer may obtain keys derived from the EMSK.  

Requested change:

Section 2.1
----------- 
change

"Of these phases, Phase 0, 1b and Phase 2 are handled by a lower layer."

To 

"Of these phases, Phase 0, 1b and Phase 2 are handled external to EAP.
Phases 0 and 2 are handled by the lower layer protocol and phase 1b is
typically handled by a AAA protocol."

Section 2.2
------------
(remove references to IV)
---
Change

"The EMSK MUST NOT be provided to the lower layer, nor is it permitted
to pass any quantity to the lower layer from which the EMSK could be
computed without breaking some cryptographic assumption, such as
inverting a one-way function."

To

"The EMSK MUST NOT be provided to an entity outside the EAP server or
peer, 
nor is it permitted to pass any quantity to an entity outside the EAP
server or peer
from which the EMSK could be
computed without breaking some cryptographic assumption, such as
inverting a one-way function."
---
Change 

"In order to preserve the security of keys derived within EAP methods,
   lower layers other than AAA MUST NOT export keys passed down by EAP
   methods.  "

To 

"In order to preserve the security of keys derived within EAP methods,
 lower layers MUST NOT export keys passed down by EAP
 methods.  "
---
Change

"EAP keying material and parameters provided to a lower layer other
   than AAA MUST NOT be transported to another entity."

To

"EAP keying material and parameters provided to a lower layer MUST NOT
be transported to another entity."
---
Change

"The exception to the "no sharing" rule is the AAA layer.  On EAP
   server, keying material requested by and passed down to the AAA layer
   may be replicated to the AAA layer on the authenticator.   On the
   authenticator, the AAA layer may provide the replicated keying
   material to the lower layer over which the EAP authentication
   conversation took place.  This enables "mode independence" to be
   maintained. "

To 

"The AAA layer may transport keys that are exported from the EAP server.
On EAP
   server, keying material requested by and passed down to the AAA layer
   may be replicated to the AAA layer on the authenticator.   On the
   authenticator, the AAA layer may provide the replicated keying
   material to the lower layer over which the EAP authentication
   conversation took place.  This enables "mode independence" to be
   maintained."

-----------
Section 2.3
-----------

Change 
"The caching behavior of existing EAP lower layers is as follows:"
To
"The caching behavior of existing EAP lower layers and AAA layers is as
follows:"

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

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

---

From: Jari Arkko <[email-masked]>
Date: Tue, 06 Dec 2005 08:14:30 +0200

>EAP Authenticator.  It is between these entities that the security
Yes. This also seems consistent with the RFC 3748
definition:

   [a] Lower layer.  The lower layer is responsible for transmitting and
       receiving EAP frames between the peer and authenticator.  ...

>the lower layer may obtain keys derived from the EMSK.  
I fear we may have some descriptions where EAP provides
some information "to the lower layer", and we need to make
sure that such text is changed so that it fits both the AAA and
integrated cases, without breaking mode independence.

>Section 2.1
Ok.

>Section 2.2
Ok.

> lower layers MUST NOT export keys passed down by EAP
Ok, I think...

>be transported to another entity."
Seems to prohibit distributed authenticators, including
802.11r. I'd be OK with this if we didn't exclude transportation
of keys derived from the provided keys.

>   conversation took place.  This enables "mode independence" to be
Ok.

Ok. Maybe s/AAA layers/AAA/

--Jari

---

From: Julien Bournelle <[email-masked]>
Date: Wed, 7 Dec 2005 18:24:15 +0100

Hi all,

> association protocol is typically run.  The MSK is transported to the

 just a question: what do we mean here by the security association
 protocol ? the protocol used to secure the access (e.g. IKE or 4
 way-handshake) or the EAP lower-layer ?
 
 I ask the question because in PANA, we have this distinction. From the
 AAA-Key, we derived the PANA_MAC_Key which is used to protect further
 PANA signaling between the EAP client (PaC) and the EAP Authenticator
 (PAA). We also derive a key from the AAA-Key which can be used as an
 IKE psk between the EAP peer (PaC) and the Enforcement Point located in
 the AR (cf. draft-ietf-pana-ipsec-xx.txt).

 Julien

-- 
julien.bournelle at int-evry.fr
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/eap

---

From: Jari Arkko <[email-masked]>
Date: Tue, 13 Dec 2005 14:42:31 +0200

> way-handshake) or the EAP lower-layer ?
Figure 2 and Section 3.1 should define this... let us know
otherwise. Its the client - NAS protocol to run after EAP has
completed.

> the AR (cf. draft-ietf-pana-ipsec-xx.txt).
I think that's fine.

--Jari

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 13 Dec 2005 10:43:16 -0500

I think there is an issue.

In the eap-keying draft, secure association protocol is to be run
between the peer and authenticator, but in draft-ietf-pana-pana and
draft-ietf-pana-framework, secure association protocol is to be run
between PaC and EP, where EP in the PANA model does not have
authenticator functionality.

We could resolve this issue by revising the definition of secure
association protocol such that it is run between peer port and
authenticator port.  This is not bad because the secure association
protocol is for particular pair of ports.

Yoshihiro Ohba

---

From: Jari Arkko <[email-masked]>
Date: Tue, 13 Dec 2005 18:17:26 +0200

Yes. But would issue 313 (distributed authenticators)
also solve the problem?

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 13 Dec 2005 11:43:33 -0500

I have read Issue 313, but I think it does not solve the SAP issue for
PANA because PANA EP is not authenticator or even part of
authenticator.

BTW, draft-nakhjiri-aaa-hokey-ps-00.txt is introducing another secure
association protocol named Link Secure Association Protocol (LSAP)
that is run between Mobile Node and Access Node.  To me "LSAP" and
"SAP" are the same protocol and "Access Node" and "authenticator port"
are the same entity.  I really think we need to avoid introducing
multiple terms pointing to similar things.

Yoshihiro Ohba

---

From: Jari Arkko <[email-masked]>
Date: Tue, 13 Dec 2005 18:54:28 +0200

>PANA because PANA EP is not authenticator or even part of
It could be, if you define authenticator = PAA + EP, or?

--Jari

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 13 Dec 2005 14:13:37 -0500

I see what you mean.  That works for me.

Thank you,
Yoshihiro Ohba

---

From: "Alper Yegin" <[email-masked]>
Date: Mon, 19 Dec 2005 14:54:16 +0200

> It could be, if you define authenticator = PAA + EP, or?

I have always perceived the "authenticator" as the node that hosts the
"EAP authenticator". We could say NAS = PAA + EAP + RADIUS_client + EP;
where we can see "EP" as a "NAS port".

Does this make sense?

Alper