Design Guidelines Thursday July 26, 2007 Bernard Aboba IETF 69 Chicago, IL

Where We Are Design guidelines is a key deliverable on which other documents depend. New document editor: Alan DeKok Principles (from IETF 66): Guidelines document should focus on current data model only, not extensions. Description of current data model needs to provide thorough coverage of existing usage. Existing formats should not be deprecated, since implementations already support it. Guidelines document should articulate key design principles consistent with existing practice.

Document Outline Section 1: Introduction Goal: To provide guidelines for the design of RADIUS attributes both within the IETF as well as within other SDOs. 1.1 Applicability This document applies to attributes used to encode data. RADIUS protocol changes (such as new commands) is out of scope. This document does not provide guidance on changes to the RADIUS operational model. 1.2 Terminology 1.3 Requirements language

Document Outline (cont’d) Section 2: RADIUS Data Model Section 2.1: Standard Space Section Basic Data Types  Text [RFC2865]  String [RFC2865]  IPv4 Address [RFC2865]  32-bit unsigned Integer [RFC2865]  Time [RFC2869]  IPv6 address [RFC3162]  64-bit unsigned integer [RFC2869][RFC3162]  Note: no support for signed integers or unsigned integers of other sizes (e.g. UINT8, 16, 128)

Document Outline (cont’d) Section 2: RADIUS Data Model Section 2.1: Standard Space Section Tagging  One octet tag value, used in RFC 2868  Drawbacks:  Limited number of unique tags (31)  Can’t always tell if the first byte after the length is the tag or the first byte of the untagged value  When integer values are tagged, the value portion is reduced to 3 bytes.  No support for nesting or grouping.

Document Outline (cont’d) Section 2: RADIUS Data Model Section Complex Attributes  Authentication attributes: changes to both client and server would have been required anyway  CHAP-Password: [RFC2865] Section 5.3  Tunnel-Password: [RFC2868] Section 3.5  ARAP-Password: [RFC2869] Section 5.4  ARAP-Features: [RFC2869] Section 5.5  Address Prefixes  Framed-IPv6-Prefix [RFC3162] Section 2.3  Delegated-IPv6-Prefix [RFC4818] Section 3  Issues with Complex Attributes  From server to client: Need to change server dictionary and forms code to support the complex data type.  From client to server: Need to upgrade the RADIUS server policy engine to support sub-element matching

Document Outline (cont’d) Section 2: RADIUS Data Model Section 2.2 Vendor Space Issues with single octet Vendor Type:  SDOs or vendors that need more attributes  SDOs with sub-groups that individually need their own space  Should we recommend an alternative, such as a 16-bit Vendor Type? Problems in translation between RADIUS VSAs and Diameter  What should we do to fix this?  Option 1: Support Type 26 in Diameter? (David Mitton Proposal)  Option 2: Encourage implementations to keep track of and support multiple VSA formats?

Document Outline (cont’d) Section 3: Data Model Issues Standard RADIUS attributes have a more constrained data model than within the vendor space. Translation between the vendor and standard spaces can be difficult. Substantial changes in format can be required Many standard attributes can be required to translate a single VSA with sub-attributes, depleting the standard space. Conclusion: While some enhancements made in the vendor space may migrate to the standard space (e.g. RADIUS Attribute Extension document), divergence of standard and vendor spaces is probably a fact of life.

Document Outline (cont’d) Section 3: Data Model Issues Section 3.1 Vendor Space Theory: [RFC2865] Section 6.2: “Use… should be encouraged for functions specific only to one vendor's implementation of RADIUS, where no interoperability is deemed useful.” Reality: VSAs are now used where interoperability is not only useful, but essential! (e.g. SDO specifications) Reasons  Efficiency:  SDOs want to design their own RADIUS attributes  Few companies willing to fund employees to participate in an SDO and IETF to develop a RADIUS attribute specification  Long tradition of SNMP enterprise MIB development  Attribute scarcity  Not enough standards space attributes to satisfy SDO (or even IETF) needs.

Document Outline (cont’d) Section 3: Data Model Issues Section 3.1 Vendor Space VSA limitations (RFC 2865, Section 5.26):  VSAs cannot affect the operation of the RADIUS protocol (e.g. no new commands, changes to the protocol exchanges, new protocol variants, etc.)  Servers not equipped to interpret VSAs MUST ignore it  Clients which don’t receive desired VSAs SHOULD make an attempt to operate with out How serious are these limitations, really?  Inability to change the RADIUS protocol: not a problem (from the IETF’s point of view)  Handling of VSAs: Does not appear to preclude most VSA uses (e.g. still possible to negotiate use of VSAs between consenting parties). Conclusion: VSAs should not be treated like a “second class citizen”.

Document Outline (cont’d) Section 3: Data Model Issues Section 3.1 Vendor Space Recommendation: IETF should separate review, publication and allocation processes  IETF should encourage publication of SDO RADIUS attribute specifications as RFCs.  IETF should support SDOs in designing their own RADIUS attributes by publishing Design Guidelines and providing review (such as via RADEXT mailing list or AAA Doctors)  RADIUS attribute specifications intended primarily for use within an SDO (or even more than one SDO) should be allocated from the vendor space, not the RADIUS standard space. Section 3.2 Polymorphic Attributes Definition: An attribute whose format is dynamic. Polymorphism is NOT RECOMMENDED.

Document Outline (cont’d) Section 4: Diameter Compatibility Issues with translation of RADIUS VSAs to Diameter. Section 5: IANA Considerations Section 6: Security Considerations The current standard mechanism for “attribute hiding” (e.g. MD5-based stream cipher) is weak. It is NOT RECOMMENDED for use in new specifications. New RADIUS attribute utilizing cryptographic algorithms SHOULD support algorithm negotiation, as well as a mandatory-to-implement algorithm.

Next Steps Posting of a revised Internet Draft Request for WG review Discussion! On existing formats: On compound attributes: Acceptance as a WG work item WG last call

Feedback?