RADIUS attributes dictionary
Attributes dictionaries from RFC2865, RFC2866, RFC2868 and Vendor Specific Attributes
Attribute
|
Description
|
Values | Source |
---|---|---|---|
Citrix-UID |
|
citrix | |
Citrix-GID |
|
citrix | |
Citrix-Home |
|
citrix | |
Citrix-Shell |
|
citrix | |
Citrix-Group-Names |
|
citrix | |
Citrix-Group-Ids |
|
citrix | |
Citrix-User-Groups |
|
citrix | |
Dlink-User-Level |
|
User, Operator, Admin ... | dlink |
Dlink-Ingress-Bandwidth-Assignment |
|
dlink | |
Dlink-Egress-Bandwidth-Assignment |
|
dlink | |
Dlink-1p-Priority |
|
dlink | |
Dlink-VLAN-Name |
|
dlink | |
Dlink-VLAN-ID |
|
dlink | |
Dlink-ACL-Profile |
|
dlink | |
Dlink-ACL-Rule |
|
dlink | |
Dlink-ACL-Script |
|
dlink | |
Juniper-Local-User-Name |
|
juniper | |
Juniper-Allow-Commands |
|
juniper | |
Juniper-Deny-Commands |
|
juniper | |
Juniper-Allow-Configuration |
|
juniper | |
Juniper-Deny-Configuration |
|
juniper | |
Juniper-Interactive-Command |
|
juniper | |
Juniper-Configuration-Change |
|
juniper | |
Juniper-User-Permissions |
|
juniper | |
Juniper-Junosspace-Profile |
|
juniper | |
Juniper-CTP-Group |
|
Admin, Privileged_Admin, Auditor ... | juniper |
Juniper-CTPView-APP-Group |
|
Net_Admin, Global_Admin | juniper |
Juniper-CTPView-OS-Group |
|
System_Admin, Auditor | juniper |
Juniper-Primary-Dns |
|
juniper | |
Juniper-Primary-Wins |
|
juniper | |
Juniper-Secondary-Dns |
|
juniper | |
Juniper-Secondary-Wins |
|
juniper | |
Juniper-Interface-id |
|
juniper | |
Juniper-Ip-Pool-Name |
|
juniper | |
Juniper-Keep-Alive |
|
juniper | |
Juniper-CoS-Traffic-Control-Profile |
|
juniper | |
Juniper-CoS-Parameter |
|
juniper | |
Juniper-encapsulation-overhead |
|
juniper | |
Juniper-cell-overhead |
|
juniper | |
Juniper-tx-connect-speed |
|
juniper | |
Juniper-rx-connect-speed |
|
juniper | |
Juniper-Firewall-filter-name |
|
juniper | |
Juniper-Policer-Parameter |
|
juniper | |
Juniper-Local-Group-Name |
|
juniper | |
Juniper-Local-Interface |
|
juniper | |
Juniper-Switching-Filter |
|
juniper | |
Juniper-VoIP-Vlan |
|
juniper | |
Meraki-Device-Name |
|
meraki | |
Meraki-Network-Name |
|
meraki | |
Meraki-Ap-Name |
|
meraki | |
Meraki-Ap-Tags |
|
meraki | |
MS-CHAP-Response |
|
microsoft | |
MS-CHAP-Error |
|
microsoft | |
MS-CHAP-CPW-1 |
|
microsoft | |
MS-CHAP-CPW-2 |
|
microsoft | |
MS-CHAP-LM-Enc-PW |
|
microsoft | |
MS-CHAP-NT-Enc-PW |
|
microsoft | |
MS-MPPE-Encryption-Policy |
|
Encryption-Required | microsoft |
MS-MPPE-Encryption-Type |
|
microsoft | |
MS-MPPE-Encryption-Types |
|
RC4-128bit-Allowed, RC4-40or128-bit-Allowed | microsoft |
MS-RAS-Vendor |
|
microsoft | |
MS-CHAP-Domain |
|
microsoft | |
MS-CHAP-Challenge |
|
microsoft | |
MS-CHAP-MPPE-Keys |
|
microsoft | |
MS-BAP-Usage |
|
Allowed, Required | microsoft |
MS-Link-Utilization-Threshold |
|
microsoft | |
MS-Link-Drop-Time-Limit |
|
microsoft | |
MS-MPPE-Send-Key |
|
microsoft | |
MS-MPPE-Recv-Key |
|
microsoft | |
MS-RAS-Version |
|
microsoft | |
MS-Old-ARAP-Password |
|
microsoft | |
MS-New-ARAP-Password |
|
microsoft | |
MS-ARAP-PW-Change-Reason |
|
Expired-Password, Admin-Requires-Password-Change, Password-Too-Short ... | microsoft |
MS-Filter |
|
microsoft | |
MS-Acct-Auth-Type |
|
CHAP, MS-CHAP-1, MS-CHAP-2 ... | microsoft |
MS-Acct-EAP-Type |
|
OTP, Generic-Token-Card, TLS ... | microsoft |
MS-CHAP2-Response |
|
microsoft | |
MS-CHAP2-Success |
|
microsoft | |
MS-CHAP2-CPW |
|
microsoft | |
MS-Primary-DNS-Server |
|
microsoft | |
MS-Secondary-DNS-Server |
|
microsoft | |
MS-Primary-NBNS-Server |
|
microsoft | |
MS-Secondary-NBNS-Server |
|
microsoft | |
MS-RAS-Client-Name |
MS-RAS-Client-Name is a vendor-specific attribute (VSA).
It is used to specify the name of the endpoint generating a request. The fields of the MS-RAS-Client-Name VSA MUST be set as follows: Vendor-Type: An 8-bit unsigned integer that MUST be set to 0x22 for MS-RAS-Client-Name. Vendor-Length: An 8-bit unsigned integer that MUST be set to 2 added to the length of the Attribute-Specific Value field. Its value MUST be at least 3 and less than 36. Attribute-Specific Value: This field MUST be the machine name of the endpoint that requests network access, sent in ASCII format, and MUST be null terminated. A valid character set includes the symbols ! @ # $ % ^ & ' ) ( . - _ { } ~ in addition to letters and numbers. When the RADIUS server receives this VSA, it MUST search the PolicyConfiguration.RASClientName ADM element for the value of the VSA. If a match is not found, the server SHOULD send an Access-Reject message to the NAS and stop processing. If the clientName parameter of the SendRadiusAccessRequest abstract interface is set to NULL, this attribute MUST NOT be set. Otherwise, the attribute-specific value is obtained by serializing the clientName parameter to the format described above. |
microsoft | |
MS-RAS-Client-Version |
|
microsoft | |
MS-Quarantine-IPFilter |
|
microsoft | |
MS-Quarantine-Session-Timeout |
|
microsoft | |
MS-User-Security-Identity |
If the RADIUS User-Name attribute ( section 5.1) is found in the request, the RADIUS
server MUST ignore this attribute. Otherwise, the RADIUS server SHOULD convert the SID to a Fully Qualified User Name using Active Directory Domain Services (AD DS). Once the Fully Qualified User Name is available, the server MUST follow the same processing rules specified for MS-RAS-Client-Name. If the server fails to obtain the Fully Qualified User Name from AD DS, the server SHOULD send an Access-Reject message back to the NAS and stop processing. Used to specify the security-identifier (SID). A security identifier (SID) uniquely identifies a security principal. Each security principal has a unique SID that is issued by a security agent. The agent can be a Windows local system or domain. The agent generates the SID when the security principal is created. The SID can be represented as a character string or as a structure. When represented as strings, for example in documentation or logs, SIDs are expressed as follows: The fields of MS-User-Security-Identity MUST be set as follows: Vendor-Type: An 8-bit unsigned integer that MUST be set to 0x28 for MS-User-Security-Identity. Vendor-Length: An 8-bit unsigned integer that MUST be set to 2 plus the length of the Attribute-Specific Value field. Its value MUST be at least 3. Attribute-Specific Value: This field MUST contain the account SID of the user requesting access in the format of a binary SID used to authenticate a remote access client. |
microsoft | |
MS-Identity-Type |
|
Ignore-User-Lookup-Failure | microsoft |
MS-Service-Class |
|
microsoft | |
MS-Quarantine-User-Class |
|
microsoft | |
MS-Quarantine-State |
|
Quarantine, Probation | microsoft |
MS-Quarantine-Grace-Time |
|
microsoft | |
MS-Network-Access-Server-Type |
MS-Network-Access-Server-Type is a VSA used to specify the type of the network access server making the request.
The fields of MS-Network-Access-Server-Type MUST be set as follows: Vendor-Type: An 8-bit unsigned integer that MUST be set to 0x2F. Vendor-Length: An 8-bit unsigned integer that MUST be set to 6. Attribute-Specific Value: A 32-bit unsigned integer in network byte order that MUST indicate the type of the NAS. The value MUST be interpreted in accordance with the following table: 0x00000000 Unspecified 0x00000001 Terminal Server Gateway 0x00000002 Remote Access Service (RAS) server (VPN or dial-in) 0x00000003 DHCP server 0x00000005 Health Registration Authority (HRA) 0x00000006 Host Credential Authorization Protocol (HCAP) server All Other Values A tag value used to identify applicable network access policies on the RADIUS server. |
Terminal-Server-Gateway, Remote-Access-Server, DHCP-Server ... | microsoft |
MS-AFW-Zone |
|
MS-AFW-Zone-Unprotected-Policy, MS-AFW-Zone-Protected-Policy | microsoft |
MS-AFW-Protection-Level |
MS-AFW-Protection-Level is a vendor-specific attribute (VSA).
It is used as a hint for dynamic selection of a preconfigured IPsec policy by the endpoint requesting access. The fields of MS-AFW-Protection-Level MUST be set as follows: Vendor-Type: An 8-bit unsigned integer that MUST be set to 0x31. Vendor-Length: An 8-bit unsigned integer that MUST be set to 6. Attribute-Specific Value: A 32-bit unsigned integer in network byte order that MUST indicate the protection level that the RADIUS server authorizes for the endpoint. It MUST be set to one of the following values. 0x00000001 Indicates that the certificate payload specified in the response can be used for signing data. 0x00000002 Indicates that the certificate payload in the HCEP response can be used for signing and encrypting data. |
HECP-Response-Sign-And-Encrypt | microsoft |
MS-Machine-Name |
|
microsoft | |
MS-IPv6-Filter |
|
microsoft | |
MS-IPv4-Remediation-Servers |
|
microsoft | |
MS-IPv6-Remediation-Servers |
|
microsoft | |
MS-RNAP-Not-Quarantine-Capable |
|
SoH-Not-Sent | microsoft |
MS-Quarantine-SOH |
|
microsoft | |
MS-RAS-Correlation |
|
microsoft | |
MS-Extended-Quarantine-State |
When a NAS receives this attribute, it MUST assign the extended Quarantine state specified by this
attribute, to the client requesting access. This attribute is used in NAP scenarios. This attribute further qualifies the level of network access that the RADIUS server authorizes to the endpoint. When a network access server receives this attribute from a RADIUS server in an Access-Accept message, it MAY combine the value of this attribute with the value of MS-Quarantine-State attribute in an implementation specific manner. The MS-Extended-Quarantine-State VSA is used to specify additional information about a restricted access decision by a RADIUS server. The fields of MS-Extended-Quarantine-State MUST be set as follows: Vendor-Type: An 8-bit unsigned integer that MUST be set to 0x39. Vendor-Length: An 8-bit unsigned integer that MUST be set to 6. Attribute-Specific Value: A 32-bit unsigned integer in network-byte order that MUST contain one of the following values. 0x00000000 No data 0x00000001 Transition 0x00000002 Infected 0x00000003 Unknown |
Infected, Unknown, No-Data ... | microsoft |
MS-HCAP-User-Groups |
|
microsoft | |
MS-HCAP-Location-Group-Name |
|
microsoft | |
MS-HCAP-User-Name |
HCAP-User-Name is a VSA used to indicate user identity information received over a
HCAP interface by a RADIUS client. The fields of HCAP-User-Name MUST be set as follows: Vendor-Type: An 8-bit unsigned integer that MUST be set to 0x3C. Vendor-Length: An 8-bit unsigned integer that MUST be set to the length of the Attribute-Specific Value field plus 2. Its value MUST be at least 3. Attribute-Specific Value: An octet string that contains characters from Windows ANSI code page (for more information, see ) and MUST specify the name for the HCAP user (as specified in ). |
microsoft | |
MS-User-IPv4-Address |
|
microsoft | |
MS-User-IPv6-Address |
|
microsoft | |
MS-TSG-Device-Redirection |
|
microsoft | |
Mikrotik-Recv-Limit |
|
mikrotik | |
Mikrotik-Xmit-Limit |
|
mikrotik | |
Mikrotik-Group |
|
mikrotik | |
Mikrotik-Wireless-Forward |
|
mikrotik | |
Mikrotik-Wireless-Skip-Dot1x |
|
mikrotik | |
Mikrotik-Wireless-Enc-Algo |
|
40-bit-WEP, 104-bit-WEP, AES-CCM ... | mikrotik |
Mikrotik-Wireless-Enc-Key |
|
mikrotik | |
Mikrotik-Rate-Limit |
|
mikrotik | |
Mikrotik-Realm |
|
mikrotik | |
Mikrotik-Host-IP |
|
mikrotik | |
Mikrotik-Mark-Id |
|
mikrotik | |
Mikrotik-Advertise-URL |
|
mikrotik | |
Mikrotik-Advertise-Interval |
|
mikrotik | |
Mikrotik-Recv-Limit-Gigawords |
|
mikrotik | |
Mikrotik-Xmit-Limit-Gigawords |
|
mikrotik | |
Mikrotik-Wireless-PSK |
|
mikrotik | |
Mikrotik-Total-Limit |
|
mikrotik | |
Mikrotik-Total-Limit-Gigawords |
|
mikrotik | |
Mikrotik-Address-List |
|
mikrotik | |
Mikrotik-Wireless-MPKey |
|
mikrotik | |
Mikrotik-Wireless-Comment |
|
mikrotik | |
Mikrotik-Delegated-IPv6-Pool |
|
mikrotik | |
Mikrotik-DHCP-Option-Set |
|
mikrotik | |
Mikrotik-DHCP-Option-Param-STR1 |
|
mikrotik | |
Mikrotik-DHCP-Option-ParamSTR2 |
|
mikrotik | |
Mikrotik-Wireless-VLANID |
|
mikrotik | |
Mikrotik-Wireless-VLANID-Type |
|
802.1ad | mikrotik |
Mikrotik-Wireless-Minsignal |
|
mikrotik | |
Mikrotik-Wireless-Maxsignal |
|
mikrotik | |
pfSense-Bandwidth-Max-Up |
|
pfsense | |
pfSense-Bandwidth-Max-Down |
|
pfsense | |
pfSense-Max-Total-Octets |
|
pfsense | |
User-Name |
This Attribute indicates the name of the user to be authenticated.
It MUST be sent in Access-Request packets if available. It MAY be sent in an Access-Accept packet, in which case the client SHOULD use the name returned in the Access-Accept packet in all Accounting-Request packets for this session. If the Access- Accept includes Service-Type = Rlogin and the User-Name attribute, a NAS MAY use the returned User-Name when performing the Rlogin function. A summary of the User-Name 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- | Type | Length | String ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Type 1 for User-Name. Length >= 3 String The String field is one or more octets. The NAS may limit the maximum length of the User-Name but the ability to handle at least 63 octets is recommended. The format of the username MAY be one of several forms: text Consisting only of UTF-8 encoded 10646 characters. network access identifier A Network Access Identifier as described in. distinguished name A name in ASN.1 form used in Public Key authentication systems. |
rfc2865 | |
User-Password |
This Attribute indicates the password of the user to be
authenticated, or the user's input following an Access-Challenge. It is only used in Access-Request packets. On transmission, the password is hidden. The password is first padded at the end with nulls to a multiple of 16 octets. A one- way MD5 hash is calculated over a stream of octets consisting of the shared secret followed by the Request Authenticator. This value is XORed with the first 16 octet segment of the password and placed in the first 16 octets of the String field of the User- Password Attribute. If the password is longer than 16 characters, a second one-way MD5 hash is calculated over a stream of octets consisting of the shared secret followed by the result of the first xor. That hash is XORed with the second 16 octet segment of the password and placed in the second 16 octets of the String field of the User- Password Attribute. If necessary, this operation is repeated, with each xor result being used along with the shared secret to generate the next hash to xor the next segment of the password, to no more than 128 characters. The method is taken from the book "Network Security" by Kaufman, Perlman and Speciner pages 109-110. A more precise explanation of the method follows: Call the shared secret S and the pseudo-random 128-bit Request Authenticator RA. Break the password into 16-octet chunks p1, p2, etc. with the last one padded at the end with nulls to a 16-octet boundary. Call the ciphertext blocks c(1), c(2), etc. We'll need intermediate values b1, b2, etc. b1 = MD5(S + RA) c(1) = p1 xor b1 b2 = MD5(S + c(1)) c(2) = p2 xor b2 . . . . . . bi = MD5(S + c(i-1)) c(i) = pi xor bi The String will contain c(1)+c(2)+...+c(i) where + denotes concatenation.On receipt, the process is reversed to yield the original password. A summary of the User-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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- | Type | Length | String ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Type 2 for User-Password. Length At least 18 and no larger than 130. String The String field is between 16 and 128 octets long, inclusive. |
rfc2865 | |
CHAP-Password |
This Attribute indicates the response value provided by a PPP
Challenge-Handshake Authentication Protocol (CHAP) user in response to the challenge. It is only used in Access-Request packets. The CHAP challenge value is found in the CHAP-Challenge Attribute (60) if present in the packet, otherwise in the Request Authenticator field. 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. |
rfc2865 | |
NAS-IP-Address |
This Attribute indicates the identifying IP Address of the NAS
which is requesting authentication of the user, and SHOULD be unique to the NAS within the scope of the RADIUS server. NAS-IP- Address is only used in Access-Request packets. Either NAS-IP- Address or NAS-Identifier MUST be present in an Access-Request packet. Note that NAS-IP-Address MUST NOT be used to select the shared secret used to authenticate the request. The source IP address of the Access-Request packet MUST be used to select the shared secret. A summary of the NAS-IP-Address 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 | Address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Address (cont) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 4 for NAS-IP-Address.Length 6 Address The Address field is four octets. |
rfc2865 | |
NAS-Port |
This Attribute indicates the physical port number of the NAS which
is authenticating the user. It is only used in Access-Request packets. Note that this is using "port" in its sense of a physical connection on the NAS, not in the sense of a TCP or UDP port number. Either NAS-Port or NAS-Port-Type (61) or both SHOULD be present in an Access-Request packet, if the NAS differentiates among its ports. A summary of the NAS-Port 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 | Value +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Value (cont) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 5 for NAS-Port. Length 6 Value The Value field is four octets. |
rfc2865 | |
Service-Type |
This Attribute indicates the type of service the user has
requested, or the type of service to be provided. It MAY be used in both Access-Request and Access-Accept packets. A NAS is not required to implement all of these service types, and MUST treat unknown or unsupported Service-Types as though an Access-Reject had been received instead. A summary of the Service-Type 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 | Value +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Value (cont) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 6 for Service-Type. Length 6 Value The Value field is four octets. 1 Login 2 Framed 3 Callback Login 4 Callback Framed 5 Outbound 6 Administrative 7 NAS Prompt 8 Authenticate Only 9 Callback NAS Prompt 10 Call Check 11 Callback AdministrativeThe service types are defined as follows when used in an Access- Accept. When used in an Access-Request, they MAY be considered to be a hint to the RADIUS server that the NAS has reason to believe the user would prefer the kind of service indicated, but the server is not required to honor the hint. Login The user should be connected to a host. Framed A Framed Protocol should be started for the User, such as PPP or SLIP. Callback Login The user should be disconnected and called back, then connected to a host. Callback Framed The user should be disconnected and called back, then a Framed Protocol should be started for the User, such as PPP or SLIP. Outbound The user should be granted access to outgoing devices. Administrative The user should be granted access to the administrative interface to the NAS from which privileged commands can be executed. NAS Prompt The user should be provided a command prompt on the NAS from which non-privileged commands can be executed. Authenticate Only Only Authentication is requested, and no authorization information needs to be returned in the Access-Accept (typically used by proxy servers rather than the NAS itself). Callback NAS Prompt The user should be disconnected and called back, then provided a command prompt on the NAS from which non-privileged commands can be executed. Call Check Used by the NAS in an Access-Request packet to indicate that a call is being received and that the RADIUS server should send back an Access-Accept to answer the call, or an Access-Reject to not accept the call, typically based on the Called-Station-Id or Calling-Station-Id attributes. It isrecommended that such Access-Requests use the value of Calling-Station-Id as the value of the User-Name. Callback Administrative The user should be disconnected and called back, then granted access to the administrative interface to the NAS from which privileged commands can be executed. |
Framed-User, Callback-Login-User, Callback-Framed-User ... | rfc2865 |
Framed-Protocol |
This Attribute indicates the framing to be used for framed access.
It MAY be used in both Access-Request and Access-Accept packets. A summary of the Framed-Protocol 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 | Value +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Value (cont) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 7 for Framed-Protocol. Length 6 Value The Value field is four octets. 1 PPP 2 SLIP 3 AppleTalk Remote Access Protocol (ARAP) 4 Gandalf proprietary SingleLink/MultiLink protocol 5 Xylogics proprietary IPX/SLIP 6 X.75 Synchronous |
SLIP, ARAP, Gandalf-SLML ... | rfc2865 |
Framed-IP-Address |
This Attribute indicates the address to be configured for the
user. It MAY be used in Access-Accept packets. It MAY be used in an Access-Request packet as a hint by the NAS to the server that it would prefer that address, but the server is not required to honor the hint. A summary of the Framed-IP-Address 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 | Address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Address (cont) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 8 for Framed-IP-Address. Length 6 Address The Address field is four octets. The value 0xFFFFFFFF indicates that the NAS Should allow the user to select an address (e.g. Negotiated). The value 0xFFFFFFFE indicates that the NAS should select an address for the user (e.g. Assigned from a pool of addresses kept by the NAS). Other valid values indicate that the NAS should use that value as the user's IP address. |
rfc2865 | |
Framed-IP-Netmask |
This Attribute indicates the IP netmask to be configured for the
user when the user is a router to a network. It MAY be used in Access-Accept packets. It MAY be used in an Access-Request packet as a hint by the NAS to the server that it would prefer that netmask, but the server is not required to honor the hint.A summary of the Framed-IP-Netmask 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 | Address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Address (cont) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 9 for Framed-IP-Netmask. Length 6 Address The Address field is four octets specifying the IP netmask of the user. |
rfc2865 | |
Framed-Routing |
This Attribute indicates the routing method for the user, when the
user is a router to a network. It is only used in Access-Accept packets. A summary of the Framed-Routing 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 | Value +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Value (cont) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 10 for Framed-Routing.Length 6 Value The Value field is four octets. 0 None 1 Send routing packets 2 Listen for routing packets 3 Send and Listen |
Broadcast, Listen, Broadcast-Listen ... | rfc2865 |
Filter-Id |
This Attribute indicates the name of the filter list for this
user. Zero or more Filter-Id attributes MAY be sent in an Access-Accept packet. Identifying a filter list by name allows the filter to be used on different NASes without regard to filter-list implementation details. A summary of the Filter-Id 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- | Type | Length | Text ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Type 11 for Filter-Id. Length >= 3 Text The Text field is one or more octets, and its contents are implementation dependent. It is intended to be human readable and MUST NOT affect operation of the protocol. It is recommended that the message contain UTF-8 encoded 10646 characters. |
rfc2865 | |
Framed-MTU |
This Attribute indicates the Maximum Transmission Unit to be
configured for the user, when it is not negotiated by some other means (such as PPP). It MAY be used in Access-Accept packets. It MAY be used in an Access-Request packet as a hint by the NAS to the server that it would prefer that value, but the server is not required to honor the hint. A summary of the Framed-MTU 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 | Value +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Value (cont) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 12 for Framed-MTU. Length 6 Value The Value field is four octets. Despite the size of the field, values range from 64 to 65535. |
rfc2865 | |
Framed-Compression |
This Attribute indicates a compression protocol to be used for the
link. It MAY be used in Access-Accept packets. It MAY be used in an Access-Request packet as a hint to the server that the NAS would prefer to use that compression, but the server is not required to honor the hint. More than one compression protocol Attribute MAY be sent. It is the responsibility of the NAS to apply the proper compression protocol to appropriate link traffic.A summary of the Framed-Compression 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 | Value +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Value (cont) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 13 for Framed-Compression. Length 6 Value The Value field is four octets. 0 None 1 VJ TCP/IP header compression 2 IPX header compression 3 Stac-LZS compression |
Van-Jacobson-TCP-IP, IPX-Header-Compression, Stac-LZS ... | rfc2865 |
Login-IP-Host |
This Attribute indicates the system with which to connect the user,
when the Login-Service Attribute is included. It MAY be used in Access-Accept packets. It MAY be used in an Access-Request packet as a hint to the server that the NAS would prefer to use that host, but the server is not required to honor the hint. A summary of the Login-IP-Host 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 | Address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Address (cont) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 14 for Login-IP-Host. Length 6 Address The Address field is four octets. The value 0xFFFFFFFF indicates that the NAS SHOULD allow the user to select an address. The value 0 indicates that the NAS SHOULD select a host to connect the user to. Other values indicate the address the NAS SHOULD connect the user to. |
rfc2865 | |
Login-Service |
This Attribute indicates the service to use to connect the user to
the login host. It is only used in Access-Accept packets. A summary of the Login-Service 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 | Value +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Value (cont) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 15 for Login-Service.Length 6 Value The Value field is four octets. 0 Telnet 1 Rlogin 2 TCP Clear 3 PortMaster (proprietary) 4 LAT 5 X25-PAD 6 X25-T3POS 8 TCP Clear Quiet (suppresses any NAS-generated connect string) |
Rlogin, TCP-Clear, PortMaster ... | rfc2865 |
Login-TCP-Port |
This Attribute indicates the TCP port with which the user is to be
connected, when the Login-Service Attribute is also present. It is only used in Access-Accept packets. A summary of the Login-TCP-Port 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 | Value +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Value (cont) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 16 for Login-TCP-Port. Length 6 Value The Value field is four octets. Despite the size of the field, values range from 0 to 65535. |
Rlogin, Rsh | rfc2865 |
Reply-Message |
This Attribute indicates text which MAY be displayed to the user.
When used in an Access-Accept, it is the success message. When used in an Access-Reject, it is the failure message. It MAY indicate a dialog message to prompt the user before another Access-Request attempt. When used in an Access-Challenge, it MAY indicate a dialog message to prompt the user for a response. Multiple Reply-Message's MAY be included and if any are displayed, they MUST be displayed in the same order as they appear in the packet. A summary of the Reply-Message 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- | Type | Length | Text ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Type 18 for Reply-Message. Length >= 3 Text The Text field is one or more octets, and its contents are implementation dependent. It is intended to be human readable, and MUST NOT affect operation of the protocol. It is recommended that the message contain UTF-8 encoded 10646 characters. |
rfc2865 | |
Callback-Number |
This Attribute indicates a dialing string to be used for callback.
It MAY be used in Access-Accept packets. It MAY be used in an Access-Request packet as a hint to the server that a Callback service is desired, but the server is not required to honor the hint. A summary of the Callback-Number 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- | Type | Length | String ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Type 19 for Callback-Number. Length >= 3 String The String field is one or more octets. The actual format of the information is site 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. |
rfc2865 | |
Callback-Id |
This Attribute indicates the name of a place to be called, to be
interpreted by the NAS. It MAY be used in Access-Accept packets.A summary of the Callback-Id 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- | Type | Length | String ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Type 20 for Callback-Id. Length >= 3 String The String field is one or more octets. The actual format of the information is site 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. |
rfc2865 | |
Framed-Route |
This Attribute provides routing information to be configured for
the user on the NAS. It is used in the Access-Accept packet and can appear multiple times. A summary of the Framed-Route 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- | Type | Length | Text ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-Type 22 for Framed-Route. Length >= 3 Text The Text field is one or more octets, and its contents are implementation dependent. It is intended to be human readable and MUST NOT affect operation of the protocol. It is recommended that the message contain UTF-8 encoded 10646 characters. For IP routes, it SHOULD contain a destination prefix in dotted quad form optionally followed by a slash and a decimal length specifier stating how many high order bits of the prefix to use. That is followed by a space, a gateway address in dotted quad form, a space, and one or more metrics separated by spaces. For example, "192.168.1.0/24 192.168.1.1 1 2 -1 3 400". The length specifier may be omitted, in which case it defaults to 8 bits for class A prefixes, 16 bits for class B prefixes, and 24 bits for class C prefixes. For example, "192.168.1.0 192.168.1.1 1". Whenever the gateway address is specified as "0.0.0.0" the IP address of the user SHOULD be used as the gateway address. |
rfc2865 | |
Framed-IPX-Network |
This Attribute indicates the IPX Network number to be configured
for the user. It is used in Access-Accept packets. A summary of the Framed-IPX-Network 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 | Value +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Value (cont) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Type 23 for Framed-IPX-Network. Length 6 Value The Value field is four octets. The value 0xFFFFFFFE indicates that the NAS should select an IPX network for the user (e.g. assigned from a pool of one or more IPX networks kept by the NAS). Other values should be used as the IPX network for the link to the user. |
rfc2865 | |
State |
This Attribute is available to be sent by the server to the client
in an Access-Challenge and MUST be sent unmodified from the client to the server in the new Access-Request reply to that challenge, if any. This Attribute is available to be sent by the server to the client in an Access-Accept that also includes a Termination-Action Attribute with the value of RADIUS-Request. If the NAS performs the Termination-Action by sending a new Access-Request upon termination of the current session, it MUST include the State attribute unchanged in that Access-Request. In either usage, the client MUST NOT interpret the attribute locally. A packet must have only zero or one State Attribute. Usage of the State Attribute is implementation dependent. A summary of the State 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- | Type | Length | String ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Type 24 for State.Length >= 3 String The String field is one or more octets. The actual format of the information is site 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. |
rfc2865 | |
Class |
This Attribute is available to be sent by the server to the client
in an Access-Accept and SHOULD be sent unmodified by the client to the accounting server as part of the Accounting-Request packet if accounting is supported. The client MUST NOT interpret the attribute locally. A summary of the Class 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- | Type | Length | String ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Type 25 for Class. Length >= 3 String The String field is one or more octets. The actual format of the information is site 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. |
rfc2865 | |
Vendor-Specific |
This Attribute is available to allow vendors to support their own
extended Attributes not suitable for general usage. It MUST not affect the operation of the RADIUS protocol. Servers not equipped to interpret the vendor-specific information sent by a client MUST ignore it (although it may be reported). Clients which do not receive desired vendor-specific information SHOULD make an attempt to operate without it, although they may do so (and report they are doing so) in a degraded mode. A summary of the Vendor-Specific 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 | Vendor-Id +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Vendor-Id (cont) | String... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Type 26 for Vendor-Specific. Length >= 7 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" RFC . String The String field is one or more octets. The actual format of the information is site 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.It SHOULD be encoded as a sequence of vendor type / vendor length / value fields, as follows. The Attribute-Specific field is dependent on the vendor's definition of that attribute. An example encoding of the Vendor-Specific attribute using this method follows: 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. |
rfc2865 | |
Session-Timeout |
This Attribute sets the maximum number of seconds of service to be
provided to the user before termination of the session or prompt. This Attribute is available to be sent by the server to the client in an Access-Accept or Access-Challenge. A summary of the Session-Timeout 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 | Value +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Value (cont) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 27 for Session-Timeout. Length 6Value The field is 4 octets, containing a 32-bit unsigned integer with the maximum number of seconds this user should be allowed to remain connected by the NAS. |
rfc2865 | |
Idle-Timeout |
This Attribute sets the maximum number of consecutive seconds of
idle connection allowed to the user before termination of the session or prompt. This Attribute is available to be sent by the server to the client in an Access-Accept or Access-Challenge. A summary of the Idle-Timeout 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 | Value +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Value (cont) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 28 for Idle-Timeout. Length 6 Value The field is 4 octets, containing a 32-bit unsigned integer with the maximum number of consecutive seconds of idle time this user should be permitted before being disconnected by the NAS. |
rfc2865 | |
Termination-Action |
This Attribute indicates what action the NAS should take when the
specified service is completed. It is only used in Access-Accept packets.A summary of the Termination-Action 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 | Value +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Value (cont) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 29 for Termination-Action. Length 6 Value The Value field is four octets. 0 Default 1 RADIUS-Request If the Value is set to RADIUS-Request, upon termination of the specified service the NAS MAY send a new Access-Request to the RADIUS server, including the State attribute if any. |
RADIUS-Request | rfc2865 |
Called-Station-Id |
This Attribute allows the NAS to send in the Access-Request packet
the phone number that the user called, using Dialed Number Identification (DNIS) or similar technology. Note that this may be different from the phone number the call comes in on. It is only used in Access-Request packets. A summary of the Called-Station-Id 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- | Type | Length | String ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-Type 30 for Called-Station-Id. Length >= 3 String The String field is one or more octets, containing the phone number that the user's call came in on. The actual format of the information is site or application specific. UTF-8 encoded 10646 characters are recommended, but 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. |
rfc2865 | |
Calling-Station-Id |
The Calling-Station-Id attribute (Type value 31) is of type String.
When used within PMIPv6 deployments, the attribute contains the MN Link-Layer Identifier option of the MN as defined in , Sectionsand. |
rfc2865 | |
NAS-Identifier |
This Attribute contains a string identifying the NAS originating
the Access-Request. It is only used in Access-Request packets. Either NAS-IP-Address or NAS-Identifier MUST be present in an Access-Request packet. Note that NAS-Identifier MUST NOT be used to select the shared secret used to authenticate the request. The source IP address of the Access-Request packet MUST be used to select the shared secret. A summary of the NAS-Identifier 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- | Type | Length | String ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Type 32 for NAS-Identifier. Length >= 3String The String field is one or more octets, and should be unique to the NAS within the scope of the RADIUS server. For example, a fully qualified domain name would be suitable as a NAS-Identifier. The actual format of the information is site 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. |
rfc2865 | |
Proxy-State |
This Attribute is available to be sent by a proxy server to
another server when forwarding an Access-Request and MUST be returned unmodified in the Access-Accept, Access-Reject or Access-Challenge. When the proxy server receives the response to its request, it MUST remove its own Proxy-State (the last Proxy- State in the packet) before forwarding the response to the NAS. If a Proxy-State Attribute is added to a packet when forwarding the packet, the Proxy-State Attribute MUST be added after any existing Proxy-State attributes. The content of any Proxy-State other than the one added by the current server should be treated as opaque octets and MUST NOT affect operation of the protocol. Usage of the Proxy-State Attribute is implementation dependent. A description of its function is outside the scope of this specification. A summary of the Proxy-State 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- | Type | Length | String ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Type 33 for Proxy-State.Length >= 3 String The String field is one or more octets. The actual format of the information is site 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. |
rfc2865 | |
Login-LAT-Service |
This Attribute indicates the system with which the user is to be
connected by LAT. It MAY be used in Access-Accept packets, but only when LAT is specified as the Login-Service. It MAY be used in an Access-Request packet as a hint to the server, but the server is not required to honor the hint. Administrators use the service attribute when dealing with clustered systems, such as a VAX or Alpha cluster. In such an environment several different time sharing hosts share the same resources (disks, printers, etc.), and administrators often configure each to offer access (service) to each of the shared resources. In this case, each host in the cluster advertises its services through LAT broadcasts. Sophisticated users often know which service providers (machines) are faster and tend to use a node name when initiating a LAT connection. Alternately, some administrators want particular users to use certain machines as a primitive form of load balancing (although LAT knows how to do load balancing itself). A summary of the Login-LAT-Service 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- | Type | Length | String ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-Type 34 for Login-LAT-Service. Length >= 3 String The String field is one or more octets, and contains the identity of the LAT service to use. The LAT Architecture allows this string to contain $ (dollar), - (hyphen), . (period), _ (underscore), numerics, upper and lower case alphabetics, and the ISO Latin-1 character set extension . All LAT string comparisons are case insensitive. |
rfc2865 | |
Login-LAT-Node |
This Attribute indicates the Node with which the user is to be
automatically connected by LAT. It MAY be used in Access-Accept packets, but only when LAT is specified as the Login-Service. It MAY be used in an Access-Request packet as a hint to the server, but the server is not required to honor the hint. A summary of the Login-LAT-Node 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- | Type | Length | String ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Type 35 for Login-LAT-Node. Length >= 3String The String field is one or more octets, and contains the identity of the LAT Node to connect the user to. The LAT Architecture allows this string to contain $ (dollar), - (hyphen), . (period), _ (underscore), numerics, upper and lower case alphabetics, and the ISO Latin-1 character set extension. All LAT string comparisons are case insensitive. |
rfc2865 | |
Login-LAT-Group |
This Attribute contains a string identifying the LAT group codes
which this user is authorized to use. It MAY be used in Access- Accept packets, but only when LAT is specified as the Login- Service. It MAY be used in an Access-Request packet as a hint to the server, but the server is not required to honor the hint. LAT supports 256 different group codes, which LAT uses as a form of access rights. LAT encodes the group codes as a 256 bit bitmap. Administrators can assign one or more of the group code bits at the LAT service provider; it will only accept LAT connections that have these group codes set in the bit map. The administrators assign a bitmap of authorized group codes to each user; LAT gets these from the operating system, and uses these in its requests to the service providers. A summary of the Login-LAT-Group 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- | Type | Length | String ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Type 36 for Login-LAT-Group. Length 34String The String field is a 32 octet bit map, most significant octet first. 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. |
rfc2865 | |
Framed-AppleTalk-Link |
This Attribute indicates the AppleTalk network number which should
be used for the serial link to the user, which is another AppleTalk router. It is only used in Access-Accept packets. It is never used when the user is not another router. A summary of the Framed-AppleTalk-Link 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 | Value +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Value (cont) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 37 for Framed-AppleTalk-Link. Length 6 Value The Value field is four octets. Despite the size of the field, values range from 0 to 65535. The special value of 0 indicates that this is an unnumbered serial link. A value of 1-65535 means that the serial line between the NAS and the user should be assigned that value as an AppleTalk network number. |
rfc2865 | |
Framed-AppleTalk-Network |
This Attribute indicates the AppleTalk Network number which the
NAS should probe to allocate an AppleTalk node for the user. It is only used in Access-Accept packets. It is never used when the user is another router. Multiple instances of this Attribute indicate that the NAS may probe using any of the network numbers specified. A summary of the Framed-AppleTalk-Network 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 | Value +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Value (cont) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 38 for Framed-AppleTalk-Network. Length 6 Value The Value field is four octets. Despite the size of the field, values range from 0 to 65535. The special value 0 indicates that the NAS should assign a network for the user, using its default cable range. A value between 1 and 65535 (inclusive) indicates the AppleTalk Network the NAS should probe to find an address for the user. |
rfc2865 | |
Framed-AppleTalk-Zone |
This Attribute indicates the AppleTalk Default Zone to be used for
this user. It is only used in Access-Accept packets. Multiple instances of this attribute in the same packet are not allowed.A summary of the Framed-AppleTalk-Zone 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- | Type | Length | String ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Type 39 for Framed-AppleTalk-Zone. Length >= 3 String The name of the Default AppleTalk Zone to be used for this user. 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. |
rfc2865 | |
CHAP-Challenge |
This Attribute contains the CHAP Challenge sent by the NAS to a
PPP Challenge-Handshake Authentication Protocol (CHAP) user. It is only used in Access-Request packets. If the CHAP challenge value is 16 octets long it MAY be placed in the Request Authenticator field instead of using this attribute. A summary of the CHAP-Challenge 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- | Type | Length | String... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-Type 60 for CHAP-Challenge. Length >= 7 String The String field contains the CHAP Challenge. |
rfc2865 | |
NAS-Port-Type |
This Attribute indicates the type of the physical port of the NAS
which is authenticating the user. It can be used instead of or in addition to the NAS-Port (5) attribute. It is only used in Access-Request packets. Either NAS-Port (5) or NAS-Port-Type or both SHOULD be present in an Access-Request packet, if the NAS differentiates among its ports. A summary of the NAS-Port-Type 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 | Value +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Value (cont) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 61 for NAS-Port-Type. Length 6 Value The Value field is four octets. "Virtual" refers to a connection to the NAS via some transport protocol, instead of through a physical port. For example, if a user telnetted into a NAS toauthenticate himself as an Outbound-User, the Access-Request might include NAS-Port-Type = Virtual as a hint to the RADIUS server that the user was not on a physical port. 0 Async 1 Sync 2 ISDN Sync 3 ISDN Async V.120 4 ISDN Async V.110 5 Virtual 6 PIAFS 7 HDLC Clear Channel 8 X.25 9 X.75 10 G.3 Fax 11 SDSL - Symmetric DSL 12 ADSL-CAP - Asymmetric DSL, Carrierless Amplitude Phase Modulation 13 ADSL-DMT - Asymmetric DSL, Discrete Multi-Tone 14 IDSL - ISDN Digital Subscriber Line 15 Ethernet 16 xDSL - Digital Subscriber Line of unknown type 17 Cable 18 Wireless - Other 19 Wireless - IEEE 802.11 PIAFS is a form of wireless ISDN commonly used in Japan, and stands for PHS (Personal Handyphone System) Internet Access Forum Standard (PIAFS). |
Sync, ISDN, ISDN-V120 ... | rfc2865 |
Port-Limit |
This Attribute sets the maximum number of ports to be provided to
the user by the NAS. This Attribute MAY be sent by the server to the client in an Access-Accept packet. It is intended for use in conjunction with Multilink PPP or similar uses. It MAY also be sent by the NAS to the server as a hint that that many ports are desired for use, but the server is not required to honor the hint. A summary of the Port-Limit 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 | Value +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Value (cont) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 62 for Port-Limit. Length 6 Value The field is 4 octets, containing a 32-bit unsigned integer with the maximum number of ports this user should be allowed to connect to on the NAS. |
rfc2865 | |
Login-LAT-Port |
This Attribute indicates the Port with which the user is to be
connected by LAT. It MAY be used in Access-Accept packets, but only when LAT is specified as the Login-Service. It MAY be used in an Access-Request packet as a hint to the server, but the server is not required to honor the hint. A summary of the Login-LAT-Port 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- | Type | Length | String ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Type 63 for Login-LAT-Port. Length >= 3String The String field is one or more octets, and contains the identity of the LAT port to use. The LAT Architecture allows this string to contain $ (dollar), - (hyphen), . (period), _ (underscore), numerics, upper and lower case alphabetics, and the ISO Latin-1 character set extension. All LAT string comparisons are case insensitive. |
rfc2865 | |
Acct-Status-Type |
This attribute indicates whether this Accounting-Request marks the
beginning of the user service (Start) or the end (Stop). It MAY be used by the client to mark the start of accounting (for example, upon booting) by specifying Accounting-On and to mark the end of accounting (for example, just before a scheduled reboot) by specifying Accounting-Off. A summary of the Acct-Status-Type 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 | Value +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Value (cont) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Type 40 for Acct-Status-Type. Length 6 Value The Value field is four octets. 1 Start 2 Stop 3 Interim-Update 7 Accounting-On 8 Accounting-Off 9-14 Reserved for Tunnel Accounting 15 Reserved for Failed |
Stop, Alive, Interim-Update ... | rfc2866 |
Acct-Delay-Time |
This attribute indicates how many seconds the client has been
trying to send this record for, and can be subtracted from the time of arrival on the server to find the approximate time of the event generating this Accounting-Request. (Network transit time is ignored.) Note that changing the Acct-Delay-Time causes the Identifier to change; see the discussion under Identifier above. A summary of the Acct-Delay-Time 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 | Value +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Value (cont) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Type 41 for Acct-Delay-Time. Length 6 Value The Value field is four octets. |
rfc2866 | |
Acct-Input-Octets |
This attribute indicates how many octets have been received from
the port over the course of this service being provided, and can only be present in Accounting-Request records where the Acct- Status-Type is set to Stop. A summary of the Acct-Input-Octets 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 | Value +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Value (cont) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 42 for Acct-Input-Octets. Length 6 Value The Value field is four octets. |
rfc2866 | |
Acct-Output-Octets |
This attribute indicates how many octets have been sent to the
port in the course of delivering this service, and can only be present in Accounting-Request records where the Acct-Status-Type is set to Stop. A summary of the Acct-Output-Octets 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 | Value +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Value (cont) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 43 for Acct-Output-Octets. Length 6 Value The Value field is four octets. |
rfc2866 | |
Acct-Session-Id |
This attribute is a unique Accounting ID to make it easy to match
start and stop records in a log file. The start and stop records for a given session MUST have the same Acct-Session-Id. An Accounting-Request packet MUST have an Acct-Session-Id. An Access-Request packet MAY have an Acct-Session-Id; if it does, then the NAS MUST use the same Acct-Session-Id in the Accounting- Request packets for that session. The Acct-Session-Id SHOULD contain UTF-8 encoded 10646 characters.For example, one implementation uses a string with an 8-digit upper case hexadecimal number, the first two digits increment on each reboot (wrapping every 256 reboots) and the next 6 digits counting from 0 for the first person logging in after a reboot up to 2^24-1, about 16 million. Other encodings are possible. A summary of the Acct-Session-Id 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Text ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 44 for Acct-Session-Id. Length >= 3 String The String field SHOULD be a string of UTF-8 encoded 10646 characters. |
rfc2866 | |
Acct-Authentic |
This attribute MAY be included in an Accounting-Request to
indicate how the user was authenticated, whether by RADIUS, the NAS itself, or another remote authentication protocol. Users who are delivered service without being authenticated SHOULD NOT generate Accounting records. A summary of the Acct-Authentic 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 | Value +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Value (cont) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Type 45 for Acct-Authentic. Length 6 Value The Value field is four octets. 1 RADIUS 2 Local 3 Remote |
Local, Remote, Diameter ... | rfc2866 |
Acct-Session-Time |
This attribute indicates how many seconds the user has received
service for, and can only be present in Accounting-Request records where the Acct-Status-Type is set to Stop. A summary of the Acct-Session-Time 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 | Value +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Value (cont) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 46 for Acct-Session-Time. Length 6 Value The Value field is four octets. |
rfc2866 | |
Acct-Input-Packets |
This attribute indicates how many packets have been received from
the port over the course of this service being provided to a Framed User, and can only be present in Accounting-Request records where the Acct-Status-Type is set to Stop. A summary of the Acct-Input-packets 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 | Value +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Value (cont) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 47 for Acct-Input-Packets. Length 6 Value The Value field is four octets. |
rfc2866 | |
Acct-Output-Packets |
This attribute indicates how many packets have been sent to the
port in the course of delivering this service to a Framed User, and can only be present in Accounting-Request records where the Acct-Status-Type is set to Stop. A summary of the Acct-Output-Packets 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 | Value +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Value (cont) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 48 for Acct-Output-Packets. Length 6 Value The Value field is four octets. |
rfc2866 | |
Acct-Terminate-Cause |
This attribute indicates how the session was terminated, and can
only be present in Accounting-Request records where the Acct- Status-Type is set to Stop. A summary of the Acct-Terminate-Cause 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 | Value +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Value (cont) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Type 49 for Acct-Terminate-Cause Length 6 Value The Value field is four octets, containing an integer specifying the cause of session termination, as follows: 1 User Request 2 Lost Carrier 3 Lost Service 4 Idle Timeout 5 Session Timeout 6 Admin Reset 7 Admin Reboot 8 Port Error 9 NAS Error 10 NAS Request 11 NAS Reboot 12 Port Unneeded 13 Port Preempted 14 Port Suspended 15 Service Unavailable 16 Callback 17 User Error 18 Host Request The termination causes are as follows: User Request User requested termination of service, for example with LCP Terminate or by logging out. Lost Carrier DCD was dropped on the port. Lost Service Service can no longer be provided; for example, user's connection to a host was interrupted. Idle Timeout Idle timer expired. Session Timeout Maximum session length timer expired. Admin Reset Administrator reset the port or session.Admin Reboot Administrator is ending service on the NAS, for example prior to rebooting the NAS. Port Error NAS detected an error on the port which required ending the session. NAS Error NAS detected some error (other than on the port) which required ending the session. NAS Request NAS ended session for a non-error reason not otherwise listed here. NAS Reboot The NAS ended the session in order to reboot non-administratively ("crash"). Port Unneeded NAS ended session because resource usage fell below low-water mark (for example, if a bandwidth-on-demand algorithm decided that the port was no longer needed). Port Preempted NAS ended session in order to allocate the port to a higher priority use. Port Suspended NAS ended session to suspend a virtual session. Service Unavailable NAS was unable to provide requested service. Callback NAS is terminating current session in order to perform callback for a new session. User Error Input from user is in error, causing termination of session. Host Request Login Host terminated session normally. |
Lost-Carrier, Lost-Service, Idle-Timeout ... | rfc2866 |
Acct-Multi-Session-Id |
This attribute is a unique Accounting ID to make it easy to link
together multiple related sessions in a log file. Each session linked together would have a unique Acct-Session-Id but the same Acct-Multi-Session-Id. It is strongly recommended that the Acct- Multi-Session-Id contain UTF-8 encoded 10646 characters. A summary of the Acct-Session-Id 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | String ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 50 for Acct-Multi-Session-Id. Length >= 3 String The String field SHOULD contain UTF-8 encoded 10646 characters. |
rfc2866 | |
Acct-Link-Count |
This attribute gives the count of links which are known to have been
in a given multilink session at the time the accounting record is generated. The NAS MAY include the Acct-Link-Count attribute in any Accounting-Request which might have multiple links. A summary of the Acct-Link-Count attribute format is show 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 | Value +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Value (cont) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Type 51 for Acct-Link-Count. Length 6 Value The Value field is four octets, and contains the number of links seen so far in this Multilink Session. It may be used to make it easier for an accounting server to know when it has all the records for a given Multilink session. When the number of Accounting-Requests received with Acct-Status-Type = Stop and the same Acct-Multi-Session-Id and unique Acct-Session- Id's equals the largest value of Acct-Link-Count seen in those Accounting-Requests, all Stop Accounting-Requests for that Multilink Session have been received. An example showing 8 Accounting-Requests should make things clearer. For clarity only the relevant attributes are shown, but additional attributes containing accounting information will also be present in the Accounting-Request. Multi-Session-Id Session-Id Status-Type Link-Count "10" "10" Start 1 "10" "11" Start 2 "10" "11" Stop 2 "10" "12" Start 3 "10" "13" Start 4 "10" "12" Stop 4 "10" "13" Stop 4 "10" "10" Stop 4 |
rfc2866 | |
Acct-Tunnel-Connection |
This Attribute indicates the identifier assigned to the tunnel
session. It SHOULD be included in Accounting-Request packets which contain an Acct-Status-Type attribute having the value Start, Stop or any of the values described above. This attribute, along with the Tunnel-Client-Endpoint and Tunnel- Server-Endpoint attributes , may be used to provide a means to uniquely identify a tunnel session for auditing purposes. A summary of the Acct-Tunnel-Connection 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | String ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 68 for Acct-Tunnel-Connection Length >= 3 String The format of the identifier represented by the String field depends upon the value of the Tunnel-Type attribute . For example, to fully identify an L2TP tunnel connection, the L2TP Tunnel ID and Call ID might be encoded in this field. The exact encoding of this field is implementation dependent. |
rfc2867 | |
Acct-Tunnel-Packets-Lost |
This Attribute indicates the number of packets lost on a given
link. It SHOULD be included in Accounting-Request packets which contain an Acct-Status-Type attribute having the value Tunnel-Link-Stop.A summary of the Acct-Tunnel-Packets-Lost 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 | Lost +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Lost (cont) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 86 for Acct-Tunnel-Packets-Lost Length 6 Lost The Lost field is 4 octets in length and represents the number of packets lost on the link.5. Table of AttributesThe following table provides a guide to which attributes may be found in Accounting-Request packets. No tunnel attributes should be found in Accounting-Response packets. Request # Attribute 0-1 64 Tunnel-Type 0-1 65 Tunnel-Medium-Type 0-1 66 Tunnel-Client-Endpoint 0-1 67 Tunnel-Server-Endpoint 0-1 68 Acct-Tunnel-Connection 0 69 Tunnel-Password 0-1 81 Tunnel-Private-Group-ID 0-1 82 Tunnel-Assignment-ID 0 83 Tunnel-Preference 0-1 86 Acct-Tunnel-Packets-LostThe following table defines the meaning of the above table entries. 0 This attribute MUST NOT be present in packet. 0+ Zero or more instances of this attribute MAY be present in packet. 0-1 Zero or one instance of this attribute MAY be present in packet.6. Security ConsiderationsBy "sniffing" RADIUS Accounting packets, it might be possible for an eavesdropper to perform a passive analysis of tunnel connections.7. References Rigney, C., "RADIUS Accounting",, June 2000. Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels",,, March 1997. Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M. and I. Goyret, "RADIUS Attributes for Tunnel Protocol Support",, June 2000. Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G. and B. Palter, "Layer Two Tunneling Protocol "L2TP"",, August 1999. Hamzeh, K., Pall, G., Verthein, W., Taarud, J., Little, W. and G. Zorn, "Point-to-Point Tunneling Protocol (PPTP)",, July 1999.8. AcknowledgmentsThanks to Aydin Edguer, Ly Loi, Matt Holdrege and Gurdeep Singh Pall for salient input and review.9. Authors' AddressesQuestions about this memo can be directed to: Glen Zorn Cisco Systems, Inc. 500 108th Avenue N.E., Suite 500 Bellevue, Washington 98004 USA Phone: +1 425 438 8218 FAX: +1 425 438 1848 EMail: [email protected] Dave Mitton Nortel Networks 880 Technology Park Drive Billerica, MA 01821 Phone: +1 978 288 4570 Fax: +1 978 288 3030 EMail: [email protected] Bernard Aboba Microsoft Corporation One Microsoft Way Redmond, Washington 98052 Phone: +1 425 936 6605 Fax: +1 425 936 7329 EMail: [email protected]. Full Copyright StatementCopyright (C) The Internet Society (2000). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Zorn, et al. Informational |
rfc2867 | |
Tunnel-Type |
This Attribute indicates the tunneling protocol(s) to be used (in
the case of a tunnel initiator) or the the tunneling protocol in use (in the case of a tunnel terminator). It MAY be included in Access-Request, Access-Accept and Accounting-Request packets. If the Tunnel-Type Attribute is present in an Access-Request packet sent from a tunnel initiator, it SHOULD be taken as a hint to the RADIUS server as to the tunnelling protocols supported by the tunnel end-point; the RADIUS server MAY ignore the hint, however. A tunnel initiator is not required to implement any of these tunnel types; if a tunnel initiator receives an Access-Accept packet which contains only unknown or unsupported Tunnel-Types, the tunnel initiator MUST behave as though an Access-Reject had been received instead. If the Tunnel-Type Attribute is present in an Access-Request packet sent from a tunnel terminator, it SHOULD be taken to signify the tunnelling protocol in use. In this case, if the RADIUS server determines that the use of the communicated protocol is not authorized, it MAY return an Access-Reject packet. If a tunnel terminator receives an Access-Accept packet which containsone or more Tunnel-Type Attributes, none of which represent the tunneling protocol in use, the tunnel terminator SHOULD behave as though an Access-Reject had been received instead. A summary of the Tunnel-Type 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 | Value +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Value (cont) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 64 for Tunnel-Type Length Always 6. 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 Tag field is unused, it MUST be zero (0x00). Value The Value field is three octets and contains one of the following values, indicating the type of tunnel to be started. 1 Point-to-Point Tunneling Protocol (PPTP) 2 Layer Two Forwarding (L2F) 3 Layer Two Tunneling Protocol (L2TP) 4 Ascend Tunnel Management Protocol (ATMP) 5 Virtual Tunneling Protocol (VTP) 6 IP Authentication Header in the Tunnel-mode (AH) 7 IP-in-IP Encapsulation (IP-IP) 8 Minimal IP-in-IP Encapsulation (MIN-IP-IP) 9 IP Encapsulating Security Payload in the Tunnel-mode (ESP) 10 Generic Route Encapsulation (GRE) 11 Bay Dial Virtual Services (DVS) 12 IP-in-IP Tunneling |
L2F, L2TP, ATMP ... | rfc2868 |
Tunnel-Medium-Type |
The Tunnel-Medium-Type Attribute indicates which transport medium
to use when creating a tunnel for those protocols (such as L2TP) that can operate over multiple transports. It MAY be included in both Access-Request and Access-Accept packets; if it is present in an Access-Request packet, it SHOULD be taken as a hint to the RADIUS server as to the tunnel media supported by the tunnel end- point. The RADIUS server MAY ignore the hint, however. A summary of the Tunnel-Medium-Type Attribute format is given below. The fields are transmitted 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 | Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Value (cont) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 65 for Tunnel-Medium-Type Length 6 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 Tag field is unused, it MUST be zero (0x00). Value The Value field is three octets and contains one of the values listed under "Address Family Numbers" in . For the sake of convenience, a relevant excerpt of this list is reproduced below. 1 IPv4 (IP version 4) 2 IPv6 (IP version 6) 3 NSAP 4 HDLC (8-bit multidrop) 5 BBN 1822 6 802 (includes all 802 media plus Ethernet "canonical format") 7 E.163 (POTS) 8 E.164 (SMDS, Frame Relay, ATM)9 F.69 (Telex) 10 X.121 (X.25, Frame Relay) 11 IPX 12 Appletalk 13 Decnet IV 14 Banyan Vines 15 E.164 with NSAP format subaddress |
IPv4, IPv6, NSAP ... | rfc2868 |
Tunnel-Client-Endpoint |
This Attribute contains the address of the initiator end of the
tunnel. It MAY be included in both Access-Request and Access- Accept packets to indicate the address from which a new tunnel is to be initiated. If the Tunnel-Client-Endpoint Attribute is included in an Access-Request packet, the RADIUS server should take the value as a hint; the server is not obligated to honor the hint, however. This Attribute SHOULD be included in Accounting- Request packets which contain Acct-Status-Type attributes with values of either Start or Stop, in which case it indicates the address from which the tunnel was initiated. This Attribute, along with the Tunnel-Server-Endpoint and Acct-Tunnel-Connection- ID attributes, may be used to provide a globally unique means to identify a tunnel for accounting and auditing purposes. A summary of the Tunnel-Client-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 66 for Tunnel-Client-Endpoint. Length >= 3Tag 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. If Tunnel-Medium-Type is IPv6 (2), then this string is either the FQDN of the tunnel client machine, or it is a text representation of the address in either the preferred or alternate form . Conformant implementations MUST support the preferred form and SHOULD support both the alternate text form and the FQDN format for IPv6 addresses. If Tunnel-Medium-Type is neither IPv4 nor IPv6, this string is a tag referring to configuration data local to the RADIUS client that describes the interface and medium-specific address to use. |
rfc2868 | |
Tunnel-Server-Endpoint |
This Attribute indicates the address of the server end of the
tunnel. The Tunnel-Server-Endpoint Attribute MAY be included (as a hint to the RADIUS server) in the Access-Request packet and MUST be included in the Access-Accept packet if the initiation of a tunnel is desired. It SHOULD be included in Accounting-Request packets which contain Acct-Status-Type attributes with values of either Start or Stop and which pertain to a tunneled session. This Attribute, along with the Tunnel-Client-Endpoint and Acct- Tunnel-Connection-ID Attributes , may be used to provide a globally unique means to identify a tunnel for accounting and auditing purposes.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. If Tunnel-Medium-Type is IPv6 (2), then this string is either the FQDN of the tunnel client machine, or it is a text representation of the address in either the preferred or alternate form . Conformant implementations MUST support the preferred form and SHOULD support both the alternate text form and the FQDN format for IPv6 addresses. If Tunnel-Medium-Type is not IPv4 or IPv6, this string is a tag referring to configuration data local to the RADIUS client that describes the interface and medium-specific address to use. |
rfc2868 | |
Tunnel-Password |
This Attribute may contain a password to be used to authenticate
to a remote server. It may only be included in an Access-Accept packet. A summary of the Tunnel-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 | Tag | Salt +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Salt (cont) | String ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 69 for Tunnel-Password Length >= 5 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 containsthe 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. |
rfc2868 | |
Tunnel-Private-Group-Id |
|
rfc2868 | |
Tunnel-Assignment-Id |
|
rfc2868 | |
Tunnel-Preference |
If more than one set of tunneling attributes is returned by the
RADIUS server to the tunnel initiator, this Attribute SHOULD be included in each set to indicate the relative preference assigned to each tunnel. For example, suppose that Attributes describing two tunnels are returned by the server, one with a Tunnel-Type of PPTP and the other with a Tunnel-Type of L2TP. If the tunnel initiator supports only one of the Tunnel-Types returned, it will initiate a tunnel of that type. If, however, it supports both tunnel protocols, it SHOULD use the value of the Tunnel-Preference Attribute to decide which tunnel should be started. The tunnel having the numerically lowest value in the Value field of this Attribute SHOULD be given the highest preference. The values assigned to two or more instances of the Tunnel-PreferenceAttribute within a given Access-Accept packet MAY be identical. In this case, the tunnel initiator SHOULD use locally configured metrics to decide which set of attributes to use. This Attribute MAY be included (as a hint to the server) in Access-Request packets, but the RADIUS server is not required to honor this hint. A summary of the Tunnel-Preference 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 | Value +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Value (cont) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 83 for Tunnel-Preference Length Always 6. 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 Tag field is unused, it MUST be zero (0x00). Value The Value field is three octets in length and indicates the preference to be given to the tunnel to which it refers; higher preference is given to lower values, with 0x000000 being most preferred and 0xFFFFFF least preferred. |
rfc2868 | |
Tunnel-Client-Auth-Id |
|
rfc2868 | |
Tunnel-Server-Auth-Id |
|
rfc2868 | |
Acct-Input-Gigawords |
This attribute indicates how many times the Acct-Input-Octets
counter has wrapped around 2^32 over the course of this service being provided, and can only be present in Accounting-Request records where the Acct-Status-Type is set to Stop or Interim- Update. A summary of the Acct-Input-Gigawords 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 | Value +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Value (cont) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 52 for Acct-Input-Gigawords. Length 6 Value The Value field is four octets. |
rfc2869 | |
Acct-Output-Gigawords |
This attribute indicates how many times the Acct-Output-Octets
counter has wrapped around 2^32 in the course of delivering this service, and can only be present in Accounting-Request records where the Acct-Status-Type is set to Stop or Interim-Update. A summary of the Acct-Output-Gigawords 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 | Value +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Value (cont) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 53 for Acct-Output-Gigawords. Length 6 Value The Value field is four octets. |
rfc2869 | |
Event-Timestamp |
This attribute is included in an Accounting-Request packet to
record the time that this event occurred on the NAS, in seconds since January 1, 1970 00:00 UTC. A summary of the Event-Timestamp 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 | Value +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Value (cont) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 55 for Event-Timestamp Length 6 Value The Value field is four octets encoding an unsigned integer with the number of seconds since January 1, 1970 00:00 UTC. |
rfc2869 | |
ARAP-Password |
This attribute is only present in an Access-Request packet
containing a Framed-Protocol of ARAP. Only one of User-Password, CHAP-Password, or ARAP-Password needs to be present in an Access-Request, or one or more EAP-Messages. 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). |
rfc2869 | |
ARAP-Features |
This attribute is sent in an Access-Accept packet with Framed-
Protocol of ARAP, and includes password information that the NAS should sent to the user in an ARAP "feature flags" packet. A summary of the ARAP-Features 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value5 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 71 for ARAP-Features. Length 16Value The Value field is a compound string containing information the NAS should send to the user in the ARAP "feature flags" packet. Value1: If zero, user cannot change their password. If non-zero user can. (RADIUS does not handle the password changing, just the attribute which indicates whether ARAP indicates they can.) Value2: Minimum acceptable password length, from 0 to 8. Value3: Password creation date in Macintosh format, defined as 32 unsigned bits representing seconds since Midnight GMT January 1, 1904. Value4: Password Expiration Delta from create date in seconds. Value5: Current RADIUS time in Macintosh format. |
rfc2869 | |
ARAP-Zone-Access |
This attribute is included in an Access-Accept packet with
Framed-Protocol of ARAP to indicate how the ARAP zone list for the user should be used. A summary of the ARAP-Zone-Access 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 | Value +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Value (cont) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 72 for ARAP-Zone-Access. Length 6Value The Value field is four octets encoding an integer with one of the following values: 1 Only allow access to default zone 2 Use zone filter inclusively 4 Use zone filter exclusively The value 3 is skipped, not because these are bit flags, but because 3 in some ARAP implementations means "all zones" which is the same as not specifying a list at all under RADIUS. If this attribute is present and the value is 2 or 4 then a Filter-Id must also be present to name a zone list filter to apply the access flag to. |
Zone-Filter-Inclusive, Zone-Filter-Exclusive | rfc2869 |
ARAP-Security |
This attribute identifies the ARAP Security Module to be used in
an Access-Challenge packet. A summary of the ARAP-Security 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 | Value +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Value (cont) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 73 for ARAP-Security. Length 6Value The Value field is four octets, containing an integer specifying the security module signature, which is a Macintosh OSType. (Macintosh OSTypes are 4 ascii characters cast as a 32-bit integer) |
rfc2869 | |
ARAP-Security-Data |
This attribute contains the actual security module challenge or
response, and can be found in Access-Challenge and Access-Request packets. A summary of the ARAP-Security-Data 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | String... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 74 for ARAP-Security-Data. Length >=3 String The String field contains the security module challenge or response associated with the ARAP Security Module specified in ARAP-Security. |
rfc2869 | |
Password-Retry |
This attribute MAY be included in an Access-Reject to indicate how
many authentication attempts a user may be allowed to attempt before being disconnected. It is primarily intended for use with ARAP authentication.A summary of the Password-Retry 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 | Value +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Value (cont) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 75 for Password-Retry. Length 6 Value The Value field is four octets, containing an integer specifying the number of password retry attempts to permit the user. |
rfc2869 | |
Prompt |
This attribute is used only in Access-Challenge packets, and
indicates to the NAS whether it should echo the user's response as it is entered, or not echo it. A summary of the Prompt 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 | Value +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Value (cont) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 76 for Prompt.Length 6 Value The Value field is four octets. 0 No Echo 1 Echo |
Echo | rfc2869 |
Connect-Info |
This attribute is sent from the NAS to indicate the nature of the
user's connection. The NAS MAY send this attribute in an Access-Request or Accounting-Request to indicate the nature of the user's connection. A summary of the Connect-Info 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Text... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 77 for Connect-Info. Length >= 3 Text The Text field consists of UTF-8 encoded 10646 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" More than one Connect-Info attribute may be present in an Accounting-Request packet to accommodate expected efforts by ITU to have modems report more connection information in a standard format that might exceed 252 octets. |
rfc2869 | |
Configuration-Token |
This attribute is for use in large distributed authentication
networks based on proxy. It is sent from a RADIUS Proxy Server to a RADIUS Proxy Client in an Access-Accept to indicate a type of user profile to be used. It should not be sent to a NAS. A summary of the Configuration-Token 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | String ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 78 for Configuration-Token. Length >= 3 String The String field is one or more octets. The actual format of the information is site 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. |
rfc2869 | |
EAP-Message |
This attribute encapsulates Extended Access Protocol packets
so as to allow the NAS to authenticate dial-in users via EAP without having to understand the EAP protocol. The NAS places any EAP messages received from the user into one or more EAP attributes and forwards them to the RADIUS Server as part of the Access-Request, which can return EAP messages in Access- Challenge, Access-Accept and Access-Reject packets. A RADIUS Server receiving EAP messages that it does not understand SHOULD return an Access-Reject. The NAS places EAP messages received from the authenticating peer into one or more EAP-Message attributes and forwards them to the RADIUS Server within an Access-Request message. If multiple EAP- Messages are contained within an Access-Request or Access- Challenge packet, they MUST be in order and they MUST be consecutive attributes in the Access-Request or Access-Challenge packet. Access-Accept and Access-Reject packets SHOULD only have ONE EAP-Message attribute in them, containing EAP-Success or EAP- Failure. It is expected that EAP will be used to implement a variety of authentication methods, including methods involving strong cryptography. In order to prevent attackers from subverting EAP by attacking RADIUS/EAP, (for example, by modifying the EAP-Success or EAP-Failure packets) it is necessary that RADIUS/EAP provide integrity protection at least as strong as those used in the EAP methods themselves. Therefore the Message-Authenticator attribute MUST be used to protect all Access-Request, Access-Challenge, Access-Accept, and Access-Reject packets containing an EAP-Message attribute. Access-Request packets including an EAP-Message attribute without a Message-Authenticator attribute SHOULD be silently discarded by the RADIUS server. A RADIUS Server supporting EAP-Message MUST calculate the correct value of the Message-Authenticator and silently discard the packet if it does not match the value sent. A RADIUS Server not supporting EAP-Message MUST return an Access- Reject if it receives an Access-Request containing an EAP-Message attribute. A RADIUS Server receiving an EAP-Message attribute that it does not understand MUST return an Access-Reject.Access-Challenge, Access-Accept, or Access-Reject packets including an EAP-Message attribute without a Message-Authenticator attribute SHOULD be silently discarded by the NAS. A NAS supporting EAP-Message MUST calculate the correct value of the Message-Authenticator and silently discard the packet if it does not match the value sent. A summary of the EAP-Message 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | String... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 79 for EAP-Message. Length >= 3 String The String field contains EAP packets, as defined in . If multiple EAP-Message attributes are present in a packet their values should be concatenated; this allows EAP packets longer than 253 octets to be passed by RADIUS. |
rfc2869 | |
Message-Authenticator |
This attribute MAY be used to sign Access-Requests to prevent
spoofing Access-Requests using CHAP, ARAP or EAP authentication methods. It MAY be used in any Access-Request. It MUST be used in any Access-Request, Access-Accept, Access-Reject or Access- Challenge that includes an EAP-Message attribute. A RADIUS Server receiving an Access-Request with a Message- Authenticator Attribute present MUST calculate the correct value of the Message-Authenticator and silently discard the packet if it does not match the value sent.A RADIUS Client receiving an Access-Accept, Access-Reject or Access-Challenge with a Message-Authenticator Attribute present MUST calculate the correct value of the Message-Authenticator and silently discard the packet if it does not match the value sent. Earlier drafts of this memo used "Signature" as the name of this attribute, but Message-Authenticator is more precise. Its operation has not changed, just the name. A summary of the Message-Authenticator 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | String... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 80 for Message-Authenticator Length 18 String When present in an Access-Request packet, Message-Authenticator is an HMAC-MD5 checksum of the entire Access-Request packet, including Type, ID, Length and authenticator, using the shared secret as the key, as follows. Message-Authenticator = HMAC-MD5 (Type, Identifier, Length, Request Authenticator, Attributes) When the checksum is calculated the signature string should be considered to be sixteen octets of zero. For Access-Challenge, Access-Accept, and Access-Reject packets, the Message-Authenticator is calculated as follows, using the Request-Authenticator from the Access-Request this packet is in reply to: Message-Authenticator = HMAC-MD5 (Type, Identifier, Length, Request Authenticator, Attributes)When the checksum is calculated the signature string should be considered to be sixteen octets of zero. The shared secret is used as the key for the HMAC-MD5 hash. The is calculated and inserted in the packet before the Response Authenticator is calculated. This attribute is not needed if the User-Password attribute is present, but is useful for preventing attacks on other types of authentication. This attribute is intended to thwart attempts by an attacker to setup a "rogue" NAS, and perform online dictionary attacks against the RADIUS server. It does not afford protection against "offline" attacks where the attacker intercepts packets containing (for example) CHAP challenge and response, and performs a dictionary attack against those packets offline. IP Security will eventually make this attribute unnecessary, so it should be considered an interim measure. |
rfc2869 | |
ARAP-Challenge-Response |
This attribute is sent in an Access-Accept packet with Framed-
Protocol of ARAP, and contains the response to the dial-in client's challenge. A summary of the ARAP-Challenge-Response 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 | Value... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 84 for ARAP-Challenge-Response. Length 10Value The Value field contains an 8 octet response to the dial-in client's challenge. The RADIUS server calculates this value by taking the dial-in client's challenge from the high order 8 octets of the ARAP-Password attribute and performing DES encryption on this value with the authenticating user's password as the key. If the user's password is less than 8 octets in length, the password is padded at the end with NULL octets to a length of 8 before using it as a key. |
rfc2869 | |
Acct-Interim-Interval |
This attribute indicates the number of seconds between each
interim update in seconds for this specific session. This value can only appear in the Access-Accept message. A summary of the Acct-Interim-Interval 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 | Value +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value (cont) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 85 for Acct-Interim-Interval. Length 6 Value The Value field contains the number of seconds between each interim update to be sent from the NAS for this session. The value MUST NOT be smaller than 60. The value SHOULD NOT be smaller than 600, and careful consideration should be given to its impact on network traffic. |
rfc2869 | |
NAS-Port-Id |
This Attribute contains a text string which identifies the port of
the NAS which is authenticating the user. It is only used in Access-Request and Accounting-Request packets. Note that this is using "port" in its sense of a physical connection on the NAS, not in the sense of a TCP or UDP port number. Either NAS-Port or NAS-Port-Id SHOULD be present in an Access- Request packet, if the NAS differentiates among its ports. NAS- Port-Id is intended for use by NASes which cannot conveniently number their ports. A summary of the NAS-Port-Id 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Text... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 87 for NAS-Port-Id. Length >= 3 Text The Text field contains the name of the port using UTF-8 encoded 10646 characters. |
rfc2869 | |
Framed-Pool |
This Attribute contains the name of an assigned address pool that
SHOULD be used to assign an address for the user. If a NAS does not support multiple address pools, the NAS should ignore this Attribute. Address pools are usually used for IP addresses, but can be used for other protocols if the NAS supports pools for those protocols.A summary of the Framed-Pool 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | String... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 88 for Framed-Pool Length >= 3 String The string field contains the name of an assigned address pool configured on the NAS. |
rfc2869 | |
NAS-IPv6-Address |
This Attribute indicates the identifying IPv6 Address of the NAS
which is requesting authentication of the user, and SHOULD be unique to the NAS within the scope of the RADIUS server. NAS- IPv6-Address is only used in Access-Request packets. NAS-IPv6- Address and/or NAS-IP-Address MAY be present in an Access-Request packet; however, if neither attribute is present then NAS- Identifier MUST be present. A summary of the NAS-IPv6-Address 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 | Address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Type 95 for NAS-IPv6-Address Length 18 Address The Address field is 16 octets. |
rfc3162 | |
Framed-Interface-Id |
This Attribute indicates the IPv6 interface identifier to be
configured for the user. It MAY be used in Access-Accept packets. If the Interface-Identifier IPv6CP option has been successfully negotiated, this Attribute MUST be included in an Access-Request packet as a hint by the NAS to the server that it would prefer that value. It is recommended, but not required, that the server honor the hint. 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. |
rfc3162 | |
Framed-IPv6-Prefix |
This Attribute indicates an IPv6 prefix (and corresponding route)
to be configured for the user. It MAY be used in Access-Accept packets, and can appear multiple times. It MAY be used in an Access-Request packet as a hint by the NAS to the server that it would prefer these prefix(es), but the server is not required to honor the hint. Since it is assumed that the NAS will plumb a route corresponding to the prefix, it is not necessary for the server to also send a Framed-IPv6-Route attribute for the same prefix. A summary of the Framed-IPv6-Prefix 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 | Reserved | Prefix-Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Prefix +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Prefix +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Prefix +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Prefix | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 97 for Framed-IPv6-Prefix Length At least 4 and no larger than 20. Reserved This field, which is reserved and MUST be present, is always set to zero. Prefix-Length The length of the prefix, in bits. At least 0 and no larger than 128.Prefix The Prefix field is up to 16 octets in length. Bits outside of the Prefix-Length, if included, must be zero. |
rfc3162 | |
Login-IPv6-Host |
This Attribute indicates the system with which to connect the
user, when the Login-Service Attribute is included. It MAY be used in Access-Accept packets. It MAY be used in an Access- Request packet as a hint to the server that the NAS would prefer to use that host, but the server is not required to honor the hint. A summary of the Login-IPv6-Host 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 | Address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 98 for Login-IPv6-Host Length 18Address The Address field is 16 octets in length. The value 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF indicates that the NAS SHOULD allow the user to select an address or name to be connected to. The value 0 indicates that the NAS SHOULD select a host to connect the user to. Other values indicate the address the NAS SHOULD connect the user to. |
rfc3162 | |
Framed-IPv6-Route |
This Attribute provides routing information to be configured for
the user on the NAS. It is used in the Access-Accept packet and can appear multiple times. A summary of the Framed-IPv6-Route 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- | Type | Length | Text ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Type 99 for Framed-IPv6-Route Length >=3 Text The Text field is one or more octets, and its contents are implementation dependent. The field is not NUL (hex 00) terminated. It is intended to be human readable and MUST NOT affect operation of the protocol. For IPv6 routes, it SHOULD contain a destination prefix optionally followed by a slash and a decimal length specifier stating how many high order bits of the prefix to use. That is followed by a space, a gateway address, a space, and one or more metrics (encoded in decimal) separated by spaces. Prefixes and addresses are formatted as described in . For example, "2000:0:0:106::/64 2000::106:a00:20ff:fe99:a998 1".Whenever the gateway address is the IPv6 unspecified address the IP address of the user SHOULD be used as the gateway address. The unspecified address can be expressed in any of the acceptable formats described in . For example, "2000:0:0:106::/64 :: 1". |
rfc3162 | |
Framed-IPv6-Pool |
This Attribute contains the name of an assigned pool that SHOULD
be used to assign an IPv6 prefix for the user. If a NAS does not support multiple prefix pools, the NAS MUST ignore this Attribute. A summary of the Framed-IPv6-Pool 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | String... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 100 for Framed-IPv6-Pool Length >= 3 String The string field contains the name of an assigned IPv6 prefix pool configured on the NAS. The field is not NUL (hex 00) terminated.3. Table of AttributesThe following table provides a guide to which attributes may be found in which kinds of packets, and in what quantity. Request Accept Reject Challenge Accounting # Attribute Request 0-1 0 0 0 0-1 95 NAS-IPv6-Address 0-1 0-1 0 0 0-1 96 Framed-Interface-Id 0+ 0+ 0 0 0+ 97 Framed-IPv6-Prefix 0+ 0+ 0 0 0+ 98 Login-IPv6-Host 0 0+ 0 0 0+ 99 Framed-IPv6-Route 0 0-1 0 0 0-1 100 Framed-IPv6-Pool4. References Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels",,, March, 1997. Yergeau, F., "UTF-8, a transformation format of Unicode and ISO 10646",, October 1996. Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy Implementation in Roaming",, June 1999. Rigney, C., Rubens, A., Simpson, W. and S. Willens, "Remote Authentication Dial In User Service (RADIUS)",, June 2000. Rigney, C., "RADIUS Accounting",, June 2000. Zorn, G., Mitton, D. and B. Aboba, "RADIUS Accounting Modifications for Tunnel Protocol Support",, June 2000. Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M. and I. Goyret, "RADIUS Attributes for Tunnel Protocol Support",, June 2000. Rigney, C., Willats, W. and P. Calhoun, "RADIUS Extensions",, June 2000. Kent S. and R. Atkinson, "Security Architecture for the Internet Protocol",, November 1998. Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs",,, October 1998. Haskin, D. and E. Allen, "IP Version 6 over PPP",, December 1998. Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds",, February 2001. Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification",, December 1998. Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 Domains without Explicit Tunnels",, March 1999. Gilligan, R. and E. Nordmark, "Transition Mechanisms for IPv6 Hosts and Routers",, August 2000. Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture",, July 1998.5. Security ConsiderationsThis document describes the use of RADIUS for the purposes of authentication, authorization and accounting in IPv6-enabled networks. In such networks, the RADIUS protocol may run either over IPv4 or over IPv6. Known security vulnerabilities of the RADIUS protocol are described in , and . Since IPSEC is mandatory to implement for IPv6, it is expected that running RADIUS implementations supporting IPv6 will typically run over IPSEC. Where RADIUS is run over IPSEC and where certificates are used for authentication, it may be desirable to avoid management of RADIUS shared secrets, so as to leverage the improved scalability of public key infrastructure. Within RADIUS, a shared secret is used for hiding of attributes such as User-Password and Tunnel-Password . In addition, the shared secret is used in computation of the Response Authenticator , as well as the Message-Authenticator attribute . Therefore, in RADIUS a shared secret is used to provide confidentiality as well as integrity protection and authentication. As a result, only use of IPSEC ESP with a non-null transform can provide security services sufficient to substitute for RADIUS application-layer security. Therefore, where IPSEC AH or ESP null is used, it will typically still be necessary to configure a RADIUS shared secret. However, where RADIUS is run over IPSEC ESP with a non-null transform, the secret shared between the NAS and the RADIUS server MAY NOT be configured. In this case, a shared secret of zero length MUST be assumed.6. IANA ConsiderationsThis document requires the assignment of six new RADIUS attribute numbers for the following attributes: NAS-IPv6-Address Framed-Interface-Id Framed-IPv6-Prefix Login-IPv6-Host Framed-IPv6-Route Framed-IPv6-Pool Seefor the registered list of numbers.7. AcknowledgmentsThe authors would like to acknowledge Jun-ichiro itojun Hagino of IIJ Research Laboratory, Darran Potter of Cisco and Carl Rigney of Lucent for contributions to this document.8. Authors' AddressesBernard Aboba Microsoft Corporation One Microsoft Way Redmond, WA 98052 Phone: +1 425 936 6605 Fax: +1 425 936 7329 EMail: [email protected] Glen Zorn Cisco Systems, Inc. 500 108th Avenue N.E., Suite 500 Bellevue, WA 98004 Phone: +1 425 471 4861 EMail: [email protected] Dave Mitton Circular Logic UnLtd. 733 Turnpike Street #154 North Andover, MA 01845 Phone: 978 683-1814 Email: [email protected] Copyright Statement Copyright (C) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Aboba, et al. Standards Track |
rfc3162 | |
Error-Cause |
It is possible that the NAS cannot honor Disconnect-Request or
CoA-Request messages for some reason. The Error-Cause Attribute provides more detail on the cause of the problem. It MAY be included within Disconnect-ACK, Disconnect-NAK and CoA-NAK messages. A summary of the Error-Cause 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 | Value +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Value (cont) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 101 for Error-Cause Length 6 Value The Value field is four octets, containing an integer specifying the cause of the error. Values 0-199 and 300-399 are reserved. Values 200-299 represent successful completion, so that these values may only be sent within Disconnect-ACK or CoA-ACK message and MUST NOT be sent within a Disconnect-NAK or CoA-NAK. Values400-499 represent fatal errors committed by the RADIUS server, so that they MAY be sent within CoA-NAK or Disconnect-NAK messages, and MUST NOT be sent within CoA-ACK or Disconnect-ACK messages. Values 500-599 represent fatal errors occurring on a NAS or RADIUS proxy, so that they MAY be sent within CoA-NAK and Disconnect-NAK messages, and MUST NOT be sent within CoA-ACK or Disconnect-ACK messages. Error-Cause values SHOULD be logged by the RADIUS server. Error-Code values (expressed in decimal) include: # Value --- ----- 201 Residual Session Context Removed 202 Invalid EAP Packet (Ignored) 401 Unsupported Attribute 402 Missing Attribute 403 NAS Identification Mismatch 404 Invalid Request 405 Unsupported Service 406 Unsupported Extension 501 Administratively Prohibited 502 Request Not Routable (Proxy) 503 Session Context Not Found 504 Session Context Not Removable 505 Other Proxy Processing Error 506 Resources Unavailable 507 Request Initiated "Residual Session Context Removed" is sent in response to a Disconnect-Request if the user session is no longer active, but residual session context was found and successfully removed. This value is only sent within a Disconnect-ACK and MUST NOT be sent within a CoA-ACK, Disconnect-NAK or CoA-NAK. "Invalid EAP Packet (Ignored)" is a non-fatal error that MUST NOT be sent by implementations of this specification. "Unsupported Attribute" is a fatal error sent if a Request contains an attribute (such as a Vendor-Specific or EAP-Message Attribute) that is not supported. "Missing Attribute" is a fatal error sent if critical attributes (such as NAS or session identification attributes) are missing from a Request. "NAS Identification Mismatch" is a fatal error sent if one or more NAS identification attributes (see.) do not match the identity of the NAS receiving the Request."Invalid Request" is a fatal error sent if some other aspect of the Request is invalid, such as if one or more attributes (such as EAP- Message Attribute(s)) are not formatted properly. "Unsupported Service" is a fatal error sent if a Service-Type Attribute included with the Request is sent with an invalid or unsupported value. "Unsupported Extension" is a fatal error sent due to lack of support for an extension such as Disconnect and/or CoA messages. This will typically be sent by a proxy receiving an ICMP port unreachable message after attempting to forward a Request to the NAS. "Administratively Prohibited" is a fatal error sent if the NAS is configured to prohibit honoring of Request messages for the specified session. "Request Not Routable" is a fatal error which MAY be sent by a RADIUS proxy and MUST NOT be sent by a NAS. It indicates that the RADIUS proxy was unable to determine how to route the Request to the NAS. For example, this can occur if the required entries are not present in the proxy's realm routing table. "Session Context Not Found" is a fatal error sent if the session context identified in the Request does not exist on the NAS. "Session Context Not Removable" is a fatal error sent in response to a Disconnect-Request if the NAS was able to locate the session context, but could not remove it for some reason. It MUST NOT be sent within a CoA-ACK, CoA-NAK or Disconnect-ACK, only within a Disconnect-NAK. "Other Proxy Processing Error" is a fatal error sent in response to a Request that could not be processed by a proxy, for reasons other than routing. "Resources Unavailable" is a fatal error sent when a Request could not be honored due to lack of available NAS resources (memory, non- volatile storage, etc.). "Request Initiated" is a fatal error sent in response to a Request including a Service-Type Attribute with a value of "Authorize Only". It indicates that the Disconnect-Request or CoA-Request has not been honored, but that a RADIUS Access-Request including a Service-Type Attribute with value "Authorize Only" is being sent to the RADIUS server. |
Invalid-EAP-Packet, Unsupported-Attribute, Missing-Attribute ... | rfc3576 |
EAP-Key-Name |
The EAP-Key-Name Attribute, defined in "Diameter Extensible
Authentication Protocol (EAP) Application" , contains the EAP Session-Id, as described in "Extensible Authentication Protocol (EAP) Key Management Framework" . Exactly how this attribute is used depends on the link layer in question. It should be noted that not all link layers use this name. An EAP-Key-Name Attribute MAY be included within Access-Request, Access-Accept, and CoA-Request packets. A summary of the EAP-Key- Name 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 | String... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 102 Length >=3 String The String field is one or more octets, containing the EAP Session-Id, as defined in "Extensible Authentication Protocol (EAP) Key Management Framework" . Since the NAS operates as a pass-through in EAP, it cannot know the EAP Session-Id before receiving it from the RADIUS server. As a result, an EAP-Key-Name Attribute sent in an Access-Request MUST only contain a single NUL character. A RADIUS server receiving an Access-Request with an EAP-Key-Name Attribute containing anything other than a single NUL character MUST silently discard the attribute. In addition, the RADIUS server SHOULD include this attribute in an Access-Accept or CoA-Request only if an EAP-Key-Name Attribute was present in the Access-Request. Since a NAS will typically only include an EAP- Key-Name Attribute in an Access-Request in situations where the attribute is required to provision service, if an EAP-Key-Name Attribute is included in an Access-Request but is not present in the Access-Accept, the NAS SHOULD treat the Access-Accept as though it were an Access-Reject. If an EAP-Key-Name Attribute was not present in the Access-Request but is included in the Access- Accept, then the NAS SHOULD silently discard the EAP-Key-Name Attribute. As noted in Section 6.2.2 of , the Connectivity Association Key Name (CKN) is derived from the EAP Session-Id, and, as described in Section 9.3.3 of , the CKN is subsequently used in the derivation of the Key Encrypting Key (KEK) and the Integrity Check Value Key (ICK), which protect the Secure Association Keys (SAKs) utilized by Media Access Control Security (MACsec). As a result, for the NAS to acquire information needed in the MACsec Key Agreement (MKA) exchange, it needs to include the EAP-Key-Name Attribute in the Access-Request and receive it from the RADIUS server in the Access-Accept. |
rfc4072 | |
Chargeable-User-Identity |
The Chargeable-User-Identity attribute, or CUI, (Type value 89) is a
unique, temporary handle used as means to, for example, correlate authentication, accounting, and bill post-processing for a particular chargeable subscriber. The CUI format and use follows guidelines defined by . In the scope of this document, the CUI attribute MAY be present in the Access-Request. The CUI MAY also be present in the Access- Accept. The CUI MUST be present in the Access-Accept if it was present in the Access-Request. If the use of the Chargeable-User- Identity attribute is supported, then the MAG and/or the LMA commits to include the Chargeable-User-Identity attribute in all subsequent RADIUS Accounting packets they send for the given user. |
rfc4372 | |
Egress-VLANID |
|
rfc4675 | |
Ingress-Filters |
|
Disabled | rfc4675 |
Egress-VLAN-Name |
|
rfc4675 | |
User-Priority-Table |
|
rfc4675 | |
ADSL-Forum-DHCP-Vendor-Specific |
|
rfc4679 | |
ADSL-Agent-Circuit-Id |
|
rfc4679 | |
ADSL-Agent-Remote-Id |
|
rfc4679 | |
Actual-Data-Rate-Upstream |
This Attribute contains the actual upstream train rate of a
subscriber's synchronized DSL link. It MAY be included in both Access-Request and Accounting-Request packets. A summary of the Actual-Data-Rate-Upstream 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vendor-Type | Vendor-Length | Value +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Value (cont'd.) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Vendor-Type 129 (0x81) for Actual-Data-Rate-Upstream Vendor-Length 6 Value This field contains a 4-byte unsigned integer, indicating the subscriber's actual data rate upstream of a synchronized DSL link. The rate is coded in bits per second. |
rfc4679 | |
Actual-Data-Rate-Downstream |
This Attribute contains the actual downstream train rate of a
subscriber's synchronized DSL link. It MAY be included in both Access-Request and Accounting-Request packets. A summary of the Actual-Data-Rate-Downstream 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vendor-Type | Vendor-Length | Value +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Value (cont'd.) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Vendor-Type 130 (0x82) for Actual-Data-Rate-Downstream Vendor-Length 6 Value This field contains a 4-byte unsigned integer, indicating the subscriber's actual data rate downstream of a synchronized DSL link. The rate is coded in bits per second. |
rfc4679 | |
Minimum-Data-Rate-Upstream |
This Attribute contains the subscriber's operator-configured
minimum upstream data rate. It MAY be included in Accounting- Request packets. A summary of the Minimum-Data-Rate-Upstream 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vendor-Type | Vendor-Length | Value +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Value (cont'd.) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Vendor-Type 131 (0x83) for Minimum-Data-Rate-Upstream Vendor-Length 6Value This field contains a 4-byte unsigned integer, indicating the subscriber's minimum upstream data rate (as configured by the operator). The rate is coded in bits per second. |
rfc4679 | |
Minimum-Data-Rate-Downstream |
This Attribute contains the subscriber's operator-configured
minimum downstream data rate. It MAY be included in Accounting- Request packets. A summary of the Minimum-Data-Rate-Downstream 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vendor-Type | Vendor-Length | Value +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Value (cont'd.) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Vendor-Type 132 (0x84) for Minimum-Data-Rate-Downstream Vendor-Length 6 Value This field contains a 4-byte unsigned integer, indicating the subscriber's minimum downstream data rate (as configured by the operator). The rate is coded in bits per second. |
rfc4679 | |
Attainable-Data-Rate-Upstream |
This Attribute contains the subscriber's attainable upstream data
rate. It MAY be included in Accounting-Request packets. A summary of the Attainable-Data-Rate-Upstream 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vendor-Type | Vendor-Length | Value +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Value (cont'd.) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Vendor-Type 133 (0x85) for Attainable-Data-Rate-Upstream Vendor-Length 6 Value This field contains a 4-byte unsigned integer, indicating the subscriber's actual DSL attainable upstream data rate. The rate is coded in bits per second. |
rfc4679 | |
Attainable-Data-Rate-Downstream |
This Attribute contains the subscriber's attainable downstream
data rate. It MAY be included in Accounting-Request packets. A summary of the Attainable-Data-Rate-Downstream 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vendor-Type | Vendor-Length | Value +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Value (cont'd.) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Vendor-Type 134 (0x86) for Attainable-Data-Rate-Downstream Vendor-Length 6Value This field contains a 4-byte unsigned integer, indicating the subscriber's actual DSL attainable downstream data rate. The rate is coded in bits per second. |
rfc4679 | |
Maximum-Data-Rate-Upstream |
This Attribute contains the subscriber's maximum upstream data
rate, as configured by the operator. It MAY be included in Accounting-Request packets. A summary of the Maximum-Data-Rate-Upstream 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vendor-Type | Vendor-Length | Value +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Value (cont'd.) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Vendor-Type 135 (0x87) for Maximum-Data-Rate-Upstream Vendor-Length 6 Value This field is a 4-byte unsigned integer, indicating the numeric value of the subscriber's DSL maximum upstream data rate. The rate is coded in bits per second. |
rfc4679 | |
Maximum-Data-Rate-Downstream |
This Attribute contains the subscriber's maximum downstream data
rate, as configured by the operator. It MAY be included in Accounting-Request packets.A summary of the Maximum-Data-Rate-Downstream 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vendor-Type | Vendor-Length | Value +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Value (cont'd.) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Vendor-Type 136 (0x88) for Maximum-Data-Rate-Downstream Vendor-Length 6 Value This field is a 4-byte unsigned integer, indicating the numeric value of the subscriber's DSL maximum downstream data rate. The rate is coded in bits per second. |
rfc4679 | |
Minimum-Data-Rate-Upstream-Low-Power |
This Attribute contains the subscriber's minimum upstream data
rate in low power state, as configured by the operator. It MAY be included in Accounting-Request packets. A summary of the Minimum-Data-Rate-Upstream-Low-Power 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vendor-Type | Vendor-Length | Value +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Value (cont'd.) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Vendor-Type 137 (0x89) for Minimum-Data-Rate-Upstream-Low-PowerVendor-Length 6 Value This field is a 4-byte unsigned integer, indicating the numeric value of the subscriber's DSL minimum upstream data rate when in low power state (L1/L2). The rate is coded in bits per second. |
rfc4679 | |
Minimum-Data-Rate-Downstream-Low-Power |
This Attribute contains the subscriber's minimum downstream data
rate in low power state, as configured by the operator. It MAY be included in Accounting-Request packets. A summary of the Minimum-Data-Rate-Downstream-Low-Power 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vendor-Type | Vendor-Length | Value +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Value (cont'd.) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Vendor-Type 138 (0x8A) for Minimum-Data-Rate-Downstream-Low-Power Vendor-Length 6 Value This field is a 4-byte unsigned integer, indicating the numeric value of the subscriber's DSL minimum downstream data rate. The rate is coded in bits per second. |
rfc4679 | |
Maximum-Interleaving-Delay-Upstream |
This Attribute contains the subscriber's maximum one-way upstream
interleaving delay, as configured by the operator. It MAY be included in Accounting-Request packets. A summary of the Maximum-Interleaving-Delay-Upstream 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vendor-Type | Vendor-Length | Value +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Value (cont'd.) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Vendor-Type 139 (0x8B) for Maximum-Interleaving-Delay-Upstream Vendor-Length 6 Value This field is a 4-byte unsigned integer, indicating the numeric value in milliseconds of the subscriber's DSL maximum one-way upstream interleaving delay. |
rfc4679 | |
Actual-Interleaving-Delay-Upstream |
This Attribute contains the subscriber's actual one-way upstream
interleaving delay. It MAY be included in Accounting-Request packets. A summary of the Actual-Interleaving-Delay-Upstream 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vendor-Type | Vendor-Length | Value +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Value (cont'd.) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Vendor-Type 140 (0x8C) for Actual-Interleaving-Delay-Upstream Vendor-Length 6 Value This field is a 4-byte unsigned integer, indicating the numeric value in milliseconds of the subscriber's DSL actual upstream interleaving delay. |
rfc4679 | |
Maximum-Interleaving-Delay-Downstream |
This Attribute contains the subscriber's maximum one-way
downstream interleaving delay, as configured by the operator. It MAY be included in Accounting-Request packets. A summary of the Maximum-Interleaving-Delay-Downstream 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vendor-Type | Vendor-Length | Value +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Value (cont'd.) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Vendor-Type 141 (0x8D) for Maximum-Interleaving-Delay-DownstreamVendor-Length 6 Value This field is a 4-byte unsigned integer, indicating the numeric value in milliseconds of the subscriber's DSL maximum one-way downstream interleaving delay. |
rfc4679 | |
Actual-Interleaving-Delay-Downstream |
This Attribute contains the subscriber's actual one-way downstream
interleaving delay. It MAY be included in Accounting-Request packets. A summary of the Actual-Interleaving-Delay-Downstream 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vendor-Type | Vendor-Length | Value +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Value (cont'd.) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Vendor-Type 142 (0x8E) for Actual-Interleaving-Delay-Downstream Vendor-Length 6 Value This field is a 4-byte unsigned integer, indicating the numeric value in milliseconds of the subscriber's DSL actual downstream interleaving delay. |
rfc4679 | |
Access-Loop-Encapsulation |
This Attribute describes the encapsulation(s) used by the
subscriber on the DSL access loop. It MAY be present in both Access-Request and Accounting-Request packets. A summary of the Access-Loop-Encapsulation 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vendor-Type | Vendor-Length | Value +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Value (cont'd) | +-+-+-+-+-+-+-+-+ Vendor-Type 144 (0x90) for Access-Loop-Encapsulation Vendor-Length 5 Value This field is a string 3 bytes in length, logically divided into three 1-byte sub-fields as shown in the following diagram: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data Link | Encaps 1 | Encaps 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Valid values for the sub-fields are as follows: Data Link 0x01 AAL5 0x02 EthernetEncaps 1 0x00 NA - Not Available 0x01 Untagged Ethernet 0x02 Single-Tagged Ethernet Encaps 2 0x00 NA - Not Available 0x01 PPPoA LLC 0x02 PPPoA Null 0x03 IPoA LLC 0x04 IPoA Null 0x05 Ethernet over AAL5 LLC with FCS 0x06 Ethernet over AAL5 LLC without FCS 0x07 Ethernet over AAL5 Null with FCS 0x08 Ethernet over AAL5 Null without FCS |
rfc4679 | |
IWF-Session |
The presence of this Attribute indicates that the IWF has been
performed with respect to the subscriber's session; note that no data field is necessary. It MAY be included in both Access- Request and Accounting-Request packets. A summary of the IWF-Session Attribute format is shown below. The fields are transmitted from left to right. 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vendor-Type | Vendor-Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Vendor-Type 254 (0xFE) for IWF-Session Vendor-Length 24. Table of AttributesThe following table provides a guide to which attributes may be found in which kinds of packets, and in what quantity; note that since none of the DSL Forum VSAs may be present in the Access-Accept, Access- Reject or Access-Challenge packets, those columns have been omitted from the table. Request Acct-Request # Attribute 0-1 0-1 1 Agent-Circuit-Id 0-1 0-1 2 Agent-Remote-Id 0-1 0-1 129 Actual-Data-Rate-Upstream 0-1 0-1 130 Actual-Data-Rate-Downstream 0 0-1 131 Minimum-Data-Rate-Upstream 0 0-1 132 Minimum-Data-Rate-Downstream 0 0-1 133 Attainable-Data-Rate-Upstream 0 0-1 134 Attainable-Data-Rate-Downstream 0 0-1 135 Maximum-Data-Rate-Upstream 0 0-1 136 Maximum-Data-Rate-Downstream 0 0-1 137 Minimum-Data-Rate-Upstream-Low-Power 0 0-1 138 Minimum-Data-Rate-Downstream-Low-Power 0 0-1 139 Maximum-Interleaving-Delay-Upstream 0 0-1 140 Actual-Interleaving-Delay-Upstream 0 0-1 141 Maximum-Interleaving-Delay-Downstream 0 0-1 142 Actual-Interleaving-Delay-Downstream 0-1 0-1 144 Access-Loop-Encapsulation 0-1 0-1 254 IWF-Session The following table defines the meaning of the above table entries. 0 This Attribute MUST NOT be present in packet. 0-1 Zero or one instances of this Attribute MAY be present in packet.5. Security ConsiderationsThe security of these Attributes relies on an implied trust relationship between the Access Node/DSLAM and the BRAS. The identifiers that are inserted by the Access Node/DSLAM are unconditionally trusted; the BRAS does not perform any validity check on the information received. These Attributes are intended to be used in environments in which the network infrastructure (the Access Node/DSLAM, the BRAS, and the entire network in which those two devices reside) is trusted and secure.As used in this document, the word "trusted" implies that unauthorized traffic cannot enter the network except through secured and trusted devices and that all devices internal to the network are secure and trusted. Careful consideration should be given to the potential security vulnerabilities that are present in this model before deploying this option in actual networks. The Attributes described in this document neither increase nor decrease the security of the RADIUS protocol. For discussions of various RADIUS vulnerabilities, see , , , and .6. References |
rfc4679 | |
Delegated-IPv6-Prefix |
|
rfc4818 | |
NAS-Filter-Rule |
|
rfc4849 | |
Digest-Response |
If this attribute is present in an Access-Request message, a
RADIUS server implementing this specification MUST treat the Access-Request as a request for Digest Authentication. When a RADIUS client receives a (Proxy-)Authorization header, it puts the request-digest value into a Digest-Response Attribute. This attribute (which enables the user to prove possession of the password) MUST only be used in Access-Request packets.Type 103 for Digest-Response. Length >= 3 Text When using HTTP Digest, the text field is 32 octets long and contains a hexadecimal representation of a 16-octet digest value as it was calculated by the authenticated client. Other digest algorithms MAY define different digest lengths. The text field MUST be copied from request-digest of digest- response without surrounding quotes. |
rfc5090 | |
Digest-Realm |
This attribute describes a protection space component of the
RADIUS server. HTTP-style protocols differ in their definition of the protection space. See, for details. It MUST only be used in Access-Request, Access- Challenge, and Accounting-Request packets. Type 104 for Digest-Realm Length >= 3 Text In Access-Requests, the RADIUS client takes the value of the realm directive (realm-value according to ) without surrounding quotes from the HTTP-style request it wants to authenticate. In Access-Challenge packets, the RADIUS server puts the expected realm value into this attribute. |
rfc5090 | |
Digest-Nonce |
This attribute holds a nonce to be used in the HTTP Digest
calculation. If the Access-Request had a Digest-Method and a Digest-URI but no Digest-Nonce Attribute, the RADIUS server MUST put a Digest-Nonce Attribute into its Access-Challenge packet. This attribute MUST only be used in Access-Request and Access-Challenge packets. Type 105 for Digest-Nonce Length >= 3Text In Access-Requests, the RADIUS client takes the value of the nonce directive (nonce-value in ) without surrounding quotes from the HTTP-style request it wants to authenticate. In Access-Challenge packets, the attribute contains the nonce selected by the RADIUS server. |
rfc5090 | |
Digest-Response-Auth |
This attribute enables the RADIUS server to prove possession of
the password. If the previously received Digest-Qop Attribute was 'auth-int' (without surrounding quotes), the RADIUS server MUST send a Digest-HA1 Attribute instead of a Digest-Response- Auth Attribute. The Digest-Response-Auth Attribute MUST only be used in Access-Accept packets. The RADIUS client puts the attribute value without surrounding quotes into the rspauth directive of the Authentication-Info header. Type 106 for Digest-Response-Auth. Length >= 3 Text The RADIUS server calculates a digest according toand copies the result into this attribute. Digest algorithms other than the one defined in MAY define digest lengths other than 32. |
rfc5090 | |
Digest-Nextnonce |
This attribute holds a nonce to be used in the HTTP Digest
calculation. The RADIUS server MAY put a Digest-Nextnonce Attribute into an Access-Accept packet. If this attribute is present, the RADIUS client MUST put the contents of this attribute into the nextnonce directive of an Authentication-Info header in its HTTP-style response. This attribute MUST only be used in Access-Accept packets. Type 107 for Digest-Nextnonce Length >= 3 Text It is recommended that this text be base64 or hexadecimal data. |
rfc5090 | |
Digest-Method |
This attribute holds the method value to be used in the HTTP
Digest calculation. This attribute MUST only be used in Access-Request and Accounting-Request packets. Type 108 for Digest-Method Length >= 3 Text In Access-Requests, the RADIUS client takes the value of the request method from the HTTP-style request it wants to authenticate. |
rfc5090 | |
Digest-URI |
This attribute is used to transport the contents of the
digest-uri directive or the URI of the HTTP-style request. It MUST only be used in Access-Request and Accounting-Request packets. Type 109 for Digest-URI Length >= 3 Text If the HTTP-style request has an Authorization header, the RADIUS client puts the value of the uri directive found in the HTTP-style request Authorization header (known as "digest-uri- value" in) without surrounding quotes into this attribute. If there is no Authorization header, the RADIUS client takes the value of the request URI from the HTTP-style request it wants to authenticate. |
rfc5090 | |
Digest-Qop |
This attribute holds the Quality of Protection parameter that
influences the HTTP Digest calculation. This attribute MUST only be used in Access-Request, Access-Challenge, and Accounting-Request packets. A RADIUS client SHOULD insert one of the Digest-Qop attributes it has received in a previous Access-Challenge packet. RADIUS servers SHOULD insert at least one Digest-Qop Attribute in an Access-Challenge packet. Digest-Qop is optional in order to preserve backward compatibility with a minimal implementation of .Type 110 for Digest-Qop Length >= 3 Text In Access-Requests, the RADIUS client takes the value of the qop directive (qop-value as described in ) from the HTTP-style request it wants to authenticate. In Access- Challenge packets, the RADIUS server puts a desired qop-value into this attribute. If the RADIUS server supports more than one "quality of protection" value, it puts each qop-value into a separate Digest-Qop Attribute. |
rfc5090 | |
Digest-Algorithm |
This attribute holds the algorithm parameter that influences
the HTTP Digest calculation. It MUST only be used in Access- Request, Access-Challenge and Accounting-Request packets. If this attribute is missing, MD5 is assumed. Type 111 for Digest-Algorithm Length >= 3 Text In Access-Requests, the RADIUS client takes the value of the algorithm directive (as described in) from the HTTP-style request it wants to authenticate. In Access-Challenge packets, the RADIUS server SHOULD put the desired algorithm into this attribute. |
rfc5090 | |
Digest-Entity-Body-Hash |
When using the qop-value 'auth-int', a hash of the HTTP-style
message body's contents is required for digest calculation. Instead of sending the complete body of the message, only its hash value is sent. This hash value can be used directly in the digest calculation. The clarifications described inabout the hash of empty entity bodies apply to the Digest-Entity- Body-Hash Attribute. This attribute MUST only be sent in Access-Request packets. Type 112 for Digest-Entity-Body-Hash Length >= 3Text The attribute holds the hexadecimal representation of H(entity-body). This hash is required by certain authentication mechanisms, such as HTTP Digest with quality of protection set to 'auth-int'. RADIUS clients MUST use this attribute to transport the hash of the entity body when HTTP Digest is the authentication mechanism and the RADIUS server requires that the integrity of the entity body (e.g., qop parameter set to 'auth-int') be verified. Extensions to this document may define support for authentication mechanisms other than HTTP Digest. |
rfc5090 | |
Digest-CNonce |
This attribute holds the client nonce parameter that is used in
the HTTP Digest calculation. It MUST only be used in Access- Request packets. Type 113 for Digest-CNonce Length >= 3 Text This attribute includes the value of the cnonce-value without surrounding quotes, taken from the HTTP-style request. |
rfc5090 | |
Digest-Nonce-Count |
This attribute includes the nonce count parameter that is used
to detect replay attacks. The attribute MUST only be used in Access-Request packets. Type 114 for Digest-Nonce-Count Length 10 Text In Access-Requests, the RADIUS client takes the value of the nc directive (nc-value according to ) without surrounding quotes from the HTTP-style request it wants to authenticate. |
rfc5090 | |
Digest-Username |
This attribute holds the user name used in the HTTP Digest
calculation. The RADIUS server MUST use this attribute only for the purposes of calculating the digest. In order to determine the appropriate user credentials, the RADIUS serverMUST use the User-Name (1) Attribute, and MUST NOT use the Digest-Username Attribute. This attribute MUST only be used in Access-Request and Accounting-Request packets. Type 115 for Digest-Username Length >= 3 Text In Access-Requests, the RADIUS client takes the value of the username directive (username-value according to ) without surrounding quotes from the HTTP-style request it wants to authenticate. |
rfc5090 | |
Digest-Opaque |
This attribute holds the opaque parameter that is passed to the
HTTP-style client. The HTTP-style client will pass this value back to the server (i.e., the RADIUS client) without modification. This attribute MUST only be used in Access- Request and Access-Challenge packets. Type 116 for Digest-Opaque Length >= 3 Text In Access-Requests, the RADIUS client takes the value of the opaque directive (opaque-value according to ) without surrounding quotes from the HTTP-style request it wants to authenticate and puts it into this attribute. In Access- Challenge packets, the RADIUS server MAY include this attribute. |
rfc5090 | |
Digest-Auth-Param |
This attribute is a placeholder for future extensions and
corresponds to the auth-param parameter defined in. The Digest-Auth-Param is the mechanism whereby the RADIUS client and RADIUS server can exchange auth- param extension parameters contained within Digest headers that are not understood by the RADIUS client and for which there are no corresponding stand-alone attributes. Unlike the previously listed Digest-* attributes, the Digest- Auth-Param contains not only the value but also the parameter name, since the parameter name is unknown to the RADIUS client. If the Digest header contains several unknown parameters, thenthe RADIUS implementation MUST repeat this attribute, and each instance MUST contain one different unknown Digest parameter/value combination. This attribute MUST ONLY be used in Access-Request, Access-Challenge, Access-Accept, and Accounting-Request packets. Type 117 for Digest-Auth-Param Length >= 3 Text The text consists of the whole parameter, including its name, the equal sign ('='), and quotes. |
rfc5090 | |
Digest-AKA-Auts |
This attribute holds the auts parameter that is used in the
Digest AKA calculation. It is only used if the algorithm of the digest-response denotes a version of AKA Digest . This attribute MUST only be used in Access- Request packets. Type 118 for Digest-AKA-Auts Length >= 3 Text In Access-Requests, the RADIUS client takes the value of the auts directive (auts-param according to) without surrounding quotes from the HTTP-style request it wants to authenticate. |
rfc5090 | |
Digest-Domain |
When a RADIUS client has asked for a nonce, the RADIUS server
MAY send one or more Digest-Domain attributes in its Access- Challenge packet. The RADIUS client puts them into the quoted, space-separated list of URIs of the domain directive of a WWW- Authenticate header. Together with Digest-Realm, the URIs in the list define the protection space (see ,) for some HTTP-style protocols. This attribute MUST only be used in Access-Challenge and Accounting-Request packets. Type 119 for Digest-Domain Length 3Text This attribute consists of a single URI that defines a protection space component. |
rfc5090 | |
Digest-Stale |
This attribute is sent by a RADIUS server in order to notify
the RADIUS client whether it has accepted a nonce. If the nonce presented by the RADIUS client was stale, the value is 'true' and is 'false' otherwise. The RADIUS client puts the content of this attribute into a stale directive of the WWW- Authenticate header in the HTTP-style response to the request it wants to authenticate. The attribute MUST only be used in Access-Challenge packets. Type 120 for Digest-Stale Length 3 Text The attribute has either the value 'true' or 'false' (both values without surrounding quotes). |
rfc5090 | |
Digest-HA1 |
This attribute is used to allow the generation of an
Authentication-Info header, even if the HTTP-style response's body is required for the calculation of the rspauth value. It SHOULD be used in Access-Accept packets if the required quality of protection (qop) is 'auth-int'. This attribute MUST NOT be sent if the qop parameter was not specified or has a value of 'auth' (in this case, use Digest- Response-Auth instead). The Digest-HA1 Attribute MUST only be sent by the RADIUS server or processed by the RADIUS client if at least one of the following conditions is true: + The Digest-Algorithm Attribute's value is 'MD5-sess' or 'AKAv1-MD5-sess'. + IPsec is configured to protect traffic between the RADIUS client and RADIUS server with IPsec (see). This attribute MUST only be used in Access-Accept packets.Type 121 for Digest-HA1 Length >= 3 Text This attribute contains the hexadecimal representation of H(A1) as described in , Sections,, and. |
rfc5090 | |
SIP-AOR |
This attribute is used for the authorization of SIP messages.
The SIP-AOR Attribute identifies the URI, the use of which must be authenticated and authorized. The RADIUS server uses this attribute to authorize the processing of the SIP request. The SIP-AOR can be derived from, for example, the To header field in a SIP REGISTER request (user under registration), or the From header field in other SIP requests. However, the exact mapping of this attribute to SIP can change due to new developments in the protocol. This attribute MUST only be used when the RADIUS client wants to authorize SIP users and MUST only be used in Access-Request packets. Type 122 for SIP-AOR Length >= 3 Text The syntax of this attribute corresponds either to a SIP URI (with the format defined in or a tel URI (with the format defined in ). The SIP-AOR Attribute holds the complete URI, including parameters and other parts. It is up to the RADIUS server as to which components of the URI are regarded in the authorization decision.4. Diameter CompatibilityThis document defines support for Digest Authentication in RADIUS. A companion document "Diameter Session Initiation Protocol (SIP) Application" defines support for Digest Authentication in Diameter, and addresses compatibility issues between RADIUS and Diameter.5. Table of AttributesThe following table provides a guide to which attributes may be found in which kinds of packets, and in what quantity.Access- Access- Access- Access- Acct- Request Accept Reject Challenge Req # Attribute 0-1 0 0 0 0-1 1 User-Name 0-1 0 0 1 0 24 State 1 1 1 1 0-1 80 Message-Authenticator 0-1 0 0 0 0 103 Digest-Response 0-1 0 0 1 0-1 104 Digest-Realm 0-1 0 0 1 0 105 Digest-Nonce 0 0-1 0 0 0 106 Digest-Response-Auth 0 0-1 0 0 0 107 Digest-Nextnonce 1 0 0 0 0-1 108 Digest-Method 0-1 0 0 0 0-1 109 Digest-URI 0-1 0 0 0+ 0-1 110 Digest-Qop 0-1 0 0 0-1 0-1 111 Digest-Algorithm 0-1 0 0 0 0 112 Digest-Entity-Body-Hash 0-1 0 0 0 0 113 Digest-CNonce 0-1 0 0 0 0 114 Digest-Nonce-Count 0-1 0 0 0 0-1 115 Digest-Username 0-1 0 0 0-1 0 116 Digest-Opaque 0+ 0+ 0 0+ 0+ 117 Digest-Auth-Param 0-1 0 0 0 0 118 Digest-AKA-Auts 0 0 0 0+ 0+ 119 Digest-Domain 0 0 0 0-1 0 120 Digest-Stale 0 0-1 0 0 0 121 Digest-HA1 0-1 0 0 0 0 122 SIP-AOR The following table defines the meaning of the above table entries. 0 This attribute MUST NOT be present in the packet. 0+ Zero or more instances of this attribute MAY be present in the packet. 0-1 Zero or one instance of this attribute MAY be present in the packet. Digest-HA1 MUST be used instead of Digest-Response-Auth if Digest-Qop is 'auth-int'. Digest-Response-Auth MUST be used instead of Digest-HA1 if Digest-Qop is 'auth'. If Digest-Algorithm is missing, 'MD5' is assumed. An Access-Challenge MUST contain a State attribute, which is copied to the subsequent Access-Request. A server receiving an Access-Request that contains a State attribute MUST respond with either an Access-Accept or an Access-Reject; the server MUST NOT respond with an Access-Challenge.6. ExamplesThis is an example selected from the traffic between a softphone (A), a Proxy Server (B), and an example.com RADIUS server (C). The communication between the Proxy Server and a SIP Public Switched Telephone Network (PSTN) gateway is omitted for brevity. The SIP messages are not shown completely. The password of user '12345678' is 'secret'. The shared secret between the RADIUS client and server is 'secret'. To ease testing, only the last byte of the RADIUS authenticator changes between requests. In a real implementation, this would be a serious flaw. A->B INVITE sip:[email protected] SIP/2.0 From: <sip:[email protected]> To: <sip:[email protected]> B->A SIP/2.0 100 Trying B->C Code = Access-Request (1) Packet identifier = 0x7c (124) Length = 97 Authenticator = F5E55840E324AA49D216D9DBD069807C NAS-IP-Address = 192.0.2.38 NAS-Port = 5 User-Name = 12345678 Digest-Method = INVITE Digest-URI = sip:[email protected] Message-Authenticator = 7600D5B0BDC33987A60D5C6167B28B3B C->B Code = Access-challenge (11) Packet identifier = 0x7c (124) Length = 72 Authenticator = EBE20199C26EFEAD69BF8AB0E786CA4D Digest-Nonce = 3bada1a0 Digest-Realm = example.com Digest-Qop = auth Digest-Algorithm = MD5 Message-Authenticator = 5DA18ED3BBC9513DCBDE0A37F51B7DE3B->A SIP/2.0 407 Proxy Authentication Required Proxy-Authenticate: Digest realm="example.com" ,nonce="3bada1a0",qop=auth,algorithm=MD5 Content-Length: 0 A->B ACK sip:[email protected] SIP/2.0 A->B INVITE sip:[email protected] SIP/2.0 Proxy-Authorization: Digest nonce="3bada1a0" ,realm="example.com" ,response="756933f735fcd93f90a4bbdd5467f263" ,uri="sip:[email protected]",username="12345678" ,qop=auth,algorithm=MD5 ,cnonce="56593a80,nc="00000001" From: <sip:[email protected]> To: <sip:[email protected]> B->C Code = Access-Request (1) Packet identifier = 0x7d (125) Length = 221 Authenticator = F5E55840E324AA49D216D9DBD069807D NAS-IP-Address = 192.0.2.38 NAS-Port = 5 User-Name = 12345678 Digest-Method = INVITE Digest-URI = sip:[email protected] Digest-Realm = example.com Digest-Qop = auth Digest-Algorithm = MD5 Digest-CNonce = 56593a80 Digest-Nonce = 3bada1a0 Digest-Nonce-Count = 00000001 Digest-Response = 756933f735fcd93f90a4bbdd5467f263 Digest-Username = 12345678 SIP-AOR = sip:[email protected] Message-Authenticator = B6C7F7F8D11EF261A26933D234561A60C->B Code = Access-Accept (2) Packet identifier = 0x7d (125) Length = 72 Authenticator = FFDD74D6470D21CB6FC4D6056BE245D2 Digest-Response-Auth = f847de948d12285f8f4199e366f1af21 Message-Authenticator = 7B76E2F10A7067AF601938BF13B0A62E B->A SIP/2.0 180 Ringing B->A SIP/2.0 200 OK A->B ACK sip:[email protected] SIP/2.0 A second example shows the traffic between a web browser (A), a web server (B), and a RADIUS server (C). A->B GET /index.html HTTP/1.1 B->C Code = Access-Request (1) Packet identifier = 0x7e (126) Length = 68 Authenticator = F5E55840E324AA49D216D9DBD069807E NAS-IP-Address = 192.0.2.38 NAS-Port = 5 Digest-Method = GET Digest-URI = /index.html Message-Authenticator = 690BFC95E88DF3B185F15CD78E469992C->B Code = Access-challenge (11) Packet identifier = 0x7e (126) Length = 72 Authenticator = 2EE5EB01C02C773B6C6EC8515F565E8E Digest-Nonce = a3086ac8 Digest-Realm = example.com Digest-Qop = auth Digest-Algorithm = MD5 Message-Authenticator = 646DB2B0AF9E72FFF2CF7FEB33C4952A B->A HTTP/1.1 401 Authentication Required WWW-Authenticate: Digest realm="example.com", nonce="a3086ac8",qop=auth,algorithm=MD5 Content-Length: 0 A->B GET /index.html HTTP/1.1 Authorization: Digest = algorithm=MD5,qop=auth,nonce="a3086ac8" ,nc="00000001",cnonce="56593a80" ,realm="example.com" ,response="a4fac45c27a30f4f244c54a2e99fa117" ,uri="/index.html",username="12345678" B->C Code = Access-Request (1) Packet identifier = 0x7f (127) Length = 176 Authenticator = F5E55840E324AA49D216D9DBD069807F NAS-IP-Address = 192.0.2.38 NAS-Port = 5 User-Name = 12345678 Digest-Method = GET Digest-URI = /index.html Digest-Realm = example.com Digest-Qop = auth Digest-Algorithm = MD5 Digest-CNonce = 56593a80 Digest-Nonce = a3086ac8 Digest-Nonce-Count = 00000001 Digest-Response = a4fac45c27a30f4f244c54a2e99fa117 Digest-Username = 12345678 Message-Authenticator = 237D85C1478C70C67EEAF22A9C456821C->B Code = Access-Accept (2) Packet identifier = 0x7f (127) Length = 72 Authenticator = 6364FA6ED66012847C05A0895607C694 Digest-Response-Auth = 08c4e942d1d0a191de8b3aa98cd35147 Message-Authenticator = 43795A3166492AD2A890AD57D5F97D56 B->A HTTP/1.1 200 OK ... <html> ...7. IANA ConsiderationsThe following values from the RADIUS Attribute Types number space were assigned in . This document requests that the values in the table below be entered within the existing registry. Attribute # --------------- ---- Digest-Response 103 Digest-Realm 104 Digest-Nonce 105 Digest-Response-Auth 106 Digest-Nextnonce 107 Digest-Method 108 Digest-URI 109 Digest-Qop 110 Digest-Algorithm 111 Digest-Entity-Body-Hash 112 Digest-CNonce 113 Digest-Nonce-Count 114 Digest-Username 115 Digest-Opaque 116 Digest-Auth-Param 117 Digest-AKA-Auts 118 Digest-Domain 119 Digest-Stale 120 Digest-HA1 121 SIP-AOR 1228. Security ConsiderationsThe RADIUS extensions described in this document enable RADIUS to transport the data that is required to perform a digest calculation. As a result, RADIUS inherits the vulnerabilities of HTTP Digest (see) in addition to RADIUS security vulnerabilities described in, and. An attacker compromising a RADIUS client or proxy can carry out man- in-the-middle attacks even if the paths between A, B and B, C (Figure 2) have been secured with TLS or IPsec. The RADIUS server MUST check the Digest-Realm Attribute it has received from a client. If the RADIUS client is not authorized to serve HTTP-style clients of that realm, it might be compromised. |
rfc5090 | |
MIP6-Feature-Vector |
Diameter reserves AVP Code space 1-255 as RADIUS attribute
compatibility space. The MIP6-Feature-Vector attribute (Type value 124) defined in is of type OctetString and contains a 64-bit flags field of supported mobility capabilities. This document reserves two new capability bits according to the rules in , and reuses the PMIPv6 capability bits defined by . The following capability flag bits are used or defined in this document: PMIP6_SUPPORTED (0x0000010000000000) This capability bit is used as defined in . IP4_HOA_SUPPORTED (0x0000020000000000) This capability bit is used as defined in . Assignment of the IPv4-HoA (Home Address) is defined by .LOCAL_MAG_ROUTING_SUPPORTED (0x0000040000000000) This capability bit is used as defined in . IP4_TRANSPORT_SUPPORTED (0x0000800000000000) This capability bit is used for negotiation of the IPv4 transport support between the MAG and AAA. When the MAG sets this flag bit in the MIP6-Feature-Vector, it indicates the ability of the MAG to provide IPv4 transport (i.e., IPv4-based encapsulation) for carrying IP traffic between the MAG and the LMA. If this flag bit is unset in the returned MIP6-Feature-Vector attribute, the AAA does not authorize the use of IPv4 transport on the MAG-to-LMA tunnel. IP4_HOA_ONLY_SUPPORTED (0x0001000000000000) This capability bit is used for determination of the authorized PMIPv6 mobility mode. When this bit is set by the AAA, it indicates PMIPv6 mobility with IPv4 support has only been authorized for the MN. As a result, the RADIUS Access-Accept SHOULD NOT carry the IPv6 Home Network Prefix (IPv6 HNP). When this bit is set, the PMIP6_SUPPORTED flag MUST also be set and the IP4_HOA_SUPPORTED flag MUST NOT be set. To summarize the use of the MIP6-Feature-Vector the following capability bit combination settings mean: PMIP6-SUPPORTED bit set - only IPv6 mobility is supported and authorized. PMIP6-SUPPORTED and IP4-ONLY-HOA-SUPPORTED bits set - only IPv4 mobility is supported and authorized. PMIP6-SUPPORTED and IP4-HOA-SUPPORTED bits set - both IPv6 and IPv4 mobility are supported and authorized. The MIP6-Feature-Vector attribute is also used on the LMA to the RADIUS AAA interface. This capability announcement attribute enables direct capability negotiation between the LMA and the AAA. The capabilities that are announced by both parties in the MIP6-Feature- Vector are known to be mutually supported. The LMA may use this mechanism during authorization of the received PBU against the AAA to check individual PMIPv6 feature permissions for a particular MN. If the RADIUS Access-Accept contains a contradicting combination of the capability flag bits such as both the IP4_HOA_ONLY_SUPPORTED and the IP4_HOA_SUPPORTED flags being set, then the RADIUS client MUSTtreat the Access-Accept as an Access-Reject and SHOULD log the event. Similarly, if the RADIUS Access-Request contains a contradicting combination of the capability flag bits, then the RADIUS server MUST reply with an Access-Reject message and SHOULD log the event. |
rfc5447 | |
MIP6-Home-Link-Prefix |
|
rfc5447 | |
Operator-Name |
|
rfc5580 | |
Location-Information |
|
rfc5580 | |
Location-Data |
|
rfc5580 | |
Basic-Location-Policy-Rules |
|
rfc5580 | |
Extended-Location-Policy-Rules |
|
rfc5580 | |
Location-Capable |
|
Geo-Location, Users-Location, NAS-Location ... | rfc5580 |
Requested-Location-Info |
|
Geo-Location, Users-Location, NAS-Location ... | rfc5580 |
Framed-Management |
|
Web-Based, Netconf, FTP ... | rfc5607 |
Management-Transport-Protection |
|
Integrity-Protection, Integrity-Confidentiality-Protection | rfc5607 |
Management-Policy-Id |
|
rfc5607 | |
Management-Privilege-Level |
|
rfc5607 | |
PKM-SS-Cert |
The PKM-SS-Cert Attribute is variable length and MAY be
transmitted in the Access-Request message. The Value field is of type string and contains the X.509 certificate binding a public key to the identifier of the Subscriber Station. The minimum size of an SS certificate exceeds the maximum size of a RADIUS attribute. Therefore, the client MUST encapsulate the certificate in the Value fields of two or more instances of the PKM-SS-Cert Attribute, each (except possibly the last) having a length of 255 octets. These multiple PKM-SS-Cert Attributes MUST appear consecutively and in order within the packet. Upon receipt, the RADIUS server MUST recover the original certificate by concatenating the Value fields of the received PKM-SS-Cert Attributes in order. A summary of the PKM-SS-Cert Attribute format is shown below. The fields are transmitted from left to right. 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 | Len | Value... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 137 for PKM-SS-Cert Len > 2 Value The Value field is variable length and contains a (possibly complete) portion of an X.509 certificate. |
rfc5904 | |
PKM-CA-Cert |
The PKM-CA-Cert Attribute is variable length and MAY be
transmitted in the Access-Request message. The Value field is of type string and contains the X.509 certificate used by the CA to sign the SS certificate carried in the PKM-SS-Cert attribute () in the same message. The minimum size of a CA certificate exceeds the maximum size of a RADIUS attribute. Therefore, the client MUST encapsulate the certificate in the Value fields of two or more instances of the PKM-CA-Cert Attribute, each (except possibly the last) having a length of 255 octets. These multiple PKM-CA-Cert Attributes MUST appear consecutively and in order within the packet. Upon receipt, the RADIUS server MUST recover the original certificate by concatenating the Value fields of the received PKM-CA-Cert Attributes in order. A summary of the PKM-CA-Cert Attribute format is shown below. The fields are transmitted from left to right. 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 | Len | Value... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 138 for PKM-CA-Cert Len > 2 Value The Value field is variable length and contains a (possibly complete) portion of an X.509 certificate. |
rfc5904 | |
PKM-Config-Settings |
The PKM-Config-Settings Attribute is of type string . It
is 30 octets in length and consists of seven independent fields, each of which is conceptually an unsigned integer. Each of the fields contains a timeout value and corresponds to a Type-Length- Value (TLV) tuple encapsulated in the IEEE 802.16 "PKM configuration settings" attribute; for details on the contents of each field, see Section 11.9.19 of . One instance of the PKM-Config-Settings Attribute MAY be included in the Access-Accept message. A summary of the PKM-Config-Settings Attribute format is shown below. The fields are transmitted from left to right. 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 | Len | Auth Wait Timeout +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Auth Wait Timeout (cont.) | Reauth Wait Timeout +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Reauth Wait Timeout (cont.) | Auth Grace Time +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Auth Grace Time (cont.) | Op Wait Timeout +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Op Wait Timeout (cont.) | Rekey Wait Timeout +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Rekey Wait Timeout (cont.) | TEK Grace Time +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ TEK Grace Time (cont.) | Auth Rej Wait Timeout +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Auth Rej Wait Timeout (cont.) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 139 for PKM-Config-Settings Len 30Auth Wait Timeout The Auth Wait Timeout field is 4 octets in length and corresponds to the "Authorize wait timeout" field of the 802.16 "PKM configuration settings" attribute. Reauth Wait Timeout The Reauth Wait Timeout field is 4 octets in length and corresponds to the "Reauthorize wait timeout" field of the 802.16 "PKM configuration settings" attribute. Auth Grace Time The Auth Grace Time field is 4 octets in length and corresponds to the "Authorize grace time" field of the 802.16 "PKM configuration settings" attribute. Op Wait Timeout The Op Wait Timeout field is 4 octets in length and corresponds to the "Operational wait timeout" field of the 802.16 "PKM configuration settings" attribute. Rekey Wait Timeout The Rekey Wait Timeout field is 4 octets in length and corresponds to the "Rekey wait timeout" field of the 802.16 "PKM configuration settings" attribute. TEK Grace Time The TEK Grace Time field is 4 octets in length and corresponds to the "TEK grace time" field of the 802.16 "PKM configuration settings" attribute. Auth Rej Wait Timeout The Auth Rej Wait Timeout field is 4 octets in length and corresponds to the "Authorize reject wait timeout" field of the 802.16 "PKM configuration settings" attribute. |
rfc5904 | |
PKM-Cryptosuite-List |
The PKM-Cryptosuite-List Attribute is of type string and
is variable length; it corresponds roughly to the "Cryptographic- Suite-List" 802.16 attribute (see Section 11.19.15 of ), the difference being that the RADIUS Attribute contains only the list of 3-octet cryptographic suite identifiers, omitting the IEEE Type and Length fields. The PKM-Cryptosuite-List Attribute MAY be present in an Access- Request message. Any message in which the PKM-Cryptosuite-List Attribute is present MUST also contain an instance of the Message- Authenticator Attribute . Implementation Note The PKM-Cryptosuite-List Attribute is used as a building block to create the 802.16 "Security-Capabilities" attribute (, Section 11.9.13); since this document only pertains to PKM version 1, the "Version" sub-attribute in that structure MUST be set to 0x01 when the RADIUS client constructs it. A summary of the PKM-Cryptosuite-List Attribute format is shown below. The fields are transmitted from left to right. 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 | Len | Value... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 140 for PKM-Cryptosuite-List Len 2 + 3n < 39, where 'n' is the number of cryptosuite identifiers in the list.Value The Value field is variable length and contains a sequence of one or more cryptosuite identifiers, each of which is 3 octets in length and corresponds to the Value field of an IEEE 802.16 Cryptographic-Suite attribute. |
rfc5904 | |
PKM-SAID |
The PKM-SAID Attribute is of type string . It is 4
octets in length and contains a PKM Security Association Identifier (, Section 11.9.7). It MAY be included in an Access-Request message. A summary of the PKM-SAID Attribute format is shown below. The fields are transmitted from left to right. 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 | Len | SAID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 141 for PKM-SAID Len 4 SAID The SAID field is two octets in length and corresponds to the Value field of the 802.16 PKM SAID attribute |
rfc5904 | |
PKM-SA-Descriptor |
The PKM-SA-Descriptor Attribute is of type string and is 8 octets
in length. It contains three fields, described below, which together specify the characteristics of a PKM security association. One or more instances of the PKM-SA-Descriptor Attribute MAY occur in an Access-Accept message.A summary of the PKM-SA-Descriptor Attribute format is shown below. The fields are transmitted from left to right. 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 | Len | SAID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SA Type | Cryptosuite | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 142 for PKM-SA-Descriptor Len 8 SAID The SAID field is two octets in length and contains a PKM SAID (). SA Type The SA Type field is one octet in length. The contents correspond to those of the Value field of an IEEE 802.16 SA-Type attribute. Cryptosuite The Cryptosuite field is 3 octets in length. The contents correspond to those of the Value field of an IEEE 802.16 Cryptographic-Suite attribute. |
rfc5904 | |
PKM-Auth-Key |
|
rfc5904 | |
DS-Lite-Tunnel-Name |
|
rfc6519 | |
Mobile-Node-Identifier |
The Mobile-Node-Identifier attribute (Type value 145) is of type
String and contains the mobile node identifier (MN-Identifier), see , in a form of a Network Access Identifier (NAI) . This identifier and the identifier used for access authentication may be different; however, there needs to be a mapping between the two identities as specified in. This attribute is used on the interface between the MAG and the AAA server. The Mobile-Node-Identifier attribute is designed for deployments where the identity used during network access authentication and the identity used for mobility management is decoupled. It may also be the case where the MAG does not have means to find out the MN identity that could be used in subsequent PBU and Proxy Binding Acknowledgement (PBA) exchanges (e.g., due to identity hiding during the network access authentication) or when the HAAA wants to assign periodically changing identities to the MN. The Mobile-Node-Identifier attribute MAY be returned by the HAAA in the RADIUS Access-Accept message that completes a successful authentication and authorization exchange between the MAG and the HAAA. The MAG MUST use the received MN-Identifier. 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 | Mobile Node Identifier... ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: Mobile-Node-Identifier 145. Length: In octets, including Type and Length fields (>= 3). Mobile Node Identifier: This field is of type String and contains the MN-Identifier of the MN to be used in the PBU/PBA exchange. |
rfc6572 | |
Service-Selection |
The Service-Selection attribute (Type value 146) is of type UTF-8
text and contains the name of the service or the external network with which the mobility service for the particular MN SHOULD be associated . The identifier MUST be unique within the PMIPv6 Domain when normalized using the selected normalization form for the particular PMIPv6 Domain deployment. For instance, uses the Normalization Form KC (NFKC). The MAG MUST include the Service-Selection attribute in the Access- Request sent to the AAA if the information was acquired, e.g., by operator-specific configuration. The AAA MAY include the Service- Selection attribute in the Access-Accept response message to the MAG even if it was not included in the Access-Request as a means of indicating the MN's default service. The Service Selection mobility option defined in can be used in PBU/PBA messages between the MAG and LMA. On the LMA-to-AAA interface, the LMA MAY populate the Service-Selection attribute in the Access-Request message using the service information found in the received PBU, if such a mobility option were included. The Service- Selection identifier should be used to assist the PBU authorization, the assignment of the MN-HNP, and the IPv4-MN-HoA as described in and . 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 | Service Identifier... ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: Service-Selection 146. Length: In octets, including Type and Length fields (>= 3). Text: This field is of type UTF-8 text and contains the Service Identifier with which the MN is associated. |
rfc6572 | |
PMIP6-Home-LMA-IPv6-Address |
The PMIP6-Home-LMA-IPv6-Address attribute (Type value 147) is of type
IPv6 address and is used to deliver the IPv6 address of the LMA located in the home network.Before the MAG can initiate Proxy Mobile IPv6 signaling, it must be aware of the LMA's IP address. When the LMA is assigned to the MN from the home network, this attribute MAY be sent by the HAAA to the MAG in the RADIUS Access- Accept message. 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 | Home LMA IPv6 address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Home LMA IPv6 address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Home LMA IPv6 address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Home LMA IPv6 address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Home LMA IPv6 address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: PMIP6-Home-LMA-IPv6-Address 147. Length: = 18 octets Home LMA IPv6 address: 128-bit IPv6 address of the assigned home LMA IPv6 address. |
rfc6572 | |
PMIP6-Visited-LMA-IPv6-Address |
The PMIP6-Visited-LMA-IPv6-Address attribute (Type value 148) is of
type IPv6 address and is used to propose a particular LMA in the visited network and to authorize the use of the LMA in the visited/ local network. PMIP6-Visited-LMA-IPv6-Address attribute MAY be included by the MAG in the RADIUS Access-Request message. The LMA in the visited/local network may be assigned by the AAA as the result of retrieved policy profile. If included by the AAA in the RADIUS Access- Accept sent to the MAG, the use of the LMA in the visited/local network is authorized and the attribute SHALL carry the IPv6 address of the LMA assigned for the particular MN. Seehow the MIP6-Feature-Vector attribute and LOCAL_HOME_AGENT_ASSIGNMENT capability flag is used with the LMA (Home Agent) assignment.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 | Visited LMA IPv6 address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Visited LMA IPv6 address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Visited LMA IPv6 address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Visited LMA IPv6 address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Visited LMA IPv6 address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: PMIP6-Visited-LMA-IPv6-Address 148. Length: = 18 octets Visited LMA IPv6 address: 128-bit IPv6 address of the assigned visited LMA IPv6 address. |
rfc6572 | |
PMIP6-Home-LMA-IPv4-Address |
The PMIP6-Home-LMA-IPv4-Address attribute (Type value 149) is of type
IPv4 address and contains the IPv4 address of the LMA assigned by the HAAA. The supports Proxy Mobile IPv6 signaling exchange between MAG and LMA using the IPv4 transport. When the LMA is located in the home network, this attribute MAY be sent by the HAAA to the MAG in the RADIUS Access-Accept message. 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 | Home LMA IPv4 address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Home LMA IPv4 address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: PMIP6-Home-LMA-IPv4-Address 149. Length: = 6 octetsHome LMA IPv4 address: 32-bit IPv4 address of the assigned LMA. |
rfc6572 | |
PMIP6-Visited-LMA-IPv4-Address |
The PMIP6-Visited-LMA-IPv4-Address attribute (Type value 150) is of
type IPv4 address and is used to propose a particular LMA in the visited network and to authorize the use of the LMA in the visited network. PMIP6-Visited-LMA-IPv4-Address attribute MAY be included by the MAG in the RADIUS Access-Request message. The LMA in the visited/local network may be assigned by the AAA as the result of retrieved policy profile. If included by the AAA in the RADIUS Access- Accept sent to the MAG, the use of the LMA in the visited/local network is authorized and the attribute SHALL carry the IPv4 address of the LMA assigned for the particular MN. Seehow the MIP6-Feature-Vector attribute and LOCAL_HOME_AGENT_ASSIGNMENT capability flag is used with the LMA (Home Agent) assignment. 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 | Visited LMA IPv4 address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Visited LMA IPv4 address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: PMIP6-Visited-LMA-IPv4-Address 150. Length: = 6 octets IPv4 LMA address: 32-bit IPv4 address of the assigned LMA. |
rfc6572 | |
PMIP6-Home-HN-Prefix |
The PMIP6-Home-HN-Prefix attribute (Type value 151) is of type IPv6
prefix. It contains the Mobile Node - Home Network Prefix (MN-HNP), which is the IPv6 prefix assigned to the link between the MN and the MAG. The MN configures its IP interface from its home network prefix(es). When the LMA is located in the home network, the PMIP6- Home-HN-Prefix attribute is used to deliver the MN-HNP from the HAAA to the MAG.The PMIP6-Home-HN-Prefix attribute is also used on the LMA-to-HAAA interface containing the prefix assigned to the MN. If the LMA delegates the MN-HNP assignment to the HAAA, the attribute MUST contain all zeroes in the address of (i.e., '::') the Access-Request message. The attribute MUST be present in the RADIUS Access-Accept message if the prior request already included one and SHOULD carry the MN-HNP the HAAA assigned to the MN. 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 | Reserved | Prefix-Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Home MN-HNP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Home MN-HNP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Home MN-HNP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Home MN-HNP | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: PMIP6-Home-HN-Prefix 151. Length: = at least 4 and no larger than 20. Reserved: Reserved for future use. The bits MUST be set to zero by the sender and MUST be ignored by the receiver. Prefix-Length: The 8-bit unsigned integer indicating the prefix length of the home network prefix (at least 0 and no larger than 128). If the home network prefix contains an address of all zeroes (i.e., '::'), then the Prefix-Length MUST be set to 128. Home Network Prefix: The home network prefix for the MN's IPv6 address configuration. The Prefix field is up to 16 octets in length. Bits outside of the Prefix-Length, if included, must be zero. |
rfc6572 | |
PMIP6-Visited-HN-Prefix |
The PMIP6-Visited-HN-Prefix attribute (Type value 152) is of type
IPv6 prefix. It contains the Mobile Node - Home Network Prefix (MN- HNP), which is the IPv6 prefix assigned to the link between the MNand the MAG. The MN configures its IP interface from its home network prefix(es). When the LMA is located in the visited network, the PMIP6-Visited-HN-Prefix attribute is used to deliver the MN-HNP from the VAAA to the MAG. The PMIP6-Visited-HN-Prefix attribute is also used on the LMA-to-VAAA interface containing the IPv6 prefix assigned to the MN. If the LMA delegates the assignment of the MN-HNP to the VAAA, the attribute MUST contain an address of all zeroes (i.e., '::') in the RADIUS Access-Request message. The attribute MUST be present in Access- Accept message if the prior request already included one and SHOULD carry the MN-HNP the VAAA assigned to the MN. The attribute SHOULD NOT be included if the use of LMA in the home network is authorized (the PMIP6-Home-HN-Prefix and/or PMIP6-Home- LMA-IPv6-Address attributes are already present). However, if the VAAA local policy allows both home and visited LMA addresses to be delivered to the MAG, then this attribute MAY also be included. 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 | Reserved | Prefix-Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Visited MN-HNP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Visited MN-HNP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Visited MN-HNP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Visited MN-HNP | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: PMIP6-Visited-HN-Prefix 152. Length: = at least 4 and no larger than 20. Reserved: Reserved for future use. The bits MUST be set to zero by the sender and MUST be ignored by the receiver. Prefix-Length: The 8-bit unsigned integer indicating the prefix length of the Visited MN-HNP (at least 0 and no larger than 128). If the visited home network prefix contains an address of all zeroes (i.e., '::'), then the Prefix-Length MUST be set to 128.Visited Home Network Prefix: The home network prefix for the MN's IPv6 address configuration. The Prefix field is up to 16 octets in length. Bits outside of the Prefix-Length, if included, must be zero. |
rfc6572 | |
PMIP6-Home-Interface-ID |
The PMIP6-Home-Interface-ID attribute (Type value 153) is of type
String and contains the MN's interface identifier. The selection of the interface identifier SHOULD NOT allow the tracking of individual MNs or users between PMIPv6 mobility sessions for privacy reasons. This attribute is applicable in network systems and link technologies, where the network explicitly delivers an interface identifier to the MN during the link setup. Third Generation Partnership Project (3GPP) and PPP link technologies are examples of such. This attribute MAY be sent by the LMA or the MAG to the HAAA in the RADIUS Access-Request packet as a proposal. This attribute MAY be sent by the HAAA to the LMA or to the MAG in an Access-Accept packet; however, it MUST be present if the prior request already included one. 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 | Home Interface Identifier +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Home Interface Identifier +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Home Interface Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: PMIP6-Home-Interface-ID 153. Length: = 10 octets. Home Interface Identifier: The 64-bit long interface identifier (8 octets). |
rfc6572 | |
PMIP6-Visited-Interface-ID |
The PMIP6-Visited-Interface-ID attribute (Type value 154) is of type
String and contains the MN's interface identifier. The selection of the interface identifier SHOULD NOT allow the tracking of individual MNs or users between PMIPv6 mobility session for privacy reasons.This attribute is applicable in network systems and link technologies, where the network explicitly delivers an interface identifier to the MN during the link setup. 3GPP and PPP link technologies are examples of such. This attribute MAY be sent by the LMA or the MAG to the VAAA in the RADIUS Access-Request packet as a proposal. This attribute MAY be sent by the VAAA to the LMA or to the MAG in an Access-Accept packet; however, it MUST be present if the prior request already included one. 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 | Visited Interface Identifier +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Visited Interface Identifier +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Visited Interface Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: PMIP6-Visited-Interface-ID 154. Length: = 10 octets. Visited Interface Identifier: The 64-bit long interface identifier (8 octets). |
rfc6572 | |
PMIP6-Home-IPv4-HoA |
specifies extensions to Proxy Mobile IPv6 protocol that
enable IPv4 home address mobility support to the MN. The PMIP6-Home- IPv4-HoA attribute (Type value 155) is of type Address and contains the IPv4 Home Address of the MN. The primary use of this attribute is to deliver the assigned IPv4-HoA from HAAA to the MAG. The PMIP6-Home-IPv4-HoA is also used on the LMA-to-HAAA interface. If the LMA in the home network delegates the assignment of the IPv4-HoA to the HAAA, the attribute MUST contain an address of all zeroes (i.e., 0.0.0.0) in the Access-Request message. The attribute MUST be included in by HAAA in the Access-Accept message if the previous request included it, and it contains the IPv4-HoA assigned to the MN.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 | Reserved |Prefix-Len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Home IPv4 HoA | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: PMIP6-Home-IPv4-HoA 155. Length: = 8 octets Reserved The 10-bit field reserved for future use. The value MUST be initialized to zero by sender and MUST be ignored by the receiver. Prefix-Len The 6-bit unsigned integer indicating the prefix length of the IPv4 HoA. If the Home IPv4 HoA contains an address of all zeroes (i.e., '0.0.0.0'), then the Prefix-Len MUST be set to 32. Home IPv4 HoA: This field is of type Address and contains the IPv4 home address of the MN in the home network. |
rfc6572 | |
PMIP6-Visited-IPv4-HoA |
When both the MAG and the LMA are in the visited network, the PMIP6-
Visited-IPv4-HoA attribute (Type value 156) is of type Address and is used to exchange information between the VAAA and the MAG on the assignment of the IPv4 Home Address to the MN being present in the visited network. The PMIP6-Visited-IPv4-HoA is also used on the LMA-to-VAAA interface. If the LMA delegates the assignment of the IPv4-HoA to the VAAA, the attribute MUST contain an address of all zeroes (i.e., 0.0.0.0) in the RADIUS Access-Request message. The Access-Accept message MUST have the attribute present if the prior request to the VAAA already included one. The attribute SHOULD NOT be included if the use of the LMA in the home network is authorized (the PMIP6-Home-IPv4-HoA and/or PMIP6- Home-LMA-IPv4-Address attributes are already present). However, if the VAAA local policy allows both home and visited LMA addresses to be delivered to the MAG, then this attribute MAY also be included.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 | Reserved |Prefix-Len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Visited IPv4 HoA | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: PMIP6-Visited-IPv4-HoA 156. Length: = 8 octets Reserved: The 10-bit field reserved for future use. The value MUST be initialized to zero by the sender and MUST be ignored by the receiver. Prefix-Len: 6-bit unsigned integer indicating the prefix length of the IPv4 HoA. If the Visited IPv4 HoA contains an address of all zeroes (i.e., '0.0.0.0'), then the Prefix-Len MUST be set to 32. Visited IPv4 HoA: This field is of type Address and contains the IPv4 home address of the MN in the visited network. |
rfc6572 | |
PMIP6-Home-DHCP4-Server-Address |
The PMIP6-Home-DHCP4-Server-Address (Type value 157) is of type
Address and contains the IPv4 address of the DHCPv4 server in the home network. The particular DHCP server address is indicated to the MAG that serves the concerning MN. The HAAA MAY assign a DHCP server to the MAG in deployments where the MAG acts as a DHCP Relay, as defined in . 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 | Home DHCPv4 server address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Home DHCPv4 server address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: PMIP6-Home-DHCP4-Server-Address 157.Length: = 6 octets. Home DHCPv4 server address: This field is of type Address and contains a 4-octet IPv4 address of the DHCP server. |
rfc6572 | |
PMIP6-Visited-DHCP4-Server-Address |
The PMIP6-Visited-DHCP4-Server-Address attribute (Type value 158) is
of type Address and delivers the IPv4 address of the DHCPv4 server from the visited network to the MAG. When both the MAG and the LMA are in the visited network, the VAAA MAY assign a DHCPv4 server to the MAG in deployments where the MAG acts as a DHCP Relay, as defined in . 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 | Visited DHCPv4 server address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Visited DHCPv4 server address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: PMIP6-Visited-DHCP4-Server-Address 158. Length: = 6 octets Visited DHCPv4 server address: This field is of type Address and contains a 4-octet IPv4 address of the DHCPv4 server. |
rfc6572 | |
PMIP6-Home-DHCP6-Server-Address |
The PMIP6-Home-DHCP6-Server-Address (Type value 159) is of type IPv6
address and contains the IPv6 address of the DHCPv6 server in the home network indicated by the HAAA to the MAG that serves the MN. The HAAA MAY assign a DHCPv6 server to the MAG in deployments where the MAG acts as a DHCP Relay, as defined in .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 | Home DHCPv6 server address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Home DHCPv6 server address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Home DHCPv6 server address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Home DHCPv6 server address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Home DHCPv6 server address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: PMIP6-Home-DHCP6-Server-Address 159. Length: = 18 octets Home DHCPv6 server address: This field is of type Address and contains 16-octet IPv6 address of the DHCPv6 server. |
rfc6572 | |
PMIP6-Visited-DHCP6-Server-Address |
The PMIP6-Visited-DHCP6-Server-Address attribute (Type value 160) is
of type IPv6 address and contains the IPv6 address of the DHCPv6 server in the visited network indicated by the VAAA to the MAG that serves the MN. When both MAG and the LMA are located in the visited network, the VAAA MAY assign a DHCPv6 server to the MAG in deployments where the MAG acts as a DHCP Relay, as defined in .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 | Visited DHCPv6 server address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Visited DHCPv6 server address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Visited DHCPv6 server address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Visited DHCPv6 server address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Visited DHCPv6 server address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: PMIP6-Visited-DHCP6-Server-Address 160. Length: = 18 octets Visited DHCPv6 server address: This field is of type Address and contains the 16-octet IPv6 address of the DHCPv6 server. |
rfc6572 | |
PMIP6-Home-IPv4-Gateway |
specifies extensions to Proxy Mobile IPv6 protocol that
enable IPv4 home address mobility support to the MN. The PMIP6-Home- IPv4-Gateway attribute (Type value 161) is of type Address and contains the default gateway IPv4 address for the MN. This address is populated into the PMIPv6 IPv4 Default-Router Address Option . The address MUST belong to the subnet defined in the PMIP6-Home-IPv4-HoA 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 | Home IPv4 default gateway +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: PMIP6-Home-IPv4-Gateway 161. Length: = 6 octets Home IPv4 default gateway address: This field is of type Address and contains a 4-octet IPv4 default gateway address. |
rfc6572 | |
PMIP6-Visited-IPv4-Gateway |
specifies extensions to Proxy Mobile IPv6 protocol that
enable IPv4 home address mobility support to the MN. The PMIP6- Visited-IPv4-Gateway attribute (Type value 162) is of type Address and contains the default gateway IPv4 address for the MN. This address is populated into the PMIPv6 IPv4 Default-Router Address Option . The address MUST belong to the subnet defined in the PMIP6-Visited-IPv4-HoA 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 | Visited IPv4 default gateway +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: PMIP6-Visited-IPv4-Gateway 162. Length: = 6 octets Visited IPv4 default gateway address: This field is of type Address and contains a 4-octet IPv4 default gateway address.5. MAG to RADIUS AAA Interface |
rfc6572 | |
EAP-Lower-Layer |
|
IEEE-802.1X-No-Preauth, IEEE-802.1X-Preauth, IEEE-802.16e ... | rfc6677 |
Framed-IPv6-Address |
|
rfc6911 | |
DNS-Server-IPv6-Address |
|
rfc6911 | |
Route-IPv6-Information |
|
rfc6911 | |
Delegated-IPv6-Prefix-Pool |
|
rfc6911 | |
Stateful-IPv6-Address-Pool |
|
rfc6911 | |
IPv6-6rd-Configuration |
|
rfc6930 | |
IPv6-6rd-IPv4MaskLen |
|
rfc6930 | |
IPv6-6rd-Prefix |
|
rfc6930 | |
IPv6-6rd-BR-IPv4-Address |
|
rfc6930 | |
GSS-Acceptor-Service-Name |
|
rfc7055 | |
GSS-Acceptor-Host-Name |
|
rfc7055 | |
GSS-Acceptor-Service-Specifics |
|
rfc7055 | |
GSS-Acceptor-Realm-Name |
|
rfc7055 | |
Originating-Line-Info |
|
rfc7155 | |
Allowed-Called-Station-Id |
The Allowed-Called-Station-Id Attribute allows the RADIUS server
to specify the authenticator MAC addresses and/or networks to which the user is allowed to connect. One or more Allowed-Called- Station-Id Attributes MAY be included in an Access-Accept, CoA- Request, or Accounting-Request packet. The Allowed-Called-Station-Id Attribute can be useful in situations where pre-authentication is supported (e.g., IEEE 802.11 pre-authentication). In these scenarios, a Called-Station- Id Attribute typically will not be included within the Access- Request so that the RADIUS server will not know the network that the user is attempting to access. The Allowed-Called-Station-Id enables the RADIUS server to restrict the networks and attachment points to which the user can subsequently connect. A summary of the Allowed-Called-Station-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 | String... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 174 Length >=3 String The String field is one or more octets, specifying a Called- Station-Id that the user MAY connect to; if the Called-Station-Id that the user connects to does not match one of the Allowed- Called-Station-Id Attributes, the Network Access Server (NAS) MUST NOT permit the user to access the network.In the case of IEEE 802, the Allowed-Called-Station-Id Attribute is used to store the Medium Access Control (MAC) address, represented as an uppercase ASCII character string in Canonical format and with octet values separated by a "-", for example, "00-10-A4-23-19-C0". Where restrictions on both the network and authenticator MAC address usage are intended, the network name MUST be appended to the authenticator MAC address, separated from the MAC address with a ":", for example, "00-10-A4-23-19-C0:AP1". Where no MAC address restriction is intended, the MAC address field MUST be omitted, but ":" and the network name field MUST be included, for example, ":AP1". Within IEEE 802.11 , the Service Set Identifier (SSID) constitutes the network name; within IEEE 802.1X wired networks, the Network-Id Name (NID-Name) constitutes the network name. Since a NID-Name can be up to 253 octets in length, when used with wired networks, there may not be sufficient room within the Allowed-Called- Station-Id Attribute to include both a MAC address and a network name. However, as the Allowed-Called-Station-Id Attribute is expected to be used largely in wireless access scenarios, this restriction is not considered serious. |
rfc7268 | |
EAP-Peer-Id |
The EAP-Peer-Id Attribute contains a Peer-Id generated by the EAP
method. Exactly how this name is used depends on the link layer in question. See for more discussion. The EAP-Peer-Id Attribute MAY be included in Access-Request, Access-Accept, and Accounting-Request packets. More than one EAP-Peer-Id Attribute MUST NOT be included in an Access-Request; one or more EAP-Peer-Id Attributes MAY be included in an Access-Accept.It should be noted that not all link layers use this name, and existing EAP method implementations do not generate it. Since the NAS operates as a pass-through in EAP , it cannot know the EAP-Peer-Id before receiving it from the RADIUS server. As a result, an EAP-Peer-Id Attribute sent in an Access-Request MUST only contain a single NUL character. A home RADIUS server receiving an Access-Request with an EAP-Peer-Id Attribute containing anything other than a single NUL character MUST silently discard the attribute. In addition, the home RADIUS server SHOULD include one or more EAP-Peer-Id Attributes in an Access-Accept only if an EAP-Peer-Id Attribute was present in the Access-Request. If a NAS receives EAP-Peer-Id Attribute(s) in an Access-Accept without having included one in an Access-Request, the NAS SHOULD silently discard the attribute(s). A summary of the EAP-Peer-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 | String... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 175 Length >=3 String The String field is one or more octets, containing an EAP Peer-Id exported by the EAP method. For details, see. A robust implementation SHOULD support the field as undistinguished octets. Only a single EAP Peer-Id may be included per attribute. |
rfc7268 | |
EAP-Server-Id |
The EAP-Server-Id Attribute contains a Server-Id generated by the
EAP method. Exactly how this name is used depends on the link layer in question. See for more discussion. The EAP- Server-Id Attribute is only allowed in Access-Request, Access- Accept, and Accounting-Request packets. More than one EAP-Server-Id Attribute MUST NOT be included in an Access-Request; one or more EAP-Server-Id Attributes MAY be included in an Access-Accept. It should be noted that not all link layers use this name, and existing EAP method implementations do not generate it. Since the NAS operates as a pass-through in EAP , it cannot know the EAP-Server-Id before receiving it from the RADIUS server. As a result, an EAP-Server-Id Attribute sent in an Access-Request MUST contain only a single NUL character. A home RADIUS server receiving an Access-Request with an EAP-Server-Id Attribute containing anything other than a single NUL character MUST silently discard the attribute. In addition, the home RADIUS server SHOULD include this attribute in an Access-Accept only if an EAP-Server-Id Attribute was present in the Access-Request. A summary of the EAP-Server-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 | String... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 176 Length >=3 String The String field is one or more octets, containing an EAP Server- Id exported by the EAP method. For details, see. A robust implementation SHOULD support the field as undistinguished octets. |
rfc7268 | |
Mobility-Domain-Id |
A single Mobility-Domain-Id Attribute MAY be included in an
Access-Request or Accounting-Request in order to enable the NAS to provide the RADIUS server with the Mobility Domain Identifier (MDID), defined in Section 8.4.2.49 of . A summary of the Mobility-Domain-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 | Value +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 177 Length 6 Value The Value field is four octets, containing a 32-bit unsigned integer. The two most significant octets MUST be set to zero by the sender and are ignored by the receiver; the two least significant octets contain the Mobility Domain Identifier (MDID) defined in Section 8.4.2.49 of . 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 | Mobility Domain Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
rfc7268 | |
Preauth-Timeout |
This attribute sets the maximum number of seconds that pre-
authentication state is required to be kept by the NAS without being utilized within a user session. For example, when pre-authentication is used, if a user has not attempted to utilize the Pairwise Master Key (PMK) derived as a result of pre-authentication within the time specified by the Preauth-Timeout Attribute, the PMK MAY be discarded by the Access Point. However, once the session is underway, the Preauth-Timeout Attribute has no bearing on the maximum session time for the user or the maximum time during which key state may be kept prior to re-authentication. This is determined by the Session-Timeout Attribute, if present.A single Preauth-Timeout Attribute MAY be included within an Access-Accept or CoA-Request packet. A summary of the Preauth- Timeout 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 | Value +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Value (cont) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 178 Length 6 Value The field is 4 octets, containing a 32-bit unsigned integer encoding the maximum time in seconds that pre-authentication state should be retained by the NAS. |
rfc7268 | |
Network-Id-Name |
The Network-Id-Name Attribute is utilized by implementations of
IEEE-802.1X to specify the name of a Network-Id (NID-Name). Unlike the IEEE 802.11 SSID (which is a maximum of 32 octets in length), the NID-Name may be up to 253 octets in length. Consequently, if the MAC address is included within the Called- Station-Id Attribute, it is possible that there will not be enough remaining space to encode the NID-Name as well. Therefore, when used with IEEE 802.1X , the Called-Station-Id Attribute SHOULD contain only the MAC address, with the Network- Id-Name Attribute used to transmit the NID-Name. The Network-Id- Name Attribute MUST NOT be used to encode the IEEE 802.11 SSID; as noted in , the Called-Station-Id Attribute is used for this purpose.Zero or one Network-Id-Name Attribute is permitted within an Access-Request, Access-Challenge, Access-Accept or Accounting- Request packet. When included within an Access-Request packet, the Network-Id-Name Attribute represents a hint of the NID-Name to which the Supplicant should be granted access. When included within an Access-Accept packet, the Network-Id-Name Attribute represents the NID-Name to which the Supplicant is to be granted access. When included within an Accounting-Request packet, the Network-Id-Name Attribute represents the NID-Name to which the Supplicant has been granted access. A summary of the Network-Id-Name 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 | String... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 179 Length >=3 String The String field is one or more octets, containing a NID-Name. For details, see . A robust implementation SHOULD support the field as undistinguished octets. |
rfc7268 | |
EAPoL-Announcement |
The EAPoL-Announcement Attribute contains EAPoL-Announcement Type-
Length-Value (TLV) tuples defined within Table 11-8 of IEEE-802.1X . The acronym "EAPoL" stands for Extensible Authentication Protocol over Local Area Network. Zero or more EAPoL-Announcement Attributes are permitted within an Access-Request, Access-Accept, Access-Challenge, Access-Reject, Accounting-Request, CoA-Request, or Disconnect-Request packet.When included within an Access-Request packet, EAPoL-Announcement Attributes contain EAPoL-Announcement TLVs that the user sent in an EAPoL-Announcement. When included within an Access-Accept, Access-Challenge, Access-Reject, CoA-Request or Disconnect-Request packet, EAPoL-Announcement Attributes contain EAPoL-Announcement TLVs that the NAS is to send to the user in a unicast EAPoL- Announcement. When sent within an Accounting-Request packet, EAPoL-Announcement Attributes contain EAPoL-Announcement TLVs that the NAS has most recently sent to the user in a unicast EAPoL- Announcement. A summary of the EAPoL-Announcement 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 | String... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 180 Length >=3 String The String field is one or more octets, containing EAPoL- Announcement TLVs in the format defined in Figure 11-8 ofof . Any EAPoL-Announcement TLV Type MAY be included within an EAPoL-Announcement Attribute, including Organizationally Specific TLVs. If multiple EAPoL-Announcement Attributes are present in a packet, their String fields MUST be concatenated before being parsed for EAPoL-Announcement TLVs; this allows EAPoL-Announcement TLVs longer than 253 octets to be transported by RADIUS. Similarly, EAPoL-Announcement TLVs larger than 253 octets MUST be fragmented between multiple EAPoL- Announcement Attributes. |
rfc7268 | |
WLAN-HESSID |
The WLAN-HESSID Attribute contains a MAC address that identifies
the Homogenous Extended Service Set. The HESSID is a globally unique identifier that, in conjunction with the SSID, encoded within the Called-Station-Id Attribute as described in , may be used to provide network identification for a subscription service provider network (SSPN), as described in Section 8.4.2.94 of . Zero or one WLAN-HESSID Attribute is permitted within an Access-Request or Accounting-Request packet. A summary of the WLAN-HESSID 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 | String... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 181 Length 19 String The String field is encoded in uppercase ASCII characters with the octet values separated by dash characters, as described in, for example, "00-10-A4-23-19-C0". |
rfc7268 | |
WLAN-Venue-Info |
The WLAN-Venue-Info Attribute identifies the category of venue
hosting the WLAN, as defined in Section 8.4.1.34 of . Zero or more WLAN-Venue-Info Attributes may be included in an Access-Request or Accounting-Request.A summary of the WLAN-Venue-Info 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 | Value +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 182 Length 6 Value The Value field is four octets, containing a 32-bit unsigned integer. The two most significant octets MUST be set to zero by the sender, and are ignored by the receiver; the two least significant octets contain the Venue Group and Venue Type fields. 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 | Venue Group | Venue Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Venue Group The Venue Group field is a single octet and describes the broad category of the venue, e.g., "Assembly". See Section 8.4.1.34 of for Venue Group codes and descriptions. Venue Type The Venue Type field is a single octet and describes the venue in a finer granularity within the Venue Group, e.g., "Library". See Section 8.4.1.34 of for Venue Type codes and descriptions. |
rfc7268 | |
WLAN-Venue-Language |
The WLAN-Venue-Language Attribute is a string encoded by
ISO-14962-1997 that defines the language used in the WLAN-Venue-Name Attribute. Zero or more WLAN-Venue-Language Attributes may be included in an Access-Request or Accounting- Request, and each one indicates the language of the WLAN-Venue- Name Attribute that follows it. A summary of the WLAN-Venue-Language 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 | String... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ String (cont) | +-+-+-+-+-+-+-+-+ Type 183 Length 4-5 String The String field is a two- or three-character language code selected from ISO-639 . A two-character language code has a zero ("null" in ISO-14962-1997) appended to make it 3 octets in length. |
rfc7268 | |
WLAN-Venue-Name |
The WLAN-Venue-Name Attribute provides additional metadata on the
Basic Service Set (BSS). For example, this information may be used to assist a user in selecting the appropriate BSS with which to associate. Zero or more WLAN-Venue-Name Attributes may be included in an Access- Request or Accounting-Request in the same or different languages. A summary of the WLAN-Venue-Name 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 | String... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 184 Length >=3 String The String field is encoded in UTF-8 and contains the venue's name. The maximum length of this field is 252 octets. |
rfc7268 | |
WLAN-Reason-Code |
The WLAN-Reason-Code Attribute contains information on the reason
why a Station has been refused network access and has been disassociated or de-authenticated. This can occur due to policy or for reasons related to the user's subscription. A WLAN-Reason-Code Attribute MAY be included within an Access- Reject or Disconnect-Request packet, as well as within an Accounting-Request packet. Upon receipt of an Access-Reject or Disconnect-Request packet containing a WLAN-Reason-Code Attribute, the WLAN-Reason-Code value is copied by the Access Point into the Reason Code field of a Disassociation or Deauthentication frame (see Clauses 8.3.3.4 and 8.3.3.12, respectively, in ), which is subsequently transmitted to the Station. A summary of the WLAN-Reason-Code 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 | Value +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 185 Length 6 Value The Value field is four octets, containing a 32-bit unsigned integer. The two most significant octets MUST be set to zero by the sender and are ignored by the receiver; the two least significant octets contain the Reason Code values defined in Table 8-36 of Section 8.4.1.7 of .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 | Reason Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
rfc7268 | |
WLAN-Pairwise-Cipher |
The WLAN-Pairwise-Cipher Attribute contains information on the
pairwise ciphersuite used to establish the robust security network association (RSNA) between the AP and mobile device. A WLAN- Pairwise-Cipher Attribute MAY be included within Access-Request and Accounting-Request packets. A summary of the WLAN-Pairwise-Cipher 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 | Value +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 186 Length 6 Value The Value field is four octets, containing a 32-bit unsigned integer, in Suite selector format as specified in Figure 8-187 within Section 8.4.2.27.2 of , with values of OUI and Suite Type drawn from Table 8-99. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OUI | Suite Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
rfc7268 | |
WLAN-Group-Cipher |
The WLAN-Group-Cipher Attribute contains information on the group
ciphersuite used to establish the robust security network association (RSNA) between the AP and mobile device. A WLAN- Group-Cipher Attribute MAY be included within Access-Request and Accounting-Request packets. A summary of the WLAN-Group-Cipher 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 | Value +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 187 Length 6 Value The Value field is four octets, containing a 32-bit unsigned integer, in Suite selector format as specified in Figure 8-187 within Section 8.4.2.27.2 of , with values of OUI and Suite Type drawn from Table 8-99. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OUI | Suite Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
rfc7268 | |
WLAN-AKM-Suite |
The WLAN-AKM-Suite Attribute contains information on the
authentication and key management suite used to establish the robust security network association (RSNA) between the AP and mobile device. A WLAN-AKM-Suite Attribute MAY be included within Access-Request and Accounting-Request packets. A summary of the WLAN-AKM-Suite 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 | Value +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 188 Length 6 Value The Value field is four octets, containing a 32-bit unsigned integer, in Suite selector format as specified in Figure 8-187 within Section 8.4.2.27.2 of , with values of OUI and Suite Type drawn from Table 8-101: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OUI | Suite Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
rfc7268 | |
WLAN-Group-Mgmt-Cipher |
The WLAN-Group-Mgmt-Cipher Attribute contains information on the
group management cipher used to establish the robust security network association (RSNA) between the AP and mobile device. Zero or one WLAN-Group-Mgmt-Cipher Attribute MAY be included within Access-Request and Accounting-Request packets. The presence of the Attribute indicates that the Station negotiated to use management frame protection during association. A summary of the WLAN-Group-Mgmt-Cipher 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 | Value +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 189 Length 6 Value The Value field is four octets, containing a 32-bit unsigned integer, in Suite selector format as specified in Figure 8-187 within Section 8.4.2.27.2 of , with values of OUI and Suite Type drawn from Table 8-99: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OUI | Suite Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
rfc7268 | |
WLAN-RF-Band |
The WLAN-RF-Band Attribute contains information on the radio
frequency (RF) band used by the Access Point for transmission and reception of information to and from the mobile device. Zero or one WLAN-RF-Band Attribute MAY be included within an Access- Request or Accounting-Request packet. A summary of the WLAN-RF-Band 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 | Value +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 190 Length 6 Value The Value field is four octets, containing a 32-bit unsigned integer. The three most significant octets MUST be set to zero by the sender and are ignored by the receiver; the least significant octet contains the RF Band field, whose values are defined by the IEEE 802.11 Band ID field (Table 8-53a of ) 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 | RF Band | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+3. Table of AttributesThe following table provides a guide to which attributes may be found in which kinds of packets and in what quantity. Access- Access- Access- Access- Request Accept Reject Challenge # Attribute 0 0+ 0 0 174 Allowed-Called-Station-Id 0-1 0-1 0 0 102 EAP-Key-Name 0-1 0+ 0 0 175 EAP-Peer-Id 0-1 0+ 0 0 176 EAP-Server-Id 0-1 0 0 0 177 Mobility-Domain-Id 0-1 0-1 0 0 178 Preauth-Timeout 0-1 0 0 0 179 Network-Id-Name 0+ 0+ 0+ 0+ 180 EAPoL-Announcement 0-1 0 0 0 181 WLAN-HESSID 0-1 0 0 0 182 WLAN-Venue-Info 0+ 0 0 0 183 WLAN-Venue-Language 0+ 0 0 0 184 WLAN-Venue-Name 0 0 0-1 0 185 WLAN-Reason-Code 0-1 0 0 0 186 WLAN-Pairwise-Cipher 0-1 0 0 0 187 WLAN-Group-Cipher 0-1 0 0 0 188 WLAN-AKM-Suite 0-1 0 0 0 189 WLAN-Group-Mgmt-Cipher 0-1 0 0 0 190 WLAN-RF-Band CoA- Dis- Acct- Req Req Req # Attribute 0+ 0 0+ 174 Allowed-Called-Station-Id 0-1 0 0 102 EAP-Key-Name 0 0 0+ 175 EAP-Peer-Id 0 0 0+ 176 EAP-Server-Id 0 0 0-1 177 Mobility-Domain-Id 0-1 0 0 178 Preauth-Timeout 0 0 0-1 179 Network-Id-Name 0+ 0+ 0+ 180 EAPoL-Announcement 0 0 0-1 181 WLAN-HESSID 0 0 0-1 182 WLAN-Venue-Info 0 0 0+ 183 WLAN-Venue-Language 0 0 0+ 184 WLAN-Venue-Name 0 0-1 0-1 185 WLAN-Reason-Code 0 0 0-1 186 WLAN-Pairwise-Cipher 0 0 0-1 187 WLAN-Group-Cipher 0 0 0-1 188 WLAN-AKM-Suite 0 0 0-1 189 WLAN-Group-Mgmt-Cipher 0 0 0-1 190 WLAN-RF-BandThe following table defines the above table entries. 0 This attribute MUST NOT be present in packet. 0+ Zero or more instances of this attribute MAY be present in the packet. 0-1 Zero or one instance of this attribute MAY be present in the packet.4. IANA ConsiderationsThis document uses the RADIUS namespace; see <>. Per this specification, RADIUS attribute types have been assigned for the following attributes: Attribute Type ========= ==== Allowed-Called-Station-Id 174 EAP-Peer-Id 175 EAP-Server-Id 176 Mobility-Domain-Id 177 Preauth-Timeout 178 Network-Id-Name 179 EAPoL-Announcement 180 WLAN-HESSID 181 WLAN-Venue-Info 182 WLAN-Venue-Language 183 WLAN-Venue-Name 184 WLAN-Reason-Code 185 WLAN-Pairwise-Cipher 186 WLAN-Group-Cipher 187 WLAN-AKM-Suite 188 WLAN-Group-Mgmt-Cipher 189 WLAN-RF-Band 190 Since this specification relies entirely on values assigned by IEEE 802, no registries are established for maintenance by the IANA.5. Security ConsiderationsSince this document describes the use of RADIUS for purposes of authentication, authorization, and accounting in IEEE 802 networks, it is vulnerable to all of the threats that are present in other RADIUS applications. For a discussion of these threats, see , , , , , and . In particular, when RADIUS traffic is sent in the clear, the attributes defined in this document can be obtained by an attackersnooping the exchange between the RADIUS client and server. As a result, RADIUS confidentiality is desirable; for a review of RADIUS security and crypto-agility requirements, see . While it is possible for a RADIUS server to make decisions on whether to accept or reject an Access-Request based on the values of the WLAN-Pairwise-Cipher, WLAN-Group-Cipher, WLAN-AKM-Suite, WLAN-Group- Mgmt-Cipher, and WLAN-RF-Band Attributes, the value of doing this is limited. In general, an Access-Reject should not be necessary, except where Access Points and Stations are misconfigured so as to enable connections to be made with unacceptable values. Rather than rejecting access on an ongoing basis, users would be better served by fixing the misconfiguration. Where access does need to be rejected, the user should be provided with an indication of why the problem has occurred, or else they are likely to become frustrated. For example, if the values of the WLAN- Pairwise-Cipher, WLAN-Group-Cipher, WLAN-AKM-Suite, or WLAN-Group- Mgmt-Cipher Attributes included in the Access-Request are not acceptable to the RADIUS server, then a WLAN-Reason-Code Attribute with a value of 29 (Requested service rejected because of service provider ciphersuite or AKM requirement) SHOULD be returned in the Access-Reject. Similarly, if the value of the WLAN-RF-Band Attribute included in the Access-Request is not acceptable to the RADIUS server, then a WLAN-Reason-Code Attribute with a value of 11 (Disassociated because the information in the Supported Channels element is unacceptable) SHOULD be returned in the Access-Reject.6. References |
rfc7268 | |
Frag-Status |
|
Fragmentation-Supported, More-Data-Pending, More-Data-Request ... | rfc7499 |
Proxy-State-Length |
|
rfc7499 | |
Response-Length |
|
rfc7930 | |
Original-Packet-Code |
|
rfc7930 | |
IP-Port-Limit-Info |
|
rfc8045 | |
IP-Port-Range |
|
rfc8045 | |
IP-Port-Forwarding-Map |
|
rfc8045 | |
IP-Port-Type |
|
rfc8045 | |
IP-Port-Limit |
|
rfc8045 | |
IP-Port-Ext-IPv4-Addr |
|
rfc8045 | |
IP-Port-Int-IPv4-Addr |
The format of IP-Port-Int-IPv4 TLV is shown in Figure 7. This
attribute carries IPFIX Information Element 8, "sourceIPv4Address", which is the IPv4 source address before NAT operation (refer to ). 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 | Length | sourceIPv4Address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ sourceIPv4Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 7 TLV-Type 4 Length Six octets sourceIPv4Address Integer. This field contains the data (ipv4Address) of sourceIPv4Address (8) defined in IPFIX. If the internal realm is with an IPv4 address family, the IP-Port-Int-IPv4-Addr TLV MUST be included as part of the IP-Port-Forwarding-Map Attribute (refer to), identified as 241.7.4. |
rfc8045 | |
IP-Port-Int-IPv6-Addr |
The format of IP-Port-Int-IPv6-Addr TLV is shown in Figure 8. This
attribute carries IPFIX Information Element 27, "sourceIPv6Address", which is the IPv6 source address before NAT operation (refer to ). 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 | Length | sourceIPv6Address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ sourceIPv6Address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ sourceIPv6Address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ sourceIPv6Address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ sourceIPv6Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 8 TLV-Type 5 Length Eighteen octets sourceIPv6Address IPv6 address (128 bits). This field contains the data (ipv6Address) of sourceIPv6Address (27) defined in IPFIX. If the internal realm is with an IPv6 address family, the IP-Port-Int-IPv6-Addr TLV MUST be included as part of the IP-Port-Forwarding-Map Attribute (refer to), identified as 241.7.5. |
rfc8045 | |
IP-Port-Int-Port |
The format of IP-Port-Int-Port TLV is shown in Figure 9. This
attribute carries IPFIX Information Element 7, "sourceTransportPort", which is the source transport number associated with an internal IPv4 or IPv6 address (refer to ). 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 | Length | sourceTransportPort +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ sourceTransportPort | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 9 TLV-Type 6 Length Six octets sourceTransportPort Integer. This field contains the data (unsigned16) of sourceTransportPort (7) defined in IPFIX, right justified, and unused bits MUST be set to zero. IP-Port-Int-Port TLV MUST be included as part of the IP-Port-Forwarding-Map Attribute (refer to), identified as 241.7.6. |
rfc8045 | |
IP-Port-Ext-Port |
The format of IP-Port-Ext-Port TLV is shown in Figure 10. This
attribute carries IPFIX Information Element 227, "postNAPTSourceTransportPort", which is the transport number associated with an external IPv4 address (refer to ). 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 | Length | postNAPTSourceTransportPort +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ postNAPTSourceTransportPort | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 10 TLV-Type 7 Length Six octets postNAPTSourceTransportPort Integer. This field contains the data (unsigned16) of postNAPTSourceTransportPort (227) defined in IPFIX, right justified, and unused bits MUST be set to zero. IP-Port-Ext-Port TLV MUST be included as part of the IP-Port-Forwarding-Map Attribute (refer to), identified as 241.7.7. |
rfc8045 | |
IP-Port-Alloc |
The format of IP-Port-Alloc TLV is shown in Figure 11. This
attribute carries IPFIX Information Element 230, "natEvent", which is a flag to indicate an action of NAT operation (refer to ). When the value of natEvent is "1" (Create event), it means to allocate a range of transport ports; when the value is "2", it means to deallocate a range of transports ports. For the purpose of this TLV, no other value is used. 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 | Length | natEvent +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ natEvent | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 11 TLV-Type 8 Length Six octets natEvent Integer. This field contains the data (unsigned8) of natEvent (230) defined in IPFIX, right justified, and unused bits MUST be set to zero. It indicates the allocation or deallocation of a range of IP ports as follows: 0: Reserved 1: Allocation 2: Deallocation IP-Port-Alloc TLV MUST be included as part of the IP-Port-Range Attribute (refer to), identified as 241.6.8. |
Allocation, Deallocation | rfc8045 |
IP-Port-Range-Start |
The format of IP-Port-Range-Start TLV is shown in Figure 12. This
attribute carries IPFIX Information Element 361, "portRangeStart", which is the smallest port number of a range of contiguous transport ports (refer to ). 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 | Length | portRangeStart +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ portRangeStart | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 12 TLV-Type 9 Length Six octets portRangeStart Integer. This field contains the data (unsigned16) of portRangeStart (361) defined in IPFIX, right justified, and unused bits MUST be set to zero. IP-Port-Range-Start TLV is included as part of the IP-Port-Range Attribute (refer to), identified as 241.6.9. |
rfc8045 | |
IP-Port-Range-End |
The format of IP-Port-Range-End TLV is shown in Figure 13. This
attribute carries IPFIX Information Element 362, "portRangeEnd", which is the largest port number of a range of contiguous transport ports (refer to ). 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 | Length | portRangeEnd +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ portRangeEnd | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 13 TLV-Type 10 Length Six octets portRangeEnd Integer. This field contains the data (unsigned16) of portRangeEnd (362) defined in IPFIX, right justified, and unused bits MUST be set to zero. IP-Port-Range-End TLV is included as part of the IP-Port-Range Attribute (refer to), identified as 241.6.10. |
rfc8045 | |
IP-Port-Local-Id |
The format of IP-Port-Local-Id TLV is shown in Figure 14. This
attribute carries a string called "localID", which is a local significant identifier as explained below. The primary issue addressed by this TLV is that there are CGN deployments that do not distinguish internal hosts by their internal IP address alone but use further identifiers for unique subscriber identification. For example, this is the case if a CGN supports overlapping private or shared IP address spaces (as described in and ) for internal hosts of different subscribers. In such cases, different internal hosts are identified and mapped at the CGN by their IP address and/or another identifier, for example,the identifier of a tunnel between the CGN and the subscriber. In these scenarios (and similar ones), the internal IP address is not sufficient to demultiplex connections from internal hosts. An additional identifier needs to be present in the IP-Port-Range Attribute and IP-Port-Forwarding-Mapping Attribute in order to uniquely identify an internal host. The IP-Port-Local-Id TLV is used to carry this identifier. 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 | Length | localID .... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 14 TLV-Type 11 Length Variable number of octets localID String. The data type of this field is string (refer to ). This field contains the data that is a local significant identifier at the customer premise, such as MAC address, interface ID, VLAN ID, PPP sessions ID, VRF ID, IP address/prefix, or another local significant identifier. IP-Port-Local-Id TLV MAY be included in the following Attributes if it is necessary to identify the subscriber: o IP-Port-Range Attribute, identified as 241.6.11 (see) o IP-Port-Forwarding-Mapping Attribute, identified as 241.7.11 (see)4. Applications, Use Cases, and ExamplesThis section describes some applications and use cases to illustrate the use of the attributes proposed in this document. |
rfc8045 | |
IP-Port-Range-Type |
|
rfc8045 | |
IP-Port-Range-Limit |
|
rfc8045 | |
IP-Port-Range-Ext-IPv4-Addr |
|
rfc8045 | |
IP-Port-Range-Int-IPv4-Addr |
|
rfc8045 | |
IP-Port-Range-Int-IPv6-Addr |
|
rfc8045 | |
IP-Port-Range-Int-Port |
|
rfc8045 | |
IP-Port-Range-Ext-Port |
|
rfc8045 | |
IP-Port-Range-Alloc |
|
Allocation, Deallocation | rfc8045 |
IP-Port-Range-Range-Start |
|
rfc8045 | |
IP-Port-Range-Range-End |
|
rfc8045 | |
IP-Port-Range-Local-Id |
|
rfc8045 | |
IP-Port-Map-Type |
|
rfc8045 | |
IP-Port-Map-Limit |
|
rfc8045 | |
IP-Port-Map-Ext-IPv4-Addr |
|
rfc8045 | |
IP-Port-Map-Int-IPv4-Addr |
|
rfc8045 | |
IP-Port-Map-Int-IPv6-Addr |
|
rfc8045 | |
IP-Port-Map-Int-Port |
|
rfc8045 | |
IP-Port-Map-Ext-Port |
|
rfc8045 | |
IP-Port-Map-Alloc |
|
Allocation, Deallocation | rfc8045 |
IP-Port-Map-Range-Start |
|
rfc8045 | |
IP-Port-Map-Range-End |
|
rfc8045 | |
IP-Port-Map-Local-Id |
|
rfc8045 | |
Operator-NAS-Identifier |
|
rfc8559 | |
Unix-FTP-UID |
|
unix | |
Unix-FTP-GID |
|
unix | |
Unix-FTP-Home |
|
unix | |
Unix-FTP-Shell |
|
unix | |
Unix-FTP-Group-Names |
|
unix | |
Unix-FTP-Group-Ids |
|
unix | |
Yubikey-Key |
|
yubico | |
Yubikey-Public-ID |
|
yubico | |
Yubikey-Private-ID |
|
yubico | |
Yubikey-Counter |
|
yubico | |
Yubikey-Timestamp |
|
yubico | |
Yubikey-Random |
|
yubico | |
Yubikey-OTP |
|
yubico |
Showing of entries