1 / 8

RADEXT WG RADIUS Attribute Guidelines

Provides guidelines for designing RADIUS attributes, considering data types and backward compatibility across attribute classes. Includes milestones, issues, and recommendations for attribute design.

davidbwalker
Download Presentation

RADEXT WG RADIUS Attribute Guidelines

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. J F M A M J J A S O N D 2005 J F M A M J J A S O N D 2006 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 completionOriginally Dec ‘04 Guide-02 ExtAttr-00 Guide-01 Guide-03 Guide-00 DraftRevisions CharteredMilestones 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 encryptionDon’t preclude future mechanisms (a la crypto agility); address current practice in Security Considerations • IETF-65: Independent SDO workEnable SDOs to work independently, so IETF is not blocking • IETF-65: Structured data categorizationCategorize structured data based on which entity consumes/parses the elements; consistent, explicit structure required only when this is a RADIUS entity. Current version diff: http://employees.org/~gdweber/02-03-diff.html 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 2.2.1 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

More Related