Subject: [eap] PANA and EAP keying framework

From: Yoshihiro Ohba <[email-masked]>
Date: Mon, 09 Jan 2006 22:02:01 -0500

Description of issue
Submitter name: Yoshihiro Ohba
Submitter email address: [email-masked]
Date first submitted: Insert_Date_Here
Reference: 
Document: Keying Framework
Comment type: 'T'
Priority: '1'
Section: 2.3
Rationale/Explanation of issue: It would be useful to add some
description on how PANA handle the caching of EAP keying material and
the generation of transient session keys.

Requested change:

Add the following description in Section 2.3:

"
PANA 

     PANA [I-D.ietf-pana-pana] supports caching of the MSK, but not
     the EMSK, IV, Session-ID, Peer-ID or Server-ID.  In the PANA
     model [I-D.ietf-pana-framework], TSKs are generated using a
     Secure Association Protocol between the peer and and
     authenticator port (which is referred to as an Enforcement
     Point), where both link-layer specific key exchange protocols and
     IKE can be used as the Secure Association Protocol depending on
     whether link-layer ciphering or IPsec is used between the peer
     and the authenticator port.  The key scope and lifetime of the
     TSKs are communicated from the authenticator to the peer.  The
     key scope is specified as a list of device identifiers of the
     Enforcement Points.  Depending on the Secure Association
     Protocol in use, TSK rekey is possible without EAP
     re-authentication.
"
_________________________________________________________________
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: Mon, 09 Jan 2006 22:59:25 -0800

>      TSKs are generated using a Secure Association Protocol

Can you elaborate on this?  If the TSKs are generated via an IKE DH 
exchange, with the MSK used only for authentication (as in  IKEv2/EAP) then 
the TSKs are not dependent on the MSK and PFS is possible, right?

>      between the peer and and authenticator port

Not sure I understand this.   The SAP exchange is between the peer and 
authenticator, not between specific ports.  However, a result of the SAP 
exchange can be derivation of TSKs which are bound to specific ports.

>      and the authenticator port.

What is a "link-layer specific key exchange protocol"?  Are we talking about 
existing SAPs such as 802.11i 4-way handshake, or something else?

>      The key scope and lifetime of the
>      TSKs are communicated from the authenticator to the peer.

How?  IKE does not define explicit lifetimes, nor does it care about key 
scope because it doesn't support caching.

>      The key scope is specified as a list of device identifiers of the
>      Enforcement Points.

This doesn't make sense where IKE is used as the SAP unless we are talking 
about MOBIKE (which can move SAs between addresses).

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 10 Jan 2006 11:20:54 -0500

> the TSKs are not dependent on the MSK and PFS is possible, right?

Yes.  When IKE is used as the SAP, the IKE PSK derived from MSK is
used only for peer entity authentication for IKE DH and thus PFS is
possible.  On the other hand when IEEE 802.11i 4-way handshake is used
as the SAP, PFS is possible if the negotiated EAP method supports
this.

> exchange can be derivation of TSKs which are bound to specific ports.

Since an authenticator port part of authenticator, it does not seem to 
conflict with the statement that the SAP exchange is between the peer and 
authenticator.

> What is a "link-layer specific key exchange protocol"?  Are we talking 
> about existing SAPs such as 802.11i 4-way handshake, or something else?

Yes, 802.11i 4-way handshake is a link-layer specific key exchange
protocol.

> scope because it doesn't support caching.

The lifetime of PANA session is carried in PANA message.  This
lifetime is the same as the authorization lifetime which is also same
as the lifetime of the MSK.  Then, draft-ietf-pana-ipsec specifies
that when IKE is used as the SAP, the lifetime of the IKE SA is bound
to the lifetime of the MSK.

Regarding the key scope, it is important for the peer to know which
authenticator ports (Enforcement Points) belong to the authenticator
the peer is communicating.  This fact does not seem to depend on the
type of the SAP.  The list of EPs clearly defines the key scope.

> about MOBIKE (which can move SAs between addresses).

Even without mobility, the peer can choose any one or more of EPs to
secure data traffic using IPsec (e.g., for load balancing purpose).
The list of EPs can make sense to help the peer to know the choices.

Yoshihiro Ohba

---

From: "Bernard Aboba" <[email-masked]>
Date: Tue, 10 Jan 2006 08:35:29 -0800

>as the SAP, PFS is possible if the negotiated EAP method supports

The IEEE 802.11i standard does not support PANA, so how can this work?

A single "virtual AP" either allows "open" authentication, or it requires 
802.11i, but it can't do both simultaneously.  Therefore PANA cannot be used 
for the initial authentication, since PANA traffic will be dropped by the AP 
prior to completion of 802.1X.

>conflict with the statement that the SAP exchange is between the peer and

Are you saying that the exchange isn't between ports, but just between the 
authenticator and peer?

>as the lifetime of the MSK.

Since IKEv2 does not support caching of EAP keying parameters, including the 
MSK, the PANA lifetime cannot be used; the MSK is discarded by IKEv2 
regardless of what is in the PANA lifetime.

>Then, draft-ietf-pana-ipsec specifies

The IPsec SA lifetime is determined by IKE, not PANA.  Since IKE discards 
the MSK after it completes, there is no notion of an MSK lifetime in IKE.

>type of the SAP.  The list of EPs clearly defines the key scope.

So PANA attempts to modify the IPsec SADB?

---

From: Jari Arkko <[email-masked]>
Date: Tue, 10 Jan 2006 18:35:53 +0200

Yoshi, Bernard,

>It would be useful to add some

Yes,this would be useful. Thanks for the input.

> exchange, with the MSK used only for authentication (as in  IKEv2/EAP) 
> then the TSKs are not dependent on the MSK and PFS is possible, right?

Yes.  But PANA does not mandate IKE, it could also run with some 
yet-to-be-designed
L2 mechanism that does not offer PFS.

> authenticator, not between specific ports.  However, a result of the 
> SAP exchange can be derivation of TSKs which are bound to specific ports.

In PANA, the authenticator can be "distributed", i.e., consist of the
point where the EAP/AAA handling happens, and multiple enforcement
points where the L2/L3 crypto for the actual session is terminated.

Anyway, the term "port" is somewhat confusing here... not well
defined.

> about existing SAPs such as 802.11i 4-way handshake, or something else?

802.11i is mentioned as a specific example in the documents,
but I don't know if the details of how to use PANA with it
are written down anywhere. The details about IKE usage
are in draft-ietf-pana-ipsec.

It might be an idea to explain the pana/ike case here, and
not the open-ended other possible scenarios.

> How?  IKE does not define explicit lifetimes, nor does it care about 
> key scope because it doesn't support caching.

Identifiers of the parties and session are delivered to the enforcement
point. The client also knows them. Lifetime can be known by the
enforcement point and locally enforced, but as you note it can not
be communicated to the client under IKEv2.

> This doesn't make sense where IKE is used as the SAP unless we are 
> talking about MOBIKE (which can move SAs between addresses).

According to draft-ietf-pana-ipsec, from the enforcement
point's point of view, the scope is exactly one EP.

--Jari

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 10 Jan 2006 15:20:36 -0500

On Tue, Jan 10, 2006 at 08:35:29AM -0800, Bernard Aboba wrote:
> 802.11i, but it can't do both simultaneously.  Therefore PANA cannot be 
> used for the initial authentication, since PANA traffic will be dropped by 
> the AP prior to completion of 802.1X.

I don't think 802.11i prohibits any IP traffic to pass throuth
uncontrolled port before 4-way handshake.  In fact, there is a
description in section 5.4.2.2 of IEEE 802.11i 2004 specification:

" 
IEEE 802.1X Supplicants and Authenticators exchange
protocol information via the IEEE 802.1X Uncontrolled Port. It is
expected that most other protocol exchanges will make use of the IEEE
802.1X Controlled Ports. However, a given protocol may need to bypass
the authorization function and make use of the IEEE 802.1X
Uncontrolled Port.
"

Section 10.2.2 of draft-ietf-pana-framework-05.txt has general 
description on IEEE 802.11i usage in PANA.

> Since IKEv2 does not support caching of EAP keying parameters, including 
> the MSK, the PANA lifetime cannot be used; the MSK is discarded by IKEv2 

When IKEv2 is used as the SAP for PANA, the usage is different from
that of running EAP over IKEv2.  In the PANA usage, IKE pre-shared key
and IKE SA lifetime are dynamically configured and unconfigured using
EAP parameters obtained by running PANA/EAP, while those parameters
are most likely be statically configured in non-PANA IKEv2 usage.

> So PANA attempts to modify the IPsec SADB?

Yes.

Yoshihiro Ohba