eap Mailing List: Re: issue: distributed authenticators (review of eap-keying-08 by mats naslund)

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 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 <jari.arkko [at] piuha.net>

To: eap [at] frascone.com

CC: "Mats Näslund (KI/EAB)" <mats.naslund [at] ericsson.com>

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

Date: Thu, 01 Dec 2005 07:28:56 +0200
Submitter name: Mats Naslund
Submitter email address: Mats.Naslund [at] ericsson.com
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

Re: issue: distributed authenticators (review of eap-keying-08 by mats naslund)	<– Date –> <– Thread –>
From: Jari Arkko (jari.arkkopiuha.net)
Date: Fri, 2 Dec 2005 07:35:25 -0800 (PST)

eap Mailing List
View Index by: Date - Thread - Author