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 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 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 that has been assigned an SMI Private Enterprise Number (TBD: ref) from the IANA automatically gets a number space, and every standards development organisation can get either one or 2^24 number spaces, depending on its requirements. 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... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The fields of this structure are described as follows: STD The STD field defines the number spaces for the Vendor and Type fields. It MUST be set to one of the following values upon transmission: 0x00: The Vendor field contains a SMI Private Enterprise Number (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 process outside the IETF to assign type numbers. (TBD: I'm not aware of any SDO registry at the IANA - 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 for this purpose from the IANA. 0xc0: The Vendor and Type numbers are governed by this document or any later backwards compatible revision. All other values are reserved. Values should be allocated using the highest order bits first, ie. the next value assigned would be 0x20. Attributes containing a value in this field that is not understood by the recipient MUST be ignored. Vendor Together with the STD field, the Vendor field defines the number space for the Type field. The interpretation of the Vendor field depends on the value of the STD field as described above. It can contain either a SMI Private Enterprise Number (STD=0x00), a number designating an SDO (STD=0x40), a number referring to an IETF standard that requires its own Type space (STD=0x80), or one of the following values (std=0xc0): 0: The Type number space is shared with DIAMETER, where types 0-255 are RADIUS attributes and assigned using the process given in section 6 of ; types 256 through 2^32-1 should ideally be assigned using a light weight assignment process at the IANA 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. 1: Reserved. This value MUST NOT be set upon transmission. Alternatively, if sharing the extended RADIUS space and DIAMETER is undesireable or politically infeasible, Vendor=0 could be used for attributes in the RADIUS and Extended RADIUS attribute type number space only and Vendor=1 for attributes from the DIAMETER number space. (Decision TBD) 2: The Type number space is defined by the parent attribute. This value SHOULD be used when an attribute has no meaning except as a member of a structured set of attributes attached to another attribute. See the description of the Tag and Child-Tag fields. All other values MUST NOT be set upon transmission except when a future revision of this document specifies otherwise; if a recipient does not understand the meaning of the value of this field, the attribute MUST be ignored. 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. In DIAMETER, this field is referred to as the AVP Code. In any case, 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. 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. Example: a IPv6 prefix to route to a user, could be given by an attribute Ext-Framed-IPv6-Route (999), containing a subattribute 1 that specifies a prefix length in bits and a subattribute 2 that specifies the prefix, as follows:

STD VND Type Tag Child-Tag Length Data 0xc0 0x00 999 0 1 12 <none> 0xc0 0x02 1 1 0 13 96 0xc0 0x02 2 1 0 24 <12 octets IPv6 prefix> 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.