draft-ietf-radext-fixes-07.txt   draft-ietf-radext-fixes-08.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-07.txt> <draft-ietf-radext-fixes-08.txt>
Expires: March 1, 2007 Expires: March 13, 2008
4 September 2007 13 September 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 1, line 35 skipping to change at page 1, line 35
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 10, 2007. This Internet-Draft will expire on March 13, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
This document describes common issues seen in RADIUS implementations This document describes common issues seen in RADIUS implementations
and suggests some fixes. Where applicable, ambiguities and errors in and suggests some fixes. Where applicable, ambiguities and errors in
previous RADIUS specifications are clarified. previous RADIUS specifications are clarified.
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 ..................... 6 2.1.2. Request-ID Supplementation ..................... 6
2.2. Overload Conditions ................................. 7 2.2. Overload Conditions ................................. 7
2.2.1. Retransmission Behavior ........................ 7 2.2.1. Retransmission Behavior ........................ 7
2.2.2. Duplicate detection and orderly delivery. ...... 9 2.2.2. Duplicate detection and orderly delivery. ...... 10
2.2.3. Server Response to Overload .................... 11 2.2.3. Server Response to Overload .................... 11
2.3. Accounting Issues ................................... 12 2.3. Accounting Issues ................................... 12
2.3.1. Attributes allowed in an Interim Update ........ 12 2.3.1. Attributes allowed in an Interim Update ........ 12
2.3.2. Acct-Session-Id and Acct-Multi-Session-Id ...... 12 2.3.2. Acct-Session-Id and Acct-Multi-Session-Id ...... 12
2.3.3. Request Authenticator .......................... 13 2.3.3. Request Authenticator .......................... 13
2.3.4. Interim-Accounting-Interval .................... 13 2.3.4. Interim-Accounting-Interval .................... 13
2.3.5. Counter values in the RADIUS Management Informat 14 2.3.5. Counter values in the RADIUS Management Informat 14
2.4. Multiple Filter-ID Attributes ....................... 15 2.4. Multiple Filter-ID Attributes ....................... 15
2.5. Mandatory and Optional Attributes ................... 16 2.5. Mandatory and Optional Attributes ................... 16
2.6. Interpretation of Access-Reject ..................... 17 2.6. Interpretation of Access-Reject ..................... 17
2.6.1. Improper Use of Access-Reject .................. 17 2.6.1. Improper Use of Access-Reject .................. 17
2.6.2. Service Request Denial ......................... 19 2.6.2. Service Request Denial ......................... 19
2.7. Addressing .......................................... 19 2.7. Addressing .......................................... 20
2.7.1. Link-Local Addresses ........................... 20 2.7.1. Link-Local Addresses ........................... 20
2.7.2. Multiple Addresses ............................. 20 2.7.2. Multiple Addresses ............................. 20
2.8. Idle-Timeout ........................................ 20 2.8. Idle-Timeout ........................................ 21
2.9. Unknown Identity .................................... 21 2.9. Unknown Identity .................................... 21
2.10. Responses after retransmissions .................... 22 2.10. Responses after retransmissions .................... 22
2.11. Framed-IPv6-Prefix ................................. 23 2.11. Framed-IPv6-Prefix ................................. 23
3. IANA Considerations ...................................... 24 3. IANA Considerations ...................................... 24
4. Security Considerations .................................. 24 4. Security Considerations .................................. 24
5. References ............................................... 24 5. References ............................................... 24
5.1. Normative references ................................ 24 5.1. Normative references ................................ 25
5.2. Informative references .............................. 25 5.2. Informative references .............................. 25
Intellectual Property Statement .............................. 26 Intellectual Property Statement .............................. 27
Disclaimer of Validity ....................................... 28 Disclaimer of Validity ....................................... 28
Full Copyright Statement ..................................... 28 Full Copyright Statement ..................................... 28
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.
skipping to change at page 5, line 30 skipping to change at page 5, line 30
The only permissible values for a State attribute are values provided The only permissible values for a State attribute are values provided
in an Access-Accept, Access-Challenge, CoA-Request or Disconnect- in an Access-Accept, Access-Challenge, CoA-Request or Disconnect-
Request packet. A RADIUS client MUST use only those values for the Request packet. A RADIUS client MUST use only those values for the
State attribute that it has previously received from a server. An State attribute that it has previously received from a server. An
Access-Request sent as a result of a new or restarted authentication Access-Request sent as a result of a new or restarted authentication
run MUST NOT include the State attribute, even if a State attribute run MUST NOT include the State attribute, even if a State attribute
has previously been received in an Access-Challenge for the same user has previously been received in an Access-Challenge for the same user
and port. and port.
In contrast, Access-Requests which are intended to perform
authorization checks MUST contain a State attribute in order to tie
the authorization check to a previous authentication session. This
last requirement often means that an Access-Accept needs to contain a
State attribute, which is then used in a later Access-Request that
performs authorization checks.
Access-Request packets that contain a Service-Type attribute with Access-Request packets that contain a Service-Type attribute with
value Authorize Only (17) MUST contain a State attribute. Access- value Authorize Only (17) MUST contain a State attribute. Access-
Request packets that contain a Service-Type attribute with value Call Request packets that contain a Service-Type attribute with value Call
Check (10) SHOULD NOT contain a State attribute. Any other Access- Check (10) SHOULD NOT contain a State attribute. Any other Access-
Request packet that performs authorization checks MUST contain a Request packet that performs authorization checks MUST contain a
State attribute. State attribute. This last requirement often means that an Access-
Accept needs to contain a State attribute, which can then be used in
a later Access-Request that performs authorization checks.
The standard use case for Call-Check is pre-screening authentication The standard use case for Call-Check is pre-screening authentication
based solely on the end-point identifier information, such as phone based solely on the end-point identifier information, such as phone
number or MAC address in Calling-Station-ID and optionally Called- number or MAC address in Calling-Station-ID and optionally Called-
Station-ID. In that use case there is no source of the State Station-ID. In this use case, the NAS has no way to obtain a State
attribute in the NAS. Other, non-standard, uses of Call-Check may Attribute suitable for inclusion in an Access-Request. Other, non-
require or permit the use of a State Attribute, but are beyond the standard, uses of Call-Check may require or permit the use of a State
scope of this document. Attribute, but are beyond the scope of this document.
Implementing Call Check functionality via requests where the User- In an Access-Request with a Service-Type Attribute with value "Call
Name and User-Password contain the same information (e.g. MAC Check", it is NOT RECOMMENDED for the User-Name and User-Password
address) is NOT RECOMMENDED. This practice gives an attacker both attributes to contain the same values (e.g. a MAC address).
Implementing MAC address checking without using a Service-Type of
Call Check is NOT RECOMMENDED. This practice gives an attacker both
the clear-text and cipher-text of the User-Password field, which the clear-text and cipher-text of the User-Password field, which
permits many additional attacks on the security of the RADIUS permits many attacks on the security of the RADIUS protocol. For
protocol. For example, if the Request Authenticator does not satisfy example, if the Request Authenticator does not satisfy the [RFC2865]
the [RFC2865] requirements on global and temporal uniqueness, the requirements on global and temporal uniqueness, the practice
practice described above may lead to the compromise of the User- described above may lead to the compromise of the User-Password
Password attribute in other Access-Requests for unrelated users. attribute in other Access-Requests for unrelated users. Access to
Access to the cipher-text also greatly simplifies offline dictionary the cipher-text enabes offline dictionary attacks, potentially
attacks, potentially exposing the shared secret, and compromising the exposing the shared secret, and compromising the entire RADIUS
entire RADIUS protocol. protocol.
Any Access-Request packet that performs authorization checks, Any Access-Request packet that performs authorization checks,
including Call Check, MUST contain a Message-Authenticator attribute. including Call Check, SHOULD contain a Message-Authenticator
Any response to an Access-Request performing an authorization check attribute. Any response to an Access-Request performing an
MUST NOT contain confidential information about any user (such as authorization check MUST NOT contain confidential information about
Tunnel-Password), unless that Access-Request contains a State any user (such as Tunnel-Password), unless that Access-Request
attribute. The use of State here permits the authorization check to contains a State attribute. The use of State here permits the
be tied to an earlier user authentication. In that case, the server authorization check to be tied to an earlier user authentication. In
MAY respond to the NAS with confidential information about that user. that case, the server MAY respond to the NAS with confidential
The server MUST NOT respond to that authorization check with information about that user. The server MUST NOT respond to that
confidential information about any other user. authorization check with confidential information about any other
user.
For an Access-Request packet performing an authorization check that
does not contain a State attribute, the server MUST response with an
Access-Reject.
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 22, line 45 skipping to change at page 22, line 52
undesirable side effects. Since RADIUS does not have a clear undesirable side effects. Since RADIUS does not have a clear
definition of a "session", it is perfectly valid for a RADIUS server definition of a "session", it is perfectly valid for a RADIUS server
to treat a retransmission as a new session request, and to reject it to treat a retransmission as a new session request, and to reject it
due to (say) multiple simultaneous login restrictions are enforced. due to (say) multiple simultaneous login restrictions are enforced.
In that situation, the NAS may receive a belated Access-Accept for In that situation, the NAS may receive a belated Access-Accept for
the first request, and an Access-Reject for the retransmitted the first request, and an Access-Reject for the retransmitted
request, both of which apply to the same "session". request, both of which apply to the same "session".
We suggest that the contents of Access-Request packets SHOULD NOT be We suggest that the contents of Access-Request packets SHOULD NOT be
changed during retransmissions. If they must be changed due to the changed during retransmissions. If they must be changed due to the
inclusion of an Event-Timestampt attribute, for example, then inclusion of an Event-Timestamp attribute, for example, then
responses to earlier transmissions MUST be silently discarded. Any responses to earlier transmissions MUST be silently discarded. Any
response to the current request MUST be treated as the definitive response to the current request MUST be treated as the definitive
response, even if as noted above, it disagrees with earlier response, even if as noted above, it disagrees with earlier
responses. responses.
This problem can be made worse by implementations that use a fixed This problem can be made worse by implementations that use a fixed
retransmission timeout (30 seconds is common). We reiterate the retransmission timeout (30 seconds is common). We reiterate the
suggestions above in Section 2.1 about using congestive backoff. In suggestions above in Section 2.1 about using congestive backoff. In
that case, responses to earlier transmissions MAY be used as data that case, responses to earlier transmissions MAY be used as data
points for congestive backoff, even if their contents are discarded. points for congestive backoff, even if their contents are discarded.
skipping to change at page 24, line 8 skipping to change at page 24, 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 Time To Live (TTL) field of IP headers. In that decrementing the Hop Limit field of IP headers. In that case, it
case, it should be delegated a prefix by the NAS via the Delegated- should be delegated a prefix by the NAS via the Delegated-IPv6-Prefix
IPv6-Prefix attribute. [RFC4818]. If the CPE is not decrementing attribute. [RFC4818]. If the CPE is not decrementing Hop Limit, it
TTL, it does not require a delegated prefix. 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 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
 End of changes. 15 change blocks. 
46 lines changed or deleted 48 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/