Subject: [eap] issue: distributed authenticators (review of eap-keying-08 by mats naslund)

From: Jari Arkko <[email-masked]>
Date: Thu, 01 Dec 2005 07:28:56 +0200

Submitter name: Mats Naslund
Submitter email address: [email-masked]
Reference: (this email)
Document: Keying Framework
Comment type: T
Priority: 1
Section: multiple
Rationale/Explanation of issue:

     Encryption Key" (Enc-SEND-Key) (reception is defined from the point
     of view of the authenticator).  Within [IEEE-802.11i] Octets 0-31
     of the MSK (Enc-RECV-Key) are known as the Pairwise Master Key
     (PMK).  In [IEEE-802.11i] the TKIP and AES CCMP ciphersuites derive
     their Transient Session Keys (TSKs) solely from the PMK, whereas
     the WEP ciphersuite as noted in [RFC3580], derives its TSKs from
     both halves of the MSK.

MN: See comment a few lines down.

Transient EAP Keys (TEKs)
     Session keys which are used to establish a protected channel
     between the EAP peer and server during the EAP authentication
     exchange. The TEKs are appropriate for use with the ciphersuite
     negotiated between EAP peer and server for use in protecting the
     EAP conversation.  The TEKs are stored locally by the EAP method
     and are not exported.  Note that the ciphersuite used to set up the
     protected channel between the EAP peer and server during EAP
     authentication is unrelated to the ciphersuite used to subsequently
     protect data sent between the EAP peer and authenticator.  An
     example TEK key hierarchy is described in Appendix A.

Transient Session Keys (TSKs)
     Session keys used to protect data exchanged in a session between
     the peer and authenticator after the EAP authentication has
     successfully completed.  TSKs are appropriate for the lower layer
     ciphersuite negotiated between the ports of the EAP peer and
     authenticator.  Examples of TSK derivation are provided in Appendix
     B.

MN: Here I have some trouble... This seems to mandate that protection
(on the network side) MUST be terminated in the authenticator.
In WiMAX, the authenticator is in the AGW, but the session protection
is in the BS.

I.e. it is not clear why both PMK and TSK should be shared between the
same two entities... Doesn't one shared key suufice?

   TSKs are permitted to be accessed only by the EAP peer and
   authenticator.  Since the TSKs can be determined from the transported

MN: does this imply that the authenticator always needs to be in the
"base station"? (since the base station will know TSKs)

_________________________________________________________________
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: Wed, 30 Nov 2005 22:25:35 -0800

The key framework document does not constrain the authenticator 
implementation. For
example, any of the CAPWAP architectures can be used.

The EAP conversation is between the peer and server. These are the only 
identities
that matter to the parties; the authenticator identity, if known at all, is 
only treated
as an opaque blob for the purposes of Channel bindings.

However, the SAP conversation is between the peer and the authenticator. It 
is possible for
multiple base stations and a "controller" (e.g. WLAN switch) to comprise a 
single authenticator.
Since an authenticator may have many ports, the authenticator ID is distinct 
from any port
identifier (e.g. BSSID).

Therefore from the point of view of the EAP peer, the "base station 
identity"
(e.g. Called-Station-ID) is irrelevant except as an opaque blob to be used 
in
Channel Bindings. All that matters is the authenticator identity, because 
that
defines the scope of the EAP keying material. Many base stations can share 
the
same authenticator identity.

Having said this, the scope of the Transient Session Keys is defined by the 
SAP. Typically
a SAP will bind the TSKs to a particular port, so that the session keys do 
*not* have
authenticator-wide scope -- they can only be used on a particular port (e.g. 
layer 2
endpoint address). But this is not a requirement; an authenticator can allow
TSKs to be reused on different ports assuming that it can guarantee TSK 
freshness
(such as by keeping centralized replay counter state). My understanding is 
that some
WLAN switches allow multiple ports to use the same TSK with IEEE 802.11i.

Perhaps it would be more clear to state:

Transient Session Keys (TSKs)
    Session keys used to protect data exchanged after EAP authentication
has successfully completed, using the ciphersuite negotiated
between the EAP peer and authenticator.

>From: Jari Arkko <[email-masked]>
>To: [email-masked]
>CC: "Mats Näslund (KI/EAB)" <[email-masked]>
>Subject: [eap] issue: distributed authenticators (review of eap-keying-08 
>by mats naslund)
>Date: Thu, 01 Dec 2005 07:28:56 +0200
>

---

From: Jari Arkko <[email-masked]>
Date: Fri, 02 Dec 2005 08:13:11 +0200

Ok. But I wonder if it would be good to have some of the
text from your e-mail below even in the document.

--Jari

Bernard Aboba wrote:

> The EAP conversation is between the peer and server. These are the 
> only identities
> that matter to the parties; the authenticator identity, if known at 
> all, is only treated
> However, the SAP conversation is between the peer and the 
> authenticator. It is possible for
> multiple base stations and a "controller" (e.g. WLAN switch) to 
> comprise a single authenticator.
> Since an authenticator may have many ports, the authenticator ID is 
> distinct from any port
> identifier (e.g. BSSID).
>
> (e.g. Called-Station-ID) is irrelevant except as an opaque blob to be 
> used in
> Channel Bindings. All that matters is the authenticator identity, 
> because that
> defines the scope of the EAP keying material. Many base stations can 
> share the
> Having said this, the scope of the Transient Session Keys is defined 
> by the SAP. Typically
> a SAP will bind the TSKs to a particular port, so that the session 
> keys do *not* have
> authenticator-wide scope -- they can only be used on a particular port 
> (e.g. layer 2
> TSKs to be reused on different ports assuming that it can guarantee 
> TSK freshness
> (such as by keeping centralized replay counter state). My 
> understanding is that some
>> Subject: [eap] issue: distributed authenticators (review of 
>> eap-keying-08 by mats naslund)