draft-ietf-radext-fixes-03.txt   draft-ietf-radext-fixes-04.txt 
Network Working Group David Nelson Network Working Group David Nelson
INTERNET-DRAFT Elbrys Networks, Inc INTERNET-DRAFT Elbrys Networks, Inc
Updates: 2865, 2866, 2869, 3579 Alan DeKok Updates: 2865, 2866, 2869, 3579 Alan DeKok
Category: Proposed Standard FreeRADIUS Category: Proposed Standard FreeRADIUS
<draft-ietf-radext-fixes-03.txt> <draft-ietf-radext-fixes-04.txt>
Expires: September 10, 2007 Expires: December 25, 2007
Common RADIUS Implementation Issues and Suggested Fixes
Common Remote Authentication Dial In User Service (RADIUS)
Implementation Issues and Suggested Fixes
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 2, line 17 skipping to change at page 2, line 17
1. Introduction ............................................. 3 1. Introduction ............................................. 3
1.1. Terminology ......................................... 3 1.1. Terminology ......................................... 3
1.2. Requirements Language ............................... 3 1.2. Requirements Language ............................... 3
2. Issues ................................................... 4 2. Issues ................................................... 4
2.1. Session Definition .................................. 4 2.1. Session Definition .................................. 4
2.1.1. State Attribute ................................ 4 2.1.1. State Attribute ................................ 4
2.1.2. Request-ID Supplementation ..................... 5 2.1.2. Request-ID Supplementation ..................... 5
2.2. Overload Conditions ................................. 6 2.2. Overload Conditions ................................. 6
2.2.1. Retransmission Behavior ........................ 6 2.2.1. Retransmission Behavior ........................ 6
2.2.2. Duplicate detection and orderly delivery. ...... 6 2.2.2. Duplicate detection and orderly delivery. ...... 6
2.2.3. Server Response to Overload .................... 7 2.2.3. Server Response to Overload .................... 8
2.3. Accounting Issues ................................... 8 2.3. Accounting Issues ................................... 8
2.3.1. Attributes allowed in an Interim Update ........ 8 2.3.1. Attributes allowed in an Interim Update ........ 8
2.3.2. Acct-Session-Id and Acct-Multi-Session-Id ...... 8 2.3.2. Acct-Session-Id and Acct-Multi-Session-Id ...... 8
2.3.3. Request Authenticator .......................... 9 2.3.3. Request Authenticator .......................... 9
2.3.4. Interim-Accounting-Interval .................... 9 2.3.4. Interim-Accounting-Interval .................... 9
2.3.5. Counter values in the RADIUS MIBs .............. 10 2.3.5. Counter values in the RADIUS Management Informat 10
2.4. Multiple Filter-ID Attributes ....................... 11 2.4. Multiple Filter-ID Attributes ....................... 12
2.5. Mandatory and Optional Attributes ................... 12 2.5. Mandatory and Optional Attributes ................... 12
2.6. Interpretation of Access-Reject ..................... 13 2.6. Interpretation of Access-Reject ..................... 13
2.6.1. Improper Use of Access-Reject .................. 13 2.6.1. Improper Use of Access-Reject .................. 13
2.6.2. Service Request Denial ......................... 15 2.6.2. Service Request Denial ......................... 15
2.7. Addressing .......................................... 15 2.7. Addressing .......................................... 16
2.7.1. Link-Local Addresses ........................... 15 2.7.1. Link-Local Addresses ........................... 16
2.7.2. Multiple Addresses ............................. 16 2.7.2. Multiple Addresses ............................. 16
2.8. Idle-Timeout ........................................ 16 2.8. Idle-Timeout ........................................ 17
2.9. Unknown Identity .................................... 17 2.9. Unknown Identity .................................... 17
2.10. Responses after retransmissions .................... 18 2.10. Responses after retransmissions .................... 18
2.11. Framed-IPv6-Prefix ................................. 18 2.11. Framed-IPv6-Prefix ................................. 19
3. IANA Considerations ...................................... 20 3. IANA Considerations ...................................... 20
4. Security Considerations .................................. 20 4. Security Considerations .................................. 20
5. References ............................................... 20 5. References ............................................... 20
5.1. Normative references ................................ 20 5.1. Normative references ................................ 20
5.2. Informative references .............................. 20 5.2. Informative references .............................. 21
6. RFC Editor instructions .................................. 21
Intellectual Property Statement .............................. 22 Intellectual Property Statement .............................. 22
Disclaimer of Validity ....................................... 23 Disclaimer of Validity ....................................... 23
Full Copyright Statement ..................................... 23 Full Copyright Statement ..................................... 23
1. Introduction 1. Introduction
The last few years have seen an increase in the deployment of RADIUS The last few years have seen an increase in the deployment of RADIUS
clients and servers. This document describes common issues seen in clients and servers. This document describes common issues seen in
RADIUS implementations and suggests some fixes. Where applicable, RADIUS implementations and suggests some fixes. Where applicable,
ambiguities and errors in previous RADIUS specifications are ambiguities and errors in previous RADIUS specifications are
clarified. clarified.
1.1. Terminology 1.1. Terminology
This document uses the following terms: This document uses the following terms:
Network Access Server (NAS) Network Access Server (NAS)
The device providing access to the network. Also known as the The device providing access to the network. Also known as the
Authenticator (IEEE 802.1X or EAP terminology) or RADIUS client. Authenticator in IEEE 802.1X or Extensible Authentication Protocol
(EAP) terminology, or RADIUS client.
service service
The NAS provides a service to the user, such as network access via The NAS provides a service to the user, such as network access via
802.11 or PPP. 802.11 or Point to Point Protocol (PPP).
session session
Each service provided by the NAS to a peer constitutes a session, Each service provided by the NAS to a peer constitutes a session,
with the beginning of the session defined as the point where with the beginning of the session defined as the point where
service is first provided and the end of the session defined as the 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 point where service is ended. A peer may have multiple sessions in
parallel or series if the NAS supports that, with each session parallel or series if the NAS supports that, with each session
generating a separate start and stop accounting record. generating a separate start and stop accounting record.
silently discard silently discard
skipping to change at page 4, line 32 skipping to change at page 4, line 32
termination of the current session, it MUST include the State termination of the current session, it MUST include the State
attribute unchanged in that Access-Request. attribute unchanged in that Access-Request.
Some RADIUS client implementations do not properly use the State Some RADIUS client implementations do not properly use the State
attribute in order to distinguish a restarted EAP authentication attribute in order to distinguish a restarted EAP authentication
process from the continuation of an ongoing process (by the same user process from the continuation of an ongoing process (by the same user
on the same NAS and port). on the same NAS and port).
Where an EAP-Message attribute is included in an Access-Challenge or Where an EAP-Message attribute is included in an Access-Challenge or
Access-Accept attribute, RADIUS servers SHOULD also include a State Access-Accept attribute, RADIUS servers SHOULD also include a State
attribute. See the following section for additional benefits to attribute. See Section 2.1.3 on Request ID supplementation for
using the State attribute in this fashion. additional benefits to using the State attribute in this fashion.
An Access-Request sent as a result of a new or restarted An Access-Request sent as a result of a new or restarted
authentication run MUST NOT include the State attribute, even if the authentication run MUST NOT include the State attribute, even if the
State attribute has previously been received in an Access-Challenge State attribute has previously been received in an Access-Challenge
for the same user and port. for the same user and port.
Since a State attribute is always initially provided by the server in Since a State attribute is always initially provided by the server in
an Access-Accept, Access-Challenge, CoA-Request or Disconnect- an Access-Accept, Access-Challenge, CoA-Request or Disconnect-
Request, a RADIUS client MUST NOT insert a State attribute that it Request, a RADIUS client MUST NOT insert a State attribute that it
has not previously received from the server. has not previously received from the server.
skipping to change at page 5, line 27 skipping to change at page 5, line 27
Id, Called-Station-Id, Calling-Station-Id and Originating-Line- Id, Called-Station-Id, Calling-Station-Id and Originating-Line-
Info. Info.
There are issues with the suggested algorithm. Since proxies may There are issues with the suggested algorithm. Since proxies may
modify Access-Request attributes such as NAS-IP-Address, depending on modify Access-Request attributes such as NAS-IP-Address, depending on
any attribute under control of the NAS to distinguish request any attribute under control of the NAS to distinguish request
identifiers can result in deployment problems. identifiers can result in deployment problems.
The FreeRADIUS implementation does not track EAP identifiers by NAS- The FreeRADIUS implementation does not track EAP identifiers by NAS-
IP-Address or other non-EAP attributes sent by the NAS. Instead, it IP-Address or other non-EAP attributes sent by the NAS. Instead, it
uses the EAP identifier, source IP address, and the State attribute uses the EAP identifier, source Internet Protocol (IP) address, and
as a "key" to uniquely identify each EAP session. Since the State the State attribute as a "key" to uniquely identify each EAP session.
attribute is under the control of the RADIUS server, this means that Since the State attribute is under the control of the RADIUS server,
the uniqueness of each session is controlled by the server, not the this means that the uniqueness of each session is controlled by the
NAS. The algorithm used in FreeRADIUS is as follows: server, not the NAS. The algorithm used in FreeRADIUS is as follows:
if (EAP start, or EAP identity) { if (EAP start, or EAP identity) {
allocate unique State Attribute allocate unique State Attribute
insert session into "active session" table with insert session into "active session" table with
key=(EAP identifier, State, source IP) key=(EAP identifier, State, source IP)
} else { } else {
look up active session in table, with above key look up active session in table, with above key
} }
This algorithm appears to work well in variety of situations, This algorithm appears to work well in variety of situations,
skipping to change at page 6, line 14 skipping to change at page 6, line 14
2.2. Overload Conditions 2.2. Overload Conditions
2.2.1. Retransmission Behavior 2.2.1. Retransmission Behavior
[RFC2865] Section 2.4 describes the retransmission requirements for [RFC2865] Section 2.4 describes the retransmission requirements for
RADIUS clients: RADIUS clients:
At one extreme, RADIUS does not require a "responsive" detection At one extreme, RADIUS does not require a "responsive" detection
of lost data. The user is willing to wait several seconds for the of lost data. The user is willing to wait several seconds for the
authentication to complete. The generally aggressive TCP authentication to complete. The generally aggressive Transmission
retransmission (based on average round trip time) is not required, Control Protocol (TCP) retransmission (based on average round trip
nor is the acknowledgment overhead of TCP. time) is not required, nor is the acknowledgment overhead of TCP.
At the other extreme, the user is not willing to wait several At the other extreme, the user is not willing to wait several
minutes for authentication. Therefore the reliable delivery of minutes for authentication. Therefore the reliable delivery of
TCP data two minutes later is not useful. The faster use of an TCP data two minutes later is not useful. The faster use of an
alternate server allows the user to gain access before giving up. alternate server allows the user to gain access before giving up.
Some existing RADIUS clients implement excessively aggressive Some existing RADIUS clients implement excessively aggressive
retransmission behavior, utilizing default retransmission timeouts of retransmission behavior, utilizing default retransmission timeouts of
one second or less without support for congestive backoff. When one second or less without support for congestive backoff. When
deployed at large scale, these implementations are susceptible to deployed at large scale, these implementations are susceptible to
skipping to change at page 6, line 51 skipping to change at page 6, line 51
SHOULD double the initial retransmission timer until a maximum SHOULD double the initial retransmission timer until a maximum
retransmission time is reached, after which the client will retransmission time is reached, after which the client will
failover to another RADIUS server. For example, if the initial failover to another RADIUS server. For example, if the initial
retransmission timer is one second, a maximum retransmission timer retransmission timer is one second, a maximum retransmission timer
of 16 seconds might be used. of 16 seconds might be used.
2.2.2. Duplicate detection and orderly delivery. 2.2.2. Duplicate detection and orderly delivery.
When packets are retransmitted by a client, the server may receive When packets are retransmitted by a client, the server may receive
duplicate requests. The limitations of the transport protocol used duplicate requests. The limitations of the transport protocol used
by RADIUS (UDP) means that the Access-Request packets may be by RADIUS, the User Datagram Protocol (UDP), means that the Access-
received, and potentially processed, in an order different from the Request packets may be received, and potentially processed, in an
order in which the packets were sent. However, the discussion of the order different from the order in which the packets were sent.
Identifier field in Section 3 of [RFC2865] suys: However, the discussion of the Identifier field in Section 3 of
[RFC2865] says:
The RADIUS server can detect a duplicate request if it has the The RADIUS server can detect a duplicate request if it has the
same client source IP address and source UDP port and Identifier same client source IP address and source UDP port and Identifier
within a short span of time. within a short span of time.
Also, Section 7 of [RFC4669] defines a Also, Section 7 of [RFC4669] defines a
radiusAuthServDupAccessRequests object, as radiusAuthServDupAccessRequests object, as
The number of duplicate Access-Request packets received. The number of duplicate Access-Request packets received.
This text has a number of implications. First, without duplicate This text has a number of implications. First, without duplicate
detection, a RADIUS server may process an authentication request detection, a RADIUS server may process an authentication request
twice, leading to an erroneous conclusion that a user has logged in twice, leading to an erroneous conclusion that a user has logged in
twice. That behavior is undesirable, so duplicate detection is twice. That behavior is undesirable, so duplicate detection is
desirable. Second, the server may track not only the duplicate desirable. Second, the server may track not only the duplicate
request, but also the replies to those requests. This behavior request, but also the replies to those requests. This behavior
permits the server to send duplicate replies in response to duplicate permits the server to send duplicate replies in response to duplicate
requests, increasing network stability. requests, increasing network stability.
Since Access-Request packets may also be sent by the client in Since Access-Request packets may also be sent by the client in
skipping to change at page 7, line 32 skipping to change at page 7, line 36
Since Access-Request packets may also be sent by the client in Since Access-Request packets may also be sent by the client in
response to an Access-Challenge from the server, those packets form a response to an Access-Challenge from the server, those packets form a
logically ordered stream, and therefore have additional ordering logically ordered stream, and therefore have additional ordering
requirements over Access-Request packets for different sessions. requirements over Access-Request packets for different sessions.
Implementing duplicate detection results in new packets being Implementing duplicate detection results in new packets being
processed only once, ensuring order. processed only once, ensuring order.
RADIUS servers MUST therefore implement duplicate detection for RADIUS servers MUST therefore implement duplicate detection for
Access-Request packets, as described in Section 3 of [RFC2865]. Access-Request packets, as described in Section 3 of [RFC2865].
Implementations MUST also cache the Responses (Access-Accept, Access- Implementations MUST also cache the Responses (Access-Accept, Access-
Challenge, or Access-Reject) that is sends for those Access-Request Challenge, or Access-Reject) that they send in response to Access-
packets. If a server receives a valid duplicate Access-Request for Request packets. If a server receives a valid duplicate Access-
which is already has sent a Response, it MUST resend its original Request for which is already has sent a Response, it MUST resend its
Response without reprocessing the request. The server MUST silently original Response without reprocessing the request. The server MUST
discard any duplicate Access-Requests for which a Response has not silently discard any duplicate Access-Requests for which a Response
been sent yet. has not been sent yet.
Each cache entry SHOULD be purged after a period of time. This time Each cache entry SHOULD be purged after a period of time. This time
SHOULD be no less than 5 seconds, and no more than 30 seconds. SHOULD be no less than 5 seconds, and no more than 30 seconds.
Cache entries MUST also be purged if the server receives an Access- Cache entries MUST also be purged if the server receives an Access-
Request packet that matches a cached Access-Request packet in source Request packet that matches a cached Access-Request packet in source
address, source port, RADIUS Identifier, and receiving socket, but address, source port, RADIUS Identifier, and receiving socket, but
where the Request Authenticator field is different from the one in where the Request Authenticator field is different from the one in
the cached packet. the cached packet.
skipping to change at page 9, line 20 skipping to change at page 9, line 24
A summary of the Acct-Session-Id attribute format ... A summary of the Acct-Session-Id attribute format ...
This text should read This text should read
A summary of the Acct-Multi-Session-Id attribute format ... A summary of the Acct-Multi-Session-Id attribute format ...
The Acct-Multi-Session-Id attribute is also defined as being of type The Acct-Multi-Session-Id attribute is also defined as being of type
"String". However, the language in the text strongly recommends that "String". However, the language in the text strongly recommends that
implementors consider the attribute as being of type "Text". It is implementors consider the attribute as being of type "Text". It is
unclear why the type "String" was chosen for this attribute when the unclear why the type "String" was chosen for this attribute when the
type "Text" would be sufficient. type "Text" would be sufficient. This attribute SHOULD be treated as
"Text".
2.3.3. Request Authenticator 2.3.3. Request Authenticator
[RFC2866] Section 4.1 states: [RFC2866] Section 4.1 states:
The Request Authenticator of an Accounting-Request contains a The Request Authenticator of an Accounting-Request contains a
16-octet MD5 hash value calculated according to the method 16-octet MD5 hash value calculated according to the method
described in "Request Authenticator" above. described in "Request Authenticator" above.
However, the text does not indicate any action to take when an However, the text does not indicate any action to take when an
skipping to change at page 10, line 15 skipping to change at page 10, line 21
Accounting-Interval, based on resource constraints in the NAS, and Accounting-Interval, based on resource constraints in the NAS, and
network loading in the local environment of the NAS. In such cases, network loading in the local environment of the NAS. In such cases,
the value administratively provisioned in the NAS should not be over- the value administratively provisioned in the NAS should not be over-
ridden by a smaller value from an Access-Accept message. The NAS's ridden by a smaller value from an Access-Accept message. The NAS's
value could be over-ridden by a larger one, however. The intent is value could be over-ridden by a larger one, however. The intent is
that the NAS sends accounting information at fixed intervals, short that the NAS sends accounting information at fixed intervals, short
enough such that the potential loss of billable revenue is limited, enough such that the potential loss of billable revenue is limited,
but also that the accounting updates are infrequent enough such that but also that the accounting updates are infrequent enough such that
the NAS, network, and RADIUS server are not overloaded. the NAS, network, and RADIUS server are not overloaded.
2.3.5. Counter values in the RADIUS MIBs 2.3.5. Counter values in the RADIUS Management Information Base (MIB)
The RADIUS Authentication and Authorization Client MIB module The RADIUS Authentication and Authorization Client MIB module
[RFC2618], [RFC4668] includes counters of packet statistics. In the [RFC2618], [RFC4668] includes counters of packet statistics. In the
descriptive text of the MIB module, formulas are provided for certain descriptive text of the MIB module, formulas are provided for certain
counter objects. Implementors have noted apparent inconsistencies in counter objects. Implementors have noted apparent inconsistencies in
the formulas, which could result in negative values. the formulas, which could result in negative values.
Since the original MIB module specified in [RFC2618] had been widely Since the original MIB module specified in [RFC2618] had been widely
implemented, the RADEXT WG chose not to change the object definitions implemented, the RADEXT WG chose not to change the object definitions
or to create new ones within the revised MIB module [RFC4668]. or to create new ones within the revised MIB module [RFC4668].
skipping to change at page 12, line 26 skipping to change at page 12, line 35
2.5. Mandatory and Optional Attributes 2.5. Mandatory and Optional Attributes
RADIUS attributes do not explicitly state whether they are optional RADIUS attributes do not explicitly state whether they are optional
or mandatory. Nevertheless there are instances where RADIUS or mandatory. Nevertheless there are instances where RADIUS
attributes need to be treated as mandatory. attributes need to be treated as mandatory.
[RFC2865] Section 1.1 states: [RFC2865] Section 1.1 states:
A NAS that does not implement a given service MUST NOT implement A NAS that does not implement a given service MUST NOT implement
the RADIUS attributes for that service. For example, a NAS that the RADIUS attributes for that service. For example, a NAS that
is unable to offer ARAP service MUST NOT implement the RADIUS is unable to offer Apple Remote Access Protocol (ARAP) service
attributes for ARAP. A NAS MUST treat a RADIUS access-accept MUST NOT implement the RADIUS attributes for ARAP. A NAS MUST
authorizing an unavailable service as an access-reject instead. 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 With respect to the Service-Type attribute, [RFC2865] Section 5.6
says: says:
This Attribute indicates the type of service the user has This Attribute indicates the type of service the user has
requested, or the type of service to be provided. It MAY be used 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 in both Access-Request and Access-Accept packets. A NAS is not
required to implement all of these service types, and MUST treat required to implement all of these service types, and MUST treat
unknown or unsupported Service-Types as though an Access-Reject unknown or unsupported Service-Types as though an Access-Reject
had been received instead. had been received instead.
skipping to change at page 13, line 17 skipping to change at page 13, line 27
request for an unavailable service. However, where the Type or request for an unavailable service. However, where the Type or
Vendor-ID is unknown, a RADIUS client will not know whether the Vendor-ID is unknown, a RADIUS client will not know whether the
attribute defines a service or not. attribute defines a service or not.
In general, it is best for RADIUS clients to err on the side of In general, it is best for RADIUS clients to err on the side of
caution. On receiving an Access-Accept including an attribute of caution. On receiving an Access-Accept including an attribute of
unknown Type, a RADIUS client SHOULD assume that it is a potential unknown Type, a RADIUS client SHOULD assume that it is a potential
service definition, and treat it as an Access-Reject. Unknown VSAs service definition, and treat it as an Access-Reject. Unknown VSAs
SHOULD be ignored by RADIUS clients. SHOULD be ignored by RADIUS clients.
RADIUS authentication server implementations SHOULD ignore attributes On receiving a packet including an attribute of unknown type, RADIUS
of unknown Type. Since RADIUS accounting server implementations authentication server implementations SHOULD ignore such attributes.
typically do not need to understand attributes in order to write them However, RADIUS accounting server implementations typically do not
to stable storage or pass them to the billing engine, accounting need to understand attributes in order to write them to stable
storage or pass them to the billing engine. Therefore, accounting
server implementations SHOULD be equipped to handle unknown server implementations SHOULD be equipped to handle unknown
attributes. attributes.
To avoid misinterpretation of service requests encoded within VSAs, To avoid misinterpretation of service requests encoded within VSAs,
RADIUS servers SHOULD NOT send VSAs containing service requests to RADIUS servers SHOULD NOT send VSAs containing service requests to
RADIUS clients that are not known to understand them. For example, a RADIUS clients that are not known to understand them. For example, a
RADIUS server should not send a VSA encoding a filter without RADIUS server should not send a VSA encoding a filter without
knowledge that the RADIUS client supports the VSA. knowledge that the RADIUS client supports the VSA.
2.6. Interpretation of Access-Reject 2.6. Interpretation of Access-Reject
skipping to change at page 14, line 52 skipping to change at page 15, line 13
[RFC2869] Section 2.2. [RFC2869] Section 2.2.
We also note that the table of attributes [RFC2869] Section 5.19 has We also note that the table of attributes [RFC2869] Section 5.19 has
an error for the Password-Retry attribute. It says: an error for the Password-Retry attribute. It says:
Request Accept Reject Challenge # Attribute Request Accept Reject Challenge # Attribute
0 0 0-1 0 75 Password-Retry 0 0 0-1 0 75 Password-Retry
However, the text in [RFC2869] Section 2.3.2 says that 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 can be included within an Access-Challenge packet, for EAP
authentication sessions. We recommend a correction to the table: authentication sessions. We recommend a correction to the table,
which removes the "0-1" from the Reject column, moves it to the
Challenge column. We also add a "Note 2" to follow the existing
"Note 1" in the document, to clarify the use of this attribute.
Request Accept Reject Challenge # Attribute Request Accept Reject Challenge # Attribute
0 0 0 0-1 75 Password-Retry [Note 2] 0 0 0 0-1 75 Password-Retry [Note 2]
[Note 2] As per RFC 3579, the use of the Password-Retry in EAP [Note 2] As per RFC 3579, the use of the Password-Retry in EAP
authentications is deprecated. The Password-Retry attribute can be authentications is deprecated. The Password-Retry attribute can be
used only for ARAP authentication. used only for ARAP authentication.
2.6.2. Service Request Denial 2.6.2. Service Request Denial
RADIUS has been deployed for purposes outside network access RADIUS has been deployed for purposes outside network access
authentication, authorization and accounting. For example, RADIUS authentication, authorization and accounting. For example, RADIUS
has been deployed as a "back-end" for authenticating Voice Over IP has been deployed as a "back-end" for authenticating Voice Over IP
(VOIP) connections, HTTP sessions (e.g. Apache), FTP sessions (e.g. (VOIP) connections, Hypertext Transfer Protocol (HTTP) sessions (e.g.
proftpd), and machine logins for multiple operating systems (e.g. Apache), File Transfer Protocol (FTP) sessions (e.g. proftpd), and
bsdi, pam, gina). In those contexts, an Access-Reject sent to the machine logins for multiple operating systems (e.g. bsdi, pam, gina).
RADIUS client MUST be interpreted as a rejection of the request for In those contexts, an Access-Reject sent to the RADIUS client MUST be
service, and the RADIUS client MUST NOT offer that service to the interpreted as a rejection of the request for service, and the RADIUS
user. client MUST NOT offer that service to the user.
For example, when an authentication failure occurs in the context of For example, when an authentication failure occurs in the context of
an FTP session, the normal semantics for rejecting FTP services an FTP session, the normal semantics for rejecting FTP services
apply. The rejection does not necessarily cause the FTP server to apply. The rejection does not necessarily cause the FTP server to
terminate the underlying TCP connection, but the FTP server MUST NOT terminate the underlying TCP connection, but the FTP server MUST NOT
offer any services protected by user authentication. offer any services protected by user authentication.
Users may request multiple services from the NAS. Where those Users may request multiple services from the NAS. Where those
services are independent, the deployment MUST treat the RADIUS services are independent, the deployment MUST treat the RADIUS
sessions as being independent. sessions as being independent.
skipping to change at page 17, line 51 skipping to change at page 18, line 19
EAP-Request/Identity message to the peer, the NAS MUST copy the EAP-Request/Identity message to the peer, the NAS MUST copy the
contents of the Type-Data field of the EAP-Response/Identity contents of the Type-Data field of the EAP-Response/Identity
received from the peer into the User-Name attribute and MUST received from the peer into the User-Name attribute and MUST
include the Type-Data field of the EAP-Response/Identity in the include the Type-Data field of the EAP-Response/Identity in the
User-Name attribute in every subsequent Access-Request. User-Name attribute in every subsequent Access-Request.
This suggests that the User-Name attribute should contain the This suggests that the User-Name attribute should contain the
contents of the Type-Data field of the EAP-Response/Identity, even if contents of the Type-Data field of the EAP-Response/Identity, even if
it is zero octets in length. it is zero octets in length.
Note that [RFC4282] does not permit an NAI of zero octets, so that an Note that [RFC4282] does not permit a Network Access Identifier (NAI)
EAP-Response/Identity with a Type-Data field of zero octets MUST NOT of zero octets, so that an EAP-Response/Identity with a Type-Data
be construed as a request for privacy (e.g. anonymous NAI). 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 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 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- the User-Name attribute in the Access-Request or include the Calling-
Station-Id in the User-Name attribute, along with a Calling-Station- Station-Id in the User-Name attribute, along with a Calling-Station-
Id attribute. Id attribute.
2.10. Responses after retransmissions 2.10. Responses after retransmissions
Some implementations do not correctly handle the receipt of RADIUS Some implementations do not correctly handle the receipt of RADIUS
responses after retransmissions. [RFC2865] Section 2.5 states responses after retransmissions. [RFC2865] Section 2.5 states
If the NAS is retransmitting a RADIUS request to the same server If the NAS is retransmitting a RADIUS request to the same server
as before, and the attributes haven't changed, you MUST use the as before, and the attributes haven't changed, you MUST use the
skipping to change at page 19, line 13 skipping to change at page 19, line 29
This Attribute indicates an IPv6 prefix (and corresponding route) This Attribute indicates an IPv6 prefix (and corresponding route)
to be configured for the user. It MAY be used in Access-Accept to be configured for the user. It MAY be used in Access-Accept
packets, and can appear multiple times. It MAY be used in an packets, and can appear multiple times. It MAY be used in an
Access-Request packet as a hint by the NAS to the server that it Access-Request packet as a hint by the NAS to the server that it
would prefer these prefix(es), but the server is not required to would prefer these prefix(es), but the server is not required to
honor the hint. Since it is assumed that the NAS will plumb a honor the hint. Since it is assumed that the NAS will plumb a
route corresponding to the prefix, it is not necessary for the route corresponding to the prefix, it is not necessary for the
server to also send a Framed-IPv6-Route attribute for the same server to also send a Framed-IPv6-Route attribute for the same
prefix. prefix.
An ISP may desire to support Prefix Delegation [PREFIX] at the same An Internet Service Provider (ISP) may desire to support Prefix
time that it would like to assign a prefix for the link between the Delegation [RFC4818] at the same time that it would like to assign a
NAS and the user. The intent of the paragraph was to enable the NAS prefix for the link between the NAS and the user. The intent of the
to advertise the prefix (such as via a Router Advertisement). If the paragraph was to enable the NAS to advertise the prefix (such as via
Framed-Routing attribute is used, it is also possible that the prefix a Router Advertisement). If the Framed-Routing attribute is used, it
would be advertised in a routing protocol such as RIPNG. RFC 2865 is also possible that the prefix would be advertised in a routing
Section 5.10 describes the purpose of Framed-Routing: protocol such as RIPNG. RFC 2865 Section 5.10 describes the purpose
of Framed-Routing:
This Attribute indicates the routing method for the user, when the This Attribute indicates the routing method for the user, when the
user is a router to a network. It is only used in Access-Accept user is a router to a network. It is only used in Access-Accept
packets. packets.
The description of the Prefix-Length field in RFC 3162 indicates The description of the Prefix-Length field in RFC 3162 indicates
excessively wide latitude: excessively wide latitude:
The length of the prefix, in bits. At least 0 and no larger than The length of the prefix, in bits. At least 0 and no larger than
128. 128.
skipping to change at page 19, line 45 skipping to change at page 20, line 14
3162 already defines a Framed-IPv6-Identifier attribute to handle the 3162 already defines a Framed-IPv6-Identifier attribute to handle the
Identifier portion. Identifier portion.
It appears that the Framed-IPv6-Prefix is used for the link between It appears that the Framed-IPv6-Prefix is used for the link between
the NAS and CPE only if a /64 prefix is assigned. When a /64 or the NAS and CPE only if a /64 prefix is assigned. When a /64 or
larger prefix is sent, the intent is for the NAS to send a routing larger prefix is sent, the intent is for the NAS to send a routing
advertisement containing the information present in the Framed- advertisement containing the information present in the Framed-
IPv6-Prefix attribute. IPv6-Prefix attribute.
The CPE may also require a delegated prefix for its own use, if it is The CPE may also require a delegated prefix for its own use, if it is
decrementing the TTL field of IP headers. In that case, it should be decrementing the Time To Live (TTL) field of IP headers. In that
delegated a prefix by the NAS via the Delegated-IPv6-Prefix case, it should be delegated a prefix by the NAS via the Delegated-
attribute. [PREFIX]. If the CPE is not decrementing TTL, it does IPv6-Prefix attribute. [RFC4818]. If the CPE is not decrementing
not require a delegated prefix. TTL, it does not require a delegated prefix.
3. IANA Considerations 3. IANA Considerations
This specification does not create any new registries, nor does it This specification does not create any new registries, nor does it
require assignment of any protocol parameters. require assignment of any protocol parameters.
4. Security Considerations 4. Security Considerations
The contents of the State attribute are available to both the RADIUS
client and observers of the RADIUS protocol. RADIUS server
implementations should ensure that the state attribute does not
disclose sensitive information to a RADIUS client or third parties
observing the RADIUS protocol.
Since this document describes the use of RADIUS for purposes of Since this document describes the use of RADIUS for purposes of
authentication, authorization, and accounting in WLANs, it is authentication, authorization, and accounting in a wide variety of
vulnerable to all of the threats that are present in other RADIUS networks, applications using these specifications are vulnerable to
applications. For a discussion of these threats, see [RFC2865], all of the threats that are present in other RADIUS applications.
[RFC2607], [RFC3162], [RFC3579], and [RFC3580]. For a discussion of these threats, see [RFC2865], [RFC2607],
[RFC3162], [RFC3579], and [RFC3580].
5. References 5. References
5.1. Normative references 5.1. Normative references
[RFC2865] [RFC2865]
Rigney, C., Rubens, A., Simpson, W. and S. Willens, "Remote Rigney, C., Rubens, A., Simpson, W. and S. Willens, "Remote
Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000.
[PREFIX] [RFC4818]
Salowey, J., Droms., R, "RADIUS Delegated-IPv6-Prefix Attribute", Salowey, J., Droms., R, "RADIUS Delegated-IPv6-Prefix Attribute",
drafty-ietf-radext-delegated-prefix-05.txt, October, 2006. RFC 4818, April 2007.
5.2. Informative references 5.2. Informative references
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March, 1997. Requirement Levels", RFC 2119, March, 1997.
[RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998. Autoconfiguration", RFC 2462, December 1998.
[RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy [RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy
skipping to change at page 21, line 28 skipping to change at page 21, line 50
[RFC4282] Aboba, B., Beadles, M., Arkko, J. and P. Eronen, "The Network [RFC4282] Aboba, B., Beadles, M., Arkko, J. and P. Eronen, "The Network
Access Identifier", RFC 4282, December 2005. Access Identifier", RFC 4282, December 2005.
[RFC4668] Nelson, D, "RADIUS Authentication Client MIB for IPv6", RFC [RFC4668] Nelson, D, "RADIUS Authentication Client MIB for IPv6", RFC
4668, August 2006. 4668, August 2006.
[RFC4669] Nelson, D, "RADIUS Authentication Server MIB for IPv6", RFC [RFC4669] Nelson, D, "RADIUS Authentication Server MIB for IPv6", RFC
4669, August 2006. 4669, August 2006.
6. RFC Editor instructions
The references to [PREFIX] should be replaced with a reference to the
RFC when it is issued, and this section deleted, prior to issuing
this document as an RFC.
Acknowledgments Acknowledgments
The authors would like to acknowledge Glen Zorn and Bernard Aboba for The authors would like to acknowledge Glen Zorn and Bernard Aboba for
contributions to this document. contributions to this document.
The alternate algorithm to [RFC3579] Section 2.6.1 that is described The alternate algorithm to [RFC3579] Section 2.6.1 that is described
in section 2.1.2 of this document was designed by Raghu Dendukuri. in section 2.1.2 of this document was designed by Raghu Dendukuri.
David Nelson wishes to acknowledge the support of Enterasys Networks, David Nelson wishes to acknowledge the support of Enterasys Networks,
where he was employed during much of the work on this document. where he was employed during much of the work on this document.
 End of changes. 32 change blocks. 
77 lines changed or deleted 92 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/