Remote Authentication Dial In User Service (RADIUS) Protocol Extensions

Abstract

The Remote Authentication Dial-In User Service (RADIUS) protocol is nearing exhaustion of its current 8-bit Attribute Type space. In addition, experience shows a growing need for complex grouping, along with attributes that can carry more than 253 octets of data. This document defines changes to RADIUS that address all of the above problems. Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6929.

Data Types in RADIUS

“…The specification may, of course, define a new data type, update the "Data Type" registry, and use the new data type, all in the same document. The guidelines given in [RFC6929] MUST be followed when defining a new data type.…”

“…Use of the new extended attributes [RFC6929] makes ASCII art even more problematic. An attribute can be allocated from any of the extended spaces, with more than one option for the attribute header format.…”

“…We do not expect a need for a large number of new data types. When defining a new data type, the guidelines of [RFC6929] with respect to data types MUST be followed.…”

“…As discussed in [RFC6929], those data types are rarely necessary and can cause interoperability problems.…”

“…Of these three pieces of information, the name is recorded by IANA in the "RADIUS Attribute Types" registry but is not otherwise managed or restricted, as discussed in [RFC6929], Section 2.7.1. The value is managed by IANA and recorded in that registry.…”