| Rewrite of Key Framework Section 3 | <– Date –> <– Thread –> |
From: Bernard Aboba (aboba internaut.com)
|
|
| Date: Sun, 4 Apr 2004 18:31:20 -0400 (EDT) | |
I'm not posting this as an issue or resolution yet, since the text needs
quite a bit more work. But here is the strawman text of Section 3.
Comments welcome.
3. Security Associations
EAP key management involves five types of security associations
(SAs):
[1] EAP SA. This is an SA between the peer and EAP server, which
allows them to authenticate each other.
[2] EAP method SA. This SA is also between the peer and EAP server.
It stores state that can be used for "fast resume" or other
functionality in some EAP methods. Not all EAP methods create such
an SA.
[3] EAP-Key SA. This is an SA between the peer and EAP server, which
is used to store the keying material exported by the EAP method.
Current EAP server implementations do not retain this SA after the
EAP conversation completes, but future implementations could use
this SA for pre-emptive key distribution.
[4] AAA SA(s). These SAs are between the authenticator and the backend
authentication server. They permit the parties to mutually
authenticate each other and protect the communications between
them.
[5] Service SA(s). These SAs are between the peer and authenticator,
and they are created as a result of phases 1-2 of the conversation
(see Section 1.3).
3.1. EAP SA (peer - EAP server)
In order for the peer and EAP server to authenticate each other, they
need to store some information.
The authentication can be based on different mechanisms, such as
shared secrets or certificates. If the authentication is based on a
shared secret key, the parties store the EAP method to be used and
the key. The EAP server also stores the peer's identity and/or other
information necessary to decide whether access to some service should
be granted. The peer stores information necessary to choose which
secret to use for which service.
3.2. EAP Method SA (peer - EAP server)
An EAP method may store some state on the peer and EAP server even
after phase 1a has completed.
Typically, this is used for "fast resume": the peer and EAP server
can confirm that they are still talking to the same party, perhaps
using fewer roundtrips or less computational power. In this case,
the EAP method SA is essentially a cache for performance
optimization, and either party may remove the SA from its cache at
any point.
An EAP method may also keep state in order to support pseudonym-based
identity protection. This is typically a cache as well (the
information can be recreated if the original EAP method SA is lost),
but may be stored for longer periods of time.
The EAP method SA is not restricted to a particular service or
authenticator and is most useful when the peer accesses many
different authenticators.
An EAP method is responsible for specifying how the parties select if
an existing EAP method SA should be used, and if so, which one.
Where multiple backend authentication servers are used, EAP method
SAs are not typically synchronized between them.
EAP method implementations should consider the appropriate lifetime
for the EAP method SA. "Fast resume" assumes that the information
required (primarily the keys in the EAP method SA) hasn't been
compromised. In case the original authentication was carried out
using, for instance, a smart card, it may be easier to compromise the
EAP method SA (stored on the PC, for instance), so typically the EAP
method SAs have a limited lifetime.
Contents:
o Implicitly, the EAP method this SA refers to
o One or more internal (non-exported) keys
o EAP method SA name
o SA lifetime
3.2.1. Example: EAP-TLS
In EAP-TLS [RFC2716], after the EAP authentication the client (peer)
and server can store the following information:
o Implicitly, the EAP method this SA refers to (EAP-TLS)
o Session identifier (a value selected by the server)
o Certificate of the other party (server stores the clients's
certificate and vice versa)
o Ciphersuite and compression method
o TLS Master secret (known as the EAP-TLS Master Key or MK)
o SA lifetime (ensuring that the SA is not stored forever)
o If the client has multiple different credentials (certificates
and
corresponding private keys), a pointer to those credentials
When the server initiates EAP-TLS, the client can look up the EAP-TLS
SA based on the credentials it was going to use (certificate and
private key), and the expected credentials (certificate or name) of
the server. If an EAP-TLS SA exists, and it is not too old, the
client informs the server about the existence of this SA by including
its Session-Id in the TLS ClientHello message. The server then looks
up the correct SA based on the Session-Id (or detects that it doesn't
yet have one).
3.2.2. Example: EAP-AKA
In EAP-AKA [I-D.arkko-pppext-eap-aka], after EAP authentication the
client and server can store the following information:
o Implicitly, the EAP method this SA refers to (EAP-AKA)
o A re-authentication pseudonym
o The client's permanent identity (IMSI) (server)
o Replay protection counter
o Authentication key (K_aut)
o Encryption key (K_encr)
o Original Master Key (MK)
o SA lifetime (ensuring that the SA is not stored forever)
When the server initiates EAP-AKA, the client can look up the EAP-AKA
SA based on the credentials it was going to use (permanent identity).
If an EAP-AKA SA exists, and it is not too old, the client informs
the server about the existence of this SA by sending its re-
authentication pseudonym as its identity in EAP Identity Response
message, instead of its permanent identity. The server then looks up
the correct SA based on this identity.
3.3. EAP-key SA
This is an SA between the peer and EAP server, which is used to store
the keying material exported by the EAP method. Current EAP server
implementations do not retain this SA after the EAP conversation
completes, but future implementations could use this SA for pre-
emptive key distribution.
Contents:
o Name/identifier for this SA
o Identities of the parties
o MSK and EMSK
3.4. AAA SA(s) (authenticator - backend auth. server)
In order for the authenticator and backend authentication server to
authenticate each other, they need to store some information.
In case the authenticator and backend authentication server are
colocated, and they communicate using local procedure calls or shared
memory, this SA need not necessarily contain any information.
3.4.1. Example: RADIUS
In RADIUS, where shared secret authentication is used, the client and
server store each other's IP address and the shared secret, which is
used to calculate the Response Authenticator [RFC2865] and Message-
Authenticator [RFC3579] values, and to encrypt some attributes (such
as the AAA-Key [RFC2548]).
Where IPsec is used to protect RADIUS [RFC3579] and IKE is used for
key management, the parties store information necessary to
authenticate and authorize the other party (e.g. certificates, trust
anchors and names). The IKE exchange results in IKE Phase 1 and
Phase 2 SAs containing information used to protect the conversation
(session keys, selected ciphersuite, etc.)
3.4.2. Example: Diameter with TLS
When using Diameter protected by TLS, the parties store information
necessary to authenticate and authorize the other party (e.g.
certificates, trust anchors and names). The TLS handshake results in
a short-term TLS SA that contains information used to protect the
actual communications (session keys, selected TLS ciphersuite, etc.).
3.5. Secure Association SAs
3.5.1. Unicast Secure Association SA
The unicast Secure Association SA exists between the EAP peer and
authenticator. It includes:
o the peer port identifier (Calling-Station-Id)
o the NAS port identifier (Called-Station-Id)
o the unicast Transient Session Keys (TSKs)
o the unicast Secure Association peer nonce
o the unicast Secure Association authenticator nonce
o 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. Failure to mutually prove possession of the
AAA-Key during the unicast Secure Association Protocol exchange
(phase 2a) need not be grounds for removal of a AAA-Key SA by both
parties; rate-limiting unicast Secure Association exchanges should
suffice to prevent a brute force attack.
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 802.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.5.2. Multicast Secure Association SA
The multicast Secure Association SA includes:
o the multicast Transient Session Keys
o the direction vector (for a uni-directional SA)
0 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. Failure to mutually prove possession of the
AAA-Key during the unicast Secure Association Protocol exchange
(phase 2a) need not be grounds for removal of the AAA-Key, unicast
Secure Association and multicast Secure Association SAs; rate-
limiting unicast Secure Association exchanges should suffice to
prevent a brute force attack.
3.6. Service SA(s) (peer - authenticator)
The service SA stores information about the service being provided.
This includes:
o Service parameters (or at least those parameters
that are still needed)
o On the authenticator, service authorization
information received from the backend authentication
server (or necessary parts of it)
o On the peer, usually locally configured service
authorization information.
o Transient Session Keys used to protect the communication
o The AAA-Key, if it can be needed again (to refresh
(and/or resynchronize other keys or for another reason)
The information in the service SA can be grouped into several
different SAs. This would make sense if, for instance, the service
provided is naturally divided into several different subconversations
with different parameters.
How exactly the relevant service SA is chosen at each point depends
on the protocol; see below for examples.
3.6.1. Example: 802.11i
Note that this example is intended to be informative, and it does not
necessarily include all information stored.
o PMKSA
- Key (PMK)
- PMKID
- SSID
- Supplicant and authenticator group addresses (PMKSA can be
used if the SSID and group addresses stay the same)
- Key replay counters (for EAPOL-Key messages)
- Lifetime information (that can be different client and AP)
- Reference to PTKSA (if any), needed for:
- to delete it (e.g. AAA server-initiated disconnect)
- to replace it when a new four-way handshake is done
after reauthentication
- Authorization information. On the authenticator, this
can be locally configured or received from the backend
authentication server. On the peer, this is usually
locally configured.
- Reference to accounting context (the details of which depend
on the accounting protocol used, and various implementation
and administrative details. In RADIUS, this could include
(e.g. packet and octet counters, and Acct-Multi-Session-Id).
o PTKSA
The PTKSA is created based on the four-way handshake. When receiving
or sending a packet, the correct PTKSA is looked up based on TA and
RA (Transmitter/Received Address).
- Key (PTK)
- Selected ciphersuite
- MAC addresses of the parties
- Replay counters, and ciphersuite specific state
- Reference to PMKSA: This is needed for
- If a new four-way handshake is needed (lifetime, TKIP
countermeasures), we need to know which PMKSA to use
- Via the reference to PMKSA, or copied here:
- SSID (to select VLAN tags)
- Authorization information (such as L2 packet filters)
- Reference to accounting context (right counters etc.)
o GTKSA
The GTKSA is created based on the four-way handshake, or the four-way
handshake and a separate group key handshake. When receiving a
packet, the correct GTKSA is looked up based on source MAC address.
When sending a packet, this is looked up by own MAC address and SSID.
- Direction bit
- Key (GTK)
- Sender (AP) MAC address
- Selected cipher suite
- Ciphersuite-specific data
- Via reference to PMKSA, or copied here:
- SSID (to select VLAN tags)
- Reference to accounting context
3.6.2. Example: IKEv2/IPsec
Note that this example is intended to be informative, and it does not
necessarily include all information stored.
o IKEv2 SA
- Protocol version
- Identitites of the parties
- IKEv2 SPIs
- Selected ciphersuite
- Replay protection counters (Message ID)
- Keys for protecting IKEv2 messages (SK_ai/SK_ar/SK_ei/SK_er)
- Key for deriving keys for IPsec SAs (SK_d)
- Lifetime information
- On the authenticator, service authorization information
received from the backend authentication server.
When processing an incoming message, the correct SA is looked up based
on the SPIs.
o IPsec SAs/SPD
- Traffic selectors
- Replay protection counters
- Selected ciphersuite
- IPsec SPI
- Keys
- Lifetime information
- Protocol mode (tunnel or transport)
The correct SA is looked up based on SPI (for inbound packets), or SPD
traffic selectors (for outbound traffic). A separate IPsec SA exists for
each direction.
3.6.3. Sharing service SAs
A single service may be provided by multiple logical or physical
service elements. Each service is responsible for specifying how
changing service elements is handled. Some approaches include:
Transparent sharing
If the service parameters visible to the other party (either peer
or authenticator) do not change, the service can be moved without
requiring cooperation from the other party. Whether such a move
should be supported or used depends on implementation and
administrative considerations. For instance, an administrator may
decide to configure a group of IKEv2/IPsec gateways in a cluster
for high-availability purposes, if the implementation used supports
this. The peer does not necessarily have any way of knowing when
the change occurs.
No sharing
If the service parameters require changing, some changes may
require terminating the old service, and starting a new
conversation from phase 0. This approach is used by all services
for at least some parameters, and it doesn't require any protocol
for transferring the service SA between the service elements.
The service may support keeping the old service element active
while the new conversation takes phase, to decrease the time the
service is not available.
Some sharing
The service may allow changing some parameters by simply agreeing
about the new values. This may involve a similar exchange as in
phase 2, or perhaps a shorter conversation.
This option usually requires some protocol for transferring the
service SA between the elements. An administrator may decide not to
enable this feature at all, and typically the sharing is restricted
to some particular service elements (defined either by a service
parameter, or simple administrative decision). If the old and new
service element do not support such "context transfer", this
approach falls back to the previous option (no transfer).
Services supporting this feature should also consider what changes
require new authorization from the backend authentication server
(see Section 1.7).
Note that these considerations are not limited to service
parameters related to the authenticator--they apply to peer's
parameters as well.
3.7. 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 AAA SA (phase 1b) to its child phase 2
security associations, the phase 2 Secure Association Protocol allows
the EAP peer and authenticator to mutually prove possession of the
AAA-Key. In order to avoid confusion in the case where an EAP peer
has more than one AAA-Key (phase 1b) applicable to establishment of a
phase 2 security association, it is necessary for the secure
Association Protocol (phase 2) to support key selection, so that the
appropriate phase 1b keying material can be utilized by both parties
in the Secure Association Protocol exchange.
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.
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)."
3.8. Key Scoping
A AAA-Key provided by the backend authentication server to the
authenticator is for use only by that authenticator. While AAA
protocols such as RADIUS [RFC2865] or Diameter [RFC3588] support
mutual authentication between the authenticator (known as the AAA
client) and the backend authentication server (known as the AAA
server), the security mechanisms vary according to the AAA protocol.
In the case of RADIUS, the shared secret used for authentication is
determined by the source address of the RADIUS packet. As noted in
[RFC3579] Section 4.3.7, it is highly desirable that the source
address be checked against one or more NAS identification attributes
so as to detect and prevent impersonation attacks.
A wide variety of authenticator and peer designs need to be
accomodated within the EAP key management framework. As noted in
Section 1.3, an authenticator may contain multiple physical ports; a
single physical authenticator may, for the purpose of peer discovery,
advertise itself as multiple "virtual authenticators"; authenticators
may be compromised of multiple CPUs; authenticators may utilize
clustering in order to provide load balancing or failover.
Similarly, a peer may support multiple ports; may support multiple
CPUs; or may support clustering.
While AAA protocols mutually authenticate the AAA client and server
they do not distinguish authenticator architectures. Therefore while
the AAA-Key provided by the AAA server is for use solely by the
authenticator receiving the key, by default the usage boundary is
defined by the authenticator architecture.
This may have unexpected consequences. Where a physical authenticator
acts as multiple "virtual authenticators", unless each "virtual
authenticator" identifies itself distinctly to the AAA server, then a
AAA-Key provided by the AAA server is by default available for use by
any of the "virtual authenticators".
This enables potential security vulnerabilities. For example, an EAP
peer could authenticate with the "guest" "virtual authenticator" and
negotiate a AAA-Key. The peer could then attempt to use that AAA-Key
to do a fast handoff to the "Corporate Intranet" virtual
authenticator within the same physical authenticator. If the virtual
authenticators do not identify themselves distinctly to the AAA
server, then the key cache will be shared in common and the fast
handoff attempt will be successful.
In order to address this vulnerability, authenticators need to cache
not only the AAA-Keys, but also the associated authorizations. This
ensures that an attacker could not obtain elevated privileges even if
they could authenticate successfully to another "virtual
authenticator" hosted within the same physical chassis.
If further protection is required, it is advisable for the AAA server
to explicitly restrict the AAA-Key scope by including additional
scope restriction attributes within the AAA-Token. Examples of scope
restriction attributesw include:
Virtual authenticator restrictions
In the case of 802.11, this could involve including a list of
authorized Called-Station-Ids or SSIDs for which the AAA-Key is
valid.
Peer restrictions
In the case of 802.11, this could involve including a list of
authorized Calling-Station-Ids for which the AAA-Key is valid.
Note that in restricting the use of the AAA-Key it is important to
ensure that the EAP peer can be made aware of the restriction so
that the peer and authenticator can behave consistently.
3.9. Authorization Issues
In a typical network access scenario (dial-in, wireless LAN, etc.)
access control mechanisms are typically applied. These mechanisms
include user authentication as well as authorization for the offered
service.
As a part of the authentication process, the AAA network determines
the user's authorization profile. The user authorizations are
transmitted by the backend authentication server to the EAP
authenticator (also known as the Network Access Server or
authenticator) included with the AAA-Token, which also contains the
AAA-Key, in Phase 1b of the EAP conversation. Typically, the profile
is determined based on the user identity, but a certificate presented
by the user may also provide authorization information.
The backend authentication server is responsible for making a user
authorization decision, answering the following questions:
[a] Is this a legitimate user for this particular network?
[b] Is this user allowed the type of access he or she is requesting?
[c] Are there any specific parameters (mandatory tunneling, bandwidth,
filters, and so on) that the access network should be aware of for
this user?
[d] Is this user within the subscription rules regarding time of day?
[e] Is this user within his limits for concurrent sessions?
[f] Are there any fraud, credit limit, or other concerns that indicate
that access should be denied?
While the authorization decision is in principle simple, the process
is complicated by the distributed nature of AAA decision making.
Where brokering entities or proxies are involved, all of the AAA
devices in the chain from the authenticator to the home AAA server
are involved in the decision. For instance, a broker can disallow
access even if the home AAA server would allow it, or a proxy can add
authorizations (e.g., bandwidth limits).
Decisions can be based on static policy definitions and profiles as
well as dynamic state (e.g. time of day or limits on the number of
concurrent sessions). In addition to the Accept/Reject decision made
by the AAA chain, parameters or constraints can be communicated to
the authenticator.
The criteria for Accept/Reject decisions or the reasons for choosing
particular authorizations are typically not communicated to the
authenticator, only the final result. As a result, the authenticator
has no way to know what the decision was based on. Was a set of
authorization parameters sent because this service is always provided
to the user, or was the decision based on the time/day and the
capabilities of the requesting authenticator device?
Within EAP, "fast handoff" is defined as a conversation in which the
EAP exchange (phase 1a) and associated AAA passthrough is bypassed,
so as to reduce latency. Depending on the fast handoff mechanism,
AAA-Key transport (phase 1b) may also be bypassed or it may be
provided in a pre-emptive manner as in [IEEE-03-084] and [I-D.irtf-
aaaarch-handoff].
As we will discuss, the introduction of fast handoff creates a new
class of security vulnerabilities as well as requirements for the
secure handling of authorization context.
3.10. Correctness In Fast Handoff
Bypassing all or portions of the AAA conversation creates challenges
in ensuring that authorization is properly handled. These include:
[a] Consistent application of session time limits. A fast handoff
should not automatically increase the available session time,
allowing a user to endlessly extend their network access by
changing the point of attachment.
[b] Avoidance of privilege elevation. A fast handoff should not result
in a user being granted access to services which they are not
entitled to.
[c] Consideration of dynamic state. In situations in which dynamic
state is involved in the access decision (day/time, simultaneous
session limit) it should be possible to take this state into
account either before or after access is granted. Note that
consideration of network-wide state such as simultaneous session
limits can typically only be taken into account by the backend
authentication server.
[d] Encoding of restrictions. Since a authenticator may not be aware
of the criteria considered by a backend authentication server when
allowing access, in order to ensure consistent authorization during
a fast handoff it may be necessary to explicitly encode the
restrictions within the authorizations provided in the AAA-Token.
[e] State validity. The introduction of fast handoff should not render
the authentication server incapable of keeping track of network-
wide state.
A fast handoff mechanism capable of addressing these concerns is said
to be "correct". One condition for correctness is as follows: For a
fast handoff to be "correct" it MUST establish on the new device the
same context as would have been created had the new device completed
a AAA conversation with the authentication server.
A properly designed fast handoff scheme will only succeed if it is
"correct" in this way. If a successful fast handoff would establish
"incorrect" state, it is preferable for it to fail, in order to avoid
creation of incorrect context.
Some backend authentication server and authenticator configurations
are incapable of meeting this definition of "correctness". For
example, if the old and new device differ in their capabilities, it
may be difficult to meet this definition of correctness in a fast
handoff mechanism that bypasses AAA. Backend authentication servers
often perform conditional evaluation, in which the authorizations
returned in an Access-Accept message are contingent on the
authenticator or on dynamic state such as the time of day or number
of simultaneous sessions. For example, in a heterogeneous
deployment, the backend authentication server might return different
authorizations depending on the authenticator making the request, in
order to make sure that the requested service is consistent with the
authenticator capabilities.
If differences between the new and old device would result in the
backend authentication server sending a different set of messages to
the new device than were sent to the old device, then if the fast
handoff mechanism bypasses AAA, then the fast handoff cannot be
carried out correctly.
For example, if some authenticator devices within a deployment
support dynamic VLANs while others do not, then attributes present in
the Access-Request (such as the authenticator-IP-Address,
authenticator-Identifier, Vendor-Identifier, etc.) could be examined
to determine when VLAN attributes will be returned, as described in
[RFC3580]. VLAN support is defined in [IEEE8021Q]. If a fast
handoff bypassing the backend authentication server were to occur
between a authenticator supporting dynamic VLANs and another
authenticator which does not, then a guest user with access
restricted to a guest VLAN could be given unrestricted access to the
network.
Similarly, in a network where access is restricted based on the day
and time, Service Set Identifier (SSID), Calling-Station-Id or other
factors, unless the restrictions are encoded within the
authorizations, or a partial AAA conversation is included, then a
fast handoff could result in the user bypassing the restrictions.
In practice, these considerations limit the situations in which fast
handoff mechanisms bypassing AAA can be expected to be successful.
Where the deployed devices implement the same set of services, it may
be possible to do successful fast handoffs within such mechanisms.
However, where the supported services differ between devices, the
fast handoff may not succeed. For example, [RFC2865], section 1.1
states:
"A authenticator that does not implement a given service MUST NOT
implement the RADIUS attributes for that service. For example, a
authenticator that is unable to offer ARAP service MUST NOT
implement the RADIUS attributes for ARAP. A authenticator MUST
treat a RADIUS access-accept authorizing an unavailable service as
an access-reject instead."
Note that this behavior only applies to attributes that are known,
but not implemented. For attributes that are unknown, section of 5
of [RFC2865] states:
"A RADIUS server MAY ignore Attributes with an unknown Type. A
RADIUS client MAY ignore Attributes with an unknown Type."
In order to perform a correct fast handoff, if a new device is
provided with RADIUS context for a known but unavailable service,
then it MUST process this context the same way it would handle a
RADIUS Access-Accept requesting an unavailable service. This MUST
cause the fast handoff to fail. However, if a new device is provided
with RADIUS context that indicates an unknown attribute, then this
attribute MAY be ignored.
Although it may seem somewhat counter-intuitive, failure is indeed
the "correct" result where a known but unsupported service is
requested. Presumably a correctly configured backend authentication
server would not request that a device carry out a service that it
does not implement. This implies that if the new device were to
complete a AAA conversation that it would be likely to receive
different service instructions. In such a case, failure of the fast
handoff is the desired result. This will cause the new device to go
back to the AAA server in order to receive the appropriate service
definition.
In practice, this implies that fast handoff mechanisms which bypass
AAA are most likely to be successful within a homogeneous device
deployment within a single administrative domain. For example, it
would not be advisable to carry out a fast handoff bypassing AAA
between a authenticator providing confidentiality and another
authenticator that does not support this service. The correct result
of such a fast handoff would be a failure, since if the handoff were
blindly carried out, then the user would be moved from a secure to an
insecure channel without permission from the backend authentication
server. Thus the definition of a "known but unsupported service"
MUST encompass requests for unavailable security services. This
includes vendor-specific attributes related to security, such as
those described in [RFC2548].
-
Rewrite of Key Framework Section 3 Bernard Aboba, April 4 2004
- RE: Rewrite of Key Framework Section 3 Joseph Salowey, April 8 2004
Results generated by Tiger Technologies using MHonArc.