draft-ietf-radext-design-04.txt   draft-ietf-radext-design-05.txt 
Network Working Group G. Weber Network Working Group G. Weber
INTERNET-DRAFT Individual Contributor INTERNET-DRAFT Individual Contributor
Category: Best Current Practice Alan DeKok (ed.) Category: Best Current Practice Alan DeKok (ed.)
<draft-ietf-radext-design-04.txt> FreeRADIUS <draft-ietf-radext-design-05.txt> FreeRADIUS
Expires: January 7, 2009 Expires: February 26, 2009
26 August 2008
RADIUS Design Guidelines RADIUS Design Guidelines
draft-ietf-radext-design-04.txt draft-ietf-radext-design-05.txt
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 18 skipping to change at page 2, line 18
1.1. Applicability ....................................... 4 1.1. Applicability ....................................... 4
1.2. Terminology ......................................... 5 1.2. Terminology ......................................... 5
1.3. Requirements Language ............................... 5 1.3. Requirements Language ............................... 5
2. RADIUS Data Model ........................................ 5 2. RADIUS Data Model ........................................ 5
2.1. Standard Space ...................................... 6 2.1. Standard Space ...................................... 6
2.1.1. Basic Data Types ............................... 6 2.1.1. Basic Data Types ............................... 6
2.1.2. Tagging Mechanism .............................. 7 2.1.2. Tagging Mechanism .............................. 7
2.1.3. Complex Attribute Usage ........................ 8 2.1.3. Complex Attribute Usage ........................ 8
2.1.4. Complex Attributes and Security ................ 10 2.1.4. Complex Attributes and Security ................ 10
2.1.5. Service definitions and RADIUS ................. 11 2.1.5. Service definitions and RADIUS ................. 11
2.2. Vendor Space ........................................ 11 2.2. Extended RADIUS Attributes .......................... 11
2.3. Vendor Space ........................................ 12
3. Data Model Issues ........................................ 13 3. Data Model Issues ........................................ 13
3.1. Vendor Space ........................................ 13 3.1. Vendor Space ........................................ 14
3.1.1. Interoperability Considerations ................ 15 3.1.1. Interoperability Considerations ................ 16
3.1.2. Vendor Allocations ............................. 16 3.1.2. Vendor Allocations ............................. 16
3.1.3. SDO Allocations ................................ 16 3.1.3. SDO Allocations ................................ 17
3.1.4. Publication of specifications .................. 17 3.1.4. Publication of specifications .................. 17
3.2. Polymorphic Attributes .............................. 17 3.2. Polymorphic Attributes .............................. 18
3.3. RADIUS Operational Model ............................ 18 3.3. RADIUS Operational Model ............................ 18
4. IANA Considerations ...................................... 19 4. IANA Considerations ...................................... 21
5. Security Considerations .................................. 19 5. Security Considerations .................................. 21
6. References ............................................... 20 6. References ............................................... 22
6.1. Normative References ................................ 20 6.1. Normative References ................................ 22
6.2. Informative References .............................. 20 6.2. Informative References .............................. 22
Appendix A - Design Guidelines ............................... 23 Appendix A - Design Guidelines ............................... 25
A.1. Types matching the RADIUS data model ................. 23 A.1. Types matching the RADIUS data model ................. 25
A.1.1. Transport of simple data ........................ 23 A.1.1. Transport of simple data ........................ 25
A.1.2. Extended data types ............................. 23 A.1.2. Extended data types ............................. 25
A.1.3. Complex data types .............................. 24 A.1.3. Opaque data types ............................... 26
A.2. Improper Data Types .................................. 24 A.2. Improper Data Types .................................. 26
A.2.1. Simple Data Types ............................... 24 A.2.1. Simple Data Types ............................... 26
A.2.2. Complex Data Types .............................. 25 A.2.2. Complex Data Types .............................. 27
A.3. Vendor-Specific formats .............................. 25 A.3. Vendor-Specific formats .............................. 27
A.4. New functionality in RADIUS. ......................... 26 A.4. Changes to the RADIUS Operational Model .............. 28
A.5. Allocation of attributes ............................. 26 A.5. Allocation of attributes ............................. 29
Appendix B - Complex Attributes .............................. 28 Appendix B - Complex Attributes .............................. 30
B.1. CHAP-Password ........................................ 28 B.1. CHAP-Password ........................................ 30
B.2. CHAP-Challenge ....................................... 28 B.2. CHAP-Challenge ....................................... 30
B.3. Tunnel-Password ...................................... 28 B.3. Tunnel-Password ...................................... 30
B.4. ARAP-Password ........................................ 29 B.4. ARAP-Password ........................................ 31
B.5. ARAP-Features ........................................ 29 B.5. ARAP-Features ........................................ 31
B.6. Connect-Info ......................................... 30 B.6. Connect-Info ......................................... 32
B.7. Framed-IPv6-Prefix ................................... 30 B.7. Framed-IPv6-Prefix ................................... 32
B.8. Egress-VLANID ........................................ 31 B.8. Egress-VLANID ........................................ 33
B.9. Egress-VLAN-Name ..................................... 32 B.9. Egress-VLAN-Name ..................................... 34
Full Copyright Statement ..................................... 35
Full Copyright Statement ..................................... 33
1. Introduction 1. Introduction
This document provides guidelines for the design of RADIUS attributes This document provides guidelines for the design of RADIUS attributes
both within the IETF as well as within other Standards Development both within the IETF as well as within other Standards Development
Organizations (SDOs). By articulating RADIUS design guidelines, it Organizations (SDOs). By articulating RADIUS design guidelines, it
is hoped that this document will encourage the development and is hoped that this document will encourage the development and
publication of high quality RADIUS attribute specifications. publication of high quality RADIUS attribute specifications.
However, the advice in this document will not be helpful unless it is However, the advice in this document will not be helpful unless it is
skipping to change at page 5, line 7 skipping to change at page 5, line 7
* SDOs make their RADIUS attribute specifications publicly * SDOs make their RADIUS attribute specifications publicly
available; available;
* SDOs request review of RADIUS attribute specifications by * SDOs request review of RADIUS attribute specifications by
sending email to the AAA Doctors [DOCTORS] or equivalent mailing sending email to the AAA Doctors [DOCTORS] or equivalent mailing
list; list;
* IETF and SDO RADIUS attribute specifications are reviewed * IETF and SDO RADIUS attribute specifications are reviewed
according to the guidelines proposed in this document; according to the guidelines proposed in this document;
* Reviews of specifications are posted to the RADEXT WG or * Reviews of specifications are posted to the RADEXT WG mailing
equivalent IETF mailing list; list, the AAA Doctors mailing list [DOCTORS] or another IETF
mailing list suggested by the Operations & Management Area
Directors of the IETF.
The advice in this document applies to attributes used to encode The advice in this document applies to attributes used to encode
service-provisioning or authentication data. RADIUS protocol service-provisioning or authentication data. RADIUS protocol
changes, or specification of attributes that can be used to, in changes, or specification of attributes (such as Service-Type) that
effect, provide new RADIUS commands (such as Service-Type) require can be used to, in effect, provide new RADIUS commands require
greater expertise and deeper review, as do changes to the RADIUS greater expertise and deeper review, as do changes to the RADIUS
operational model, as described in Section 3.3 . Such changes should operational model, as described in Section 3.3 . Such changes should
not be undertaken outside the IETF and when handled within the IETF not be undertaken outside the IETF and when handled within the IETF
require "IETF Consensus" for adoption, as noted in [RFC3575] Section require "IETF Consensus" for adoption, as noted in [RFC3575] Section
2.1. 2.1.
1.2. Terminology 1.2. Terminology
This document uses the following terms: This document uses the following terms:
skipping to change at page 11, line 37 skipping to change at page 11, line 43
* authenticate users * authenticate users
* authorize users (i.e., service provisioning or changes to * authorize users (i.e., service provisioning or changes to
provisioning) provisioning)
* account for user activity (i.e., logging of session activity) * account for user activity (i.e., logging of session activity)
New commands (i.e., the Code field in the packet header) are New commands (i.e., the Code field in the packet header) are
allocated only through "IETF Consensus" as noted in [RFC3575] Section allocated only through "IETF Consensus" as noted in [RFC3575] Section
2.1. Specifications also SHOULD NOT use new attributes to modify the 2.1. Specifications also SHOULD NOT use new attributes to modify the
interpretation of existing RADIUS commands. interpretation of existing RADIUS commands.
2.2. Vendor Space 2.2. Extended RADIUS Attributes
The extended RADIUS attribute document [EXTEN] defines a number of
extensions to RADIUS. The standard attribute space is extended by
permitting standard allocations from within a specific subset of the
VSA space; the format of extended attributes is defined; and extended
data types are defined within that format.
New specifications seeking to extend the standard RADIUS data model
SHOULD examine [EXTEN] to see if their needs fit within the extended
RADIUS data model.
2.3. Vendor Space
As noted in [RFC2865] Section 5.26, the VSA format is defined as As noted in [RFC2865] Section 5.26, the VSA format is defined as
follows: follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Vendor-Id | Type | Length | Vendor-Id
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vendor-Id (cont) | String... Vendor-Id (cont) | String...
skipping to change at page 12, line 48 skipping to change at page 13, line 17
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Vendor-Id | Type | Length | Vendor-Id
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vendor-Id (cont) | Vendor type | Vendor-Id (cont) | Vendor type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor length | Attribute-Specific... | Vendor length | Attribute-Specific...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
If additional functionality is required, the format defined in
[EXTEN] SHOULD be used.
Other attribute formats are NOT RECOMMENDED. Examples of NOT Other attribute formats are NOT RECOMMENDED. Examples of NOT
RECOMMENDED formats include Vendor types of more than 16 bits, Vendor RECOMMENDED formats include Vendor types of more than 16 bits, Vendor
lengths of less than 8 bits, Vendor lengths of more than 8 bits, and lengths of less than 8 bits, Vendor lengths of more than 8 bits, and
Vendor-Specific contents that are not in Type-Length-Value format. Vendor-Specific contents that are not in Type-Length-Value format.
In order to be compatible with the above recommendations for In order to be compatible with the above recommendations for
attribute definitions, it is RECOMMENDED that RADIUS servers support attribute definitions, it is RECOMMENDED that RADIUS servers support
attributes using a 16-bit Vendor type field. attributes using a 16-bit Vendor type field.
3. Data Model Issues 3. Data Model Issues
skipping to change at page 16, line 44 skipping to change at page 17, line 16
SDO RADIUS Attribute specifications SHOULD allocate attributes from SDO RADIUS Attribute specifications SHOULD allocate attributes from
the vendor space, rather than requesting an allocation from the the vendor space, rather than requesting an allocation from the
RADIUS standard attribute space, for attributes matching any of the RADIUS standard attribute space, for attributes matching any of the
following criteria: following criteria:
* attributes relying on data types not defined within RADIUS * attributes relying on data types not defined within RADIUS
* attributes intended primarily for use within an SDO * attributes intended primarily for use within an SDO
* attributes intended primarily for use within a group of SDOs. * attributes intended primarily for use within a group of SDOs.
Any new RADIUS attributes or values intended for interoperable use
across a broad spectrum of the Internet Community SHOULD follow the
normal IETF process, and SHOULD result in allocations from the RADIUS
standard space.
The recommendation for SDOs to allocate attributes from a vendor The recommendation for SDOs to allocate attributes from a vendor
space rather than via the IETF process is a recognition that SDOs may space rather than via the IETF process is a recognition that SDOs may
desire to assert change control over their own RADIUS specifications. desire to assert change control over their own RADIUS specifications.
This change control can be obtained by requesting a PEC from the This change control can be obtained by requesting a PEC from the
Internet Assigned Number Authority (IANA), for use as a Vendor-Id Internet Assigned Number Authority (IANA), for use as a Vendor-Id
within a Vendor-Specific attribute. Further allocation of attributes within a Vendor-Specific attribute. Further allocation of attributes
inside of the VSA space defined by that Vendor-Id is subject solely inside of the VSA space defined by that Vendor-Id is subject solely
to the discretion of the SDO. Similarly, the use of data types to the discretion of the SDO. Similarly, the use of data types
(complex or not) within that VSA space is solely under the discretion (complex or not) within that VSA space is solely under the discretion
of the SDO. It is RECOMMENDED that SDOs follow the guidelines of the SDO. It is RECOMMENDED that SDOs follow the guidelines
skipping to change at page 18, line 26 skipping to change at page 18, line 50
Note that changing an attribute's format dynamically is not the same Note that changing an attribute's format dynamically is not the same
thing as using a fixed format and computing the attribute itself thing as using a fixed format and computing the attribute itself
dynamically. RADIUS authentication attributes such as User-Password, dynamically. RADIUS authentication attributes such as User-Password,
EAP-Message, etc. while being computed dynamically, use a fixed EAP-Message, etc. while being computed dynamically, use a fixed
format. format.
3.3. RADIUS Operational Model 3.3. RADIUS Operational Model
The RADIUS operational model includes several assumptions: The RADIUS operational model includes several assumptions:
* The RADIUS protocol is stateless; * Provisioning of services is * The RADIUS protocol is stateless;
not possible within an Access-Reject; * Distinction between * Provisioning of services is not possible within an
authorization checks and user authentication; * Authentication and Access-Reject;
integrity protection of RADIUS packets; * The RADIUS protocol is a * Distinction between authorization checks and user
Request/Response protocol. authentication;
* Authentication and integrity protection of RADIUS packets;
* The RADIUS protocol is a Request/Response protocol.
* Packet length restriction.
While RADIUS server implementations may keep state, the RADIUS While RADIUS server implementations may keep state, the RADIUS
protocol is stateless, although information may be passed from one protocol is stateless, although information may be passed from one
protocol transaction to another via the State Attribute. As a protocol transaction to another via the State Attribute. As a
result, documents which require stateful protocol behavior without result, documents which require stateful protocol behavior without
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 need to be redesigned. See [RFC5080] defined in [RFC2865], and need to be redesigned. See [RFC5080]
Section 2.1.1 for a more in-depth discussion of the use of the State Section 2.1.1 for a more in-depth discussion of the use of the State
Attribute. Attribute.
skipping to change at page 19, line 35 skipping to change at page 20, line 14
Access-Request packet will solicit in response at most a single Access-Request packet will solicit in response at most a single
Access-Accept, Access-Reject or Access-Challenge packet, sent to the Access-Accept, Access-Reject or Access-Challenge packet, sent to the
IP address and port of the RADIUS Client that originated the Access- IP address and port of the RADIUS Client that originated the Access-
Request. Similarly, a single Change-of-Authorization (CoA)-Request Request. Similarly, a single Change-of-Authorization (CoA)-Request
packet [RFC5176] will solicit in response at most a single CoA-ACK or packet [RFC5176] will solicit in response at most a single CoA-ACK or
CoA-NAK packet, sent to the IP address and port of the Dynamic CoA-NAK packet, sent to the IP address and port of the Dynamic
Authorization Client (DAC) that originated the CoA-Request. A single Authorization Client (DAC) that originated the CoA-Request. A single
Disconnect-Request packet will solicit in response at most a single Disconnect-Request packet will solicit in response at most a single
Disconnect-ACK or Disconnect-NAK packet, sent to the IP address and Disconnect-ACK or Disconnect-NAK packet, sent to the IP address and
port of the Dynamic Authorization Client (DAC) that originated the port of the Dynamic Authorization Client (DAC) that originated the
CoA-Request. CoA-Request. Changes to this model are likely to require major
revisions to existing implementations and so this practice is NOT
RECOMMENDED.
The Length field in the RADIUS packet header is defined in [RFC2865]
Section 3. It is noted there that the maximum length of a RADIUS
packet is 4096 octets. As a result, attribute designers SHOULD NOT
assume that a RADIUS implementation can successfully process RADIUS
packets larger than 4096 octets. If a situation is envisaged where
it may be necessary to carry authentication, authorization or
accounting data in a packet larger than 4096 octets, then one of the
following approaches is RECOMMENDED:
1. Utilization of a sequence of packets.
For RADIUS authentication, a sequence of Access-Request/ Access-
Challenge packets would be used. For this to be feasible,
attribute designers need to enable inclusion of attributes that
can consume considerable space within Access-Challenge packets.
To maintain compatibility with existing NASes, either the use of
Access-Challenge packets needs to be permissible (as with
RADIUS/EAP, defined in [RFC3579]), or support for receipt of an
Access-Challenge needs to be indicated by the NAS (as in RADIUS
Location [RADIUSLOC]). Also, the specification needs to clearly
describe how attribute splitting is to be signalled and how
attributes included within the sequence are to be interpreted,
without requiring stateful operation. Unfortunately, previous
specifications have not always exhibited the required foresight.
For example, even though very large filter rules are
conceivable, the NAS-Filter-Rule Attribute defined in [RFC4849]
is not permitted in an Access-Challenge packet, nor is a
mechanism specified to allow a set of NAS-Filter-Rule attributes
to be split across an Access-Request/Access-Challenge sequence.
In the case of RADIUS accounting, transporting large amounts of
data would require a sequence of Accounting-Request packets.
This is a non-trivial change to RADIUS, since RADIUS accounting
clients would need to be modified to split the attribute stream
across multiple Accounting-Requests, and billing servers would
need to be modified to re-assemble and interpret the attribute
stream.
2. Utilization of names rather than values.
Where an attribute relates to a policy that could conceivably be
pre-provisioned on the NAS, then the name of the pre-provisioned
policy can be transmitted in an attribute, rather than the
policy itself, which could be quite large. An example of this
is the Filter-Id Attribute defined in [RFC2865] Section 5.11,
which enables a set of pre-provisioned filter rules to be
referenced by name.
3. Utilization of Packetization Layer Path MTU Discovery
techniques, as specified in [RFC4821]. As a last resort, where
the above techniques cannot be made to work, it may be possible
to apply the techniques described in [RFC4821] to discovery of
of the maximum supported RADIUS packet size on the path between
a RADIUS client and a home server. While such an approach can
avoid the complexity of utilization of a sequence of packets,
dynamic discovery is likely to be time consuming and cannot be
guaranteed to work with existing RADIUS implementations. As a
result, this technique is not generally applicable.
4. IANA Considerations 4. IANA Considerations
This document requires no action by IANA. This document requires no action by IANA.
5. Security Considerations 5. Security Considerations
This specification provides guidelines for the design of RADIUS This specification provides guidelines for the design of RADIUS
attributes used in authentication, authorization and accounting. attributes used in authentication, authorization and accounting.
Threats and security issues for this application are described in Threats and security issues for this application are described in
skipping to change at page 21, line 44 skipping to change at page 23, line 31
[RFC4675] Congdon, P., Sanchez, M. and B. Aboba, "RADIUS Attributes for [RFC4675] Congdon, P., Sanchez, M. and B. Aboba, "RADIUS Attributes for
Virtual LAN and Priority Support", RFC 4675, September 2006. Virtual LAN and Priority Support", RFC 4675, September 2006.
[RFC4679] Mammoliti, V., et al., "DSL Forum Vendor-Specific RADIUS [RFC4679] Mammoliti, V., et al., "DSL Forum Vendor-Specific RADIUS
Attributes", RFC 4679, September 2006. Attributes", RFC 4679, September 2006.
[RFC4818] Salowey, J. and R. Droms, "RADIUS Delegated-IPv6-Prefix [RFC4818] Salowey, J. and R. Droms, "RADIUS Delegated-IPv6-Prefix
Attribute", RFC 4818, April 2007. Attribute", RFC 4818, April 2007.
[RFC4821] Mathis, M. and Heffner, J, "Packetization Layer Path MTU
Discovery", RFC 4821, March 2007.
[RFC4849] Congdon, P. et al, "RADIUS Filter-Rule Attribute", RFC 4849,
April 2007.
[RFC5080] Nelson, D. and DeKok, A, "Common Remote Authentication Dial In [RFC5080] Nelson, D. and DeKok, A, "Common Remote Authentication Dial In
User Service (RADIUS) Implementation Issues and Suggested User Service (RADIUS) Implementation Issues and Suggested
Fixes", RFC 5080, December 2007. Fixes", RFC 5080, December 2007.
[RFC5090] Sterman, B. et al., "RADIUS Extension for Digest [RFC5090] Sterman, B. et al., "RADIUS Extension for Digest
Authentication", RFC 5090, February 2008. Authentication", RFC 5090, February 2008.
[RFC5176] Chiba, M. et al., "Dynamic Authorization Extensions to Remote [RFC5176] Chiba, M. et al., "Dynamic Authorization Extensions to Remote
Authentication Dial In User Service (RADIUS)", RFC 5176, Authentication Dial In User Service (RADIUS)", RFC 5176,
January 2008. January 2008.
[IEEE-802.1Q] [DOCTORS] AAA Doctors Mailing list <aaa-doctors@ops.ietf.org>
IEEE Standards for Local and Metropolitan Area Networks: Draft
Standard for Virtual Bridged Local Area Networks,
P802.1Q-2003, January 2003.
[EXTEN] Li, Y., et al., "Extended Remote Authentication Dial In User [EXTEN] Li, Y., et al., "Extended Remote Authentication Dial In User
Service (RADIUS) Attributes", draft-ietf-radext-extended- Service (RADIUS) Attributes", draft-ietf-radext-extended-
attributes-03.txt (work in progress). attributes-04.txt, (work in progress).
[FIPS] FIPS 140-3 (DRAFT), "Security Requirements for Cryptographic [FIPS] FIPS 140-3 (DRAFT), "Security Requirements for Cryptographic
Modules", http://csrc.nist.gov/publications/fips/fips140-3/ Modules", http://csrc.nist.gov/publications/fips/fips140-3/
[DOCTORS] AAA Doctors Mailing list <aaa-doctors@ops.ietf.org> [IEEE-802.1Q]
IEEE Standards for Local and Metropolitan Area Networks: Draft
Standard for Virtual Bridged Local Area Networks,
P802.1Q-2003, January 2003.
[RADIUSLOC]
Tschofenig, H. (Ed.), "Carrying Location Objects in RADIUS and
Diameter", draft-ietf-geopriv-radius-lo-19.txt, (work in
progress)
Appendix A - Design Guidelines Appendix A - Design Guidelines
The following text provides guidelines for the design of attributes The following text provides guidelines for the design of attributes
used by the RADIUS protocol. Specifications that follow these used by the RADIUS protocol. Specifications that follow these
guidelines are expected to achieve maximum interoperability with guidelines are expected to achieve maximum interoperability with
minimal changes to existing systems. minimal changes to existing systems.
A.1. Types matching the RADIUS data model A.1. Types matching the RADIUS data model
skipping to change at page 23, line 44 skipping to change at page 25, line 44
* Complex data types for authentication and/or security. * Complex data types for authentication and/or security.
These attributes SHOULD be defined only within the RADIUS These attributes SHOULD be defined only within the RADIUS
attribute space, and SHOULD NOT be defined within the VSA space. attribute space, and SHOULD NOT be defined within the VSA space.
Note that the length limitations for VSAs of type String and Text are Note that the length limitations for VSAs of type String and Text are
less than 253 octets, due to the additional overhead of the Vendor- less than 253 octets, due to the additional overhead of the Vendor-
Specific format. Specific format.
A.1.2. Extended data types A.1.2. Extended data types
Where possible, the data types defined above in Section A.1.2 SHOULD Where possible, the data types defined above in Section A.1.1 SHOULD
be used. The extended data types SHOULD be used only where there is be used. The extended data types defined in [EXTEN] SHOULD be used
no clear method of expressing the data using existing types. only where there is no clear method of expressing the data using
existing types.
Does the data fit within the extended RADIUS data model, as outlined Does the data fit within the extended RADIUS data model, as outlined
below? If so, it SHOULD be encapsulated in a [EXTEN] format RADIUS below? If so, it SHOULD be encapsulated in a [EXTEN] format RADIUS
VSA. VSA.
* Attributes grouped into a logical container. * Attributes grouped into a logical container.
This does not include nested groups. This does not include nested groups.
* Attributes requiring the transport of more than 247 octets of * Attributes requiring the transport of more than 247 octets of
Text or String data. This includes the opaque encapsulation Text or String data. This includes the opaque encapsulation
of data structures defined outside of RADIUS. See also Section of data structures defined outside of RADIUS. See also Section
A.1.3, below. A.1.3, below.
A.1.3. Complex data types A.1.3. Opaque data types
Does the attribute encapsulate an existing data structure defined Does the attribute encapsulate an existing data structure defined
outside of the RADIUS specifications? Can the attribute be treated outside of the RADIUS specifications? Can the attribute be treated
as opaque data by RADIUS servers (including proxies?) If both as opaque data by RADIUS servers (including proxies?) If both
questions can be answered affirmatively, a complex structure MAY be questions can be answered affirmatively, a complex structure MAY be
used in a RADIUS specification. used in a RADIUS specification.
The specification of the attribute SHOULD define the encapsulating The specification of the attribute SHOULD define the encapsulating
attribute to be of type String. The specification SHOULD refer to an attribute to be of type String. The specification SHOULD refer to an
external document defining the structure. The specification SHOULD external document defining the structure. The specification SHOULD
skipping to change at page 26, line 16 skipping to change at page 28, line 17
the limit of the 8-bit [RFC2865] Vendor-Specific space. Those SDOs the limit of the 8-bit [RFC2865] Vendor-Specific space. Those SDOs
SHOULD use Vendor types of 16 bits, as described in [EXTEN]. SHOULD use Vendor types of 16 bits, as described in [EXTEN].
However, SDOs SHOULD NOT use Vendor types of 16 bits unless there are However, SDOs SHOULD NOT use Vendor types of 16 bits unless there are
immediate requirements. Future-proofing a specification is immediate requirements. Future-proofing a specification is
insufficient grounds for using 16-bit Vendor types. insufficient grounds for using 16-bit Vendor types.
In general, Vendor-Specific attributes SHOULD follow the [RFC2865] In general, Vendor-Specific attributes SHOULD follow the [RFC2865]
suggested format, or the [EXTEN] format if more functionality or a suggested format, or the [EXTEN] format if more functionality or a
larger attribute space is necessary. larger attribute space is necessary.
A.4. New functionality in RADIUS. A.4. Changes to the RADIUS Operational Model
Does the specification extend RADIUS by adding new functionality, as Does the specification extend change the RADIUS operation model, as
outlined in the list below? If so, it SHOULD NOT use RADIUS. outlined in the list below? If so, then another method of achieving
Another method of achieving the design objectives SHOULD be used. the design objectives SHOULD be used. Potential problem areas
include:
* Defining new commands in RADIUS using attributes. * Defining new commands in RADIUS using attributes.
The addition of new commands to RADIUS MUST be handled via
allocation of a new Code, and not by the use of an attribute.
This restriction includes new commands created by overloading This restriction includes new commands created by overloading
the Service-Type attribute to define new values that modify the Service-Type attribute to define new values that modify
the functionality of Access-Request packets. the functionality of Access-Request packets.
* Using RADIUS as a transport protocol for non-AAA data. * Using RADIUS as a transport protocol for data unrelated to
This restriction is partially a subset of the previous one. authentication, authorization, or accounting. Using RADIUS to
Note that using RADIUS to transport authentication methods transport authentication methods such as EAP is explicitly
(e.g., EAP) is explicitly permitted, even if those methods permitted, even if those methods require the transport of
require the transport of relatively large amounts of data. relatively large amounts of data. Transport of opaque data
* Extending the RADIUS packet length limitation past 4096 octets. relating to AAA is also permitted, as discussed above in
A multi-packet sequence of Access-Request / Access-Challenge Section 2.1.3. However, if the specification does not relate
SHOULD be used instead. If that is not possible, then a method to AAA, then RADIUS SHOULD NOT be used.
other than RADIUS SHOULD be used to transport the data. * Assuming support for packet lengths greater than 4096 octets.
Attribute designers cannot assume that RADIUS implementations
can successfully handle packets larger than 4096 octets.
If a specification could lead to a RADIUS packet larger than
4096 octets, then the alternatives described in Section 3.3
SHOULD be considered.
* Stateless operation. The RADIUS protocol is stateless, and
documents which require stateful protocol behavior without the
use of the State Attribute need to be redesigned.
* Provisioning of service in an Access-Reject. Such provisioning
is not permitted, and MUST NOT be used. If limited access needs
to be provided, then an Access-Accept with appropriate
authorizations can be used instead.
* Lack of user authentication or authorization restrictions.
In an authorization check, where there is no demonstration of a
live user, confidential data cannot be returned. Where there
is a link to a previous user authentication, the State attribute
needs to be present.
* Lack of per-packet integrity and authentication.
It is expected that documents will support per-packet
integrity and authentication.
* Modification of RADIUS packet sequences.
In RADIUS, each request is encapsulated in it's own packet, and
elicits a single response that is sent to the requester. Since
changes to this paradigm are likely to require major
modifications to RADIUS client and server implementations, they
SHOULD be avoided if possible.
For further details, see Section 3.3.
A.5. Allocation of attributes A.5. Allocation of attributes
Does the attribute have a limited scope of applicability, as outlined Does the attribute have a limited scope of applicability, as outlined
below? If so, then the attributes SHOULD be allocated from the below? If so, then the attributes SHOULD be allocated from the
Vendor-Specific space. Vendor-Specific space.
* attributes intended for a vendor to support their own systems, * attributes intended for a vendor to support their own systems,
and not suitable for general usage and not suitable for general usage
* attributes relying on data types not defined within RADIUS * attributes relying on data types not defined within RADIUS
skipping to change at page 28, line 5 skipping to change at page 29, line 40
* attributes intended primarily for use within a group of SDOs. * attributes intended primarily for use within a group of SDOs.
Note that the points listed above do not relax the recommendations Note that the points listed above do not relax the recommendations
discussed in this document. Instead, they recognize that the RADIUS discussed in this document. Instead, they recognize that the RADIUS
data model has limitations. In certain situations where data model has limitations. In certain situations where
interoperability can be strongly constrained, a data model extended interoperability can be strongly constrained, a data model extended
by the SDO or vendor MAY be used. We recommend, however, that the by the SDO or vendor MAY be used. We recommend, however, that the
RADIUS data model SHOULD be used, even if it is marginally less RADIUS data model SHOULD be used, even if it is marginally less
efficient than alternatives. efficient than alternatives.
When attributes are used primarily within a group of SDOs, and are
not applicable to the wider Internet community, we expect that one
SDO will be responsible for allocation from their own private space.
Appendix B - Complex Attributes Appendix B - Complex Attributes
This section summarizes RADIUS attributes with complex data types This section summarizes RADIUS attributes with complex data types
that are defined in existing RFCs. that are defined in existing RFCs.
B.1. CHAP-Password B.1. CHAP-Password
[RFC2865] Section 5.3 defines the CHAP-Password Attribute which is [RFC2865] Section 5.3 defines the CHAP-Password Attribute which is
sent from the RADIUS client to the RADIUS server in an Access- sent from the RADIUS client to the RADIUS server in an Access-
Request. The the data type of the CHAP Identifier is not given, only Request. The the data type of the CHAP Identifier is not given, only
 End of changes. 26 change blocks. 
71 lines changed or deleted 203 lines changed or added

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