draft-ietf-radext-fixes-04.txt   draft-ietf-radext-fixes-05.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-04.txt> <draft-ietf-radext-fixes-05.txt>
Expires: December 25, 2007 Expires: January 02, 2007
Common Remote Authentication Dial In User Service (RADIUS) Common Remote Authentication Dial In User Service (RADIUS)
Implementation Issues and Suggested Fixes 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
skipping to change at page 2, line 16 skipping to change at page 2, line 16
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. ...... 8
2.2.3. Server Response to Overload .................... 8 2.2.3. Server Response to Overload .................... 9
2.3. Accounting Issues ................................... 8 2.3. Accounting Issues ................................... 10
2.3.1. Attributes allowed in an Interim Update ........ 8 2.3.1. Attributes allowed in an Interim Update ........ 10
2.3.2. Acct-Session-Id and Acct-Multi-Session-Id ...... 8 2.3.2. Acct-Session-Id and Acct-Multi-Session-Id ...... 10
2.3.3. Request Authenticator .......................... 9 2.3.3. Request Authenticator .......................... 11
2.3.4. Interim-Accounting-Interval .................... 9 2.3.4. Interim-Accounting-Interval .................... 11
2.3.5. Counter values in the RADIUS Management Informat 10 2.3.5. Counter values in the RADIUS Management Informat 12
2.4. Multiple Filter-ID Attributes ....................... 12 2.4. Multiple Filter-ID Attributes ....................... 13
2.5. Mandatory and Optional Attributes ................... 12 2.5. Mandatory and Optional Attributes ................... 14
2.6. Interpretation of Access-Reject ..................... 13 2.6. Interpretation of Access-Reject ..................... 15
2.6.1. Improper Use of Access-Reject .................. 13 2.6.1. Improper Use of Access-Reject .................. 15
2.6.2. Service Request Denial ......................... 15 2.6.2. Service Request Denial ......................... 17
2.7. Addressing .......................................... 16 2.7. Addressing .......................................... 18
2.7.1. Link-Local Addresses ........................... 16 2.7.1. Link-Local Addresses ........................... 18
2.7.2. Multiple Addresses ............................. 16 2.7.2. Multiple Addresses ............................. 18
2.8. Idle-Timeout ........................................ 17 2.8. Idle-Timeout ........................................ 18
2.9. Unknown Identity .................................... 17 2.9. Unknown Identity .................................... 19
2.10. Responses after retransmissions .................... 18 2.10. Responses after retransmissions .................... 20
2.11. Framed-IPv6-Prefix ................................. 19 2.11. Framed-IPv6-Prefix ................................. 21
3. IANA Considerations ...................................... 20 3. IANA Considerations ...................................... 22
4. Security Considerations .................................. 20 4. Security Considerations .................................. 22
5. References ............................................... 20 5. References ............................................... 22
5.1. Normative references ................................ 20 5.1. Normative references ................................ 22
5.2. Informative references .............................. 21 5.2. Informative references .............................. 23
Intellectual Property Statement .............................. 22 Intellectual Property Statement .............................. 24
Disclaimer of Validity ....................................... 23 Disclaimer of Validity ....................................... 26
Full Copyright Statement ..................................... 23 Full Copyright Statement ..................................... 26
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
skipping to change at page 4, line 45 skipping to change at page 4, line 45
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.
A State attribute is REQUIRED in Access-Request packets neither As defined in [RFC 2865] Table 5.44, Access-Request packets MAY
including an authentication attribute nor a Service-Type attribute contain a State attribute. We extend that definition here, to say
with the value Call Check (10). that Access-Request packets that contain an authentication attribute
or a Service-Type attribute with the value Call Check (10) MAY
contain a State attribute. Access-Request packets not matching the
above description MUST contain a State attribute.
2.1.2. Request-ID Supplementation 2.1.2. Request-ID Supplementation
[RFC3579] Section 2.6.1 states: [RFC3579] Section 2.6.1 states:
In EAP, each session has its own unique Identifier space. RADIUS In EAP, each session has its own unique Identifier space. RADIUS
server implementations MUST be able to distinguish between EAP server implementations MUST be able to distinguish between EAP
packets with the same Identifier existing within distinct packets with the same Identifier existing within distinct
sessions, originating on the same NAS. For this purpose, sessions sessions, originating on the same NAS. For this purpose, sessions
can be distinguished based on NAS and session identification can be distinguished based on NAS and session identification
skipping to change at page 6, line 35 skipping to change at page 6, line 35
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
congestive collapse. For example, as the result of a power failure, congestive collapse. For example, as the result of a power failure,
a network with 3000 NAS devices with a fixed retransmission timer of a network with 3000 NAS devices with a fixed retransmission timer of
one second will continuously generate 3000 RADIUS Access-Requests per one second will continuously generate 3000 RADIUS Access-Requests per
second. This is sufficient to overwhelm most RADIUS servers. second. This is sufficient to overwhelm most RADIUS servers.
Suggested solutions include: Suggested solutions include:
[a] Jitter. To avoid synchronization, a RADIUS client SHOULD [a] Jitter. To avoid synchronization, a RADIUS client SHOULD
incorporate jitter within its retransmission algorithm. incorporate induced jitter within its retransmission algorithm, as
specified below.
[b] Congestive backoff. While it is not necessary for RADIUS client [b] Congestive backoff. While it is not necessary for RADIUS client
implementations to implement complex retransmission algorithms, implementations to implement complex retransmission algorithms,
implementations SHOULD support congestive backoff within the limits implementations SHOULD support congestive backoff within the limits
suggested by [RFC2865] Section 2.4. For example, an implementation suggested by [RFC2865] Section 2.4.
SHOULD double the initial retransmission timer until a maximum
retransmission time is reached, after which the client will RADIUS retransmission timers are based on the model used in DHCPv6
failover to another RADIUS server. For example, if the initial [RFC3315]. Variables used here are also borrowed from this
retransmission timer is one second, a maximum retransmission timer specification. RADIUS is a request/response-based protocol. The
of 16 seconds might be used. message exchange terminates when the requester successfully
receives the answer or the message exchange is considered to have
failed according to the retransmission mechanism described below.
The retransmission behavior is controlled and described by the
following variables:
RT Retransmission timeout
IRT Initial retransmission time (default 2 seconds)
MRC Maximum retransmission count (default 10 attempts)
MRT Maximum retransmission time (default 16 seconds)
MRD Maximum retransmission duration (default 30 seconds)
RAND Randomization factor
With each message transmission or retransmission, the sender sets
RT according to the rules given below. If RT expires before the
message exchange terminates, the sender recomputes RT and
retransmits the message.
Each of the computations of a new RT include a randomization factor
(RAND), which is a random number chosen with a uniform distribution
between -0.1 and +0.1. The randomization factor is included to
minimize synchronization of messages.
The algorithm for choosing a random number does not need to be
cryptographically sound. The algorithm SHOULD produce a different
sequence of random numbers from each invocation.
RT for the first message transmission is based on IRT:
RT = IRT + RAND*IRT
RT for each subsequent message retransmission is based on the
previous value of RT:
RT = 2*RTprev + RAND*RTprev
MRT specifies an upper bound on the value of RT (disregarding the
randomization added by the use of RAND). If MRT has a value of 0,
there is no upper limit on the value of RT. Otherwise:
if (RT > MRT)
RT = MRT + RAND*MRT
MRD specifies an upper bound on the length of time a sender may
retransmit a message. The message exchange fails once MRD seconds
have elapsed since the client first transmitted the message. MRD
MUST be set, and SHOULD have a value between 5 and 30 seconds.
These values mirror the values for a servers duplicate detection
cache, as described in the next section.
MRC specifies an upper bound on the number of times a sender may
retransmit a message. if MRC is zero, the message exchange fails
once MRD seconds have elapsed since the client first transmitted
the message. If MRC is non-zero, the message exchange fails when
the either the sender has transmitted the message MRC times, or
when MRD seconds have elapsed since the client first transmitted
the message.
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, the User Datagram Protocol (UDP), means that the Access- by RADIUS, the User Datagram Protocol (UDP), means that the Access-
Request packets may be received, and potentially processed, in an Request packets may be received, and potentially processed, in an
order different from the order in which the packets were sent. order different from the order in which the packets were sent.
However, the discussion of the Identifier field in Section 3 of However, the discussion of the Identifier field in Section 3 of
[RFC2865] says: [RFC2865] says:
skipping to change at page 7, line 46 skipping to change at page 9, line 12
Challenge, or Access-Reject) that they send in response to Access- Challenge, or Access-Reject) that they send in response to Access-
Request packets. If a server receives a valid duplicate Access- Request packets. If a server receives a valid duplicate Access-
Request for which is already has sent a Response, it MUST resend its Request for which is already has sent a Response, it MUST resend its
original Response without reprocessing the request. The server MUST original Response without reprocessing the request. The server MUST
silently discard any duplicate Access-Requests for which a Response silently discard any duplicate Access-Requests for which a Response
has not 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 a valid
Request packet that matches a cached Access-Request packet in source Access-Request packet that matches a cached Access-Request packet in
address, source port, RADIUS Identifier, and receiving socket, but source address, source port, RADIUS Identifier, and receiving socket,
where the Request Authenticator field is different from the one in but where the Request Authenticator field is different from the one
the cached packet. in the cached packet. If the request contains a Message-
Authenticator attribute, the request MUST be processed as described
in [RFC3580] Section 3.2. Packets with invalid Message-
Authenticators MUST NOT affect the cache in any way.
However, Access-Request packets not containing a Message-
Authenticator attribute always affect the cache, even though they may
be trivially forged. To avoid this issue, server implementations may
be configured to require the presence of a Message-Authenticator
attribute in Access-Request packets. Requests not containing a
Message-Authenticator attribute MAY then be silently discarded.
Client implementations SHOULD include a Message-Authenticator
attribute in every Access-Request, to further help mitigate this
issue.
When sending requests, RADIUS clients MUST NOT re-use Identifiers for
a source IP address and source UDP port until either a valid response
has been received, or the request has timed out. Clients SHOULD
allocate Identifiers via a least-recently-used (LRU) method for a
particular source IP address and source UDP port
RADIUS clients do not have to perform duplicate detection. When a
client sends a request, it processes the first response that has a
valid Response Authenticator as defined in [RFC2865] Section 3. Any
later responses MUST be silently discarded.
2.2.3. Server Response to Overload 2.2.3. Server Response to Overload
Some RADIUS server implementations are not robust in response to Some RADIUS server implementations are not robust in response to
overload, dropping packets with even probability across multiple overload, dropping packets with even probability across multiple
sessions. In an overload situation, this results in a high failure sessions. In an overload situation, this results in a high failure
rate for multi-round authentication protocols such as EAP [RFC3579]. rate for multi-round authentication protocols such as EAP [RFC3579].
Typically, users will continually retry in an attempt to gain access, Typically, users will continually retry in an attempt to gain access,
increasing the load even further. increasing the load even further.
skipping to change at page 13, line 27 skipping to change at page 15, line 13
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.
As there may be interoperability issues with the above suggestion,
client implementations SHOULD make the suggested behavior
configurable. A configuration flag such as "treat unknown attributes
as reject" can be exposed to the system administrator. If the flag
is set to true, then Access-Accepts containing unknown attributes are
treated as Access-Rejects. If the flag is set to false, then unknown
attributes in Access-Accepts are be silently ignored. The default
value for the flag SHOULD be set to true.
On receiving a packet including an attribute of unknown type, RADIUS On receiving a packet including an attribute of unknown type, RADIUS
authentication server implementations SHOULD ignore such attributes. authentication server implementations SHOULD ignore such attributes.
However, RADIUS accounting server implementations typically do not However, RADIUS accounting server implementations typically do not
need to understand attributes in order to write them to stable need to understand attributes in order to write them to stable
storage or pass them to the billing engine. Therefore, accounting 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
skipping to change at page 20, line 32 skipping to change at page 22, line 27
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 The contents of the State attribute are available to both the RADIUS
client and observers of the RADIUS protocol. RADIUS server client and observers of the RADIUS protocol. RADIUS server
implementations should ensure that the state attribute does not implementations should ensure that the state attribute does not
disclose sensitive information to a RADIUS client or third parties disclose sensitive information to a RADIUS client or third parties
observing the RADIUS protocol. observing the RADIUS protocol.
The cache mechanism described in Section 2.2.2 is vulnerable to
attacks when Access-Request packets do not contain a Message-
Authenticator attribute. If the server accepts requests without a
Message-Authenticator, then RADIUS packets can be trivially forged by
an attacker. Cache entries can then be forcibly expired, negating
the utility of the cache. This attack can be mitigated by following
the suggestions in [RFC3579] Section 4, or by requiring the presence
of Message-Authenticator, as described in Section 2.2.2.
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 a wide variety of authentication, authorization, and accounting in a wide variety of
networks, applications using these specifications are vulnerable to networks, applications using these specifications are vulnerable to
all of the threats that are present in other RADIUS applications. all of the threats that are present in other RADIUS applications.
For a discussion of these threats, see [RFC2865], [RFC2607], For a discussion of these threats, see [RFC2865], [RFC2607],
[RFC3162], [RFC3579], and [RFC3580]. [RFC3162], [RFC3579], and [RFC3580].
5. References 5. References
5.1. Normative references 5.1. Normative references
skipping to change at page 21, line 27 skipping to change at page 23, line 31
2618, June 1999. 2618, June 1999.
[RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
[RFC2869] Rigney, C., Willats, W. and P. Calhoun, "RADIUS Extensions", [RFC2869] Rigney, C., Willats, W. and P. Calhoun, "RADIUS Extensions",
RFC 2869, June 2000. RFC 2869, June 2000.
[RFC3162] Aboba, B., Zorn, G. and D. Mitton, "RADIUS and IPv6", RFC [RFC3162] Aboba, B., Zorn, G. and D. Mitton, "RADIUS and IPv6", RFC
3162, August 2001. 3162, August 2001.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M.
Carney, "Dynamic Host Configuration Protocol for IPv6
(DHCPv6)", RFC 3315, July 2003.
[RFC3579] Aboba, B. and P. Calhoun, "RADIUS Support for Extensible [RFC3579] Aboba, B. and P. Calhoun, "RADIUS Support for Extensible
Authentication Protocol (EAP)", RFC 3579, September 2003. Authentication Protocol (EAP)", RFC 3579, September 2003.
[RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G. and J. Roese, [RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G. and J. Roese,
"IEEE 802.1X Remote Authentication Dial In User Service "IEEE 802.1X Remote Authentication Dial In User Service
(RADIUS) Usage Guidelines", RFC 3580, September 2003. (RADIUS) Usage Guidelines", RFC 3580, September 2003.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J. and H. [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J. and H.
Levkowetz, "Extensible Authentication Protocol (EAP)", RFC Levkowetz, "Extensible Authentication Protocol (EAP)", RFC
3748, June 2004. 3748, June 2004.
skipping to change at page 22, line 9 skipping to change at page 24, line 19
4669, August 2006. 4669, August 2006.
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.
The text discussing retransmissions in Section 2.2.1 is taken with
minor edits from Section 9 of draft-ietf-pana-pana-17.txt
Alan DeKok wishes to acknowledge the support of Quiconnect Inc.,
where he was employed during much of the work on this document.
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.
Authors' Addresses Authors' Addresses
David B. Nelson David B. Nelson
Elbrys Networks, Inc. Elbrys Networks, Inc.
75 Rochester Ave., Unit 3 75 Rochester Ave., Unit 3
Portsmouth N.H. 03801 USA Portsmouth N.H. 03801 USA
 End of changes. 10 change blocks. 
45 lines changed or deleted 164 lines changed or added

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