Network Working Group G. Weber Internet-Draft Cisco Systems Expires: April 27, 2006 October 24, 2005 Design Guidelines for RADIUS Attributes draft-weber-radius-attr-guidelines-01.txt Status of this Memo By submitting this Internet-Draft, each author represents that any 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 aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 27, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This memo explores various issues related to the data model used by the Remote Authentication Dial In User Service (RADIUS) protocol. Recommendations are made to facilitate internal alignment and uniformity. Attribute design guidelines will eventually be proposed based on the recommendations. Weber Expires April 27, 2006 [Page 1] Internet-Draft RADIUS Attribute Guidelines October 2005 Table of Contents 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Divergent Data Models . . . . . . . . . . . . . . . . . . 4 3.2. Attribute Space Exhaustion . . . . . . . . . . . . . . . . 4 3.3. Diameter Alignment . . . . . . . . . . . . . . . . . . . . 4 4. Current Data Model . . . . . . . . . . . . . . . . . . . . . . 5 4.1. Data Types . . . . . . . . . . . . . . . . . . . . . . . . 5 4.2. General Attribute Format . . . . . . . . . . . . . . . . . 7 4.3. Tagging Mechanism . . . . . . . . . . . . . . . . . . . . 8 4.4. Vendor-Specific Attribute Format . . . . . . . . . . . . . 10 4.5. Value Packing . . . . . . . . . . . . . . . . . . . . . . 10 5. Data Model Features in the Vendor Space . . . . . . . . . . . 11 5.1. Grouping . . . . . . . . . . . . . . . . . . . . . . . . . 11 5.2. Attribute Encryption . . . . . . . . . . . . . . . . . . . 11 5.3. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 12 6. Scope and Solution Characteristics . . . . . . . . . . . . . . 12 6.1. Backwards Compatibility . . . . . . . . . . . . . . . . . 12 6.1.1. Intermediate Nodes . . . . . . . . . . . . . . . . . . 12 6.1.2. Dictionary-based Implementations . . . . . . . . . . . 12 6.1.3. Unaware Endpoints . . . . . . . . . . . . . . . . . . 12 6.2. Existing Vendor-Specific Attribute Usage . . . . . . . . . 13 6.3. Transport Impact . . . . . . . . . . . . . . . . . . . . . 13 6.4. Non-AAA Applications . . . . . . . . . . . . . . . . . . . 13 6.5. Diameter Compatibility . . . . . . . . . . . . . . . . . . 13 7. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 13 7.1. Extended-Attribute . . . . . . . . . . . . . . . . . . . . 13 8. Diameter Considerations . . . . . . . . . . . . . . . . . . . 14 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 10. Security Considerations . . . . . . . . . . . . . . . . . . . 15 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 11.1. Normative References . . . . . . . . . . . . . . . . . . . 15 11.2. Informative References . . . . . . . . . . . . . . . . . . 15 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 16 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17 Intellectual Property and Copyright Statements . . . . . . . . . . 18 Weber Expires April 27, 2006 [Page 2] Internet-Draft RADIUS Attribute Guidelines October 2005 1. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 2. Introduction The Remote Authentication Dial In User Service (RADIUS) protocol [RFC2865] uses an attribute paradigm as the basis for representing authentication, authorization and accounting data. RADIUS messages exchanged between client and server contain lists of similarly formatted attributes. Unlike SNMP [RFC1157] [RFC1155], RADIUS does not use a formal data definition language to describe its attributes or attribute formats. A handful of basic data types are provided, and a data type is associated with a particular attribute when that attribute is defined. Two distinct attribute spaces are defined: the standard space, and a vendor specific space. Attributes in the standard space generally are composed of a type, length, value (TLV) triplet. The vendor specific space is encapsulated within a single attribute type. The format of this space is defined by individual vendors, but the same TLV encoding used by the standard space is recommended. The similarity between attribute formats has enabled implementations to leverage a common parsing functionality, though attributes in the vendor specific space have begun to diverge in some cases from use of the common formatting. In addition, many new attributes in the vendor specific space are actually not intended to be vendor specific at all, such as those attributes defined by Standards Development Organizations (SDOs) outside the IETF, e.g. the 3rd Generation Partnership Project (3GPP). Perhaps a contributing factor in the SDOs' decision to use the vendor specific space, is that the standard attribute space is limited to approximately 250 unique attributes; of these, only about half remain available for allocation. In the vendor specific space, the number of attributes available is a function of the format of the attribute (the size of the type field). This document analyzes some of the issues around rationalizing the RADIUS attribute data model and recommends extending the model to allow more alignment between the standard and vendor attribute spaces. The proposed extension is in the form of a new RADIUS attribute with a more fully featured format to accommodate some of the features that have evolved over time in the vendor space Weber Expires April 27, 2006 [Page 3] Internet-Draft RADIUS Attribute Guidelines October 2005 including attribute grouping and an expanded attribute number space. 3. Motivation Since the closure of the IETF's RADIUS Working Group, the popularity and prevalence of RADIUS usage has continued to grow and is now commonly applied to various access media in addition to dial. The large number of vendors and SDOs developing and providing RADIUS- based solutions has lead to some technical splintering in the approach to RADIUS attribute design. 3.1. Divergent Data Models In particular, the data model covering the standard RADIUS attributes is much more constrained than the data model for vendor space attributes. Vendors have evolved the data model they use to support new functions like attribute grouping and attribute fragmentation. Multiple methods have been developed to achieve these desirable features. There is no motivation for vendors or SDOs to move generally useful attributes from the vendor space to the more stringent standard space, so the data models continue to diverge. One of RADIUS's design parameters was that new attributes should be able to be added without modifying the client or server core protocol parsing code. As attributes continue to take on new formats, this advantage will fade. In addition, more attribute-specific parsing means more complex software to develop and maintain. 3.2. Attribute Space Exhaustion Another impending problem is that eventually the standard attribute space may become depleted over time. The type code field for standard attribute is one octet, so a maximum of 255 attributes may be defined; approximately half of which are unallocated. 3.3. Diameter Alignment Section 9 of [RFC4005] describes RADIUS/Diameter interactions. While Diameter has much more functionality than RADIUS [RFC3588], it may facilitate interoperation to align the RADIUS and Diameter data models at least at some basic level. Weber Expires April 27, 2006 [Page 4] Internet-Draft RADIUS Attribute Guidelines October 2005 4. Current Data Model The following subsections describe how RADIUS data are typed and formatted according to the current specification set. Some exceptions to the rules are identified. 4.1. Data Types RADIUS attributes are typed by reference. In other words, the data type of a particular attribute is fixed when that attribute is defined. The data type information is not transported on the wire. The reference to the attribute type allows RADIUS entities to know the data type because typically, each RADIUS entity has access to a dictionary or some other mechanism describing all defined attributes. The RADIUS specifications define these data types: text 1-253 octets containing UTF-8 encoded 10646 [RFC2279] characters. Text of length zero (0) MUST NOT be sent; omit the entire attribute instead. string 1-253 octets containing binary data (values 0 through 255 decimal, inclusive). Strings of length zero (0) MUST NOT be sent; omit the entire attribute instead. address 32 bit value, most significant octet first. integer 32 bit unsigned value, most significant octet first. time 32 bit unsigned value, most significant octet first -- seconds since 00:00:00 UTC, January 1, 1970. The standard Attributes do not use this data type but it is presented here for possible use in future attributes The current specifications do not always adhere to specifying a data type from this set. For example, below, in the attribute definition for Framed-Interface-Id (from [RFC3162]), the data type is not given: Weber Expires April 27, 2006 [Page 5] Internet-Draft RADIUS Attribute Guidelines October 2005 A summary of the Framed-Interface-Id Attribute format is shown below. The fields are transmitted from left to right. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Interface-Id +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Interface-Id +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Interface-Id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 96 for Framed-Interface-Id Length 10 Interface-Id The Interface-Id field is 8 octets. And in the definition of CHAP-Password (from [RFC2865]), what is the data type of CHAP Ident? Weber Expires April 27, 2006 [Page 6] Internet-Draft RADIUS Attribute Guidelines October 2005 A summary of the CHAP-Password Attribute format is shown below. The fields are transmitted from left to right. 0 1 2 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- | Type | Length | CHAP Ident | String ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Type 3 for CHAP-Password. Length 19 CHAP Ident This field is one octet, and contains the CHAP Identifier from the user's CHAP Response. String The String field is 16 octets, and contains the CHAP Response from the user. As you can see, in some cases the data are described textually. This is possible because the data types are not sent inside the attributes. They are largely a matter for endpoint interpretation. In fact, an implementation could define additional data types, say for example IPv6 address, and use these data types today by matching them to the attribute's textual description. In fact, some RADIUS implementations treat tagged attributes (see section 4.3) as additional data types. 4.2. General Attribute Format The attribute TLV encoding is summarized in [RFC2865] as: 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- | Type | Length | Value ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Weber Expires April 27, 2006 [Page 7] Internet-Draft RADIUS Attribute Guidelines October 2005 However, some standard attributes do not follow this format. The definition of CHAP-Password above demonstrates this inconsistency. Similarly, the ARAP-Password attribute definition (from [RFC2869]) shows multiple Value fields: A summary of the ARAP-Password attribute format is shown below. The fields are transmitted from left to right. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Value1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value4 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 70 for ARAP-Password. Length 18 Value This attribute contains a 16 octet string, used to carry the dial-in user's response to the NAS challenge and the client's own challenge to the NAS. The high-order octets (Value1 and Value2) contain the dial-in user's challenge to the NAS (2 32-bit numbers, 8 octets) and the low-order octets (Value3 and Value4) contain the dial-in user's response to the NAS challenge (2 32-bit numbers, 8 octets). In general, these types of multi-valued attributes may treat the concatenation of all the values as a String data type field. However, separating out these values into different attributes each with its own type and length would enable additional error checking. 4.3. Tagging Mechanism [RFC2868] defines an attribute grouping mechanism based on the use of Weber Expires April 27, 2006 [Page 8] Internet-Draft RADIUS Attribute Guidelines October 2005 a one octect tag value. Tunnel attributes that refer to the same tunnel are grouped together by virtue of using the same tag value. A summary of the Tunnel-Server-Endpoint Attribute format is shown below. The fields are transmitted from left to right. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Tag | String ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 67 for Tunnel-Server-Endpoint. Length >= 3 Tag The Tag field is one octet in length and is intended to provide a means of grouping attributes in the same packet which refer to the same tunnel. If the value of the Tag field is greater than 0x00 and less than or equal to 0x1F, it SHOULD be interpreted as indicating which tunnel (of several alternatives) this attribute pertains. If the Tag field is greater than 0x1F, it SHOULD be interpreted as the first byte of the following String field. String The format of the address represented by the String field depends upon the value of the Tunnel-Medium-Type attribute. If Tunnel-Medium-Type is IPv4 (1), then this string is either the fully qualified domain name (FQDN) of the tunnel client machine, or it is a "dotted-decimal" IP address. Conformant implementations MUST support the dotted-decimal format and SHOULD support the FQDN format for IP addresses. ... This tagging mechanism has some drawbacks. There are a limited number of unique tags (31). The tags are not well suited for use with arbitrary binary data values because it is not always possible to tell if the first byte after the Length is the tag or the first byte of the untagged value (assuming the tag is optional). When integer values are tagged, the value portion is reduced to three bytes meaning only 24-bit numbers can be represented. The tagging mechanism does not offer an ability to create nested Weber Expires April 27, 2006 [Page 9] Internet-Draft RADIUS Attribute Guidelines October 2005 groups of attributes. 4.4. Vendor-Specific Attribute Format [RFC2865] allows each vendor to define its own attribute space under the Vendor-Specific attribute. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Vendor-Id +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Vendor-Id (cont) | String... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- The format of data in the String field of Vendor-Specific attributes is under each vendor's control, but the specification advises that this field SHOULD be encoded as show below. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Vendor-Id +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Vendor-Id (cont) | Vendor type | Vendor length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Attribute-Specific... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Multiple subattributes MAY be encoded within a single Vendor- Specific attribute, although they do not have to be. Allowing multiple subattributes does provide a form of grouping. 4.5. Value Packing Some attributes pack multiple data items into a single attribute value field. Here is the value field description from the Connect- Info attributed defined in [RFC2869] Weber Expires April 27, 2006 [Page 10] Internet-Draft RADIUS Attribute Guidelines October 2005 Text The Text field consists of UTF-8 encoded 10646 [8] characters. The connection speed SHOULD be included at the beginning of the first Connect-Info attribute in the packet. If the transmit and receive connection speeds differ, they may both be included in the first attribute with the transmit speed first (the speed the NAS modem transmits at), a slash (/), the receive speed, then optionally other information. For example, "28800 V42BIS/LAPM" or "52000/31200 V90" Encoding multiple values within a Text attribute reduces the amount of data validation that can be performed when the attribute is first encountered. This particular attribute is used in Access-Request messages. If authorization decisions are based on connection speed information, it would perhaps be better to validate it separately from the remainder of the Text attribute. 5. Data Model Features in the Vendor Space Vendors, of course, are under no obligation to publish their proprietary usages of RADIUS. Through SDOs, however, we can see some of the RADIUS usages that have developed in the vendor space. 5.1. Grouping Various strategies and justifications for organizing attribute data into groups have proven popular. The most common of these is probably the subattribute scheme introduced in the Vendor-Specific format recommendation. Here are some of the reasons given for grouping attributes: o Compactness - As with bit flags or multiply valued attributes, e.g. a list of IP addresses. o Logical Relationship - For attributes which describe multiple aspects of a single entity or which have interdependencies. o Shared Information - As with a group of attributes related to a single timestamp or remote IP address. 5.2. Attribute Encryption TBD Weber Expires April 27, 2006 [Page 11] Internet-Draft RADIUS Attribute Guidelines October 2005 5.3. Fragmentation Several different methods are in use to handle attributes which exceed the 253 octet length limit. Microsoft uses multiple attributes with an embedded sequence number to transfer MS-CHAP-LM- Enc-PW (as described in [RFC2548]). CableLabs PacketCable uses multiple attributes, requiring them to be consecutive but without embedded sequence info (see Section 13.1.5.2 [PKT-SP-EM1.5]) to transfer several large attributes. 6. Scope and Solution Characteristics These subsections describe the desirable scope of any recommended changes to make the RADIUS data model more uniform. 6.1. Backwards Compatibility It is imperative that any changes to the data model do not impact functioning deployments. 6.1.1. Intermediate Nodes RADIUS deployments can include complex proxy architectures. Intermediate nodes may be under separate administrative or operational control from the endpoint client and server. In these scenarios it would not be likely that intermediate nodes would make software or configuration changes to support new functionality at the endpoints. Any data model changes should be transparent to intermediate nodes. This means no changes in wire formats outside the value portion of attributes. 6.1.2. Dictionary-based Implementations Support for structured data or attribute groupings would likely impact dictionary-based implementations. Typically, such an implementation would use the attribute type as an index into a single description of the attribute. There is some precedent for requiring software changes to deploy new RADIUS functionality. This happened with the addition of tagged attribute support and dynamic authorization extensions [RFC3576]. 6.1.3. Unaware Endpoints Any changes must recognize the fact that any combination of client or Weber Expires April 27, 2006 [Page 12] Internet-Draft RADIUS Attribute Guidelines October 2005 server might not understand the new functionality. That said, this document will not address the idea of capability negotiation or advertisement. This would seem to be a problem common to other features and should be addressed separately. 6.2. Existing Vendor-Specific Attribute Usage No new, retroactive requirements should be placed on vendors with regard to existing use of Vendor-Specific attributes. 6.3. Transport Impact No changes will be made to the RADIUS transport or (related) maximum packet sizes. 6.4. Non-AAA Applications This document is not targeted at non-AAA applications which use RADIUS as a transport such as the Extensible Authentication Protocol (EAP) [RFC3748] [RFC3579]. These applications do not need to conform to the RADIUS data model as the RADIUS client and server are not the real endpoints of such conversations. 6.5. Diameter Compatibility Changes to the RADIUS data model should be Diameter-friendly. It is not the intent to reproduce all or even significant Diameter functionality, or to support all Diameter applications via RADIUS. Ensuring that the data models are somewhat aligned, however, will facilitate the work of Translating Agents for common applications. 7. Recommendations This document proposes a new attribute below. The purpose is to facilitate alignment between the standard and vendor attribute spaces, and make some of the commonly available features in the vendor space available to standard attributes. This attribute is defined in the standard space, but may contain subattributes from either the standard space or the vendor space. 7.1. Extended-Attribute This attribute is similar in structure to the Vendor-Specific (26) attribute, but it may be either in the vendor space or the standard space without other format changes. The format supports subattributes, fragmented attributes, and an expanded type space. Weber Expires April 27, 2006 [Page 13] Internet-Draft RADIUS Attribute Guidelines October 2005 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type (TBD) | Length |V|E|C| (reserved flags) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vendor-Id (opt) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Value... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type (TBD) Length >= 11 (if Vendor-Id is present) Flags Sixteen bit flags. The first three are allocated: V: True if Vendor-Id is present in this attribute. E: If true, the subtype field length is two octets, not one. C: If true, this attribute is a continuation of the previous Extended-Attribute Vendor-Id The high-order octet is 0 and the low-order 3 octets are the SMI Network Management Private Enterprise Code of the Vendor in network byte order, as defined in the "Assigned Numbers" [RFC1700] Type The subattribute type. Length The subattribute length. Value The subattribute value. Multiple subattributes MAY be encoded within a single Extended- Attribute, although they do not have to be. If multiple subattributes are present, the V and E flags apply to each of them, and the C flag concatenates the first subattribute value with the last subattribute value in the previous Extended-Attribute. 8. Diameter Considerations TBD. Need to understand how an Extended Attribute would translate into a Diameter grouped attribute. Weber Expires April 27, 2006 [Page 14] Internet-Draft RADIUS Attribute Guidelines October 2005 9. IANA Considerations TBD. Would a new registry be needed for attribute types larger than 255, or could the same one be used? 10. Security Considerations TBD 11. References 11.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2279, January 1998. [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. [RFC2868] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M., and I. Goyret, "RADIUS Attributes for Tunnel Protocol Support", RFC 2868, June 2000. [RFC2869] Rigney, C., Willats, W., and P. Calhoun, "RADIUS Extensions", RFC 2869, June 2000. [RFC3162] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6", RFC 3162, August 2001. [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003. [RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, "Diameter Network Access Server Application", RFC 4005, August 2005. 11.2. Informative References [PKT-SP-EM1.5] CableLabs PacketCable Project, "Event Messages", PacketCable Specifications 1.5, January 2005. Weber Expires April 27, 2006 [Page 15] Internet-Draft RADIUS Attribute Guidelines October 2005 [RFC1155] Rose, M. and K. McCloghrie, "Structure and identification of management information for TCP/IP-based internets", STD 16, RFC 1155, May 1990. [RFC1157] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network Management Protocol (SNMP)", STD 15, RFC 1157, May 1990. [RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700, October 1994. [RFC2548] Zorn, G., "Microsoft Vendor-specific RADIUS Attributes", RFC 2548, March 1999. [RFC3576] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B. Aboba, "Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS)", RFC 3576, July 2003. [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication Protocol (EAP)", RFC 3579, September 2003. [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004. Appendix A. Acknowledgments Many of the issues discussed in this document are a distillation of email threads on the RADEXT WG list which is archived here: http://ops.ietf.org/lists/radiusext/ Weber Expires April 27, 2006 [Page 16] Internet-Draft RADIUS Attribute Guidelines October 2005 Author's Address Greg Weber Cisco Systems 10850 Murdock Road Knoxville, TN 37932 USA Email: gdweber@cisco.com Weber Expires April 27, 2006 [Page 17] Internet-Draft RADIUS Attribute Guidelines October 2005 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Weber Expires April 27, 2006 [Page 18]