1. RADEXT WG RADIUS Attribute Guidelines
draft-weber-radius-attr-guidelines-03.txt
July 10, 2006 v1
IETF-66, Montréal

2. RADIUS Attribute Guidelines
WG Charter Item:
“RADIUS design guidelines. This document will provide guidelines for design of RADIUS attributes. It will specifically consider how complex data types may be introduced in a robust manner, maintaining backwards compatibility with existing RADIUS RFCs, across all the classes of attributes: Standard, Vendor-Specific and SDO-Specific. In addition, it will review RADIUS data types and associated backwards compatibility issues.”
Milestone: Oct ’06 completion Originally Dec ‘04
Guide-02
Guide-01
ExtAttr-00
Guide-03
Guide-00
Draft Revisions J F M A S O N D
2005
2006
Chartered Milestones
IESG
Submissions
WG LC1
IETF-66, Montréal
LATE

3. RADIUS Attribute Guidelines
Issues (one from the tracker, three from IETF-65 discussion):
#106: Vendor Specific Values – Closed? RFC 2882-style VSEs SHOULD NOT be used; follow 3575 instead
IETF-65: Per-attribute encryption Don’t preclude future mechanisms (a la crypto agility); address current practice in Security Considerations
IETF-65: Independent SDO work Enable SDOs to work independently, so IETF is not blocking
IETF-65: Structured data categorization Categorize structured data based on which entity consumes/parses the elements; consistent, explicit structure required only when this is a RADIUS entity.
Current version diff:
IETF-66, Montréal

4. RADIUS Attribute Guidelines
Most of the content is not contentious
Need consensus here
IETF-66, Montréal

5. RADIUS Attribute Guidelines
Section 7: new attributes SHOULD comply with the attribute design guidelines given in RFC 2865 unless one or more of the following applies:
The standard attribute space for new attributes has been exhausted.
The proposed maximum attribute length exceeds that available for attributes specified by RFC 2865.
The native data type of the data element is defined for Extended attribute, but not standard RADIUS, e.g. Integer64.
Structured data must be explicitly represented (see next)
IETF-66, Montréal

6. RADIUS Attribute Guidelines
Section 7: The guidance for when to use which mechanism to affect the logical grouping of data depends on the intended consumer of the attribute values:
Humans: consume attributes intended to aid in troubleshooting and operational problem determination.
Billing: accounting data are typically consumed by a business mediation layer in preparation for billing systems.
Non-RADIUS authorization applications: these entities include policy servers, EAP servers, and other consumers of data which are typically opaque to RADIUS servers and proxies.
RADIUS servers and proxies: parse and operate on individual elements within RADIUS messages.
Attributes in the 4th category SHOULD explicitly represent their values using the format defined by the Extended Attribute draft.
IETF-66, Montréal

7. RADIUS Attribute Guidelines
Further recommendations:
The Vendor-Specific Enumeration (VSE) encoding mechanism as proposed by Section of RFC 2882 SHOULD NOT be used. Instead, vendors should comply with the recommendations of RFC 3575.
The message lengths specified by RADIUS standards MUST NOT be exceeded.
Variable attribute content SHOULD NOT be specified. Separate attributes SHOULD be defined instead.
SDOs are RECOMMENDED to design attributes using the guidelines in this document ‘as if ’ they were destined for the standard attribute space, but of course, may continue to implement new attributes in their own attributes spaces.
IETF-66, Montréal

8. RADIUS Attribute Guidelines
Discussion
IETF-66, Montréal