[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]
Versions: 00 01 02 03 draft-ietf-radext-fixes
Network Working Group David Nelson
INTERNET-DRAFT Enterasys Networks
Updates: 2865, 2866, 2869, 3576, 3579 Alan DeKok
Category: Proposed Standard Infoblox, Inc.
<draft-aboba-radext-fixes-03.txt> Bernard Aboba
3 June 2006 Microsoft
Common RADIUS Implementation Issues and Suggested Fixes
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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 December 10, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document describes common issues seen in RADIUS implementations
and suggests some fixes. Where applicable, ambiguities and errors in
previous RADIUS specifications are clarified.
Nelson, et al. Proposed Standard [Page 1]
INTERNET-DRAFT RADIUS Issues & Fixes 3 June 2006
Table of Contents
1. Introduction .......................................... 3
1.1 Terminology ..................................... 3
1.2 Requirements Language ........................... 3
2. Issues ................................................ 4
2.1 Session Definition .............................. 4
2.2 Overload Conditions ............................. 6
2.3 Accounting Issues ............................... 7
2.4 Multiple Filter-ID Attributes ................... 8
2.5 Mandatory and Optional Attributes ............... 9
2.6 Interpretation of Access-Reject ................. 10
2.7 Addressing ...................................... 12
2.8 Idle Timeout .................................... 13
2.9 Calculation of Message-Authenticator ............ 14
2.10 Unknown Identity ................................ 15
3. IANA Considerations ................................... 16
4. Security Considerations ............................... 16
5. References ............................................ 16
5.1 Informative References ................................ 16
ACKNOWLEDGMENTS .............................................. 17
AUTHORS' ADDRESSES ........................................... 17
Intellectual Property Statement .............................. 18
Disclaimer of Validity ....................................... 19
Copyright Statement .......................................... 19
Nelson, et al. Proposed Standard [Page 2]
INTERNET-DRAFT RADIUS Issues & Fixes 3 June 2006
1. Introduction
The last few years have seen an increase in the deployment of RADIUS
clients and servers. This document describes common issues seen in
RADIUS implementations and suggests some fixes. Where applicable,
ambiguities and errors in previous RADIUS specifications are
clarified.
1.1. Terminology
This document uses the following terms:
Network Access Server (NAS)
The device providing access to the network. Also known as the
Authenticator (IEEE 802.1X or EAP terminology) or RADIUS client.
service
The NAS provides a service to the user, such as network access via
802.11 or PPP.
session
Each service provided by the NAS to a peer constitutes a session,
with the beginning of the session defined as the point where
service is first provided and the end of the session defined as the
point where service is ended. A peer may have multiple sessions in
parallel or series if the NAS supports that, with each session
generating a separate start and stop accounting record.
silently discard
This means the implementation discards the packet without further
processing. The implementation SHOULD provide the capability of
logging the error, including the contents of the silently discarded
packet, and SHOULD record the event in a statistics counter.
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].
Nelson, et al. Proposed Standard [Page 3]
INTERNET-DRAFT RADIUS Issues & Fixes 3 June 2006
2. Issues
2.1. Session Definition
2.1.1. State Attribute
Regarding the State attribute, [RFC2865] Section 5.24 states:
This Attribute is available to be sent by the server to the client
in an Access-Challenge and MUST be sent unmodified from the client
to the server in the new Access-Request reply to that challenge,
if any.
This Attribute is available to be sent by the server to the client
in an Access-Accept that also includes a Termination-Action
Attribute with the value of RADIUS-Request. If the NAS performs
the Termination-Action by sending a new Access-Request upon
termination of the current session, it MUST include the State
attribute unchanged in that Access-Request.
Some RADIUS client implementations do not properly use the State
attribute in order to distinguish a restarted EAP authentication
process from the continuation of an ongoing process (by the same user
on the same NAS and port).
Where an EAP-Message attribute is included in an Access-Challenge or
Access-Accept attribute, RADIUS servers SHOULD also include a State
attribute.
An Access-Request sent as a result of a new or restarted
authentication run MUST NOT include the State attribute, even if the
State attribute has previously been received in an Access-Challenge
for the same user and port.
Since a State attribute is always initially provided by the server in
an Access-Accept, Access-Challenge, CoA-Request or Disconnect-
Request, a RADIUS client MUST NOT insert a State attribute that it
has not previously received from the server.
A State attribute is REQUIRED in Access-Request packets neither
including an authentication attribute nor a Service-Type attribute
with the value Call Check (10). [RFC2865] Section 5.44 states:
An Access-Request MUST contain either a User-Password or a CHAP-
Password or State. An Access-Request MUST NOT contain both a
User-Password and a CHAP-Password. If future extensions allow
other kinds of authentication information to be conveyed, the
attribute for that can be used in an Access-Request instead of
Nelson, et al. Proposed Standard [Page 4]
INTERNET-DRAFT RADIUS Issues & Fixes 3 June 2006
User-Password or CHAP-Password.
[RFC3576] defines the Service-Type value of "Authorize-Only". This
Service-Type can be included within Disconnect or CoA-Request
packets. A NAS receiving such a Disconnect or CoA-Request will send
an Access-Request packet containing a Service-Type attribute with the
value "Authorize-Only" and no authentication attributes. In order to
satisfy the requirements of [RFC2865] Section 5.44, an Access-Request
with Service-Type="Authorize-Only" MUST contain a State attribute.
In order to provide a State attribute to the NAS, Disconnect and CoA-
Request packets containing a Service-Type of value "Authorize-Only"
MUST also contain a State attribute, and the NAS MUST include the
State attribute unchanged in the Access-Request. A NAS receiving a
Disconnect or CoA-Request containing a Service-Type value of
"Authorize-Only" but lacking a State attribute MUST send a Disconnect
or CoA-NAK and SHOULD include an Error-Cause attribute with value 402
(Missing Attribute).
2.1.2. Request-ID Supplementation
[RFC3579] Section 2.6.1 states:
In EAP, each session has its own unique Identifier space. RADIUS
server implementations MUST be able to distinguish between EAP
packets with the same Identifier existing within distinct
sessions, originating on the same NAS. For this purpose, sessions
can be distinguished based on NAS and session identification
attributes. NAS identification attributes include NAS-Identifier,
NAS-IPv6-Address and NAS-IPv4-Address. Session identification
attributes include User-Name, NAS-Port, NAS-Port-Type, NAS-Port-
Id, Called-Station-Id, Calling-Station-Id and Originating-Line-
Info.
There are issues with the suggested algorithm. Since proxies may
translate Access-Request attributes such as NAS-IP-Address, depending
on any attribute under control of the NAS to distinguish request
identifiers can result in deployment problems.
The FreeRADIUS implementation does not track EAP identifiers by NAS-
IP-Address or other attributes sent by the NAS. Instead, it uses the
EAP identifier, source IP address, and the State attribute. Since the
State attribute is under the control of the RADIUS server, this means
that the uniqueness of each session is controlled by the server, not
the NAS. The algorithm used in FreeRADIUS is as follows:
if (EAP start, or EAP identity) {
allocate unique State Attribute
Nelson, et al. Proposed Standard [Page 5]
INTERNET-DRAFT RADIUS Issues & Fixes 3 June 2006
insert into "active" queue, with key (EAP identifier, State, source IP)
} else {
look up active session in queue, with above key
}
This algorithm appears to work well in variety of situations,
including situations where home servers receive messages via
intermediate RADIUS proxies.
2.2. Overload Conditions
2.2.1. Retransmission Behavior
[RFC2865] Section 2.4 describes the retransmission requirements for
RADIUS clients:
At one extreme, RADIUS does not require a "responsive" detection
of lost data. The user is willing to wait several seconds for the
authentication to complete. The generally aggressive TCP
retransmission (based on average round trip time) is not required,
nor is the acknowledgment overhead of TCP.
At the other extreme, the user is not willing to wait several
minutes for authentication. Therefore the reliable delivery of
TCP data two minutes later is not useful. The faster use of an
alternate server allows the user to gain access before giving up.
Some existing RADIUS clients implement excessively aggressive
retransmission behavior, utilizing default retransmission timeouts of
one second or less without support for congestive backoff. When
deployed at large scale, these implementations are susceptible to
congestive collapse. For example, as the result of a power failure,
a network with 3000 NAS devices with a fixed retransmission timer of
one second will continuously generate 3000 RADIUS Access-Requests per
second. This is sufficient to overwhelm most RADIUS servers.
Suggested solutions include:
[b] Jitter. To avoid synchronization, a RADIUS client SHOULD
incorporate jitter within its retransmission algorithm.
[a] Congestive backoff. While it is not necessary for RADIUS client
implementations to implement complex retransmission algorithms,
implementations SHOULD support congestive backoff within the limits
suggested by [RFC2865] Section 2.4. For example, an implementation
SHOULD double the initial retransmission timer until a maximum
retransmission time is reached, after which the client will
failover to another RADIUS server. For example, if the initial
Nelson, et al. Proposed Standard [Page 6]
INTERNET-DRAFT RADIUS Issues & Fixes 3 June 2006
retransmission timer is one second, a maximum retransmission timer
of 16 seconds might be used.
2.2.2. Server Response to Overload
Some RADIUS server implementations are not robust in response to
overload, dropping packets with even probability across multiple
sessions. In an overload situation, this results in a high failure
rate for multi-round authentication protocols such as EAP [RFC3579].
Typically, users will continually retry in an attempt to gain access,
increasing the load even further.
A more sensible approach is for a RADIUS server to preferentially
accept RADIUS Access-Request packets containing a valid State
attribute, so that multi-round authentication conversations, once
begun, will be more likely to succeed. This will allow some users to
gain access to the network, reducing the load created by ongoing
access attempts.
2.3. Accounting Issues
2.3.1. Interim Update
[RFC2866] indicates that Acct-Input-Octets, Acct-Output-Octets, Acct-
Session-Time, Acct-Input-Packets, Acct-Output-Packets and Acct-
Terminate-Cause attributes "can only be present in Accounting-Request
records where the Acct-Status-Type is set to Stop."
However [RFC2869] Section 2.1 states:
It is envisioned that an Interim Accounting record (with Acct-
Status-Type = Interim-Update (3)) would contain all of the
attributes normally found in an Accounting Stop message with the
exception of the Acct-Term-Cause attribute.
Although [RFC2869] does not indicate that it updates [RFC2866], this
is an oversight, and the above attributes are allowable in an Interim
Accounting record.
2.3.2. Acct-Session-Id and Acct-Multi-Session-Id
[RFC2866] Section 5.5 describes Acct-Session-Id as Text within the
description, but also states that "The String field SHOULD be a
string of UTF-8 encoded 10646 characters."
Since Acct-Multi-Session-Id is consistently described as a String, it
appears that this is a typographical error, and that Acct-Session-Id
is of type String.
Nelson, et al. Proposed Standard [Page 7]
INTERNET-DRAFT RADIUS Issues & Fixes 3 June 2006
The implication is that a robust implementation SHOULD support the
String fields within Acct-Session-Id and Acct-Multi-Session-Id as
undistinguished octets.
2.3.3. Request Authenticator
[RFC2866] Section 4.1 states:
The Request Authenticator of an Accounting-Request contains a
16-octet MD5 hash value calculated according to the method
described in "Request Authenticator" above.
However, the text does not indicate any action to take when an
Accounting-Request packet contains an invalid Request Authenticator.
The following text should be considered to be part of the above
description:
The Request Authenticator field MUST contain the correct data, as
given by the above calculation. Invalid packets are silently
discarded. Note that some early implementations always set the
Request Authenticator to all zeros. New implementations of RADIUS
clients MUST use the above algorithm to calculate the Request
Authenticator field. New RADIUS server implementations MUST
silently discard invalid packets.
2.4. Multiple Filter-ID Attributes
[RFC2865] Section 5.11 states:
Zero or more Filter-Id attributes MAY be sent in an Access-Accept
packet.
In practice the behavior of a RADIUS client receiving multiple
Filter-ID attributes is implementation dependent. For example, some
implementations treat multiple instances of the Filter-ID attribute
as alternative filters; the first Filter-ID attribute having a name
matching a locally defined filter is used, and the remaining ones are
discarded. Other implementations may combine matching filters.
As a result, the interpretation of multiple Filter-ID attributes is
undefined within RADIUS. The sending of multiple Filter-ID
attributes within an Access-Accept SHOULD be avoided within
heterogeneous deployments and roaming scenarios, where it is likely
to produce unpredictable results.
Nelson, et al. Proposed Standard [Page 8]
INTERNET-DRAFT RADIUS Issues & Fixes 3 June 2006
2.5. Mandatory and Optional Attributes
RADIUS attributes do not explicitly state whether they are optional
or mandatory. Nevertheless there are instances where RADIUS
attributes need to be treated as mandatory.
[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.
With respect to the Service-Type attribute, [RFC2865] Section 5.6
says:
This Attribute indicates the type of service the user has
requested, or the type of service to be provided. It MAY be used
in both Access-Request and Access-Accept packets. A NAS is not
required to implement all of these service types, and MUST treat
unknown or unsupported Service-Types as though an Access-Reject
had been received instead.
[RFC2865] Section 5 states:
A RADIUS server MAY ignore Attributes with an unknown Type.
A RADIUS client MAY ignore Attributes with an unknown Type.
With respect to Vendor-Specific Attributes (VSAs), [RFC2865] Section
5.26 states:
Servers not equipped to interpret the vendor-specific information
sent by a client MUST ignore it (although it may be reported).
Clients which do not receive desired vendor-specific information
SHOULD make an attempt to operate without it, although they may do
so (and report they are doing so) in a degraded mode.
It is possible for either a standard attribute or VSA to represent a
request for an unavailable service. However, where the Type or
Vendor-ID is unknown, a RADIUS client will not know whether the
attribute defines a service or not.
In general, it is best for RADIUS clients to err on the side of
caution. On receiving an Access-Accept including an attribute of
unknown Type, a RADIUS client SHOULD assume that it is a potential
service definition, and treat it as an Access-Reject. Unknown VSAs
SHOULD be ignored by RADIUS clients.
Nelson, et al. Proposed Standard [Page 9]
INTERNET-DRAFT RADIUS Issues & Fixes 3 June 2006
RADIUS authentication server implementations SHOULD ignore attributes
of unknown Type. Since RADIUS accounting server implementations
typically do not need to understand attributes in order to write them
to stable storage or pass them to the billing engine, accounting
server implementations SHOULD be equipped to handle unknown
attributes.
To avoid misinterpretation of service requests encoded within VSAs,
RADIUS servers SHOULD NOT send VSAs containing service requests to
RADIUS clients that are not known to understand them. For example, a
RADIUS server should not send a VSA encoding a filter without
knowledge that the RADIUS client supports the VSA.
2.6. Interpretation of Access-Reject
2.6.1. Improper Use of Access-Reject
The intent of an Access-Reject is to deny access to the requested
service. [RFC2865] Section 2 states:
If any condition is not met, the RADIUS server sends an "Access-
Reject" response indicating that this user request is invalid. If
desired, the server MAY include a text message in the Access-
Reject which MAY be displayed by the client to the user. No other
Attributes (except Proxy-State) are permitted in an Access-Reject.
This text makes it clear that RADIUS does not allow the provisioning
of services within an Access-Reject. If the desire is to allow
limited access, then an Access-Accept can be sent with attributes
provisioning limited access. Attributes within an Access-Reject are
restricted to those necessary to route the message (e.g. Proxy-
State), attributes providing the user with an indication that access
has been denied (e.g. an EAP-Message attribute containing an EAP-
Failure) or attributes conveying an error message (e.g. a Reply-
Message or Error-Cause attribute).
Unfortunately, there are examples where this requirement has been
misunderstood. [RFC2869] Section 2.2 states:
If that authentication fails, the RADIUS server should return an
Access-Reject packet to the NAS, with optional Password-Retry and
Reply-Messages attributes. The presence of Password-Retry
indicates the ARAP NAS MAY choose to initiate another challenge-
response cycle,
This paragraph is problematic from two perspectives. Firstly, a
Password-Retry attribute is being returned in an Access-Reject; this
attribute does not fit into the categories established in [RFC2865].
Nelson, et al. Proposed Standard [Page 10]
INTERNET-DRAFT RADIUS Issues & Fixes 3 June 2006
Secondly, an Access-Reject packet is being sent in the context of a
continuing authentication conversation; [RFC2865] requires use of an
Access-Challenge for this. [RFC2869] uses the phrase "challenge-
response" to describe this use of Access-Reject, indicating that the
semantics of Access-Challenge are being used.
[RFC2865] Section 4.4, addresses the semantics of Access-Challenge
being equivalent to Access-Reject in some cases:
If the NAS does not support challenge/response, it MUST treat an
Access-Challenge as though it had received an Access-Reject
instead.
While it is difficult to correct existing deployments of [RFC2869],
we make the following recommendations:
[1] New RADIUS specifications and implementations MUST NOT use Access-
Reject where the semantics of Access-Challenge are intended.
[2] Access-Reject MUST mean denial of access to the requested service.
In response to an Access-Reject, the NAS MUST NOT send any
additional Access-Request packets for that user session.
[3] New deployments of ARAP [RFC2869] SHOULD use Access-Challenge
instead of Access-Reject packets in the conversations described in
[RFC2869] Section 2.2.
We also note that the table of attributes [RFC2869] Section 5.19 has
an error for the Password-Retry attribute. It says:
Request Accept Reject Challenge # Attribute
0 0 0-1 0 75 Password-Retry
However, the text in [RFC2869] Section 2.3.2 says that Password-Retry
can be included within an Access-Challenge packet, for EAP
authentication sessions. We recommend a correction to the table:
Request Accept Reject Challenge # Attribute
0 0 0 0-1 75 Password-Retry [Note 2]
[Note 2] As per RFC 3579, the use of the Password-Retry in EAP
authentications is deprecated. The Password-Retry attribute can be
used only for ARAP authentication.
2.6.2. Service Request Denial
RADIUS has been deployed for purposes outside network access
authentication, authorization and accounting. For example, RADIUS
Nelson, et al. Proposed Standard [Page 11]
INTERNET-DRAFT RADIUS Issues & Fixes 3 June 2006
has been deployed as a "back-end" for authenticating VOIP connections
[digest], HTTP sessions [apache], FTP sessions [proftpd], and machine
logins for multiple operating systems [bsdi, pam, gina]. In those
contexts, an Access-Reject sent to the RADIUS client MUST be
interpreted as a rejection of the request for service, and the RADIUS
client MUST NOT offer that service to the user.
For example, when an authentication failure occurs in the context of
an FTP session, the normal semantics for rejecting FTP services
apply. The rejection does not necessarily cause the FTP server to
terminate the underlying TCP connection, but the FTP server MUST NOT
offer any services protected by user authentication.
Users may request multiple services from the NAS. Where those
services are independent, the deployment MUST treat the RADIUS
sessions as being independent.
For example, a NAS may offer multi-link services, where a user may
have multiple simultaneous network connections. In that case, an
Access-Reject for a later multi-link connection request does not
necessarily mean that earlier multi-link connections are torn down.
Similarly, if a NAS offers both dialup and VOIP services, the
rejection of a VOIP attempt does not mean that the dialup session is
torn down.
Where a NAS offers multiple services, confusion may result with
respect to interpretation of a Disconnect-Request [RFC3576]. In
order to prevent confusion a RADIUS Server SHOULD identify the
session that it desires to terminate as specifically as possible.
For example, an Acct-Session-Id attribute SHOULD be included in
Disconnect-Request and CoA-Request packets, rather than just the
User-Name attribute.
2.7. Addressing
2.7.1. Link-Local Addresses
Since Link-Local addresses are unique only on the local link, if the
NAS and RADIUS server are not on the same link, then an IPv6 Link-
Local address [RFC2462] or an IPv4 Link-Local Address [RFC3927]
cannot be used to uniquely identify the NAS. A RADIUS server
receiving a NAS-IPv6-Address or NAS-IP-Address attribute containing a
Link-Local address SHOULD NOT count such an attribute toward
satisfying the requirements of [RFC3162] Section 2.1:
NAS-IPv6-Address and/or NAS-IP-Address MAY be present in an
Access-Request packet; however, if neither attribute is present
then NAS-Identifier MUST be present.
Nelson, et al. Proposed Standard [Page 12]
INTERNET-DRAFT RADIUS Issues & Fixes 3 June 2006
2.7.2. Multiple Addresses
There are situations in which a RADIUS client or server may have
multiple addresses. For example, a dual stack host can have both
IPv4 and IPv6 addresses; a host that is a member of multiple VLANs
could have IPv4 and/or IPv6 addresses on each VLAN; a host can have
multiple IPv4 or IPv6 addresses on a single interface. However,
[RFC2865] Section 5.44 only permits zero or one NAS-IP-Address
attribute within an Access-Request and [RFC3162] Section 3 only
permits zero or one NAS-IPv6-Address attribute within an Access-
Request. When a NAS has more than one global address and no ability
to determine which is used for identification in a particular
request, it is RECOMMENDED that the NAS include the NAS-Identifier
attribute in an Access-Request in order to identify itself to the
RADIUS server.
[RFC2865] Section 3 states:
A RADIUS server MUST use the source IP address of the RADIUS
UDP packet to decide which shared secret to use, so that
RADIUS requests can be proxied.
Therefore if a RADIUS client sends packets from more than one source
address, a shared secret will need to be configured on both the
client and server for each source address.
2.8. Idle-Timeout
With respect to the Idle-Timeout attribute, [RFC2865] Section 5.28
states:
This Attribute sets the maximum number of consecutive seconds of
idle connection allowed to the user before termination of the
session or prompt. This Attribute is available to be sent by the
server to the client in an Access-Accept or Access-Challenge.
[RFC3580] Section 3.12 states:
The Idle-Timeout attribute is described in [RFC2865]. For IEEE
802 media other than 802.11 the media are always on. As a result
the Idle-Timeout attribute is typically only used with wireless
media such as IEEE 802.11. It is possible for a wireless device
to wander out of range of all Access Points. In this case, the
Idle-Timeout attribute indicates the maximum time that a wireless
device may remain idle.
In the above paragraphs "idle" may not necessarily mean "no traffic";
the NAS may support filters defining what traffic is included in the
Nelson, et al. Proposed Standard [Page 13]
INTERNET-DRAFT RADIUS Issues & Fixes 3 June 2006
idle time determination. As a result, an "idle connection" is
defined by local policy in the absence of other attributes.
2.9. Calculation of Message-Authenticator
[RFC3579] Section 3.3 indicates that the Message-Authenticator
attribute may be included in Access-Request, Accept, Reject and
Challenge packets, and [RFC3579] Section 3.2 describes how the
Message-Authenticator attribute is calculated for these packets:
When present in an Access-Request packet, Message-Authenticator is
an HMAC-MD5 [RFC2104] checksum of the entire Access-Request
packet, including Type, ID, Length and authenticator, using the
shared secret as the key, as follows.
Message-Authenticator = HMAC-MD5 (Type, Identifier, Length,
Request Authenticator, Attributes)
When the message integrity check is calculated the signature
string should be considered to be sixteen octets of zero.
For Access-Challenge, Access-Accept, and Access-Reject packets,
the Message-Authenticator is calculated as follows, using the
Request-Authenticator from the Access-Request this packet is in
reply to:
Message-Authenticator = HMAC-MD5 (Type, Identifier, Length,
Request Authenticator, Attributes)
When the message integrity check is calculated the signature
string should be considered to be sixteen octets of zero. The
shared secret is used as the key for the HMAC-MD5 message
integrity check. The is calculated and inserted in the packet
before the Response Authenticator is calculated.
[RFC3576] Section 3.2 indicates that a Message-Authenticator
attribute may be included within a Disconnect or CoA-Request, ACK or
NAK. However [RFC3579] does not describe how a Message-Authenticator
attribute is calculated for these RADIUS packets, or for Accounting-
Request or Response packets.
The algorithm described in [RFC3579] Section 3.2 cannot be applied
because in a Disconnect, CoA or Accounting-Request packet the Request
Authenticator is not a nonce, but rather represents a keyed MD5 hash
over the packet. This creates a circular dependency -- the Request
Authenticator depends on Message-Authenticator and Message-
Authenticator depends on the Response Authenticator.
Nelson, et al. Proposed Standard [Page 14]
INTERNET-DRAFT RADIUS Issues & Fixes 3 June 2006
As a result, in Accounting, CoA or Disconnect-Request or Response
packets the Message-Authenticator attribute is calculated as follows:
Message-Authenticator = HMAC-MD5 (Type, Identifier, Length,
Authenticator, Attributes)
When the HMAC-MD5 hash is calculated the Authenticator field and
Message-Authenticator attribute should be considered to be sixteen
octets of zero. The Message-Authenticator is calculated and
inserted in the packet before the Authenticator is calculated.
2.10. Unknown Identity
[RFC3748] Section 5.1 states:
If the Identity is unknown, the Identity Response field
should be zero bytes in length.
However, [RFC2865] Section 5.1 describes the User-Name attribute as
follows:
The String field is one or more octets.
How should the RADIUS client behave if it receives an EAP-
Response/Identity that is zero octets in length?
[RFC2865] Section 5.1 states:
This Attribute indicates the name of the user to be authenticated.
It MUST be sent in Access-Request packets if available.
This suggests that the User-Name attribute may be ommitted if it is
unavailable.
However, [RFC3579] Section 2.1 states:
In order to permit non-EAP aware RADIUS proxies to forward the
Access-Request packet, if the NAS initially sends an
EAP-Request/Identity message to the peer, the NAS MUST copy the
contents of the Type-Data field of the EAP-Response/Identity received
from the peer into the User-Name attribute and MUST include the
Type-Data field of the EAP-Response/Identity in the User-Name
attribute in every subsequent Access-Request.
This suggests that the User-Name attribute should contain the
contents of the Type-Data field of the EAP-Response/Identity, even if
it is zero octets in length.
Nelson, et al. Proposed Standard [Page 15]
INTERNET-DRAFT RADIUS Issues & Fixes 3 June 2006
Note that [RFC4282] does not permit an NAI of zero octets, so that an
EAP-Response/Identity with a Type-Data field of zero octets MUST NOT
be construed as a request for privacy (e.g. anonymous NAI).
When a NAS receives an EAP-Response/Identity with a Type-Data field
that is zero octets in length, it is RECOMMENDED that it either omit
a User-Name attribute in the Access-Request or include the Calling-
Station-Id in the User-Name attribute, along with a Calling-Station-
Id attribute.
3. IANA Considerations
This specification does not create any new registries, nor does it
require assignment of any protocol parameters.
4. Security Considerations
Since this document describes the use of RADIUS for purposes of
authentication, authorization, and accounting in WLANs, it is
vulnerable to all of the threats that are present in other RADIUS
applications. For a discussion of these threats, see [RFC2865], [RFC
2607], [RFC3162], [RFC3576], [RFC3579], and [RFC3580].
5. References
5.1. Informative references
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March, 1997.
[RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998.
[RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy
Implementation in Roaming", RFC 2607, June 1999.
[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., Aboba, B. and D. Mitton, "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
Nelson, et al. Proposed Standard [Page 16]
INTERNET-DRAFT RADIUS Issues & Fixes 3 June 2006
Support", RFC 2868, June 2000.
[RFC2869] Rigney, C., Willats, W. and P. Calhoun, "RADIUS Extensions",
RFC 2869, June 2000.
[RFC2882] Mitton, D., "Network Access Servers Requirements: Extended
RADIUS Practices", RFC 2882, July 2000.
[RFC3162] Aboba, B., Zorn, G. and D. Mitton, "RADIUS and IPv6", RFC
3162, August 2001.
[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.
[RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G. and J. Roese,
"IEEE 802.1X Remote Authentication Dial In User Service
(RADIUS) Usage Guidelines", RFC 3580, September 2003.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J. and H.
Levkowetz, "Extensible Authentication Protocol (EAP)", RFC
3748, June 2004.
[RFC3927] Cheshire, S., Aboba, B. and E. Guttman, "Dynamic Configuration
of IPv4 Link-Local Addresses", RFC 3927, May 2005.
[RFC4282] Aboba, B., Beadles, M., Arkko, J. and P. Eronen, "The Network
Access Identifier", RFC 4282, December 2005.
Acknowledgments
The authors would like to acknowledge Glen Zorn for contributions to
this document.
Authors' Addresses
David B. Nelson
Enterasys Networks
50 Minuteman Road
Andover, MA 01810
EMail: dnelson@enterasys.com
Nelson, et al. Proposed Standard [Page 17]
INTERNET-DRAFT RADIUS Issues & Fixes 3 June 2006
Alan DeKok
Infoblox, Inc.
475 Potrero Ave
Sunnyvale, CA 94087
Email: adekok@infoblox.com
Phone: +1 408 716 4386
Fax: +1 408 716 4400
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 Rights 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; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Nelson, et al. Proposed Standard [Page 18]
INTERNET-DRAFT RADIUS Issues & Fixes 3 June 2006
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 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 (2006). 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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Open issues
Open issues relating to this specification are tracked on the
following web site:
http://www.drizzle.com/~aboba/RADEXT/
Nelson, et al. Proposed Standard [Page 19]
Html markup produced by rfcmarkup 1.111, available from
https://tools.ietf.org/tools/rfcmarkup/