eap Mailing List: Re: Issue 177: Rewrite of SA sections

[Jari Arkko (jari.arkko]

Bernard,

The text that you provided looks very good (thanks!)
but I still do have some question marks. Inline:

> "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.

Hmm... what do you mean in a concrete sense, the SSID?
But wouldn't this be a problem, since typically (at least
in RADIUS) the auth and authz happen in the same messages.
If we decide the "particular target network" or the SSID
after this (using Pasi's terms, after phase 1b), it appears
to be too late to decide where the user is allowed to go.

Or perhaps you mean that the EAP SA is not bound to the
particular AP (or its BSSID or group id)?

> 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-

As discussed elsewhere, AAA in the name is somewhat confusing
and "SA" is also a bit confusing given that one of the parties
will immediately forget what it sent as the SA. Is this more
like a ticket?

> 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.

Agreed, but I think we should also state the following:
"Current AAA servers make authorization decisions
both by sending attributes as well as making a dynamic
decision. If fast handoff mechanisms
do not involve a new AAA exchange for checking the authorization
again, all dynamic decision criteria from the AAA server need to
be communicated via attributes. Even this approach has limitations,
as it can not be used to implement state-based decisions, such
as limiting the number of concurrent sessions to 1 per user."

> 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.

Good list. Are we taking care of this in RADIUSEXT?

> 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.

Yes -- I like the idea of being able to turn off a feature which has
a complicated security design without a lot of mileage behind it yet...

> 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.

Hmmm... if the SAs are for multicast, they need to be bound to
more than one EAP SA at least on the other end, right? Otherwise
they could not be used for communicating to more than one entity.
But I may miss something, I haven't studied the 11i multicast
SAs, for instance.

> 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
> eap [at] frascone.com
> http://mail.frascone.com/mailman/listinfo/eap

--Jari