MikhailMS
commented
3 years ago This issue doesn't involve coding and rather focuses on identifying what is missing from the current implementation of RADIUS
Closed MikhailMS closed 3 years ago
MikhailMS
commented
3 years ago This issue doesn't involve coding and rather focuses on identifying what is missing from the current implementation of RADIUS
MikhailMS
commented
3 years ago In RFC 2865
A RADIUS server MUST use the source IP address of the RADIUS UDP
packet to decide which shared secret to use, so that RADIUS
requests can be proxied.Seems like I'd need to change allowed_hosts from list to dictionary, so we can store IP & secret
MikhailMS
commented
3 years ago In RFC 3576
Implementations of this specification SHOULD support IPsec [RFC2401]
along with IKE [RFC2409] for key management. IPsec ESP [RFC2406]
with a non-null transform SHOULD be supported, and IPsec ESP with a
non-null encryption transform and authentication support SHOULD be
used to provide per-packet confidentiality, authentication, integrity
and replay protection. IKE SHOULD be used for key management.and
Where IPsec replay protection is not used, the Event-Timestamp (55)
Attribute [RFC2869] SHOULD be included within all messages. When
this attribute is present, both the NAS and the RADIUS server MUST
check that the Event-Timestamp Attribute is current within an
acceptable time window. If the Event-Timestamp Attribute is not
current, then the message MUST be silently discarded. This implies
the need for time synchronization within the network, which can be
achieved by a variety of means, including secure NTP, as described in
[NTPAUTH].Seems like I am missing small bits from RFC 3576, so need to check on if it is beneficial to priorotise them into the next release
The rest of the RFC is either implemented or not appicable because it is more about application logic (RADIUS Server/Client) then RADIUS protocol per se
MikhailMS
commented
3 years ago In RFC 2866
text 1-253 octets containing UTF-8 encoded 10646 [7]
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.and
Request Authenticator
In Accounting-Request Packets, the Authenticator value is a 16
octet MD5 [5] checksum, called the Request Authenticator.
The NAS and RADIUS accounting server share a secret. The Request
Authenticator field in Accounting-Request packets contains a one-
way MD5 hash calculated over a stream of octets consisting of the
Code + Identifier + Length + 16 zero octets + request attributes +
shared secret (where + indicates concatenation). The 16 octet MD5
hash value is stored in the Authenticator field of the
Accounting-Request packet.
Note that the Request Authenticator of an Accounting-Request can
not be done the same way as the Request Authenticator of a RADIUS
Access-Request, because there is no User-Password attribute in an
Accounting-Request.
Response Authenticator
The Authenticator field in an Accounting-Response packet is called
the Response Authenticator, and contains a one-way MD5 hash
calculated over a stream of octets consisting of the Accounting-
Response Code, Identifier, Length, the Request Authenticator field
from the Accounting-Request packet being replied to, and the
response attributes if any, followed by the shared secret. The
resulting 16 octet MD5 hash value is stored in the Authenticator
field of the Accounting-Response packet.Seems like:
The rest of the RFC is either implemented or not appicable because it is more about application logic (RADIUS Server/Client) then RADIUS protocol per se
MikhailMS
commented
3 years ago In RFC 2868
Tunnel-Password
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 | Salt
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Salt (cont) | String ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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. Valid values for this field are 0x01 through 0x1F,
inclusive. 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;
otherwise, the Tag field SHOULD be ignored.
Salt
The Salt field is two octets in length and is used to ensure the
uniqueness of the encryption key used to encrypt each instance of
the Tunnel-Password attribute occurring in a given Access-Accept
packet. The most significant bit (leftmost) of the Salt field
MUST be set (1). The contents of each Salt field in a given
Access-Accept packet MUST be unique.
String
The plaintext String field consists of three logical sub-fields:
the Data-Length and Password sub-fields (both of which are
required), and the optional Padding sub-field. The Data-Length
sub-field is one octet in length and contains the length of the
unencrypted Password sub-field. The Password sub-field contains
Zorn, et al. Informational [Page 8]
RFC 2868 RADIUS Tunnel Authentication Attributes June 2000
the actual tunnel password. If the combined length (in octets) of
the unencrypted Data-Length and Password sub-fields is not an even
multiple of 16, then the Padding sub-field MUST be present. If it
is present, the length of the Padding sub-field is variable,
between 1 and 15 octets. The String field MUST be encrypted as
follows, prior to transmission:
Construct a plaintext version of the String field by
concatenating the Data-Length and Password sub-fields. If
necessary, pad the resulting string until its length (in
octets) is an even multiple of 16. It is recommended that zero
octets (0x00) be used for padding. Call this plaintext P.
Call the shared secret S, the pseudo-random 128-bit Request
Authenticator (from the corresponding Access-Request packet) R,
and the contents of the Salt field A. Break P into 16 octet
chunks p(1), p(2)...p(i), where i = len(P)/16. Call the
ciphertext blocks c(1), c(2)...c(i) and the final ciphertext C.
Intermediate values b(1), b(2)...c(i) are required. Encryption
is performed in the following manner ('+' indicates
concatenation):
b(1) = MD5(S + R + A) c(1) = p(1) xor b(1) C = c(1)
b(2) = MD5(S + c(1)) c(2) = p(2) xor b(2) C = C + c(2)
. .
. .
. .
b(i) = MD5(S + c(i-1)) c(i) = p(i) xor b(i) C = C + c(i)
The resulting encrypted String field will contain
c(1)+c(2)+...+c(i).
On receipt, the process is reversed to yield the plaintext String.and
## Taken from https://github.com/FreeRADIUS/freeradius-server/blob/master/share/dictionary/radius/dictionary.rfc2868
ATTRIBUTE Tunnel-Type 64 integer has_tag
ATTRIBUTE Tunnel-Medium-Type 65 integer has_tag
ATTRIBUTE Tunnel-Client-Endpoint 66 string has_tag
ATTRIBUTE Tunnel-Server-Endpoint 67 string has_tag
ATTRIBUTE Tunnel-Password 69 string has_tag,encrypt=2
ATTRIBUTE Tunnel-Private-Group-Id 81 string has_tag
ATTRIBUTE Tunnel-Assignment-Id 82 string has_tag
ATTRIBUTE Tunnel-Preference 83 integer has_tag
ATTRIBUTE Tunnel-Client-Auth-Id 90 string has_tag
ATTRIBUTE Tunnel-Server-Auth-Id 91 string has_tagIntroduces new attributtes with new logic around it, so need to ensure
MikhailMS
commented
3 years ago In RFC 2869
Introduces:
MikhailMS
commented
3 years ago In RFC 3162
Introduces new:
MikhailMS
commented
3 years ago In RFC 4072
Mainly goes about Diameter protocol & how Radius talks to Diameter, so nothing to implement here
MikhailMS
commented
3 years ago MikhailMS
commented
3 years ago MikhailMS
commented
3 years ago In RFC 5447
Talks about support for Network Access Server to Diameter Server Interaction (Diameter Mobile IPv6), so nothing to implement here
MikhailMS
commented
3 years ago MikhailMS
commented
3 years ago MikhailMS
commented
3 years ago MikhailMS
commented
3 years ago In RFC 6677
Talks about Channel-Binding support to tackle "lying NAS" problem. This relates to actual RADIUS Client/Server implementations, so there is nothing to add to this crate
MikhailMS
commented
3 years ago In RFC 6929
Extended Type
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 | Extended-Type | Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
This field is identical to the Type field of the Attribute format
defined in [RFC2865] Section 5.
Length
The Length field is one octet and indicates the length of this
Attribute, including the Type, Length, "Extended-Type", and
"Value" fields. Permitted values are between 4 and 255. If a
client or server receives an Extended Attribute with a Length of 2
or 3, then that Attribute MUST be considered to be an "invalid
attribute" and handled as per Section 2.8, below.
Extended-Type
The Extended-Type field is one octet. Up-to-date values of this
field are specified according to the policies and rules described
in Section 10. Unlike the Type field defined in [RFC2865]
Section 5, no values are allocated for experimental or
implementation-specific use. Values 241-255 are reserved and MUST
NOT be used.
The Extended-Type is meaningful only within a context defined by
the Type field. That is, this field may be thought of as defining
a new type space of the form "Type.Extended-Type". See
Section 3.5, below, for additional discussion.
A RADIUS server MAY ignore Attributes with an unknown
"Type.Extended-Type".
A RADIUS client MAY ignore Attributes with an unknown
"Type.Extended-Type".
Value
This field is similar to the "Value" field of the Attribute format
defined in [RFC2865] Section 5. The format of the data MUST be a
valid RADIUS data type.
The "Value" field is one or more octets.
Implementations supporting this specification MUST use the
identifier of "Type.Extended-Type" to determine the interpretation
of the "Value" field.
The addition of the Extended-Type field decreases the maximum
length for attributes of type "text" or "string" from 253 to
252 octets. Where an Attribute needs to carry more than
252 octets of data, the "Long Extended Type" format MUST be used.
--------
Long Extended Type
It leverages the "Extended Type" format in order to permit
the transport of attributes encapsulating more than 253 octets of
data. A summary of the 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 | Extended-Type |M| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
This field is identical to the Type field of the Attribute format
defined in [RFC2865] Section 5.
Length
The Length field is one octet and indicates the length of this
Attribute, including the Type, Length, Extended-Type, and "Value"
fields. Permitted values are between 5 and 255. If a client or
server receives a "Long Extended Type" with a Length of 2, 3, or
4, then that Attribute MUST be considered to be an "invalid
attribute" and handled as per Section 2.8, below.
Note that this Length is limited to the length of this fragment.
There is no field that gives an explicit value for the total size
of the fragmented attribute.
Extended-Type
This field is identical to the Extended-Type field defined above
in Section 2.1.
M (More)
The More field is one (1) bit in length and indicates whether or
not the current attribute contains "more" than 251 octets of data.
The More field MUST be clear (0) if the Length field has a value
of less than 255. The More field MAY be set (1) if the Length
field has a value of 255.
If the More field is set (1), it indicates that the "Value" field
has been fragmented across multiple RADIUS attributes. When the
More field is set (1), the Attribute MUST have a Length field of
value 255, there MUST be an attribute following this one, and the
next attribute MUST have both the same Type and "Extended Type".
That is, multiple fragments of the same value MUST be in order and
MUST be consecutive attributes in the packet, and the last
attribute in a packet MUST NOT have the More field set (1).
That is, a packet containing a fragmented attribute needs to
contain all fragments of the Attribute, and those fragments need
to be contiguous in the packet. RADIUS does not support
inter-packet fragmentation, which means that fragmenting an
attribute across multiple packets is impossible.
If a client or server receives an attribute fragment with the
"More" field set (1) but for which no subsequent fragment can be
found, then the fragmented attribute is considered to be an
"invalid attribute" and handled as per Section 2.8, below.
Reserved
This field is 7 bits long and is reserved for future use.
Implementations MUST set it to zero (0) when encoding an attribute
for sending in a packet. The contents SHOULD be ignored on
reception.
Future specifications may define additional meaning for this
field. Implementations therefore MUST NOT treat this field as
invalid if it is non-zero.
Value
This field is similar to the "Value" field of the Attribute format
defined in [RFC2865] Section 5. It may contain a complete set of
data (when the Length field has a value of less than 255), or it
may contain a fragment of data.
The "Value" field is one or more octets.
Implementations supporting this specification MUST use the
identifier of "Type.Extended-Type" to determine the interpretation
of the "Value" field.
Any interpretation of the resulting data MUST occur after the
fragments have been reassembled. The length of the data MUST be
taken as the sum of the lengths of the fragments (i.e., "Value"
fields) from which it is constructed. The format of the data
SHOULD be a valid RADIUS data type. If the reassembled data does
not match the expected format, all fragments MUST be treated as
"invalid attributes", and the reassembled data MUST be discarded.
We note that the maximum size of a fragmented attribute is limited
only by the RADIUS packet length limitation (i.e., 4096 octets,
not counting various headers and overhead). Implementations MUST
be able to handle the case where one fragmented attribute
completely fills the packet.
This definition increases the RADIUS Attribute Type space as above
but also provides for transport of Attributes that could contain more
than 253 octets of data.
--------
TLV Data Type
We define a new data type in RADIUS, called "tlv". The "tlv" data
type is an encapsulation layer that permits the "Value" field of an
Attribute to contain new sub-Attributes. These sub-Attributes can in
turn contain "Value"s of data type TLV. This capability both extends
the Attribute space and permits "nested" attributes to be used. This
nesting can be used to encapsulate or group data into one or more
logical containers.
The "tlv" data type reuses the RADIUS Attribute format, as given
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV-Type | TLV-Length | TLV-Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TLV-Type
The TLV-Type field is one octet. Up-to-date values of this field
are specified according to the policies and rules described in
Section 10. Values 254-255 are "Reserved" for use by future
extensions to RADIUS. The value 26 has no special meaning and
MUST NOT be treated as a Vendor-Specific Attribute.
As with the Extended-Type field defined above, the TLV-Type is
meaningful only within the context defined by "Type" fields of the
encapsulating Attributes. That is, the field may be thought of as
defining a new type space of the form
"Type.Extended-Type.TLV-Type". Where TLVs are nested, the type
space is of the form "Type.Extended-Type.TLV-Type.TLV-Type", etc.
A RADIUS server MAY ignore Attributes with an unknown "TLV-Type".
A RADIUS client MAY ignore Attributes with an unknown "TLV-Type".
A RADIUS proxy SHOULD forward Attributes with an unknown
"TLV-Type" verbatim.
TLV-Length
The TLV-Length field is one octet and indicates the length of this
TLV, including the TLV-Type, TLV-Length, and TLV-Value fields. It
MUST have a value between 3 and 255. If a client or server
receives a TLV with an invalid TLV-Length, then the Attribute that
encapsulates that TLV MUST be considered to be an "invalid
attribute" and handled as per Section 2.8, below.
TLV-Value
The TLV-Value field is one or more octets and contains information
specific to the Attribute. The format and length of the TLV-Value
field are determined by the TLV-Type and TLV-Length fields.
The TLV-Value field SHOULD encapsulate a standard RADIUS data
type. Non-standard data types SHOULD NOT be used within TLV-Value
fields. We note that the TLV-Value field MAY also contain one or
more attributes of data type TLV; data type TLV allows for simple
grouping and multiple layers of nesting.
The TLV-Value field is limited to containing 253 or fewer octets
of data. Specifications that require a TLV to contain more than
253 octets of data are incompatible with RADIUS and need to be
redesigned. Specifications that require the transport of empty
"Value"s (i.e., Length = 2) are incompatible with RADIUS and need
to be redesigned.
The TLV-Value field MUST NOT contain data using the "Extended
Type" formats defined in this document. The base Extended
Attributes format allows for sufficient flexibility that nesting
them inside of a TLV offers little additional value.
This TLV definition is compatible with the suggested format of the
"String" field of the Vendor-Specific Attribute, as defined in
[RFC2865] Section 5.26, though that specification does not discuss
nesting.
--------
EVS Data Type
We define a new data type in RADIUS, called "evs", for "Extended-
Vendor-Specific". The "evs" data type is an encapsulation layer that
permits the EVS-Value field of an Attribute to contain a Vendor-Id,
followed by an EVS-Type, and then vendor-defined data. This data can
in turn contain valid RADIUS data types or any other data as
determined by the vendor.
This data type is intended for use in attributes that carry vendor-
specific information, as is done with the Vendor-Specific Attribute
(Attribute number 26). It is RECOMMENDED that this data type be used
by a vendor only when the Vendor-Specific Attribute Type space has
been fully allocated.
Where [RFC2865] Section 5.26 makes a recommendation for the format of
the data following the Vendor-Id, we give a strict definition.
Experience has shown that many vendors have not followed the
[RFC2865] recommendations, leading to interoperability issues. We
hope here to give vendors sufficient flexibility as to meet their
needs while minimizing the use of non-standard VSA formats.
The "evs" data type MAY be used in Attributes having the format of
"Extended Type" or "Long Extended Type". It MUST NOT be used in any
other Attribute definition, including standard RADIUS attributes,
TLVs, and VSAs.
A summary of the "evs" data type 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EVS-Type | EVS-Value ....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vendor-Id
The 4 octets of the Vendor-Id field are the Network Management
Private Enterprise Code [PEN] of the vendor in network byte order.
EVS-Type
The EVS-Type field is one octet. Values are assigned at the sole
discretion of the vendor.
EVS-Value
The EVS-Value field is one or more octets. It SHOULD encapsulate
a standard RADIUS data type. Using non-standard data types is NOT
RECOMMENDED. We note that the EVS-Value field may be of data type
TLV. However, it MUST NOT be of data type "evs", as the use cases
are unclear for one vendor delegating Attribute Type space to
another vendor.
The actual format of the information is site or application
specific, and a robust implementation SHOULD support the field as
undistinguished octets. While we recognize that vendors have
complete control over the contents and format of the EVS-Value
field, we recommend that good practices be followed.
Further codification of the range of allowed usage of this field
is outside the scope of this specification.
Note that unlike the format described in [RFC2865] Section 5.26, this
data type has no "Vendor-Length" field. The length of the EVS-Value
field is implicit and is determined by taking the "Length" of the
encapsulating RADIUS attribute and then subtracting the length of the
Attribute header (2 octets), the "Extended Type" (1 octet), the
Vendor-Id (4 octets), and the EVS-Type (1 octet). That is, for
"Extended Type" Attributes the length of the EVS-Value field is eight
(8) less than the value of the Length field, and for "Long Extended
Type" Attributes the length of the EVS-Value field is nine (9) less
than the value of the Length field.
--------In RFC 7055
Introduces GSS-API mechanism for EAP. THis is strictly for actual RADIUS Client/Server implementation and not for the present crate
MikhailMS
commented
3 years ago MikhailMS
commented
3 years ago In RFC 7930
Experimental - talks about potential usage of TCP protocol to carry RADIUS packets to avoid UDP limitation and usage of fragmented RADIUS packets over UDP protocol
MikhailMS
commented
3 years ago In RFC 8044
integer
The "integer" data type encodes a 32-bit unsigned integer in network
byte order. Where the range of values for a particular attribute is
limited to a subset of the values, specifications MUST define the
valid range. Attributes with Values outside of the allowed ranges
SHOULD be treated as invalid attributes.
Name
integer
Value
1
Length
Four octets
Format
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
enum
The "enum" data type encodes a 32-bit unsigned integer in network
byte order. It differs from the "integer" data type only in that it
is used to define enumerated types, such as Service-Type (Section 5.6
of [RFC2865]). Specifications MUST define a valid set of enumerated
values, along with a unique name for each value. Attributes with
Values outside of the allowed enumerations SHOULD be treated as
invalid attributes.
Name
enum
Value
2
Length
Four octets
Format
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
time
The "time" data type encodes time as a 32-bit unsigned value in
network byte order and in seconds since 00:00:00 UTC, January 1,
1970. We note that dates before the year 2017 are likely to indicate
configuration errors or lack of access to the correct time.
Note that the "time" attribute is defined to be unsigned, which means
that it is not subject to a signed integer overflow in the year 2038.
Name
time
Value
3
Length
Four octets
Format
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
text
The "text" data type encodes UTF-8 text [RFC3629]. The maximum
length of the text is given by the encapsulating attribute. Where
the range of lengths for a particular attribute is limited to a
subset of possible lengths, specifications MUST define the valid
range(s). Attributes with lengths outside of the allowed values
SHOULD be treated as invalid attributes.
Attributes of type "text" that are allocated in the standard space
(Section 1.2 of [RFC6929]) are limited to no more than 253 octets of
data. Attributes of type "text" that are allocated in the extended
space can be longer. In both cases, these limits are reduced when
the data is encapsulated inside of another attribute.
Where the text is intended to carry data in a particular format
(e.g., Framed-Route), the format MUST be given. The specification
SHOULD describe the format in a machine-readable way, such as via the
Augmented Backus-Naur Form (ABNF) [RFC5234]. Attributes with
Values not matching the defined format SHOULD be treated as
invalid attributes.
Note that the "text" data type does not terminate with a NUL octet
(hex 00). The Attribute has a Length field and does not use a
terminator. Texts of length zero (0) MUST NOT be sent; omit the
entire attribute instead.
Name
text
Value
4
Length
One or more octets
Format
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-
| Value ...
+-+-+-+-+-+-+-+-
string
The "string" data type encodes binary data as a sequence of
undistinguished octets. Where the range of lengths for a particular
attribute is limited to a subset of possible lengths, specifications
MUST define the valid range(s). Attributes with lengths outside of
the allowed values SHOULD be treated as invalid attributes.
Attributes of type "string" that are allocated in the standard space
(Section 1.2 of [RFC6929]) are limited to no more than 253 octets of
data. Attributes of type "string" that are allocated in the extended
space can be longer. In both cases, these limits are reduced when
the data is encapsulated inside of another attribute.
Note that the "string" data type does not terminate with a NUL octet
(hex 00). The Attribute has a Length field and does not use a
terminator. Strings of length zero (0) MUST NOT be sent; omit the
entire attribute instead. Where there is a need to encapsulate
complex data structures and TLVs cannot be used, the "string"
data type MUST be used. This requirement includes encapsulation of
data structures defined outside of RADIUS that are opaque to the
RADIUS infrastructure. It also includes encapsulation of some data
structures that are not opaque to RADIUS, such as the contents of
CHAP-Password.
There is little reason to define a new RADIUS data type for only one
attribute. However, where the complex data type cannot be
represented as TLVs and is expected to be used in many attributes, a
new data type SHOULD be defined.
These requirements are stronger than [RFC6158], which makes the above
encapsulation a "SHOULD". This document defines data types for use
in RADIUS, so there are few reasons to avoid using them.
Name
string
Value
5
Length
One or more octets
Format
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-
| Octets ...
+-+-+-+-+-+-+-+-
concat
The "concat" data type permits the transport of more than 253 octets
of data in a "standard space" [RFC6929] attribute. It is otherwise
identical to the "string" data type.
If multiple attributes of this data type are contained in a packet,
all attributes of the same type code MUST be in order, and they MUST
be consecutive attributes in the packet.
The amount of data transported in a "concat" data type can be no more
than the RADIUS packet size. In practice, the requirement to
transport multiple attributes means that the limit may be
substantially smaller than one RADIUS packet. As a rough guide, it
is RECOMMENDED that this data type transport no more than 2048 octets
of data.
The "concat" data type MAY be used for "standard space" attributes.
It MUST NOT be used for attributes in the "short extended space" or
the "long extended space". It MUST NOT be used in any field or
subfields of the following data types: "tlv", "vsa", "extended",
"long-extended", or "evs".
Name
concat
Value
6
Length
One or more octets
Format
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-
| Octets ...
+-+-+-+-+-+-+-+-
ifid
The "ifid" data type encodes an Interface-Id as an 8-octet IPv6
Interface Identifier in network byte order.
Name
ifid
Value
7
Length
Eight octets
Format
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface-Id ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... Interface-Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
ipv4addr
The "ipv4addr" data type encodes an IPv4 address in network byte
order. Where the range of addresses for a particular attribute is
limited to a subset of possible addresses, specifications MUST define
the valid range(s). Attributes with Address values outside of the
allowed range(s) SHOULD be treated as invalid attributes.
Name
ipv4addr
Value
8
Length
Four octets
Format
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
ipv6addr
The "ipv6addr" data type encodes an IPv6 address in network byte
order. Where the range of addresses for a particular attribute is
limited to a subset of possible addresses, specifications MUST define
the valid range(s). Attributes with Address values outside of the
allowed range(s) SHOULD be treated as invalid attributes.
Name
ipv6addr
Value
9
Length
Sixteen octets
Format
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... Address ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... Address ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
ipv6prefix
The "ipv6prefix" data type encodes an IPv6 prefix, using both a
prefix length and an IPv6 address in network byte order. Where the
range of prefixes for a particular attribute is limited to a subset
of possible prefixes, specifications MUST define the valid range(s).
Attributes with Address values outside of the allowed range(s) SHOULD
be treated as invalid attributes.
Attributes with a Prefix-Length field having a value greater than 128
MUST be treated as invalid attributes.
Name
ipv6prefix
Value
10
Length
At least two, and no more than eighteen, octets
Format
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Prefix-Length | Prefix ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... Prefix ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... Prefix ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... Prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Subfields
Reserved
This field, which is reserved and MUST be present, is always
set to zero. This field is one octet in length.
Prefix-Length
The length of the prefix, in bits. At least 0 and no larger
than 128. This field is one octet in length.
Prefix
The Prefix field is up to 16 octets in length. Bits outside of
the Prefix-Length, if included, MUST be zero.
The Prefix field SHOULD NOT contain more octets than necessary
to encode the Prefix field.
ipv4prefix
The "ipv4prefix" data type encodes an IPv4 prefix, using both a
prefix length and an IPv4 address in network byte order. Where the
range of prefixes for a particular attribute is limited to a subset
of possible prefixes, specifications MUST define the valid range(s).
Attributes with Address values outside of the allowed range(s) SHOULD
be treated as invalid attributes.
Attributes with a Prefix-Length field having a value greater than 32
MUST be treated as invalid attributes.
Name
ipv4prefix
Value
11
Length
Six octets
Format
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Prefix-Length | Prefix ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... Prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Subfields
Reserved
This field, which is reserved and MUST be present, is always
set to zero. This field is one octet in length.
Note that this definition differs from that given in [RFC6572].
See "Prefix-Length", below, for an explanation.
Prefix-Length
The length of the prefix, in bits. The values MUST be no
larger than 32. This field is one octet in length. Note that
this definition differs from that given in [RFC6572].
As compared to [RFC6572], the Prefix-Length field has increased
in size by two bits, both of which must be zero. The
Reserved field has decreased in size by two bits. The result
is that both fields are aligned on octet boundaries, which
removes the need for bit masking of the fields.
Since [RFC6572] required the Reserved field to be zero, the
definition here is compatible with the definition in the
original specification.
Prefix
The Prefix field is 4 octets in length. Bits outside of the
Prefix-Length MUST be zero. Unlike the "ipv6prefix" data type,
this field is fixed length. If the address is all zeros (i.e.,
"0.0.0.0"), then the Prefix-Length MUST be set to 32.
integer64
The "integer64" data type encodes a 64-bit unsigned integer in
network byte order. Where the range of values for a particular
attribute is limited to a subset of the values, specifications MUST
define the valid range(s). Attributes with Values outside of the
allowed range(s) SHOULD be treated as invalid attributes.
Name
integer64
Value
12
Length
Eight octets
Format
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
tlv
The "tlv" data type encodes a Type-Length-Value, as defined in
[RFC6929], Section 2.3.
Name
tlv
Value
13
Length
Three or more octets
Format
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV-Type | TLV-Length | TLV-Data ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Subfields
TLV-Type
This field is one octet. Up-to-date values of this field are
specified according to the policies and rules described in
[RFC6929], Section 10. Values of 254-255 are reserved for use
by future extensions to RADIUS. The value 26 has no special
meaning and MUST NOT be treated as a Vendor-Specific Attribute.
The TLV-Type is meaningful only within the context defined by
Type fields of the encapsulating Attributes, using the
dotted-number notation introduced in [RFC6929].
A RADIUS server MAY ignore Attributes with an unknown
"TLV-Type".
A RADIUS client MAY ignore Attributes with an unknown
"TLV-Type".
A RADIUS proxy SHOULD forward Attributes with an unknown
"TLV-Type" verbatim.
TLV-Length
The TLV-Length field is one octet and indicates the length of
this TLV, including the TLV-Type, TLV-Length, and TLV-Value
fields. It MUST have a value between 3 and 255. If a client
or server receives a TLV with an invalid TLV-Length, then the
attribute that encapsulates that TLV MUST be considered to be
an invalid attribute and is handled as per
[RFC6929], Section 2.8.
TLVs having a TLV-Length of two (2) MUST NOT be sent; omit the
entire TLV instead.
TLV-Data
The TLV-Data field is one or more octets and contains
information specific to the attribute. The format and length
of the TLV-Data field are determined by the TLV-Type and
TLV-Length fields.
The TLV-Data field MUST contain only known RADIUS data types.
The TLV-Data field MUST NOT contain any of the following
data types: "concat", "vsa", "extended", "long-extended",
or "evs".
vsa
The "vsa" data type encodes vendor-specific data, as given in
[RFC2865], Section 5.26. It is used only in the Attr-Data field of a
Vendor-Specific Attribute. It MUST NOT appear in the contents of any
other data type.
Where an implementation determines that an attribute of data type
"vsa" contains data that does not match the expected format, it
SHOULD treat that attribute as being an invalid attribute.
Name
vsa
Value
14
Length
Five or more octets
Format
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VSA-Data ....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Subfields
Vendor-Id
The 4 octets are the Network Management Private Enterprise Code
[PEN] of the vendor in network byte order.
VSA-Data
The VSA-Data field is one or more octets. The actual format of
the information is site specific or application specific, and a
robust implementation SHOULD support the field as
undistinguished octets.
The codification of the range of allowed usage of this field is
outside the scope of this specification.
The "vsa" data type SHOULD contain a sequence of "tlv"
data types. The interpretation of the TLV-Type and TLV-Data
fields is dependent on the vendor's definition of that
attribute.
The "vsa" data type MUST be used as the contents of the
Attr-Data field of the Vendor-Specific Attribute. The "vsa"
data type MUST NOT appear in the contents of any other
data type.
extended
The "extended" data type encodes the "Extended Type" format, as given
in [RFC6929], Section 2.1. It is used only in the Attr-Data field of
an attribute allocated from the standard space. It MUST NOT appear
in the contents of any other data type.
Name
extended
Value
15
Length
Two or more octets
Format
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended-Type | Ext-Data ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Subfields
Extended-Type
The Extended-Type field is one octet. Up-to-date values of
this field are specified according to the policies and rules
described in [RFC6929], Section 10. Unlike the Type field
defined in [RFC2865], Section 5, no values are allocated for
experimental or implementation-specific use. Values 241-255
are reserved and MUST NOT be used.
The Extended-Type is meaningful only within a context defined
by the Type field. That is, this field may be thought of as
defining a new type space of the form "Type.Extended-Type".
See [RFC6929], Section 2.1 for additional discussion.
A RADIUS server MAY ignore Attributes with an unknown
"Type.Extended-Type".
A RADIUS client MAY ignore Attributes with an unknown
"Type.Extended-Type".
Ext-Data
The Ext-Data field is one or more octets.
The contents of this field MUST be a valid data type as defined
in the RADIUS "Data Type" registry. The Ext-Data field
MUST NOT contain any of the following data types: "concat",
"vsa", "extended", "long-extended", or "evs".
Implementations supporting this specification MUST use the
Identifier of "Type.Extended-Type" to determine the
interpretation of the Ext-Data field.
long-extended
The "long-extended" data type encodes the "Long Extended Type"
format, as given in [RFC6929], Section 2.2. It is used only in the
Attr-Data field of an attribute. It MUST NOT appear in the contents
of any other data type.
Name
long-extended
Value
16
Length
Three or more octets
Format
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended-Type |M|T| Reserved | Ext-Data ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Subfields
Extended-Type
This field is identical to the Extended-Type field defined
above in Section 3.15.
M (More)
The More field (M flag) is one (1) bit in length and indicates
whether or not the current attribute contains "more" than
251 octets of data. The More field MUST be clear (0) if the
Length field has a value less than 255. The More field MAY be
set (1) if the Length field has a value of 255.
If the More field is set (1), it indicates that the Ext-Data
field has been fragmented across multiple RADIUS attributes.
When the More field is set (1), the Attribute MUST have a
Length field value of 255; there MUST be an attribute following
this one; and the next attribute MUST have both the same Type
and Extended-Type. That is, multiple fragments of the same
value MUST be in order and MUST be consecutive attributes in
the packet, and the last attribute in a packet MUST NOT have
the More field set (1).
That is, a packet containing a fragmented attribute needs to
contain all fragments of the attribute, and those fragments
need to be contiguous in the packet. RADIUS does not support
inter-packet fragmentation, which means that fragmenting an
attribute across multiple packets is impossible.
If a client or server receives an attribute fragment with the
More field set (1), but for which no subsequent fragment can be
found, then the fragmented attribute is considered to be an
invalid attribute and is handled as per [RFC6929], Section 2.8.
T (Truncation)
This field is one bit in size and is called "T" for Truncation.
It indicates that the attribute is intentionally truncated in
this chunk and is to be continued in the next chunk of the
sequence. The combination of the M flag and the T flag
indicates that the attribute is fragmented (M flag) but that
all of the fragments are not available in this chunk (T flag).
Proxies implementing [RFC6929] will see these attributes as
invalid (they will not be able to reconstruct them), but they
will still forward them, as Section 5.2 of [RFC6929] indicates
that they SHOULD forward unknown attributes anyway.
Please see [RFC7499] for further discussion of the uses of
this flag.
Reserved
This field is six bits long and is reserved for future use.
Implementations MUST set it to zero (0) when encoding an
attribute for sending in a packet. The contents SHOULD be
ignored on reception.
Future specifications may define one or more additional
meanings for this field. Implementations therefore MUST NOT
treat this field as invalid if it is non-zero.
Ext-Data
The Ext-Data field is one or more octets.
The contents of this field MUST be a valid data type as defined
in the RADIUS "Data Type" registry. The Ext-Data field MUST
NOT contain any of the following data types: "concat", "vsa",
"extended", "long-extended", or "evs".
Implementations supporting this specification MUST use the
Identifier of "Type.Extended-Type" to determine the
interpretation of the Ext-Data field.
The length of the data MUST be taken as the sum of the lengths
of the fragments (i.e., Ext-Data fields) from which it is
constructed. Any interpretation of the resulting data MUST
occur after the fragments have been reassembled. If the
reassembled data does not match the expected format, each
fragment MUST be treated as an invalid attribute, and the
reassembled data MUST be discarded.
We note that the maximum size of a fragmented attribute is
limited only by the RADIUS packet length limitation.
Implementations MUST be able to handle the case where one
fragmented attribute completely fills the packet.
evs
The "evs" data type encodes an Extended-Vendor-Specific Attribute, as
given in [RFC6929], Section 2.4. The "evs" data type is used solely
to extend the vendor-specific space. It MAY appear inside of an
"extended" data type or a "long-extended" data type. It MUST NOT
appear in the contents of any other data type.
Where an implementation determines that an attribute of data type
"evs" contains data that does not match the expected format, it
SHOULD treat that attribute as being an invalid attribute.
Name
evs
Value
17
Length
Six or more octets
Format
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-Type | EVS-Data ....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Subfields
Vendor-Id
The 4 octets are the Network Management Private Enterprise Code
[PEN] of the vendor in network byte order.
Vendor-Type
The Vendor-Type field is one octet. Values are assigned at the
sole discretion of the vendor.
EVS-Data
The EVS-Data field is one or more octets. It SHOULD
encapsulate a previously defined RADIUS data type.
Non-standard data types SHOULD NOT be used. We note that the
EVS-Data field may be of data type "tlv".
The actual format of the information is site specific or
application specific, and a robust implementation SHOULD
support the field as undistinguished octets. We recognize that
vendors have complete control over the contents and format of
the Ext-Data field; at the same time, we recommend that good
practices be followed.
Further codification of the range of allowed usage of this
field is outside the scope of this specification.This RFC states clear data types and tries to ensure those to be uniform, so there is no confusing what string, text and etc are Looking at this RFC, looks like I may need to ensure dictionary.rs is all good for old data types (defined in the first RADIUS RFCs)
MikhailMS
commented
3 years ago In RFC 8045
Defines a number of new attributes, not sure anything should be added to library from this RFC
MikhailMS
commented
3 years ago In RFC 8559
Talks about Proxying CoA requests in RADIUS system. Nothing to be implemented in this library from this RFC
MikhailMS
commented
3 years ago All RFCs have been looked at, all missing things resolved into new issues, so can close this one :)
There are a number of RFCs describing protocol and standards around it, so it is better to ensure I follow them all (or as many as possible)
Right now, I only took into account (explicitly, but possibly some bits are coming from other RFCs):