draft-ietf-radext-design-17.txt   draft-ietf-radext-design-18.txt 
Network Working Group Alan DeKok (ed.) Network Working Group Alan DeKok (ed.)
INTERNET-DRAFT FreeRADIUS INTERNET-DRAFT FreeRADIUS
Category: Best Current Practice G. Weber Category: Best Current Practice G. Weber
<draft-ietf-radext-design-17.txt> Individual Contributor <draft-ietf-radext-design-18.txt> Individual Contributor
Expires: February 26, 2011 Expires: Apri 12, 2011
26 July 2010 12 October 2010
RADIUS Design Guidelines RADIUS Design Guidelines
draft-ietf-radext-design-17 draft-ietf-radext-design-18
Abstract Abstract
This document provides guidelines for the design of attributes used This document provides guidelines for the design of attributes used
by the Remote Authentication Dial In User Service (RADIUS) protocol. by the Remote Authentication Dial In User Service (RADIUS) protocol.
It is expected that these guidelines will prove useful to authors and It is expected that these guidelines will prove useful to authors and
reviewers of future RADIUS attribute specifications, both within the reviewers of future RADIUS attribute specifications, both within the
IETF as well as other Standards Development Organizations (SDOs). IETF as well as other Standards Development Organizations (SDOs).
Status of this Memo Status of this Memo
skipping to change at page 1, line 42 skipping to change at page 1, line 42
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 February 26, 2011. This Internet-Draft will expire on April 12, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info/) in effect on the date of (http://trustee.ietf.org/license-info/) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 13, line 8 skipping to change at page 13, line 8
use of the State Attribute are inherently incompatible with RADIUS as use of the State Attribute are inherently incompatible with RADIUS as
defined in [RFC2865], and MUST be redesigned. See [RFC5080] Section defined in [RFC2865], and MUST be redesigned. See [RFC5080] Section
2.1.1 for additional discussion surrounding the use of the State 2.1.1 for additional discussion surrounding the use of the State
Attribute. Attribute.
As noted in [RFC5080] Section 2.6, the intent of an Access-Reject is As noted in [RFC5080] Section 2.6, the intent of an Access-Reject is
to deny access to the requested service. As a result, RADIUS does to deny access to the requested service. As a result, RADIUS does
not allow the provisioning of services within an Access-Reject or not allow the provisioning of services within an Access-Reject or
Disconnect-Request. Documents which include provisioning of services Disconnect-Request. Documents which include provisioning of services
within an Access-Reject or Disconnect-Request are inherently within an Access-Reject or Disconnect-Request are inherently
incompatible with RADIUS, and SHOULD be redesigned. incompatible with RADIUS, and need to be redesigned.
As noted in [RFC5176] Section 3: As noted in [RFC5176] Section 3:
A Disconnect-Request MUST contain only NAS and session A Disconnect-Request MUST contain only NAS and session
identification attributes. If other attributes are included in a identification attributes. If other attributes are included in a
Disconnect- Request, implementations MUST send a Disconnect-NAK; Disconnect- Request, implementations MUST send a Disconnect-NAK;
an Error-Cause Attribute with value "Unsupported Attribute" MAY be an Error-Cause Attribute with value "Unsupported Attribute" MAY be
included. included.
As a result, documents which include provisioning of services within As a result, documents which include provisioning of services within
a Disconnect-Request are inherently incompatible with RADIUS, and a Disconnect-Request are inherently incompatible with RADIUS, and
SHOULD be redesigned. need to be redesigned.
As noted in [RFC5080] Section 2.1.1, a RADIUS Access-Request may not As noted in [RFC5080] Section 2.1.1, a RADIUS Access-Request may not
contain user authentication attributes or a State Attribute linking contain user authentication attributes or a State Attribute linking
the Access-Request to an earlier user authentication. Such an the Access-Request to an earlier user authentication. Such an
Access-Request, known as an authorization check, provides no Access-Request, known as an authorization check, provides no
assurance that it corresponds to a live user. RADIUS specifications assurance that it corresponds to a live user. RADIUS specifications
defining attributes containing confidential information (such as defining attributes containing confidential information (such as
Tunnel-Password) should be careful to prohibit such attributes from Tunnel-Password) should be careful to prohibit such attributes from
being returned in response to an authorization check. Also, being returned in response to an authorization check. Also,
[RFC5080] Section 2.1.1 notes that authentication mechanisms need to [RFC5080] Section 2.1.1 notes that authentication mechanisms need to
skipping to change at page 30, line 43 skipping to change at page 30, line 43
Attribute designers cannot assume that RADIUS implementations Attribute designers cannot assume that RADIUS implementations
can successfully handle packets larger than 4096 octets. can successfully handle packets larger than 4096 octets.
If a specification could lead to a RADIUS packet larger than If a specification could lead to a RADIUS packet larger than
4096 octets, then the alternatives described in Section 3.3 4096 octets, then the alternatives described in Section 3.3
SHOULD be considered. SHOULD be considered.
* Stateless operation. The RADIUS protocol is stateless, and * Stateless operation. The RADIUS protocol is stateless, and
documents which require stateful protocol behavior without the documents which require stateful protocol behavior without the
use of the State Attribute need to be redesigned. use of the State Attribute need to be redesigned.
* Provisioning of service in an Access-Reject or * Provisioning of service in an Access-Reject.
Disconnect-Request. Such provisioning is not permitted, and Such provisioning is not permitted, and MUST NOT be used. If
MUST NOT be used. If limited access needs to be provided, then limited access needs to be provided, then an Access-Accept with
an Access-Accept with appropriate authorizations can be used appropriate authorizations can be used instead.
instead.
* Provisioning of service in a Disconnect-Request. * Provisioning of service in a Disconnect-Request.
Such provisioning is not permitted, and MUST NOT be used. Such provisioning is not permitted, and MUST NOT be used.
If limited access needs to be provided, then a CoA-Request If limited access needs to be provided, then a CoA-Request
with appropriate authorizations can be used instead. with appropriate authorizations can be used instead.
* Lack of user authentication or authorization restrictions. * Lack of user authentication or authorization restrictions.
In an authorization check, where there is no demonstration of a In an authorization check, where there is no demonstration of a
live user, confidential data cannot be returned. Where there live user, confidential data cannot be returned. Where there
is a link to a previous user authentication, the State attribute is a link to a previous user authentication, the State attribute
 End of changes. 6 change blocks. 
12 lines changed or deleted 11 lines changed or added

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