Extended RADIUS Attributes

The data structures involved in this proposal are described before anything else, because that likely makes the rest of the discussion easier to follow. A new RADIUS attribute is proposed, the Extended-Attribute. This attribute may occur zero or more times in any RADIUS packet. Whenever multiple instances of this attribute are found, the contents of all instances must be concatenated before any further decoding is done, similar to the way EAP-Message is treated. Concatenation during decoding takes up all instances and splitting during encoding may happen at arbitrary boundaries. Thus, at most one extended attribute space can exist in a single RADIUS packet. Concatenation renders a virtual data field, called the extended attribute space. This space can be as large as is possible considering the maximum size of a RADIUS packet, which is currently 4096 bytes. It can never be larger than the length of a single RADIUS packet. An encapsulating attribute that follows the standard RADIUS format allows us to overcome the limit of 253 octets without violating the RADIUS protocol, and allows clients, proxies and servers that do not implement support for the extended attribute format to transparently pass any set of extended attributes as opaque data.

Description This RADIUS attribute encapsulates the Extended Attribute space as described in . It follows the standard RADIUS format for opaque octet strings.

A summary of this attribute 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 | String... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Type TBD for Extended-Attribute Length >= 3 String The String field contains the Extended Attribute space as defined in . If multiple instances of the Extended-Attribute are present in a packet, their values MUST be concatenated before any attempt to interpret the value is made.

The Extended Attribute space is a single virtual field of which at most one may be present in any RADIUS packet. It is encapsulated by one or more instances of the RADIUS Extended-Attribute as described in , each instance covering up to 253 octets of this virtual field. The Extended Attribute space contains one or more Extended RADIUS attributes. Extended RADIUS attributes exist on the same conceptual level as a normal RADIUS attributes and have the same semantics, but allow for more attribute types, separate number spaces, longer values and tags contained in a fixed field that does not share a function as a flag, a tag and the first octet of the value, as in .

Description Each extended attribute specifies the number space for the attribute type field, the attribute type, an optional tag, an optional reference to another set of tagged attributes, a value length and an optional value. Each attribute type number space is able to contain 2^32 attribute types. Every vendor who has an SMI Private Enterprise Number (TBD: ref) automatically gets one number space, and every standards development organisation can get either one or 2^24 number spaces. The format for vendor-specific and non-vendor specific extended RADIUS attributes is the same, contrary to RADIUS, where each vendor is effectively assigned only one attribute. Most vendors have used their given space wisely and have adopted the standard RADIUS attribute encoding for their attribute sets, but others have not. In the extended RADIUS attribute space, each vendor gets a full number space of 2^32 attribute types, which, along with the other features offered by the extended attribute format, hopefully removes the need for re-creating a simple (but inaccessible without prior knowledge) TLV structure of their own in their values. While the syntax of the value remains entirely dependent on the attribute type in question, client vendors are strongly encouraged to follow the example of RADIUS as defined by the IETF and use standard data types whenever possible; eg. UTF-8 for strings intended for human consumption, binary values contained in either 4 or 8 bytes in network order for ordinal values, an so on, to allow quick adoption of their new attributes by dictionary driven server implementations. Opaque strings are not discouraged, as long as any standard authentication and authorization process can be performed using equality testing against and assignment from a stored value in a database.

The format of the extended attribute 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | STD | Vendor | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag | Child-Tag | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ STD This field designates the standard or organization that governs the number space for the Vendor and Type fields. 0x00: The Vendor field contains a SMI Private Enterprise Numbers (TBD: ref) as assigned by the IANA; the Type number space is governed by the private entity designated by the Vendor number. 0x40: The Vendor number designates a Standards Development Organization (SDO) or other publically recognised non-IETF process to assign type numbers. (TBD: I'm not aware of any SDO registry at the IANA yet - is there one?); the Type number space is governed by the SDO or standard process designated by the Vendor number. 0x80: The Vendor number space is governed by the IETF. Any IETF standard that wants to create a distinct Type space may be assigned a new Vendor number after expert review. Any backwards compatible revision of such a standard MUST keep the same Vendor number, otherwise a new Vendor number MUST be obtained. 0xc0: The Vendor and Type numbers are governed by this document or any later backwards compatible revision and are described below. All other values are reserved. Values should be allocated using the highest order bits first, ie. the next value assigned should be 0x20. Vendor If the STD field described above is 0xc0, this value MUST be set to zero upon transmission, and MUST be ignored upon reception. (TBD: alternatively, see below) Type The attribute type number. There are 2^32 possible attribute types available for assignment in each of the 2^32 number spaces created by the STD and Vendor fields. The word Type may be confusing but is historic in RADIUS; each type represents a particular attribute or data item, not a data type. Multiple instances of each attribute type may exist; the relative ordering among instances of the same attribute type MUST be preserved by all parties. If the STD field is 0xc0 and the Vendor field is 0, then types 0-255 are shared with RADIUS and are assigned using the assignment process given in section 6 of ; all other types are shared with DIAMETER. A light weight common assignment process that reserves a number in both the DIAMETER space and the extended attribute space, even when an attribute is in practice only meaningful in either DIAMETER or RADIUS context, should be used at the IANA. TBD: Alternatively, DIAMETER and (extended) RADIUS could be separated by using STD 0xc0 and Vendor 1 for DIAMETER instead. The disadvantage is then that you can then represent standard RADIUS attributes in three ways instead of two: as RADIUS attributes, as extended RADIUS attributes and as DIAMETER attributes. This may be the only option if a shared yet sufficiently light weight assigment process is infeasible though. Tag The Tag is a number that groups attributes of different types together into a single data structure. Using this field, up to 255 of these data structures can exist in any RADIUS packet containing the extended RADIUS attribute space. This facility allows structures composed of a set of RADIUS attributes without relying on relative attribute ordering, removing the need for each instance of such a compound data structure to include the same number of instances of each attribute type. See also , which uses the same concept but a different way to represent the tags. A Tag value of zero does not represent any particular group. When no grouping is intended, the Tag field MUST be set to zero. Child-Tag If the value of this field is non-zero, the attribute containing this field refers to a data structure consisting of the set attributes tagged with the same value. This facility allows any attribute to refer to a particular set of tagged attributes as its subordinates, and thus allows structures of arbitrary depth, without recursive parsing and while preserving a flat list of attributes and a flat, numbered list of compound structures. Using this facility, each instance of any attribute type gets the ability to convey both its own value and a unique set of attributes. Splitting a data structure into subattributes by tagging them and having the parent attribute refer to the tag value using Child-Tag, allows for deeper access by dictionary driven implementations into compound data structures, which would otherwise require specific knowledge about the particular attribute. Attributes can either have a normal value and refer to at most one tagged set of attributes using its Child-Tag field, or refer to a list of tagged sets of attributes, by having one or more tags as their value. Length The total length of the attribute, excluding padding to a multiple of 4 octets. The next attribute can thus be found at (length + 3) & ~ 3 octets from the beginning of the current attribute. Value The value of the attribute. The size of this field in octets is given by the value of the Length field after subtracting the size of the attribute header (8 octets). All values MUST be padded on the right to a multiple of 4 octets. Zero-sized values are allowed. The meaning of each possible value depends entirely on the attribute type.