Subject: [eap] Issue 177: Rewrite of SA sections

From: Bernard Aboba <[email-masked]>
Date: Thu, 25 Sep 2003 12:23:16 -0700 (PDT)

Issue 177: Rewrite of SA sections
Submitter name: Bernard Aboba
Submitter email address: [email-masked]
Date first submitted: 9/25/2003
Reference:
Document: Keyframe-07
Comment type: T
Priority: S
Section: 3.1-3.5
Rationale/Explanation of issue:

The SA discussion needs to be revised given recent Key Design team
discussions. Change sections 3.1-3.5 to:

"3.1  EAP SA

An EAP SA exists between the EAP peer and server.  It includes:

   the EAP peer identity
   the EAP server identity
   the EAP method type
   the EAP peer and server nonces
   the Transient EAP Keys (TEKs)
   the Master Session Key (MSK)
   the Extended Master Session Key (EMSK)

The EAP SA is not explicitly bound to a particular port on the EAP peer.
An EAP peer with multiple ports may create an EAP SA on one port and
then choose to use that SA to subsequently create a phase 2 SA on
another port.

It cannot be assumed that the EAP SA expires after the EAP
authentication and key derivation is complete.  Some methods may be
support "fast resume" by caching EAP SA state on the EAP peer and
server.

EAP does not support SA lifetime negotiation or an SA "delete"
operation, although some EAP methods may support this.  Either the EAP
peer or EAP server may delete an EAP SA at any time, and methods which
allow an EAP SA to persist need to permit the EAP peer and server to
recognize when they have gotten out of sync with respect to the EAP SA
state.

For example, EAP TLS [RFC 2716] supports "fast resume" (TLS session
resumption), which assumes that both the EAP peer and server cache EAP
master keys (the TLS master secret).  An EAP peer attempting a fast
resume provides the session-id identifying the session that it wishes to
resume.  If the EAP server retains the master key corresponding to this
session in its cache, then the "fast resume" can proceed; otherwise a
full TLS exchange ensues.

An EAP peer may negotiate EAP SAs with one or more EAP servers as the
result of pre-authentication or AAA load balancing and failover effects.
For example, an EAP peer may pre-authenticate to one or more EAP
servers, or may be directed to more than one EAP server as the result of
an authentication server becoming unreachable.  In general, EAP servers
cannot be assumed to be synchronized with respect to EAP SA state,
particularly since they may not exist within the same administrative
domain.  Since an EAP SA is typically created prior to secure
association, the EAP SA is not bound to a particular target network.

3.2.  AAA-Key SA

An AAA-Key SA exists between the authenticator and authentication
server. It includes:

   the EAP peer name
   the NAS/authenticator name
   the AAA-Key
   the AAA-Key maximum lifetime (if known)
   the AAA attributes sent in the Access-Accept

The AAA-Key SA is created as the result of the transport of the AAA-
Token from the authentication server to the NAS/authenticator.  The AAA-
Key SA is more specific than the EAP SA in that it is bound to a
particular authenticator, as defined by the NAS identification attributes
included in the AAA request.

For example, within RADIUS the NAS is identified by the NAS-Identifier,
NAS-IP-Address and NAS-IPv6-Address attributes.  Unless the attributes
providing explicit scoping are providing, it is assumed that the AAA-Key
is usable by the NAS to which it is delivered, without restriction.

Since the AAA-Key SA is bound to the NAS identified in the AAA Request, a
NAS/authenticator that operates on a shared use network will share the
AAA-Key SA between multiple virtual NAS devices. Since these virtual NAS
devices might appear to the peer to be different NASes, a mechanism is
needed for the EAP peer to differentiate them, so that the peer can
determine which devices a AAA-Key can be used with.

In the case of IEEE 802.11, it has been proposed that a "Group Identifier"
be added to the Beacon and Probe Response messages, containing a MAC
address uniquely identifying a particular Access Point.  Such a "Group
Identifier" could be included in the NAS-Identifier attribute so as to
uniquely identify a particular NAS to the AAA server.

Since a AAA-Key SA may be shared between virtual NASes, it is possible for
an EAP peer to successfully complete a fast handoff between virtual NASes
operating on the same physical NAS.  Since the virtual NASes may have
access to different networks or even exist within different administrative
domains, this creates a security problem unless the AAA attributes are
applied to the new session.

For example, an EAP peer authenticating to a GUEST network could
successfully complete a fast handoff to the CORPORATE network.  This would
be harmless if it only resulted in the peer receiving the GUEST service,
without obtaining additional time on the network.

Existing RADIUS attributes may not be adequate to this task.  For example,
today there are no standard attributes usable to indicate:

a. Which SSIDs a peer is authorized to attach to.
b. The absolute time at which a session is to end (as opposed to the
   Session-Time attribute which is relative)
c. The times of day during which access is allowed
d. The Calling-Station-Ids from which a client may access the network
e.  Whether fast handoff is permitted.

Attribute a) is useful so that when a client attempts a fast handoff to
the CORPORATE network from the GUEST network, the NAS checking the AAA
attributes will discover that the peer is only authorized for GUEST, not
CORPORATE.  As a result, the fast handoff attempt will fail.

Attribute b) can be used to prevent a peer attempting a fast handoff
between the GUEST network and another network from obtaining additional
session time.

Attribute c) can be used to prevent a peer from accessing the
network outside of authorized hours.

Attribute d) can be used to ensure that a peer is accessing the network
only from an administrator-authorized NIC.  This might be important in
high security installations.

Attribute e) might be useful in situations where the administrator desires
to limit deployment of fast handoff.

In fast handoff, a single EAP SA may be used to establish multiple AAA-
Key SAs (see Appendix E for details).  Although a AAA-Key SA may not
persist longer than the maximum SA lifetime negotiated for an EAP SA
(for methods that support such a negotiation), if an EAP SA is deleted
by an EAP peer or authenticator, this does not necessarily imply
deletion of the child AAA-Key SA.  For example, fast handoff keying
material provided by an authentication server may continue to be cached
by NASes/authenticators after the corresponding EAP SA has been deleted
by the authentication server and/or peer.

3.3.  Unicast Secure Association SA

The unicast secure association SA exists between the EAP peer and
authenticator. It includes:

   the peer port identifier (Calling-Station-Id)
   the NAS port identifier (Called-Station-Id)
   the unicast Transient Session Keys (TSKs)
   the unicast secure association peer nonce
   the unicast secure association authenticator nonce
   the negotiated unicast capabilities and unicast ciphersuite.

During the phase 2a exchange, the EAP peer and authenticator demonstrate
mutual possession of the AAA-Key derived and transported in phase 1;
securely negotiate the session capabilities (including unicast
ciphersuites), and derive fresh unicast transient session keys.  The
AAA-Key SA (phase 1b) is therefore used to create the unicast secure
association SA (phase 2a), and in the process the phase 2a unicast
secure association SA is bound to ports on the EAP peer and
authenticator.  However in order for a phase 2a security association to
be established, it is not necessary for the phase 1a exchange to be
rerun each time.  This enables the EAP exchange to be bypassed when fast
handoff support is desired.

Since both peer and authenticator nonces are used in the creation of the
unicast secure association SA,  the transient session keys (TSKs) are
guaranteed to be fresh, even if the AAA-Key is not.  As a result one or
more unicast secure association SAs (phase 2a) may be derived from a
single AAA-Key SA (phase 1b).  The phase 2a security associations may
utilize the same security parameters (e.g. mode, ciphersuite, etc.) or
they may utilize different parameters.

A unicast secure association SA (phase 2a) may not persist longer than
the maximum lifetime of its parent AAA-Key SA (if known). However, the
deletion of a parent EAP or AAA-Key SA does not necessarily imply
deletion of the corresponding unicast secure association SA.  Similarly,
the deletion of a unicast secure association protocol SA does not imply
the deletion of the parent AAA-key SA or EAP SA.  However, the failure
to mutually prove possession of the AAA-Key during the unicast secure
association protocol exchange (phase 2a) is grounds for removal of a
AAA-Key SA by both parties.

An EAP peer may be able to negotiate multiple phase 2a SAs with a single
EAP authenticator, or may be able to maintain multiple phase 2a SAs with
multiple authenticators, based on a single EAP SA derived in phase 1a.
For example, during a re-key of the secure association protocol SA, it
is possible for two phase 2a SAs to exist during the period between when
the new phase 2a SA parameters (such as the TSKs) are calculated and
when they are installed. Except where explicitly specified by the
semantics of the unicast secure association protocol, it should not be
assumed that the installation of a new phase 2a SA necessarily implies
deletion of the old phase 2a SA.

On some media (e.g. 802.11) a port on an EAP peer may only establish
phase 2a and 2b SAs with a single port of an authenticator within a
given Local Area Network (LAN).  This implies that the successful
negotiation of phase 2a and/or 2b SAs between an EAP peer port and a new
authentiator port within a given LAN implies the deletion of existing
phase 2a and 2b SAs with authenticators offering access to that Local
Area Network (LAN).  However, since a given IEEE 820.11 SSID may be
comprised of multiple LANs, this does not imply an implicit binding of
phase 2a and 2b SAs to an SSID.

3.4.  Multicast Secure Association SA

The multicast secure association SA includes:

   the multicast Transient Session Keys
   the direction vector (for a uni-directional SA)
   the negotiated multicast capabilities and multicast ciphersuite

It is possible for more than one multicast secure association SA to be
derived from a single unicast secure association SA.   However, a
multicast secure association SA is bound to a single EAP SA and a single
AAA-Key SA.

During a re-key of the multicast secure association protocol SA, it is
possible for two phase 2b SAs to exist during the period between when
the new phase 2b SA parameters (such as the multicast TSKs) are
calculated and when they are installed. Except where explicitly
specified by the semantics of the multicast secure association protocol,
it should not be assumed that the installation of a new phase 2b SA
necessarily implies deletion of the old phase 2b SA.

A multicast secure association SA (phase 2b) may not persist longer than
the maximum lifetime of its parent AAA-Key or unicast secure association
SA.  However, the deletion of a parent EAP, AAA-Key or unicast secure
association SA does not necessarily imply deletion of the corresponding
multicast secure association SA.  For example, a unicast secure
association SA may be rekeyed without implying a rekey of the multicast
secure association SA.

Similarly, the deletion of a multicast secure association protocol SA
does not imply the deletion of the parent EAP, AAA-Key or unicast secure
association SA.  However, the failure to mutually prove possession of
the AAA-Key during the unicast secure association protocol exchange
(phase 2a) is grounds for removal of the AAA-Key, unicast secure
association and multicast secure association SAs.

3.5.  Key Naming

In order to support the correct processing of phase 2 security
associations, the secure association (phase 2) protocol supports the
naming of phase 2 security associations and associated transient session
keys, so that the correct set of transient session keys can be
identified for processing a given packet.  Explicit creation and
deletion operations are also typically supported so that establishment
and re-establishment of transient session keys can be synchronized
between the parties.

In order to securely bind the EAP security association (phase 1) to its
child phase 2 security association, the phase 2 secure association
protocol allows the EAP peer and authenticator to mutually prove
possession of the EAP (phase 1) keying material derived during the EAP
exchange (phase 1).  In order to avoid confusion in the case where an
EAP peer has more than one EAP security association (phase 1) applicable
to establishment of a given phase 2 security association, the secure
association protocol (phase 2) supports key naming so that the
appropriate phase 1 keying material can be utilized by both parties in
the secure association protocol exchange.

As noted earlier, the discovery phase (phase 0) may be insecure so that
in order to prevent spoofing of discovery packets, the secure
association (phase 2) protocol should support the secure verification of
discovered capabilities, including ciphersuites and other security
parameters.  This is more scalable than attempting to configure the
supported capabilities on each peer and authenticator and more secure
than unprotected capabilities negotiation.

For example, a peer might be pre-configured with policy indicating the
ciphersuite to be used in communicating with a given authenticator.
Within PPP, the ciphersuite is negotiated within the Encryption Control
Protocol (ECP), after EAP authentication is completed. Within
[IEEE80211i], the AP ciphersuites are advertised in the Beacon and Probe
Responses, and are securely verified during a 4-way exchange after EAP
authentication has completed.

As part of the secure association protocol (phase 2), it is necessary to
bind the Transient Session Keys (TSKs) to the keying material provided
in the AAA-Token.  This ensures that the EAP peer and authenticator are
both clear about what key to use to provide mutual proof of possession.
Keys within the EAP key hierarchy are named as follows:

EAP SA name
     The EAP security association is negotiated between the EAP peer and
     EAP server, and is uniquely named as follows <EAP peer name, EAP
     server name, EAP Method Type, EAP peer nonce, EAP server nonce>.
     Here the EAP peer name and EAP server name are the identifiers
     securely exchanged within the EAP method.  Since multiple EAP SAs
     may exist between an EAP peer and EAP server, the EAP peer nonce
     and EAP server nonce allow EAP SAs to be differentiated.  The
     inclusion of the Method Type in the EAP SA name ensures that each
     EAP method has a distinct EAP SA space.

MK Name
     The EAP Master Key, if supported by an EAP method, is named by the
     concatenation of the EAP SA name and a method-specific session-id.

AAA-Key Name
     The AAA-Key is named by the concatenation of the EAP SA name,
     "AAA-Key" and the authenticator name, since the AAA-Key is bound
     to a particular authenticator. For the purpose of identification,
     the NAS-Identifier attribute is recommended.  In order to ensure that
     all parties can agree on the NAS name this requires the NAS to
     advertise its name (typically using a media-specific mechanism,
     such as the 802.11 Beacon/Probe Response)."

_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap