One document matched: draft-congdon-radext-ieee802-03.txt
Differences from draft-congdon-radext-ieee802-02.txt
Networking Working Group Paul Congdon
INTERNET-DRAFT Mauricio Sanchez
<draft-congdon-radext-ieee802-03.txt> Hewlett-Packard Company
A. Lior
15 February 2005 Bridgewater Systems
F. Adrangi
Intel
Bernard Aboba
Microsoft
RADIUS Extensions for IEEE 802
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been
disclosed, and any of which I become aware will be disclosed, in
accordance with RFC 3668.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-Drafts
as reference material or to cite them other than as "work in
progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on July 15, 2005.
Copyright Notice
Copyright (C) The Internet Society 2004. All rights reserved.
Abstract
In certain network scenarios it is desirable to either filter user
traffic or redirect it to a specific location. This document
describes several methods that are available to be used with
Remote Authentication Dial In User Service (RADIUS) Protocol and
proposes additional attributes to be used by AAA clients, whether
in an IEEE 802.1X or Internet Service Provider environment.
Congdon, et al. Informational [Page 1]
INTERNET-DRAFT RADIUS Extensions for IEEE 802 15 February 2005
Table of Contents
1. Introduction .......................................... 3
1.1 Terminology ..................................... 4
1.2 Requirements Language ........................... 5
2. Overview .............................................. 5
2.1 Capability Advertisement ........................ 7
3. Traffic Redirection ................................... 8
3.1 Tunneling ....................................... 8
3.1.1 Service Initiation .............................. 8
3.1.2 Mid-session Redirection ......................... 8
3.1.3 Redirection Removal ............................. 8
3.2 IP Redirection ...................................... 9
3.2.1 Service Initiation .............................. 9
3.2.2 Mid-session IP Redirection ...................... 9
3.2.3 IP Redirection Removal .......................... 10
3.3 Application Layer Redirection ....................... 10
3.3.1 Service Initiation .............................. 10
3.3.2 Mid-session Application Layer Redirection ....... 11
3.3.3 Application Layer Redirection Removal ........... 11
3.3.4 Combination of methods .......................... 11
3.4 RADIUS Accounting ................................... 11
4. RADIUS Authentication ................................. 12
4.1 Egress-VLANID ................................... 12
4.2 Ingress-Filters ................................ 12
4.3 VLAN-Name ....................................... 13
4.4 User-Priority-Table ............................. 14
4.5 NAS-Filter-Rule ................................. 15
4.6 QoS-Filter-Rule ................................. 22
4.7 Redirect-Host ................................... 22
4.8 Origin-Realm .................................... 23
5. RADIUS Accounting ..................................... 24
5.1 Accounting-EAP-Auth-Method ...................... 24
6. Table of Attributes ................................... 24
7. Diameter Considerations ............................... 25
8. IANA Considerations ................................... 26
9. Security Considerations ............................... 27
9.1 Packet modification or forgery .................. 27
9.2 Dictionary Attacks .............................. 27
9.3 Known Plaintext Attacks ......................... 28
10. References ............................................ 28
10.1 Normative References .................................. 28
10.2 Informative References ................................ 30
Appendix A - Extended Attribute Formats ...................... 31
ACKNOWLEDGMENTS .............................................. 35
AUTHORS' ADDRESSES ........................................... 35
Intellectual Property Statement .............................. 36
Disclaimer of Validity ....................................... 36
Full Copyright Statement ..................................... 37
Congdon, et al. Informational [Page 2]
INTERNET-DRAFT RADIUS Extensions for IEEE 802 15 February 2005
1. Introduction
IEEE 802.1X [IEEE8021X] provides "network port authentication" for
IEEE 802 [IEEE802] media, including Ethernet [IEEE8023], Token
Ring and 802.11 [IEEE80211i] wireless LANS.
IEEE 802.1X does not require use of a backend authentication
server, and thus can be deployed with stand-alone bridges or
Access Points, as well as in centrally managed scenarios. As a
result, support for the RADIUS [RFC2865] or Diameter [RFC3588]
protocols is optional for IEEE 802.1X authenticators.
In situations where it is desirable to centrally manage
authentication, authorization and accounting (AAA) for IEEE 802
networks, deployment of a backend authentication and accounting
server is desirable. In such situations, it is expected that IEEE
802.1X authenticators will function as AAA clients.
The desire may exist to have AAA clients enforce varying levels of
authorization. Within the confines AAA environments, there has
been a general dearth of RADIUS attributes that allow explicit
expressions of granular authorization policy. A need exists to
extend RADIUS with new attributes that will allow explicit
expressions of such policies.
Besides IEEE 802.1X networks, there is a corollary need within
Internet Service Provider (ISP) environments. From time to time an
ISP requires to restrict a user's access to the Internet and
redirect their traffic to an alternate location. For example, the
user maybe on a prepaid plan and all the resources have been used
up. In this case the ISP would block the user's access to the
Internet and redirect them to a portal where the user can
replenish their account. Another example where the ISP would want
to restrict access and redirect a user that was involved in some
fraudulent behavior. Again the ISP would want to block the user's
access to the Internet and redirect to a portal where they can
inform the user as to their state and allow them to inform the
user of their concerns and potentially rectify the situation.
In the examples above it is important to note that the ability to
block and redirect user's traffic is required at service
initiation and once service has been established. These
capabilities must also be available across access technologies and
various business scenarios. For example, the ability to block and
redirect traffic is required for TCP users, cell phone users, WiFi
users. As well, this capability must work whether the user is in
their home network or roaming in a visited network which may or
may not have a direct roaming relationship with the user's home
network.
Congdon, et al. Informational [Page 3]
INTERNET-DRAFT RADIUS Extensions for IEEE 802 15 February 2005
This document describes a protocol extension to the Remote
Authentication Dial In User Service (RADIUS) Protocol [RFC2865] by
which the aforementioned requirements for IEEE 802.1X and ISP
environments can be addressed. To meet these needs eight new
RADIUS attributes are required.
Blocking and redirection of users traffic is known as hot-lining
of accounts. In this document, hot-lining is used as the
motivation for these attributes and an illustration of how they
would be used. However, the attributes may be used together or
separately to provide other features.
Furthermore, this document also describes an alternative method
for providing these capabilities, namely by using RADIUS
attributes for tunneling protocol specified in [RFC2868]. This
document describes how to provide capabilities for users traffic
redirection with or without using tunnels. Finally, the document
describes how to provide for these capabilities dynamically (mid-
service) using the RADIUS protocol extension described in
[RFC3576].
1.1. Terminology
In this document when we refer to Blocking of IP traffic we mean
Filtering of IP traffic. Additionally, this document uses the
following terms:
Access Point (AP)
A Station that provides access to the distribution services
via the wireless medium for associated Stations.
Association
The service used to establish Access Point/Station mapping
and enable Station invocation of the distribution system
services.
authenticator
An authenticator is an entity that require authentication
from the supplicant. The authenticator may be connected to
the supplicant at the other end of a point-to-point LAN
segment or 802.11 wireless link.
Authentication server
An authentication server is an entity that provides an
authentication service to an authenticator. This service
verifies from the credentials provided by the supplicant,
the claim of identity made by the supplicant.
Port Access Entity (PAE)
Congdon, et al. Informational [Page 4]
INTERNET-DRAFT RADIUS Extensions for IEEE 802 15 February 2005
The protocol entity associated with a physical or virtual
(802.11) Port. A given PAE may support the protocol
functionality associated with the Authenticator, Supplicant
or both.
Station (STA)
Any device that contains an IEEE 802.11 conformant medium
access control (MAC) and physical layer (PHY) interface to
the wireless medium (WM).
Supplicant
A supplicant is an entity that is being authenticated by an
authenticator. The supplicant may be connected to the
authenticator at one end of a point-to-point LAN segment or
802.11 wireless link.
1.2. Requirements Language
In this document, several words are used to signify the
requirements of the specification. The key words "MUST", "MUST
NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT",
"RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be
interpreted as described in [RFC2119].
An implementation is not compliant if it fails to satisfy one or
more of the must or must not requirements for the protocols it
implements. An implementation that satisfies all the must, must
not, should and should not requirements for its protocols is said
to be "unconditionally compliant"; one that satisfies all the must
and must not requirements but not all the should or should not
requirements for its protocols is said to be "conditionally
compliant".
2. Overview
As described in the Introduction section, it may be desirable
within IEEE 802.1X and ISP environments to a control user's access
to network resources (e.g. the Internet) by blocking their access
and/or redirecting them to a specific location. In this section
we will examine these requirements in more detail.
Blocking access refers to setting up some rules at the NAS such
that when the user initiates IP traffic, the NAS examines the set
of rules associated with the Service granted to the user. These
rules determine what traffic is allowed to proceed through the NAS
and what traffic will be blocked. Today this capability is
supported in RADIUS and is configurable during service
establishment and mid-service via the Filter-Id(11) attribute. To
use Filter-Id to control access to network resources the rules
Congdon, et al. Informational [Page 5]
INTERNET-DRAFT RADIUS Extensions for IEEE 802 15 February 2005
need to be configured at each NAS. Filter-Id(11) is used in an
Access-Accept to specify the name of the filter rule(s) to apply
to this session. To effect a change mid-service (dynamically),
the Filter-Id(11) is included in a Change-of-Authorization (COA)
packet. Upon receiving the Filter-Id(11) the NAS start to apply
the rules specified by the Filter-Id(11).
As pointed out by NASREQ the use Filter-Id is not roaming friendly
and it is recommended that instead one should use NAS-Filter-
Rule(400) AVP. For this reason, this document introduces NAS-
Filter-Rule(TBD) to RADIUS.
Redirection refers to an action taken by the NAS to redirect the
user's traffic to an alternate location. Redirecting traffic in
mid-session will most probably break some applications.
For hotlining, the purpose of redirection is not to continue to
provide the service. Rather the purpose is to facilitate a
mechanism whereby the user is informed of their state, and is
provided for a way to rectify the situation. In some cases
redirection could be used to redirect traffic to another location
where service can continue.
The following two examples illustrate the user's experience when
being redirected.
For the first example assume an IEEE 8021X environment, whereby a
user connects to the enterprise LAN and initiates an
authentication handshake. As part of the overall authentication
process, it is also possible to pass endpoint state such as patch
level, virus signature status, etc., all of which can be verified
by a back-end server for policy compliancy and alter the
authentication and authorization decision. In instances that an
end-host is not in compliancy, the NAS may be instructed to limit
network access in some fashion (i.e. quarantine) and limit network
access to remediation services and a web-based information site.
A user may sense degraded network performance and open a web
session, which the NAS would redirect to the web-based information
site for compliancy status, remediation actions, etc.
For the second example assume an ISP environment, whereby a
prepaid user is roaming the net in their hotel room over WiFi is
to be Hot-lined because their account has no more funds. The
user's Service Provider instructs the NAS to block all traffic,
and redirect any port 80 traffic to the Service Provider's Prepaid
Portal. Upon detecting that there is no service, the user
launches his browser and regardless of which web site is being
accessed the browser traffic will arrive at the Prepaid Portal
which will then return a page back to the subscriber indicating
that he needs to replenish his account.
Congdon, et al. Informational [Page 6]
INTERNET-DRAFT RADIUS Extensions for IEEE 802 15 February 2005
There are several ways to redirect the user's traffic. Which
method will be used depends on the capabilities available at the
NAS and Service Provider's preference. User traffic can be
redirected by tunneling the user's traffic to an alternate
location. Tunneling can be used at layer-2 or layer-3. Tunneling
will typically redirect all of the user's traffic for the Service.
When tunneling is used to redirect all the traffic then blocking
(or filtering) may not be necessary.
Another method available for redirection is to have the NAS re-
write the IP header in accordance with a redirection rule. We
call this method Layer-3 Redirection. As the NAS receives packets
from the user's device, if the packets match the redirection rule,
the destination address and (optionally) the port is re-written
causing them to arrive at the alternate location. As packets from
that location arrive back at the NAS, the NAS rewrites the source
address with the original destination address. This is similar to
what a NAT will do. This method of redirection provides more
flexibility than tunneling in that we can control which layer-3
flows are to be redirected.
Another method of redirection is redirection in the application
layer. In this method, the NAS is aware of application flows and
redirects traffic based on an application specific method. For
example, if the application is based on HTTP then an HTTP aware
NAS would redirect traffic by issuing an HTTP Redirect response
causing the users browser to navigate to an alternate Web Portal.
Finally, redirection can be achieved by utilizing the RADIUS
Framed-Route(22) attribute. Using this attribute the NAS can be
instructed to route the packet over a specific path. Due to the
security risks associated with Framed-Routing, the use of this
attribute for redirection is discouraged and hence we will not
deal with this method in this document.
2.1 Capability Advertisement
For these usage scenarios to practically work the home network
needs to know what Redirection and Filtering features are
supported by the NAS and whether or not the NAS supports RADIUS
dynamic operations.
As per [TBD], A NAS that supports filtering and redirection
capabilities should transmit the following capability attribute to
advertise its capability: TBD.
Congdon, et al. Informational [Page 7]
INTERNET-DRAFT RADIUS Extensions for IEEE 802 15 February 2005
3. Traffic Redirection
In this section we present the various methods used for
redirecting user traffic, which are:
1) Tunneling;
2) IP Redirection; and
3) HTTP Redirection
For each method, we describe how redirection is done at service
initiation and mid-sesssion. We also describe how redirection is
removed when it is no longer desired.
3.1 Tunneling
When tunneling is used it will typically be used to redirect the
entire traffic associated with the Service. Therefore, blocking
(or filtering) will not be necessary at the NAS. As discussed
above, tunneling can be used to redirect traffic at either layer-2
or layer-3. Regardless, the message flows presented in the
following sections are the same.
Note that not all tunneling methods will work all the time. While
we don't restrict the methods the operator must choose which
tunneling method to deploy.
3.1.1 Service Initiation
Redirect using tunnels at service initiation requires that the
RADIUS server send the appropriate tunnel attributes to the NAS.
The tunnel attributes will describe the tunnel endpoint and the
type of tunnel to construct. The operation is as specified in
[RFC2868].
3.1.2 Mid-session Redirection
Redirection of traffic using tunnels mid-session involves sending
the tunnel attributes as per RFC2868 [5] to the NAS using Change-
of-Authorization (COA) packet. The operation is described in
[RFC3576]. Careful attention should be paid to the security
issues in [RFC3576].
Note that if the session is already tunneled (eg. Mobile-IP) then
the COA packet with a new tunnel specification can be sent to the
NAS or alternatively the redirection can occur at the tunnel
endpoint (the Home Agent) using any one of these methods.
3.1.3 Redirection Removal
Congdon, et al. Informational [Page 8]
INTERNET-DRAFT RADIUS Extensions for IEEE 802 15 February 2005
If the normal mode for the session was to tunnel the session and
redirection was sent to the NAS, the RADIUS Server can send the
original tunnel attributes to the NAS in a COA packet. The NAS
will tear down the tunnel and establish a connection back to the
original tunnel endpoint.
However, if the normal mode for the session is not to use
tunneling then we have a problem because RADIUS does not have a
mechanism where by it can de-tunnel. Receiving a COA message
without tunnel attributes would not have an effect on an existing
tunnel. In order to de-tunnel the session, the RADIUS server has
to send the NAS a COA message with Service-Type(6) set to
"Authorize-Only" causing the NAS to perform a re-Authorization.
In response to the re-Authorization, the RADIUS server will send
an Access-Accept packet without the tunneling information. Upon
receiving the corresponding Access-Accept packet the NAS MUST
apply the new authorization attributes. If these do not contain
tunnel attributes, then the NAS MUST tear down the tunnel.
3.2 IP Redirection
This document proposes a method to convey redirection rules at the
IP layer via usage of the NAS-Filter-Rule(TBD) attribute. IP
Redirection may require the use of blocking. If only some of the
flows are redirected then the other flows will have to be blocked.
In this case, the RADIUS server MUST communicate to the NAS the
blocking rules. Blocking rules can be conveyed to the NAS using
filtering rules within the NAS-Filter-Rule(TBD) attribute. These
rules will be carried along side the redirection rules within a
given NAS-Filter-Rule(TBD) attribute.
3.2.1 Service Initiation
If redirection is required during service initiation then the
RADIUS server will send the redirection rules and optionally the
blocking rules within the NAS-Filter-Rule attribute in the Access-
Accept. The NAS will then start the service as usual with the
traffic redirected and blocked as per the received redirection and
blocking rules.
If the NAS advertised support for the redirection and it receives
a NAS-Filter-Rule(TBD) that it does not recognize, the NAS MUST
interpret the Access-Accept message as an Access-Reject message.
3.2.2 Mid-session IP Redirection
If IP redirection is required to be applied to a service that has
already been started then the RADIUS server can push the
Congdon, et al. Informational [Page 9]
INTERNET-DRAFT RADIUS Extensions for IEEE 802 15 February 2005
redirection rules, and optionally the filter rules, to the NAS
within a NAS-Filter-Rule attribute using a COA packet. The NAS
will then commence to apply the redirecting rules and/or the
filter rules.
If the NAS receives a COA message that contains an NAS-Filter-
Rule(TBD) that it does not recognize it MUST generate a COA-NAK
packet with ERROR-CAUSE(101) set to "Invalid Request"(404).
Alternatively, the RADIUS server can request that the NAS re-
authorize the session using the procedures defined in [RFC3576].
The RADIUS server responds with an Access-Accept message (with
Service-Type(6) set to "Authorize Only" that will contain the
redirection and optionally filtering rules within a NAS-Filter-
Rule(TBD).
If the NAS receives an Access-Accept message that contains a NAS-
Filter-Rule that it doesn't recognize it MUST treat the Access-
Accept as an Access-Reject and terminate the session.
3.2.3 IP Redirection Removal
The RADIUS server can turn redirection off mid-session in two
ways. It can push new redirection attributes and filter attributes
to the NAS using a COA packet or it can send the NAS a COA packet
requesting it to re-authorize.
When using COA message to return the redirection and filtering
back to "normal". There needs to be either a filter rule(or
filter-id) or redirection rule that corresponds to the "normal"
state. If normally the session did not have any filter and or
redirection rules applied then RADIUS can send a NAS-Filter-
Rule(TBD) with the action of "flush" in the COA. This action will
cause all the filter rules and redirection rules previously
assigned to the session to be removed.
If the NAS receives a NAS-Filter-Rule in the COA packet that it
does not recognize then the NAS MUST respond with a COA-NAK with
Error-Cause(101) set to "Invalid Request"(404). If the NAS
receives an Access-Accept message sent in response to its
Authorize-Only Access-Request, that contains an unrecognizable
NAS-Filter-Rule(TBD), then the NAS MUST treat the Access-Accept as
an Access-Reject and terminate the session immediately.
3.3 Application Layer Redirection
The call flow associated with performing redirection at the
application layer is very similar with the call flow associated
with redirection done at the IP layer. What is different here is
the number of different possible applications that must be
Congdon, et al. Informational [Page 10]
INTERNET-DRAFT RADIUS Extensions for IEEE 802 15 February 2005
considered. Fortunately, the most common application (and the one
that we will consider here) is HTTP based applications, or browser
based application.
The same NAS-Filter-Rule(TBD) attribute redirection described
above is used to convey the redirection rules to use for
Application Layer Redirection. HTTP redirection rules within the
NAS-Filter-Rule attribute supports the encoding of a redirection
URL to apply when a rule is matched.
3.3.1 Service Initiation
As with previous call flows, the RADIUS MAY send multiple HTTP
redirect or filtering rules within a NAS-Filter-Rule(TBD)
attribute to the NAS in the Access-Accept message. If the NAS
receives an HTTP redirect or filtering rule, which it does not
understand, then the NAS MUST treat the Access-Accept as an
Access-Reject packet.
3.3.2 Mid-session Application Layer Redirection
Mid-session initiated Application Layer Redirection is similar to
the call flows of IP-based redirection method discussed above,
except HTTP redirect rules are used instead.
3.3.3 Application Layer Redirection Removal
Redirection removal based on Application Based Redirection is
similar to the call flows of IP-based redirection method discussed
above.
3.3.4 Combination of methods
It is possible to combine the above methods. For example, HTTP-
redirection can be combined with layer-3 redirection where HTTP-
Redirection can be used to contain browser traffic and IP-
Redirection-Rule can be used to contain other IP traffic.
3.4 Accounting
Every time a session is redirected and every time the redirection
is reverted back a new session is created and the old one is
terminated. Therefore the NAS MUST generate and Accounting-
Request(Stop) for the old session and an Accounting-Request(Start)
for the new session.
As described above, when the NAS receives redirection attributes
that it does not understand in an Access-Accept packet it MUST
terminate the session and MUST generate an Accounting-
Request(Stop) packet. Note, in the case where it receives
Congdon, et al. Informational [Page 11]
INTERNET-DRAFT RADIUS Extensions for IEEE 802 15 February 2005
redirection/filtering attributes in a COA packet that it does not
understand, then it responds with a COA-NAK packet and does not
terminate the session and therefore it MUST NOT generate an
Accounting-Request(Stop) packet.
4. RADIUS Authentication
This specification introduces eight new RADIUS authentication
attributes.
4.1. Egress-VLANID
Description
The Egress-VLANID attribute represents an allowed IEEE 802
Egress VLANID for this port. The Egress-VLANID contains two
parts: the first part is the VLANID, the second part indicates
if this VLANID is allowed for tagged or untagged packets.
Multiple Egress-VLANID attributes can be delivered in an
authentication response; each attribute adds the specified VLAN
to the list of allowed egress VLANs for the port. This is an
Extended RADIUS attribute.
Code
TBD
Length
8
Data-Type
Integer32
Integer32
The values include:
1 = Tagged
2 = Untagged
4.2. Ingress-Filters
Description
802.1Q clause 8.4.5 describes the Ingress Filter variable per
port. The Ingress-Filters attribute corresponds to Ingress
Congdon, et al. Informational [Page 12]
INTERNET-DRAFT RADIUS Extensions for IEEE 802 15 February 2005
Filter per-port variable defined in IEEE 802.1Q clause 8.4.5.
When the attribute has the value "Enabled", the set of VLANs
that are allowed to ingress a port must match the set of VLANs
that are allowed to egress a port. By default, where the
Ingress-Filter attribute is not set, the value "Disabled"
should be assumed. Only a single Ingress-Filters attribute MAY
be sent within an Access-Accept or CoA-Request; this attribute
MUST NOT be sent within an Access-Request, Access-Challenge,
Access-Reject, or Disconnect-Request.
This attribute is defined as an Extended RADIUS attribute.
Code
TBD
Length
8
Data-Type
UInt32
UInt32
1 - Enabled
2 - Disabled
4.3. VLAN-Name
Description
802.1Q-2003 clause 12.10.2.1.3 (a) describes the
administratively assigned VLAN Name associated with a VLAN ID
defined within an 802.1Q bridge. The VLAN-Name attribute
represents an allowed VLAN for this port. It works similar to
the Egress-VLANID attribute except that the VLAN-ID itself is
not specified or known, rather the VLAN name is used to
identify the VLAN within the system.
The VLAN-Name attribute contains two parts; the first part is
the VLAN name, the second part indicates if frames on the VLAN
for this port are to be represented in tagged or untagged
format.
Multiple VLAN-Name attributes can be delivered in an
authentication response; each attribute adds the named VLAN to
the list of allowed egress VLANs for the port.
This attribute is defined as an Extended RADIUS attribute.
Congdon, et al. Informational [Page 13]
INTERNET-DRAFT RADIUS Extensions for IEEE 802 15 February 2005
Code
TBD
Length
>=9
Data-Type
TBD - to be assigned by IANA - VLAN-Name
String
The String field contains the VLAN Name as defined in 802.1Q-
2003 clause 12.10.2.1.3 (a). UTF-8 encoded 10646 characters
are recommended, but a robust implementation SHOULD support the
field as undistinguished octets.
Integer32
1 = Tagged
2 = Untagged
4.4. User-Priority-Table
Description
IEEE 802.1D clause 7.5.1 discusses how to regenerate (or re-
map) user priority on frames received at a port. This per-port
configuration enables a bridge to cause the priority or
received traffic at a port to be mapped to a particular
priority. The management variables are described in clause
14.6.2.2.
This attribute represents the IEEE 802 prioritization that will
be applied to packets arriving at this port. There are eight
possible user priorities, according to the IEEE 802 standard.
This attribute is defined as an Extended RADIUS attribute.
Code
TBD
Length
12
Congdon, et al. Informational [Page 14]
INTERNET-DRAFT RADIUS Extensions for IEEE 802 15 February 2005
Data-Type
UInt64
UInt64
The table, expressed as a unsigned 64-bit integer, maps the
incoming priority (if one exists - the default is 0) into one
of seven regenerated priorities. The format of this attribute
is an eight byte octet string, where the first octet maps to
incoming priority 0, the second octet to incoming priority 1,
etc. The values in each octet represent the regenerated
priority of the packet.
It is thus possible to either remap incoming priorities to more
appropriate values; or to honor the incoming priorities; or to
override any incoming priorities, forcing them to all map to a
single chosen priority.
The IEEE 802.1D specification, Annex G, provides a useful
description of traffic type - traffic class mappings.
For mapping of the priority to quality of service at the IP
layer, it is assumed that the LAN Edge Device has been provided
a table with device-wide mappings of this user priority to the
appropriate DiffServ code points. That table and its
configuration are outside the scope of this document.
4.5. NAS-Filter-Rule
Description
The NAS-Filter-Rule attribute is derived from the Diameter
IPFilterRule and enables the provisioning of Ethernet (Layer
2), Internet Protocol (Layer 3-4), and HTTP (Layer7) filter
rules and Internet Protocol and HTTP redirect rules on the NAS
by the RADIUS server. This attribute is defined as an Extended
RADIUS attribute.
When specifying an Ethernet filter rule, NAS-Filter-Rule
processes packets based on the following information that is
associated with it:
Direction (in or out)
Ethernet type
Source and destination MAC address (possibly masked)
When specifying an Internet Protocol filter or redirect rule,
NAS-Filter-Rule processes packets based on the following
information that is associated with it:
Congdon, et al. Informational [Page 15]
INTERNET-DRAFT RADIUS Extensions for IEEE 802 15 February 2005
Direction (in or out)
Source and destination IP address (possibly masked)
Protocol
Source and destination port (lists or ranges)
TCP flags
IP fragment flag
IP options
ICMP types
When specifying an HTTP filter or redirect rule, NAS-Filter-
Rule process packets based on the following information that is
associated with it:
HTTP URL
Source and destination IP address (possibly masked)
As per the requirements of RFC 2865, Section 2.3, if multiple
NAS-Filter-Rule attributes are contained within an Access-
Request or Access-Accept packet, they MUST be maintained in
order. The attributes MUST be consecutive attributes in the
packet. RADIUS proxies MUST NOT reorder NAS-Filter-Rule
attributes.
The RADIUS server can return multiple NAS-Filter-Rule
attributes in an Access-Accept packet. Where more than one NAS-
Filter-Rule attribute is included, it is assumed that the
attributes are to be concatenated to form a single filter list.
Furthermore, the concatenated filter list must abide to the
following rules of precedence:
1) Ethernet filter rules MUST appear before all other rule
types.
2) IP redirect rules MUST appear after any Ethernet filter
rules and before HTTP redirect, IP filter, and/or HTTP
filter rules.
3) HTTP redirect rules MUST appear after any IP redirect
rules and before any IP filter and/or HTTP filter rules.
4) IP filter rules MUST appear after any HTTP redirect
rules and before any HTTP filter rules.
5) HTTP filter rules MUST appear after any other rules.
Rules are evaluated in order, with the first matched rule
terminating the evaluation. Each packet is evaluated once. If
no rule matches, then packet is dropped (implicit deny all).
When an HTTP redirect rule matches, the NAS shall reply to the
HTTP request with an HTTP redirect in accordance with RFC
redirecting traffic to specific URL.
Congdon, et al. Informational [Page 16]
INTERNET-DRAFT RADIUS Extensions for IEEE 802 15 February 2005
Filter-ID (11) and NAS-Filter-Rule both define how filters are
to be applied in the NAS. They both should not appear in the
same message and only one of them should be processed. If
Filter-ID is present, it should take precedence. Furthermore,
multiple Filter-ID attributes may appear in the same Radius
message. It is unclear how implementations should process
these multiple attributes. Some implementation may append them
to one another; others may select only a single attribute to
process.
The NAS-Filter-Rule attribute is shown below. The fields are
transmitted from left to right:
+---------------------------------------------------------------+
| 1 2 3 |
|0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1|
+---------------+---------------+-------------------------------+
| Type (TBD) | Length | Text |
+---------------+---------------+-------------------------------+
| Text
+---------------+---------------+---------------+---------------+
Type
TBD for NAS-Filter-Rule.
Length
>= 2
Text
The text conforms to the following specification:
NAS-Filter-Rule MUST follow the general format:
action [args] dir proto from src to dst [options]
action
permit - Allow packets that match the rule.
deny - Drop packets that match the rule.
redirect - Redirect packets that match the rule.
flush - Remove all previously assigned filter rules.
Congdon, et al. Informational [Page 17]
INTERNET-DRAFT RADIUS Extensions for IEEE 802 15 February 2005
When flush is specified no other attributes
are specified.
args <redir_addr|redir_URL>
For IP redirect rules:
redir_addr An IPv4 or IPv6 number in dotted-quad or
canonical IPv6 form. When the redirect rule
matches (src/dst), traffic is redirected to
redir_addr address rather than allowing
traffic continue to original destination
(dst) address
For HTTP redirect rules:
redir_URL An HTTP URL. When the redirect rule matches
(src/dst), HTTP requests are redirected to
redir_URL address in accordance with RFC
redirection traffic to specific URL.
dir "in" is from the terminal, "out" is to the
terminal.
proto <etype[:val]|ipprot|ip|http>
For Ethernet filter rules:
"etype" keyword means any Ethernet type will match
etype:val Used to specify an Ethernet type by
hexadecimal number, whereby "val" is replaced
by desired number. Example: "etype:0x800" for
IP ethertype (0x0800).
For IP filter or redirect rules:
"ip" keyword means any IP protocol will match.
ipprot An IP protocol specified by number.
For HTTP filter or redirect rules:
"http" keyword used to designate rule as of http
type.
src, dst <address/mask> [ports]
For MAC filter rules, <address/mask> may be specified as:
macaddr An Ethernet MAC address with octet values
separated by a "-". Example: "00-10-A4-23-
19-C0".
macaddr/mask An Ethernet number as above with a mask
width of the form "00-10-A4-23-19-C0/24".
Congdon, et al. Informational [Page 18]
INTERNET-DRAFT RADIUS Extensions for IEEE 802 15 February 2005
In this case, all MAC addresses from 00-
10-A4-00-00-00 to 00-10-A4-FF-FF-FF will
match. The MAC address MUST NOT have bits
set beyond the mask. The keyword "any" is
00-00-00-00-00-00/0.
The sense of the match can be inverted by
preceding an address with the not modifier
(!), causing all other addresses to be
matched instead.
Note: [ports] optional argument not valid for
MAC filter rules.
For IP filter or redirect rules, the <address/mask> may
be specified as:
ipno An IPv4 or IPv6 number in dotted-quad or
canonical IPv6 form. Only this exact IP
number will match the rule.
ipno/bits An IP number as above with a mask width of
the form 1.2.3.4/24. In this case, all IP
numbers from 1.2.3.0 to 1.2.3.255 will match.
The bit width MUST be valid for the IP
version and the IP number MUST NOT have bits
set beyond the mask. For a match to occur,
the same IP version MUST be present in the
packet that was used in describing the IP
address. To test for a particular IP
version, the bits part can be set to zero.
The keyword "any" is 0.0.0.0/0 or the IPv6
equivalent. The keyword "assigned" is the
address or set of addresses assigned to the
terminal. For IPv4, a typical first rule is
often "deny in ip! assigned"
The sense of the match can be inverted by
preceding an address with the not modifier
(!), causing all other addresses to be
matched instead. This does not affect the
selection of port numbers.
With the TCP, UDP and SCTP protocols, optional ports
may be specified as:
{port/port-port}[,ports[,...]]
The '-' notation specifies a range of ports
(including boundaries). Fragmented packets that
have a non-zero offset (i.e., not the first
Congdon, et al. Informational [Page 19]
INTERNET-DRAFT RADIUS Extensions for IEEE 802 15 February 2005
fragment) will never match a rule that has one
or more port specifications. See the frag
option for details on matching fragmented
packets.
options
For IP filter or redirect rules, there are several
optional arguments that can be specified:
frag Match if the packet is a fragment and this
is not the first fragment of the datagram.
frag may not be used in conjunction with
either tcpflags or TCP/UDP port
specifications.
ipoptions spec
Match if the IP header contains the comma
separated list of options specified in
spec. The supported IP options are:
ssrr (strict source route), lsrr (loose
source route), rr (record packet route)
and ts(timestamp). The absence of a
particular option may be denoted with a
'!'.
tcpoptions spec
Match if the TCP header contains the comma
separated list of options specified in
spec. The supported TCP options are:
mss (maximum segment size), window (tcp
window advertisement), sack (selective
ack), ts (rfc1323 timestamp) and cc
(rfc1644 t/tcp connection count). The
absence of a particular option may be
denoted with a '!'.
established
TCP packets only. Match packets that have
the RST or ACK bits set.
setup TCP packets only. Match packets that have
the SYN bit set but no ACK bit.
tcpflags spec
TCP packets only. Match if the TCP header
contains the comma separated list of flags
specified in spec. The supported TCP
flags are:
Congdon, et al. Informational [Page 20]
INTERNET-DRAFT RADIUS Extensions for IEEE 802 15 February 2005
fin, syn, rst, psh, ack and urg. The
absence of a particular flag may be
denoted with a '!'. A rule that contains
a tcpflags specification can never match
a fragmented packet that has a non-zero
offset. See the frag option for details
on matching fragmented packets.
icmptypes types
ICMP packets only. Match if the ICMP type
is in the list types. The list may be
specified as any combination of ranges or
individual types separated by commas.
Both the numeric values and the symbolic
values listed below can be used. The
supported ICMP types are:
echo reply (0), destination unreachable
(3), source quench (4), redirect (5), echo
request(8), router advertisement (9),
router solicitation (10), time-to-live
exceeded (11), IP header bad (12),
timestamp request (13), timestamp reply
(14), information request (15),
information reply (16), address mask
request (17) and address mask reply (18)
Concise syntax statements for each rule type follow:
A NAS-Filter-Rule expressing a flush of all rules MUST follow
the syntax:
<flush>
A NAS-Filter-Rule expressing an Ethernet filter rule MUST
follow the syntax:
<permit|deny> <in|out> <etype[:val]> from <address/mask> to
<address/mask>
A NAS-Filter-Rule expressing an IP redirect or filter rule MUST
follow the syntax:
<permit|deny|redirect <redir_addr>> <in|out> <ip|ip_proto> from
<address/mask> to <address/mask> [ports] [options]
A NAS-Filter-Rule expressing a HTTP redirect or filter rule
MUST follow the syntax:
Congdon, et al. Informational [Page 21]
INTERNET-DRAFT RADIUS Extensions for IEEE 802 15 February 2005
<permit|deny|redirect> <URL> <in|out> from <address/mask> to
<address/mask>
A NAS that is unable to interpret or apply a deny rule MUST
terminate the session. A NAS that is unable to interpret or apply
a permit rule MAY apply a more restrictive rule. A NAS MAY apply
deny rules of its own before the supplied rules, for example to
protect the access device owner's infrastructure.
The rule syntax is a modified subset of ipfw(8) from FreeBSD, and
the ipfw.c code may provide a useful base for implementations.
4.6. QoS-Filter-Rule
Description
The QoS-Filter-Rule attribute enables the provisioning of QoS
filters on the NAS by the RADIUS server. This attribute is
defined as an Extended RADIUS attribute. The QoS-Filter-Rule
attribute is defined as follows:
Code
407
Length
>=5
Data-Type
QoSFilterRule
QoSFilterRule
The QoSFilterRule field contains a QoS filter, utilizing the
syntax defined for the QoSFilterRule derived data type defined
in [RFC3588], Section 4.3. Note that this definition contained
an error, so that the complete syntax is described in the
definition of the QoS-Filter-Rule AVP, defined in [NASREQ]
Section ?.
4.7. Redirect-Host
Description
Congdon, et al. Informational [Page 22]
INTERNET-DRAFT RADIUS Extensions for IEEE 802 15 February 2005
The Redirect-Host attribute provides support for Redirect
functionality, as described in [RFC3588], Section 6.12. This
attribute is defined as an Extended RADIUS attribute.
Code
? - Defined in [RFC3588]
Length
=4 (REQUIRED in an Access-Request)
>=5 (REQUIRED in an Access-Accept)
Data Type
String
String
The String field is one or more octets, containing the full
qualified domain name of the server to which the NAS should be
redirected. This attribute MUST only be sent in an Access-
Accept if a null Redirect-Host attribute (Length = 4) is
included in an Access-Request.
4.8. Origin-Realm
Description
The Origin-Realm attribute contains the realm of the originator
of a message, as described in [RFC3588], Section 6.4.
Code
296
Length
>=5 (Short Form)
Data Type
String
String
The String field contains the fully qualified domain name(FQDN)
representing the realm.
Congdon, et al. Informational [Page 23]
INTERNET-DRAFT RADIUS Extensions for IEEE 802 15 February 2005
5. RADIUS Accounting
5.1. Accounting-EAP-Auth-Method
Description
Accounting-EAP-Auth-Method enables a RADIUS client to include
the EAP method utilized within an accounting packet. The
semantics of this attribute are identical to that of the
Accounting-EAP-Auth-Method AVP defined in [DiamEAP], Section
4.1.5. This is a standard RADIUS attribute.
The Accounting-EAP-Auth-Method attribute is shown below. The
fields are transmitted from left to right:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
TBD
Length
10
Value
The Value field is eight octets. In case of expanded types
defined in [RFC3748] Section 5.7, the least significant 32 bits
contain the Vendor-Type field, and the next 24 bits contain the
Vendor-Id field.
6. Table of Attributes
The following table provides a guide to which attributes may be
found in which kinds of packets, and in what quantity.
Access- Access- Access- Access- CoA-
Request Accept Reject Challenge Req # Attribute
0+ 0+ 0+ 0+ 0+ TBD Extended
0 0+ 0 0 0+ TBD Egress-VLANID [a]
Congdon, et al. Informational [Page 24]
INTERNET-DRAFT RADIUS Extensions for IEEE 802 15 February 2005
0 0-1 0 0 0-1 TBD Ingress-Filters [a]
0 0-1 0 0 0-1 TBD User-Priority-Table [a]
0 0+ 0 0 0+ TBD NAS-Filter-Rule [a]
0 0+ 0 0 0+ 407 QoS-Filter-Rule [a]
0-1 0 0 0+ 0 TBD Redirect-Host
0-1 0 0 0 0 296 Origin-Realm
Actng- Actng-
Request Response # Attribute
0-1 0 TBD Accounting-EAP-Auth-Method
The following table defines the meaning of the above table
entries.
0 This attribute MUST NOT be present in packet.
0+ Zero or more instances of this attribute MAY be present in
the packet.
0-1 Zero or one instance of this attribute MAY be
present in the packet.
Notes
------
[a] This attribute MAY only be included in a COA-Request if the
NAS indicates in the Access-Request that it supports Extended
attributes. Otherwise, this attribute MUST NOT be sent in a COA-
Request.
7. Diameter Considerations
As described in Appendix A, the Extended attributes described in
this specification are defined in both RADIUS and Diameter, and
utilize the Data Types defined in [RFC3588]. Attributes already
defined within Diameter, and defined as Extended RADIUS attributes
within this specification include: NAS-IPFilter-Rule [NASREQ],
QoS-Filter-Rule [NASREQ], EAP-Master-Session-Key [DiamEAP], EAP-
Key-Name [DiamEAP], Redirect-Host [RFC3588] and Origin-Realm
[RFC3588].
Extended attributes defined within both RADIUS and Diameter
include Egress-VLANID, Ingress-Filters, User-Priority-Table,
Allowed-SSID, and Allowed-Called-Station-Id.
Attributes solely defined within RADIUS include the Extended
attribute (used to encapsulate Diameter-compatible RADIUS
attributes), as well as the Accounting-EAP-Auth-Method attribute,
defined within [DiamEAP].
In order to translate RADIUS Extended attributes to Diameter AVPs,
a RADIUS/Diameter gateway must first concatenate all RADIUS
Congdon, et al. Informational [Page 25]
INTERNET-DRAFT RADIUS Extensions for IEEE 802 15 February 2005
attributes of type Extended, and then parse the included sub-
attributes. The sub-attributes are then encapsulated within the
Diameter AVP format as folows:
a. The Code, Length, and Mandatory fields as well as the
attribute data are copied directly from the Extended
RADIUS attribute to the Diameter AVP.
b. If the RADIUS "short form" Extended format is used, then
the 'V' bit always set to zero in the Diameter AVP.
c. If the RADIUS "long form" Extended format is used, then
the 'V' bit and Vendor-Id is copies from the Extended
RADIUS attribute to the Diameter AVP.
In translating from Diameter to RADIUS, the gateway encapsulates
Diameter AVPs within Extended RADIUS attributes as follows:
a. If the 'V' bit is set to one (1), or the Diameter AVP
Code is larger than 16384, then the "Long Form" Extended
RADIUS attribute format MUST be used. Otherwise, the
"Short Form" attribute format SHOULD be used.
b. The Code, Length, and Mandatory fields as well as the
attribute data are copied directly from the Diameter
AVP to the Extended RADIUS attribute.
c. If the 'V' bit is set to one (1), then the 'V' bit
as well as the Vendor-Id fields are copies from the
Diameter AVP to the Extended RADIUS attribute.
d. Once the Extended RADIUS attributes have been encoded,
they are encapsulated within RADIUS attributes of
type Extended.
Note that automated translation may not be on an initial Access-
Request, since this packet must contain an empty Extended
attribute in order to negotiate use of the Extended attribute
format.
8. IANA Considerations
This specification does not create any new registries.
This specification requires assignment of a RADIUS attribute type
for the Extended attribute. In addition, this specification
requires assignment of the following Diameter Code values:
AVP Code
Congdon, et al. Informational [Page 26]
INTERNET-DRAFT RADIUS Extensions for IEEE 802 15 February 2005
========= ====
Egress-VLANID TBD
Ingress-Filter-Enable TBD
User-Priority-Table TBD
Allowed-SSID TBD
Allowed-Called-Station-Id TBD
9. Security Considerations
Since this document describes the use of RADIUS for purposes of
authentication, authorization, and accounting in IEEE 802.1X-
enabled networks, it is vulnerable to all of the threats that are
present in other RADIUS applications. For a discussion of these
threats, see [RFC2607], [RFC2865], [RFC3162], [RFC3576],
[RFC3579], and [RFC3580].
Vulnerabilities include:
Packet modification or forgery
Dictionary attacks
Known plaintext attacks
Key management issues
9.1. Packet Modification or Forgery
As noted in [RFC3580], when used with IEEE 802.1X, all RADIUS
packets MUST be authenticated and integrity protected. In
addition, as described in [RFC3579], Section 4.2:
To address the security vulnerabilities of RADIUS/EAP,
implementations of this specification SHOULD support IPsec
[RFC2401] along with IKE [RFC2409] for key management. IPsec
ESP [RFC2406] with non-null transform SHOULD be supported, and
IPsec ESP with a non-null encryption transform and
authentication support SHOULD be used to provide per-packet
confidentiality, authentication, integrity and replay
protection. IKE SHOULD be used for key management.
9.2. Dictionary Attacks
As discussed in [RFC3579] Section 4.3.3, the RADIUS shared secret
is vulnerable to offline dictionary attack, based on capture of
the Response Authenticator or Message-Authenticator attribute. In
order to decrease the level of vulnerability, [RFC2865], Section 3
recommends:
The secret (password shared between the client and the RADIUS
server) SHOULD be at least as large and unguessable as a well-
Congdon, et al. Informational [Page 27]
INTERNET-DRAFT RADIUS Extensions for IEEE 802 15 February 2005
chosen password. It is preferred that the secret be at least
16 octets.
In addition, the risk of an offline dictionary attack can be
further mitigated by employing IPsec ESP with non-null
transform in order to encrypt the RADIUS conversation, as
described in [RFC3579], Section 4.2.
9.3. Known Plaintext Attacks
Since IEEE 802.1X is based on EAP, which does not support PAP, the
RADIUS User-Password attribute is not used to carry hidden user
passwords. The hiding mechanism utilizes MD5, defined in
[RFC1321], in order to generate a key stream based on the RADIUS
shared secret and the Request Authenticator. Where PAP is in
use, it is possible to collect key streams corresponding to a
given Request Authenticator value, by capturing RADIUS
conversations corresponding to a PAP authentication attempt using
a known password. Since the User-Password is known, the key stream
corresponding to a given Request Authenticator can be determined
and stored.
The vulnerability is described in detail in [RFC3579], Section
4.3.4. Even though IEEE 802.1X Authenticators do not support PAP
authentication, a security vulnerability can still exist where the
same RADIUS shared secret is used for hiding User-Password as well
as other attributes. This can occur, for example, if the same
RADIUS proxy handles authentication requests for both IEEE 802.1X
(which may hide the Tunnel-Password, MS-MPPE-Send-Key and MS-MPPE-
Recv-Key attributes) and GPRS (which may hide the User-Password
attribute).
The threat can be mitigated by protecting RADIUS with IPsec ESP
with non-null transform, as described in [RFC3579], Section 4.2.
In addition, the same RADIUS shared secret MUST NOT used for both
IEEE 802.1X authentication and PAP authentication.
10. References
10.1. Normative references
[RFC1321] Rivest, R. and S. Dusse, "The MD5 Message-Digest
Algorithm", RFC 1321, April 1992.
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3", BCP 9, RFC 2026, October 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March, 1997.
Congdon, et al. Informational [Page 28]
INTERNET-DRAFT RADIUS Extensions for IEEE 802 15 February 2005
[RFC2865] Rigney, C., Rubens, A., Simpson, W. and S. Willens, "Remote
Authentication Dial In User Service (RADIUS)", RFC 2865,
June 2000.
[RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
[RFC2867] Zorn, G., Mitton, D. and B. Aboba, "RADIUS Accounting
Modifications for Tunnel Protocol Support", RFC 2867, June
2000.
[RFC2868] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M.
and I. Goyret, "RADIUS Attributes for Tunnel Protocol
Support", RFC 2868, June 2000.
[RFC2869] Rigney, C., Willats, W. and P. Calhoun, "RADIUS
Extensions", RFC 2869, June 2000.
[RFC3162] Aboba, B., Zorn, G. and D. Mitton, "RADIUS and IPv6", RFC
3162, August 2001.
[RFC3280] Housley, R., Polk, W., Ford, W. and D. Solo, "Internet
X.509 Public Key Infrastructure Certificate and Certificate
Revocation List (CRL) Profile", RFC 3280, April 2002.
[RFC3575] Aboba, B., "IANA Considerations for RADIUS", RFC 3575, July
2003.
[RFC3576] Chiba, M., Dommety, G., Eklund, M., Mitton, D. and B.
Aboba,"Dynamic Authorization Extensions to Remote
Authentication Dial In User Service (RADIUS)", RFC 3576,
July 2003.
[RFC3579] Aboba, B. and P. Calhoun, "RADIUS Support for Extensible
Authentication Protocol (EAP)", RFC 3579, September 2003.
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., Arkko,
J., "Diameter Base Protocol", RFC 3588, September 2003.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J. and H.
Levkowetz, "Extensible Authentication Protocol (EAP)", RFC
3748, June 2004.
[IEEE8021X]
IEEE Standards for Local and Metropolitan Area Networks:
Port based Network Access Control, IEEE Std 802.1X-2004,
August 2004.
[IEEE802.11i]
Institute of Electrical and Electronics Engineers,
Congdon, et al. Informational [Page 29]
INTERNET-DRAFT RADIUS Extensions for IEEE 802 15 February 2005
"Supplement to Standard for Telecommunications and
Information Exchange Between Systems - LAN/MAN Specific
Requirements - Part 11:Wireless LAN Medium Access Control
(MAC) and Physical Layer
(PHY) Specifications: Specification for Enhanced Security",
June 2004.
[Arkko] Arkko, J., "Object Identifier and Type Spaces in a
Rationalized RADIUS Data Model", post to the RADEXT WG
Mailing list, June 9, 2004,
http://ops.ietf.org/lists/radiusext/2004/msg00441.html
10.2. Informative references
[Calhoun] Calhoun, P., "Diameter Network Access Server Application".
[RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104, February
1997
[RFC2434] Alvestrand, H. and T. Narten, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
[RFC2548] Zorn, G., "Microsoft Vendor-specific RADIUS Attributes",
RFC 2548, March 1999.
[RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy
Implementation in Roaming", RFC 2607, June 1999.
[RFC2716] Aboba, B. and D. Simon, "PPP EAP TLS Authentication
Protocol", RFC 2716, October 1999.
[MD5Attack]
Dobbertin, H., "The Status of MD5 After a Recent Attack."
CryptoBytes Vol.2 No.2, Summer 1996.
[Housley56]
Housley, R., "Key Management in AAA", Presentation to the
AAA WG at IETF 56,
http://www.ietf.org/proceedings/03mar/slides/aaa-
5/index.html, March 2003.
[IEEE802] IEEE Standards for Local and Metropolitan Area Networks:
Overview and Architecture, ANSI/IEEE Std 802, 1990.
[IEEE8021Q]
IEEE Standards for Local and Metropolitan Area Networks:
Draft Standard for Virtual Bridged Local Area Networks,
Congdon, et al. Informational [Page 30]
INTERNET-DRAFT RADIUS Extensions for IEEE 802 15 February 2005
P802.1Q, January 1998.
[IEEE8023]
ISO/IEC 8802-3 Information technology - Telecommunications
And information exchange between systems - Local and
metropolitan area networks - Common specifications - Part
3: Carrier Sense Multiple Access with Collision Detection
(CSMA/CD) Access Method and Physical Layer Specifications,
(also ANSI/IEEE Std 802.3- 1996), 1996.
[IEEE80211]
Information technology - Telecommunications and information
exchange between systems - Local and metropolitan area
networks - Specific Requirements Part 11: Wireless LAN
Medium Access Control (MAC) and Physical Layer (PHY)
Specifications, IEEE Std. 802.11-1999, 1999.
[KEYFRAME]
Aboba, B., Simon, D., Arkko, J., Eronen, P. and H.
Levkowetz, "EAP Key Management Framework", draft-ietf-eap-
keying-03.txt, July 2004.
Appendix A - Extended Attribute Formats
The use of a Diameter-compatible Extended attribute format within
RADIUS was first proposed in [Arkko]. This Appendix describes a
potential definition of the Extended attribute, based on a
modified version of that proposal. The proposed definition
provides support for Diameter-compatibility as well as sub-
attributes, and support for a more efficient "short form"
encoding.
The Extended attribute, RADIUS attribute type TBD, enables the
encoding of Extended RADIUS attributes. If multiple Extended
attributes are present in a packet their values should be
concatenated; this allows attributes longer than 253 octets to be
transported by the Extended attribute format. Multiple sub-
attributes MAY be encoded within a single Extended attribute,
although they do not have to be.
Note: for the purposes of this appendix, allocation of a new
RADIUS Type value is assumed. However, on the RADEXT WG mailing
list, there has also been discussion of utilizing type 26 (Vendor-
Specific) along with a Vendor-Id of zero(0). For the purposes of
this specification either format would be work equally well.
Extended attributes MUST only be used when both the RADIUS client
and server support them. A RADIUS client supporting the Extended
attribute format MUST include an Extended attribute with a Length
Congdon, et al. Informational [Page 31]
INTERNET-DRAFT RADIUS Extensions for IEEE 802 15 February 2005
value of two (2) within the initial Access-Request of a session.
A RADIUS server receiving an empty Extended attribute within an
Access-Request MAY utilize Extended attributes within messages
sent to the client, including Access-Reject, Access-Challenge,
Access-Accept, CoA-Request and Disconnect-Request messages.
A RADIUS server not receiving an empty Extended attribute within
an initial Access-Request MUST NOT include Extended attributes in
any RADIUS message sent to the client, including Access-Reject,
Access-Challenge, Access-Accept, CoA-Request or Disconnect-Request
messages.
A.1 - Full Diameter AVP Format
The full Extended attribute format is defined as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |S| Code
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Code (opt) | Length2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Vendor-Id (opt)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-Id(opt)| Data...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
TBD - Allocated by IANA from within the RADIUS attribute space.
Length
The length of the attribute in octets, including the Type,
Length, S, Code, Length2, Flags, Vendor-Id and Data fields.
S
0 - Full Diameter AVP format
1 - Short Form
Code
Where the S bit is clear, the "full Diameter AVP" format is
used, and the Code field is 31 bits, encoding the 31 least
significant bits of the Diameter AVP format defined in
[RFC3588].
Congdon, et al. Informational [Page 32]
INTERNET-DRAFT RADIUS Extensions for IEEE 802 15 February 2005
Where the S bit is set, the "Short Form" Extended format is
used, and the Code field is 14 bits, encoding the 14 least
significant bits of the Diameter AVP format, defined in
[RFC3588].
Length2
The Length of the sub-attribute in octets, including the S, M,
Code, Length2 and Data fields.
Flags
The Flags field is a single octet, defined as follows:
+-+-+-+-+-+-+-+-+
|V|M|r|r|r|r|r|r|
+-+-+-+-+-+-+-+-+
V
0 = IETF standard
1 = Vendor Specific
M
The 'M' Bit, known as the Mandatory bit, indicates whether
support of the attribute is required. If an attribute with the
'M' bit set is received and either the attribute or its value
is unrecognized, the message MUST be silently discarded.
Attributes with the 'M' bit cleared are informational only and
a receiver that receives a message with such an attribute that
is not supported, or whose value is not supported, MAY simply
ignore the attribute.
r
The 'r' (reserved) bits are unused and SHOULD be set to 0. Note
that subsequent specifications MAY define additional bits
within the header, and an unrecognized bit SHOULD be considered
an error.
Vendor-Id
The high-order octet is 0 and the low-order 3 octets are the
SMI Network Management Private Enterprise Code of the Vendor in
network byte order.
Data
Congdon, et al. Informational [Page 33]
INTERNET-DRAFT RADIUS Extensions for IEEE 802 15 February 2005
The Data field is zero or more octets and contains information
specific to the attribute. The format and length of the Data
field is determined by the Code and Length2 fields. The format
of the Data field MUST be one of the data types defined in
[RFC3588] or a data type derived from the base data types.
A.2 - Short Form
In order to enable Extended attributes to be encoded more
economically, a "Short Form" of the Extended attribute format
is proposed. The Short Form can be used to encode any Diameter
AVP that meets the following constraints:
[a] An IETF standard attribute (not Vendor-Specific)
[b] Diameter Code between 0 and 16384 (all existing attributes)
[c] No flag bits other than the Mandatory bit.
The short form Extended attribute format is defined as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |S|M| Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length2 | Data....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
TBD - Allocated by IANA from the RADIUS attribute space.
Length
The length of the attribute in octets, including the Type,
Length, S, M, Code, Length2 and Data fields.
S
1 - Short Form
M
0 - Optional
1 - Mandatory
Code
The 14 least significant bits of the Diameter AVP Code
field, as defined in [RFC3588].
Length2
Congdon, et al. Informational [Page 34]
INTERNET-DRAFT RADIUS Extensions for IEEE 802 15 February 2005
The Length of the sub-attribute in octets, including the S,
M, Code, Length2 and Data fields.
Data
The Data field is zero or more octets and contains
information specific to the attribute. The format and
length of the Data field is determined by the Code and
Length2 fields. The format of the Data field MUST be one of
the data types defined in [RFC3588] or a data type derived
from the base data types.
Acknowledgments
The authors would like to acknowledge Dorothy Stanley of Agere,
Joseph Salowey of Cisco, David Nelson of Enterasys, Chuck Black
of Hewlett Packard, and Ashwin Palekar of Microsoft.
Authors' Addresses
Paul Congdon
Hewlett Packard Company
HP ProCurve Networking
8000 Foothills Blvd, M/S 5662
Roseville, CA 95747
EMail: paul.congdon@hp.com
Phone: +1 916 785 5753
Fax: +1 916 785 8478
Mauricio Sanchez
Hewlett Packard Company
HP ProCurve Networking
8000 Foothills Blvd, M/S 5559
Roseville, CA 95747
EMail: mauricio.sanchez@hp.com
Phone: +1 916 785 1910
Fax: +1 916 785 1815
Avi Lior
Bridgewater Systems Corporation
303 Terry Fox Drive
Suite 100
Ottawa, Ontario K2K 3J1
Canada
Phone: (613) 591-6655
EMail: avi@bridgewatersystems.com
URI: TCP://.bridgewatersystems.com/
Congdon, et al. Informational [Page 35]
INTERNET-DRAFT RADIUS Extensions for IEEE 802 15 February 2005
Farid Adrangi
Intel Corporation
2111 North East 25th
Hillsboro, Oregon 97124
United States
Phone: (503) 712-1791
EMail: farid.adrangi@intel.com
Bernard Aboba
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
EMail: bernarda@microsoft.com
Phone: +1 425 706 6605
Fax: +1 425 936 7329
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of
any intellectual property or other rights that might be claimed
to pertain to the implementation or use of the technology
described in this document or the extent to which any license
under such rights might or might not be available; neither does
it represent that it has made any effort to identify any such
rights. Information on the IETF's procedures with respect to
rights in standards-track and standards-related documentation
can be found in BCP-11. Copies of claims of rights made
available for publication and any assurances of licenses to
be made available, or the result of an attempt made to obtain a
general license or permission for the use of such proprietary
rights by implementors or users of this specification can be
obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its
attention any copyrights, patents or patent applications, or
other proprietary rights which may cover technology that may be
required to practice this standard. Please address the
information to the IETF Executive Director.
Disclaimer of Validity
This document and the information contained herein are provided
on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION
HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET
SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO
Congdon, et al. Informational [Page 36]
INTERNET-DRAFT RADIUS Extensions for IEEE 802 15 February 2005
ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT
INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2004). This document is
subject to the rights, licenses and restrictions contained in
BCP 78, and except as set forth therein, the authors retain all
their rights.
Congdon, et al. Informational [Page 37]
| PAFTECH AB 2003-2026 | 2026-04-23 00:23:37 |