Subject: [eap] Issue 182: Authorization Issues

From: Bernard Aboba <[email-masked]>
Date: Fri, 10 Oct 2003 08:06:03 -0700 (PDT)

Issue 182: Authorization Issues
Submitter name:   Bernard Aboba
Submitter email address: [email-masked]
Date first submitted: October 10, 2003
Reference:
Document: Keyframe-07
Comment type: T
Priority: S
Section: 1.4
Rationale/Explanation of issue:

Add the following section:

"1.4 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 AAA server to the EAP authenticator (also known as the
Network Access Server or NAS) 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 AAA server is responsible for making a user authorization decision,
answering the following questions:

o Is this a legitimate user for this particular network?
o Is this user allowed the type of access he or she is requesting?
o Are there any specific parameters (mandatory tunneling, bandwidth,
filters, and so on) that the access network should be aware of
for this user?
o Is this user within the subscription rules regarding time of day?
o Is this user within his limits for concurrent sessions?
o 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 NAS 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 NAS.

The criteria for Accept/Reject decisions or the reasons for choosing
particular authorizations are typically not communicated to the NAS, only
the final result. As a result, the NAS 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
NAS 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 in favor a context
transfer (see [IEEE80211f] and [Context]) 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.

1.4.1. Correctness in fast handoff

Bypassing all or portions of the AAA conversation creates
challenges in ensuring that authorization is properly handled.
These include:

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

o Avoidance of privilege elevation. A fast handoff should not
result in a user being granted access to services which they
are not entitled to.

o 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 AAA server.

o Encoding of restrictions. Since a NAS may not be aware of the
criteria considered by a AAA 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.

o 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 AAA server and NAS 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. AAA servers often perform conditional evaluation, in which
the authorizations returned in an Access-Accept message are
contingent on the NAS or on dynamic state such as the time of day
or number of simultaneous sessions. For example, in a heterogeneous
deployment, the AAA server might return different authorizations
depending on the NAS making the request, in order to make sure that the
requested
service is consistent with the NAS capabilities.

If differences between the new and old device would result in the AAA
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 NAS devices within a deployment support dynamic
VLANs while others do not, then attributes present in the Access-Request
(such as the NAS-IP-Address, NAS-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 AAA server were to occur between
a NAS supporting dynamic VLANs and another NAS 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, 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 NAS that does not implement a given service MUST NOT implement the
RADIUS attributes for that service. For example, a NAS that is
unable to offer ARAP service MUST NOT implement the RADIUS attributes
for ARAP. A NAS 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 AAA 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 NAS providing confidentiality and another
NAS 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 AAA 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]."

Add to the author list:  Jari Arkko

Add to the reference list:

[Context] Aboba, B. and T. Moore, "A Model for Context Transfer in IEEE
802", draft-aboba-802-context-03.txt, Internet draft (work in progress),
October 2003.

[IEEE8021Q]
          IEEE Standards for Local and Metropolitan Area Networks: Draft
          Standard for Virtual Bridged Local Area Networks, P802.1Q/D8,
          January 1998.
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: Jari Arkko <[email-masked]>
Date: Mon, 13 Oct 2003 16:06:10 +0300

> be "correct". One condition for correctness is as follows:

I really like this formulation of the requirements for fast handoff!

> within a single administrative domain. 

Yes. I would add that we probably need an explicit statement from
the backend authentication server that dynamic state or per-NAS
rules do not prevent fast handoff. Even if the APs are exactly
similar, it may be that the server has different rules e.g. due
to their location. That is, an "Allow-Fast-Handoff" AVP may be
needed.

--Jari