Beruflich Dokumente
Kultur Dokumente
P. Calhoun
G. Zorn
Cisco Systems Inc.
D. Spence
Consultant
D. Mitton
Circular Networks
August 2005
Calhoun, et al.
Standards Track
[Page 1]
RFC 4005
August 2005
Table of Contents
1.
2.
3.
4.
5.
6.
Introduction . . . . . . . . . . . . . . . . . . . . . . .
1.1. Terminology . . . . . . . . . . . . . . . . . . . .
1.2. Requirements Language . . . . . . . . . . . . . . .
1.3. Advertising Application Support . . . . . . . . . .
NAS Calls, Ports, and Sessions . . . . . . . . . . . . . .
2.1. Diameter Session Establishment . . . . . . . . . . .
2.2. Diameter Session Reauthentication or Reauthorization
2.3. Diameter Session Termination . . . . . . . . . . . .
NAS Messages . . . . . . . . . . . . . . . . . . . . . . .
3.1. AA-Request (AAR) Command . . . . . . . . . . . . . .
3.2. AA-Answer (AAA) Command . . . . . . . . . . . . . .
3.3. Re-Auth-Request (RAR) Command . . . . . . . . . . .
3.4. Re-Auth-Answer (RAA) Command . . . . . . . . . . . .
3.5. Session-Termination-Request (STR) Command . . . . .
3.6. Session-Termination-Answer (STA) Command . . . . . .
3.7. Abort-Session-Request (ASR) Command . . . . . . . .
3.8. Abort-Session-Answer (ASA) Command . . . . . . . . .
3.9. Accounting-Request (ACR) Command . . . . . . . . . .
3.10. Accounting-Answer (ACA) Command. . . . . . . . . . .
NAS Session AVPs . . . . . . . . . . . . . . . . . . . . .
4.1. Call and Session Information . . . . . . . . . . . .
4.2. NAS-Port AVP . . . . . . . . . . . . . . . . . . . .
4.3. NAS-Port-Id AVP . . . . . . . . . . . . . . . . . .
4.4. NAS-Port-Type AVP . . . . . . . . . . . . . . . . .
4.5. Called-Station-Id AVP . . . . . . . . . . . . . . .
4.6. Calling-Station-Id AVP . . . . . . . . . . . . . . .
4.7. Connect-Info AVP . . . . . . . . . . . . . . . . . .
4.8. Originating-Line-Info AVP . . . . . . . . . . . . .
4.9. Reply-Message AVP . . . . . . . . . . . . . . . . .
NAS Authentication AVPs . . . . . . . . . . . . . . . . .
5.1. User-Password AVP . . . . . . . . . . . . . . . . .
5.2. Password-Retry AVP . . . . . . . . . . . . . . . . .
5.3. Prompt AVP . . . . . . . . . . . . . . . . . . . . .
5.4. CHAP-Auth AVP . . . . . . . . . . . . . . . . . . .
5.5. CHAP-Algorithm AVP . . . . . . . . . . . . . . . . .
5.6. CHAP-Ident AVP . . . . . . . . . . . . . . . . . . .
5.7. CHAP-Response AVP . . . . . . . . . . . . . . . . .
5.8. CHAP-Challenge AVP . . . . . . . . . . . . . . . . .
5.9. ARAP-Password AVP . . . . . . . . . . . . . . . . .
5.10. ARAP-Challenge-Response AVP. . . . . . . . . . . . .
5.11. ARAP-Security AVP. . . . . . . . . . . . . . . . . .
5.12. ARAP-Security-Data AVP . . . . . . . . . . . . . . .
NAS Authorization AVPs . . . . . . . . . . . . . . . . . .
6.1. Service-Type AVP . . . . . . . . . . . . . . . . . .
6.2. Callback-Number AVP . . . . . . . . . . . . . . . .
6.3. Callback-Id AVP . . . . . . . . . . . . . . . . . .
Calhoun, et al.
Standards Track
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
5
5
6
6
6
7
7
8
9
9
11
13
14
15
15
16
17
17
19
20
21
22
22
22
23
23
24
24
25
26
26
27
27
27
28
28
28
28
28
28
29
29
29
30
32
32
[Page 2]
RFC 4005
6.4.
6.5.
6.6.
6.7.
6.8.
6.9.
6.10.
7.
August 2005
Idle-Timeout AVP . . . . . . . . . . . . . . . . . . . .
Port-Limit AVP . . . . . . . . . . . . . . . . . . . . .
NAS-Filter-Rule AVP . . . . . . . . . . . . . . . . . .
Filter-Id AVP . . . . . . . . . . . . . . . . . . . . .
Configuration-Token AVP . . . . . . . . . . . . . . . .
QoS-Filter-Rule AVP . . . . . . . . . . . . . . . . . .
Framed Access Authorization AVPs . . . . . . . . . . . .
6.10.1. Framed-Protocol AVP . . . . . . . . . . . . . .
6.10.2. Framed-Routing AVP. . . . . . . . . . . . . . .
6.10.3. Framed-MTU AVP. . . . . . . . . . . . . . . . .
6.10.4. Framed-Compression AVP. . . . . . . . . . . . .
6.11. IP Access Authorization AVPs.. . . . . . . . . . . . . .
6.11.1. Framed-IP-Address AVP . . . . . . . . . . . . .
6.11.2. Framed-IP-Netmask AVP . . . . . . . . . . . . .
6.11.3. Framed-Route AVP. . . . . . . . . . . . . . . .
6.11.4. Framed-Pool AVP . . . . . . . . . . . . . . . .
6.11.5. Framed-Interface-Id AVP . . . . . . . . . . . .
6.11.6. Framed-IPv6-Prefix AVP. . . . . . . . . . . . .
6.11.7. Framed-IPv6-Route AVP . . . . . . . . . . . . .
6.11.8. Framed-IPv6-Pool AVP. . . . . . . . . . . . . .
6.12. IPX Access . . . . . . . . . . . . . . . . . . . . . . .
6.12.1. Framed-IPX-Network AVP. . . . . . . . . . . . .
6.13. AppleTalk Network Access . . . . . . . . . . . . . . . .
6.13.1. Framed-AppleTalk-Link AVP . . . . . . . . . . .
6.13.2. Framed-AppleTalk-Network AVP . . . . . . . . .
6.13.3. Framed-AppleTalk-Zone AVP . . . . . . . . . . .
6.14. AppleTalk Remote Access. . . . . . . . . . . . . . . . .
6.14.1. ARAP-Features AVP . . . . . . . . . . . . . . .
6.14.2. ARAP-Zone-Access AVP. . . . . . . . . . . . . .
6.15. Non-Framed Access Authorization AVPs . . . . . . . . . .
6.15.1. Login-IP-Host AVP . . . . . . . . . . . . . . .
6.15.2. Login-IPv6-Host AVP . . . . . . . . . . . . . .
6.15.3. Login-Service AVP . . . . . . . . . . . . . . .
6.16. TCP Services . . . . . . . . . . . . . . . . . . . . . .
6.16.1. Login-TCP-Port AVP . . . . . . . . . . . . . .
6.17. LAT Services . . . . . . . . . . . . . . . . . . . . . .
6.17.1. Login-LAT-Service AVP . . . . . . . . . . . . .
6.17.2. Login-LAT-Node AVP. . . . . . . . . . . . . . .
6.17.3. Login-LAT-Group AVP . . . . . . . . . . . . . .
6.17.4. Login-LAT-Port AVP. . . . . . . . . . . . . . .
NAS Tunneling . . . . . . . . . . . . . . . . . . . . . . . .
7.1. Tunneling AVP . . . . . . . . . . . . . . . . . . . . .
7.2. Tunnel-Type AVP . . . . . . . . . . . . . . . . . . . .
7.3. Tunnel-Medium-Type AVP . . . . . . . . . . . . . . . . .
7.4. Tunnel-Client-Endpoint AVP . . . . . . . . . . . . . . .
7.5. Tunnel-Server-Endpoint AVP . . . . . . . . . . . . . . .
7.6. Tunnel-Password AVP . . . . . . . . . . . . . . . . . .
7.7. Tunnel-Private-Group-Id AVP . . . . . . . . . . . . . .
Calhoun, et al.
Standards Track
32
32
32
33
33
33
35
35
35
35
36
36
36
36
37
37
37
38
38
38
38
39
39
39
39
40
40
40
40
40
40
41
41
42
42
42
42
43
43
43
44
44
45
46
46
47
48
48
[Page 3]
RFC 4005
August 2005
Calhoun, et al.
Standards Track
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
a
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
48
49
50
50
50
51
52
52
52
52
52
53
53
54
54
55
55
55
59
60
62
63
63
64
65
65
66
68
69
69
69
. 70
70
71
71
73
74
76
77
77
78
78
78
78
78
78
[Page 4]
RFC 4005
13. References . . . . . . . . .
13.1. Normative References .
13.2. Informative References
14. Acknowledgements . . . . . .
Authors Addresses . . . . . . .
Full Copyright Statement . . . .
1.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
August 2005
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
79
79
80
83
84
85
Introduction
This document describes the Diameter protocol application used for
AAA in the Network Access Server (NAS) environment. When combined
with the Diameter Base protocol [BASE], Transport Profile
[DiamTrans], and EAP [DiamEAP] specifications, this Diameter NAS
application specification satisfies NAS-related requirements defined
in RFC 2989 [AAACriteria] and RFC 3169 [NASCriteria].
Initial deployments of the Diameter protocol are expected to include
legacy systems. Therefore, this application has been carefully
designed to ease the burden of protocol conversion between RADIUS and
Diameter. This is achieved by including the RADIUS attribute space
to eliminate the need to perform many attribute translations.
The interactions specified in this document between Diameter
applications and RADIUS are to be applied to all Diameter
applications. In this sense, this document extends the Base Diameter
protocol [BASE].
First, this document describes the operation of a Diameter NAS
application. Then it defines the Diameter message Command-Codes.
The following sections list the AVPs used in these messages, grouped
by common usage. These are session identification, authentication,
authorization, tunneling, and accounting. The authorization AVPs are
further broken down by service type. Interaction and backward
compatibility issues with RADIUS are discussed in later sections.
1.1.
Terminology
Calhoun, et al.
Standards Track
[Page 5]
RFC 4005
August 2005
Requirements Language
Calhoun, et al.
Standards Track
[Page 6]
RFC 4005
August 2005
If
Calhoun, et al.
Standards Track
[Page 7]
RFC 4005
August 2005
A Diameter server informs the NAS of the maximum time allowed before
reauthentication or reauthorization via the Authorization-Lifetime
AVP [BASE]. A NAS MAY reauthenticate and/or reauthorize before the
end, but A NAS MUST reauthenticate and/or reauthorize at the end of
the period provided by the Authorization-Lifetime AVP. The failure
of a reauthentication exchange will terminate the service.
Furthermore, it is possible for Diameter servers to issue an
unsolicited reauthentication and/or reauthorization request (e.g.,
Re-Auth-Request (RAR) message [BASE]) to the NAS. Upon receipt of
such a message, the NAS MUST respond to the request with a Re-AuthAnswer (RAA) message [BASE].
If the RAR properly identifies an active session, the NAS will
initiate a new local reauthentication or authorization sequence as
indicated by the Re-Auth-Request-Type value. This will cause the NAS
to send a new AAR message using the existing Session-Id. The server
will respond with an AAA message to specify the new service
parameters.
If accounting is active, every change of authentication or
authorization SHOULD generate an accounting message. If the NAS
service is a continuation of the prior user context, then an
Accounting-Record-Type of INTERIM_RECORD indicating the new session
attributes and cumulative status would be appropriate. If a new user
or a significant change in authorization is detected by the NAS, then
the service may send two messages of the types STOP_RECORD and
START_RECORD. Accounting may change the subsession identifiers
(Acct-Session-ID, or Acct-Sub-Session-Id) to indicate such subsessions. A service may also use a different Session-Id value for
accounting (see [BASE] section 9.6).
However, the Diameter Session-ID AVP value used for the initial
authorization exchange MUST be used to generate an STR message when
the session context is terminated.
2.3.
Calhoun, et al.
Standards Track
[Page 8]
RFC 4005
August 2005
NAS Messages
This section defines the Diameter message Command-Code [BASE] values
that MUST be supported by all Diameter implementations conforming to
this specification. The Command Codes are as follows:
Command-Name
Abbrev. Code
Reference
------------------------------------------------------AA-Request
AAR
265
3.1
AA-Answer
AAA
265
3.2
Re-Auth-Request
RAR
258
3.3
Re-Auth-Answer
RAA
258
3.4
Session-Termination-Request
STR
275
3.5
Session-Termination-Answer
STA
275
3.6
Abort-Session-Request
ASR
274
3.7
Abort-Session-Answer
ASA
274
3.8
Accounting-Request
ACR
271
3.9
Accounting-Answer
ACA
271
3.10
3.1.
Calhoun, et al.
Standards Track
[Page 9]
RFC 4005
August 2005
Calhoun, et al.
Standards Track
[Page 10]
RFC 4005
August 2005
* [ ARAP-Security-Data ]
* [ Login-IP-Host ]
* [ Login-IPv6-Host ]
[ Login-LAT-Group ]
[ Login-LAT-Node ]
[ Login-LAT-Port ]
[ Login-LAT-Service ]
* [ Tunneling ]
* [ Proxy-Info ]
* [ Route-Record ]
* [ AVP ]
3.2.
Calhoun, et al.
Standards Track
[Page 11]
RFC 4005
*
*
*
*
*
*
*
Calhoun, et al.
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
August 2005
Error-Message ]
Error-Reporting-Host ]
Failed-AVP ]
Idle-Timeout ]
Authorization-Lifetime ]
Auth-Grace-Period ]
Auth-Session-State ]
Re-Auth-Request-Type ]
Multi-Round-Time-Out ]
Session-Timeout ]
State ]
Reply-Message ]
Origin-AAA-Protocol ]
Origin-State-Id ]
Filter-Id ]
Password-Retry ]
Port-Limit ]
Prompt ]
ARAP-Challenge-Response ]
ARAP-Features ]
ARAP-Security ]
ARAP-Security-Data ]
ARAP-Zone-Access ]
Callback-Id ]
Callback-Number ]
Framed-Appletalk-Link ]
Framed-Appletalk-Network ]
Framed-Appletalk-Zone ]
Framed-Compression ]
Framed-Interface-Id ]
Framed-IP-Address ]
Framed-IPv6-Prefix ]
Framed-IPv6-Pool ]
Framed-IPv6-Route ]
Framed-IP-Netmask ]
Framed-Route ]
Framed-Pool ]
Framed-IPX-Network ]
Framed-MTU ]
Framed-Protocol ]
Framed-Routing ]
Login-IP-Host ]
Login-IPv6-Host ]
Login-LAT-Group ]
Login-LAT-Node ]
Login-LAT-Port ]
Login-LAT-Service ]
Login-Service ]
Standards Track
[Page 12]
RFC 4005
[
[
[
[
[
[
[
* [
* [
*
*
*
*
3.3.
August 2005
Login-TCP-Port ]
NAS-Filter-Rule ]
QoS-Filter-Rule ]
Tunneling ]
Redirect-Host ]
Redirect-Host-Usage ]
Redirect-Max-Cache-Time ]
Proxy-Info ]
AVP ]
A Diameter server may initiate a re-authentication and/or reauthorization service for a particular session by issuing a Re-AuthRequest (RAR) message [BASE].
For example, for pre-paid services, the Diameter server that
originally authorized a session may need some confirmation that the
user is still using the services.
If a NAS receives an RAR message with Session-Id equal to a currently
active session and a Re-Auth-Type that includes authentication, it
MUST initiate a re-authentication toward the user, if the service
supports this particular feature.
Message Format
<RA-Request>
Calhoun, et al.
Standards Track
[Page 13]
RFC 4005
*
*
*
*
3.4.
[
[
[
[
[
[
[
[
[
[
[
August 2005
Called-Station-Id ]
Calling-Station-Id ]
Originating-Line-Info ]
Acct-Session-Id ]
Acct-Multi-Session-Id ]
State ]
Class ]
Reply-Message ]
Proxy-Info ]
Route-Record ]
AVP ]
Calhoun, et al.
::= <
<
{
{
{
[
[
[
[
[
* [
* [
[
[
[
* [
[
[
[
[
[
* [
* [
[
* [
* [
Standards Track
[Page 14]
RFC 4005
3.5.
August 2005
Calhoun, et al.
::= <
<
{
{
{
[
* [
[
[
Standards Track
[Page 15]
RFC 4005
* [
[
[
* [
[
[
* [
* [
3.7.
August 2005
Failed-AVP ]
Origin-AAA-Protocol ]
Origin-State-Id ]
Redirect-Host ]
Redirect-Host-Usase ]
Redirect-Max-Cache-Time ]
Proxy-Info ]
AVP ]
Calhoun, et al.
Standards Track
[Page 16]
RFC 4005
3.8.
August 2005
The ASA message [BASE] is sent in response to the ASR. The ResultCode AVP MUST be present and indicates the disposition of the
request.
If the session identified by Session-Id in the ASR was successfully
terminated, Result-Code is set to DIAMETER_SUCCESS. If the session
is not currently active, Result-Code is set to
DIAMETER_UNKNOWN_SESSION_ID. If the access device does not stop the
session for any other reason, Result-Code is set to
DIAMETER_UNABLE_TO_COMPLY.
Message Format
<AS-Answer>
3.9.
::= <
<
{
{
{
[
[
[
[
[
[
* [
* [
[
[
* [
* [
The ACR message [BASE] is sent by the NAS to report its session
information to a target server downstream.
Either of Acct-Application-Id or Vendor-Specific-Application-Id AVPs
MUST be present. If the Vendor-Specific-Application-Id grouped AVP
is present, it must have an Acct-Application-Id inside.
The AVPs listed in the Base MUST be assumed to be present, as
appropriate. NAS service-specific accounting AVPs SHOULD be present
as described in section 8 and the rest of this specification.
Calhoun, et al.
Standards Track
[Page 17]
RFC 4005
August 2005
Message Format
<AC-Request> ::= < Diameter Header: 271, REQ, PXY >
< Session-Id >
{ Origin-Host }
{ Origin-Realm }
{ Destination-Realm }
{ Accounting-Record-Type }
{ Accounting-Record-Number }
[ Acct-Application-Id ]
[ Vendor-Specific-Application-Id ]
[ User-Name ]
[ Accounting-Sub-Session-Id ]
[ Acct-Session-Id ]
[ Acct-Multi-Session-Id ]
[ Origin-AAA-Protocol ]
[ Origin-State-Id ]
[ Destination-Host ]
[ Event-Timestamp ]
[ Acct-Delay-Time ]
[ NAS-Identifier ]
[ NAS-IP-Address ]
[ NAS-IPv6-Address ]
[ NAS-Port ]
[ NAS-Port-Id ]
[ NAS-Port-Type ]
* [ Class ]
[ Service-Type ]
[ Termination-Cause ]
[ Accounting-Input-Octets ]
[ Accounting-Input-Packets ]
[ Accounting-Output-Octets ]
[ Accounting-Output-Packets ]
[ Acct-Authentic ]
[ Accounting-Auth-Method ]
[ Acct-Link-Count ]
[ Acct-Session-Time ]
[ Acct-Tunnel-Connection ]
[ Acct-Tunnel-Packets-Lost ]
[ Callback-Id ]
[ Callback-Number ]
[ Called-Station-Id ]
[ Calling-Station-Id ]
* [ Connection-Info ]
[ Originating-Line-Info ]
[ Authorization-Lifetime ]
[ Session-Timeout ]
[ Idle-Timeout ]
Calhoun, et al.
Standards Track
[Page 18]
RFC 4005
*
*
*
*
*
*
*
*
*
*
*
*
3.10.
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
August 2005
Port-Limit ]
Accounting-Realtime-Required ]
Acct-Interim-Interval ]
Filter-Id ]
NAS-Filter-Rule ]
Qos-Filter-Rule ]
Framed-AppleTalk-Link ]
Framed-AppleTalk-Network ]
Framed-AppleTalk-Zone ]
Framed-Compression ]
Framed-Interface-Id ]
Framed-IP-Address ]
Framed-IP-Netmask ]
Framed-IPv6-Prefix ]
Framed-IPv6-Pool ]
Framed-IPv6-Route ]
Framed-IPX-Network ]
Framed-MTU ]
Framed-Pool ]
Framed-Protocol ]
Framed-Route ]
Framed-Routing ]
Login-IP-Host ]
Login-IPv6-Host ]
Login-LAT-Group ]
Login-LAT-Node ]
Login-LAT-Port ]
Login-LAT-Service ]
Login-Service ]
Login-TCP-Port ]
Tunneling ]
Proxy-Info ]
Route-Record ]
AVP ]
Calhoun, et al.
Standards Track
[Page 19]
RFC 4005
August 2005
Calhoun, et al.
Standards Track
[Page 20]
RFC 4005
August 2005
issues, should the request traverse an AAA system that only supports
the RADIUS protocol.
Some RADIUS attributes are not allowed or supported directly in
Diameter. See section 9 for more information.
4.1.
Calhoun, et al.
Standards Track
[Page 21]
RFC 4005
4.2.
August 2005
NAS-Port AVP
The NAS-Port AVP (AVP Code 5) is of type Unsigned32 and contains the
physical or virtual port number of the NAS which is authenticating
the user. Note that "port" is meant in its sense as a service
connection on the NAS, not as an IP protocol identifier.
Either NAS-Port or NAS-Port-Id (AVP Code 87) SHOULD be present in
AA-Request (AAR) commands if the NAS differentiates among its ports.
4.3.
NAS-Port-Id AVP
The NAS-Port-Id AVP (AVP Code 87) is of type UTF8String and consists
of ASCII text identifying the port of the NAS authenticating the
user. Note that "port" is meant in its sense as a service connection
on the NAS, not as an IP protocol identifier.
Either NAS-Port or NAS-Port-Id SHOULD be present in AA-Request (AAR)
commands if the NAS differentiates among its ports. NAS-Port-Id is
intended for use by NASes that cannot conveniently number their
ports.
4.4.
NAS-Port-Type AVP
Async
Sync
ISDN Sync
ISDN Async V.120
ISDN Async V.110
Virtual
PIAFS
HDLC Clear Channel
X.25
X.75
G.3 Fax
SDSL - Symmetric DSL
ADSL-CAP - Asymmetric DSL, Carrierless Amplitude Phase
Modulation
ADSL-DMT - Asymmetric DSL, Discrete Multi-Tone
IDSL - ISDN Digital Subscriber Line
Calhoun, et al.
Standards Track
[Page 22]
RFC 4005
15
16
17
18
19
20
21
22
23
24
25
Ethernet
xDSL - Digital Subscriber Line of unknown type
Cable
Wireless - Other
Wireless - IEEE 802.11
Token-Ring
[RAD802.1X]
FDDI
[RAD802.1X]
Wireless - CDMA2000
Wireless - UMTS
Wireless - 1X-EV
IAPP
[IEEE 802.11f]
4.5.
August 2005
Called-Station-Id AVP
Calling-Station-Id AVP
Calhoun, et al.
Standards Track
[Page 23]
RFC 4005
August 2005
Connect-Info AVP
The Connect-Info AVP (AVP Code 77) is of type UTF8String and is sent
in the AA-Request message or ACR STOP message. When sent in the
Access-Request, it indicates the nature of the users connection.
The connection speed SHOULD be included at the beginning of the first
Connect-Info AVP in the message. If the transmit and receive
connection speeds differ, both may be included in the first AVP with
the transmit speed listed first (the speed the NAS modem transmits
at), then a slash (/), then the receive speed, and then other
optional 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 the ITU
to have modems report more connection information in a standard
format that might exceed 252 octets.
If sent in the ACR STOP, this attribute may summarize statistics
relating to session quality. For example, in IEEE 802.11, the
Connect-Info attribute may contain information on the number of link
layer retransmissions. The exact format of this attribute is
implementation specific.
4.8.
Originating-Line-Info AVP
Calhoun, et al.
Standards Track
[Page 24]
RFC 4005
August 2005
Value
Description
-----------------------------------------------------------00
Plain Old Telephone Service (POTS)
01
Multiparty Line (more than 2)
02
ANI Failure
03
ANI Observed
04
ONI Observed
05
ANI Failure Observed
06
Station Level Rating
07
Special Operator Handling Required
08
InterLATA Restricted
10
Test Call
20
Automatic Identified Outward Dialing (AIOD)
23
Coin or Non-Coin
24
Toll Free Service (Non-Pay Origination)
25
Toll Free Service (Pay Origination)
27
Toll Free Service (Coin Control Origination)
29
Prison/Inmate Service
30-32 Intercept
30
Intercept (Blank)
31
Intercept (Trouble)
32
Intercept (Regular)
34
Telco Operator Handled Call
40-49 Unrestricted Use
52
Outward Wide Area Telecommunications Service (OUTWATS)
60
Telecommunications Relay Service (TRS)(Unrestricted)
61
Cellular/Wireless PCS (Type 1)
62
Cellular/Wireless PCS (Type 2)
63
Cellular/Wireless PCS (Roaming)
66
TRS (Hotel)
67
TRS (Restricted)
70
Pay Station, No Coin Control
93
Access for Private Virtual Network Service
4.9.
Reply-Message AVP
Calhoun, et al.
Standards Track
[Page 25]
RFC 4005
August 2005
5.1.
User-Password AVP
Calhoun, et al.
Standards Track
[Page 26]
RFC 4005
August 2005
Password-Retry AVP
The Password-Retry AVP (AVP Code 75) is of type Unsigned32 and MAY be
included in the AA-Answer if the Result-Code indicates an
authentication failure. The value of this AVP indicates how many
authentication attempts a user is permitted before being
disconnected. This AVP is primarily intended for use when the
Framed-Protocol AVP (see section 6.10.1) is set to ARAP.
5.3.
Prompt AVP
The Prompt AVP (AVP Code 76) is of type Enumerated and MAY be present
in the AA-Answer message. When present, it is used by the NAS to
determine whether the users response, when entered, should be
echoed.
The supported values are listed in [RADIUSTypes].
is informational:
0
1
5.4.
No Echo
Echo
CHAP-Auth AVP
The CHAP-Auth AVP (AVP Code 402) is of type Grouped and contains the
information necessary to authenticate a user using the PPP
Challenge-Handshake Authentication Protocol (CHAP) [PPPCHAP]. If the
CHAP-Auth AVP is found in a message, the CHAP-Challenge AVP MUST be
present as well. The optional AVPs containing the CHAP response
depend upon the value of the CHAP-Algorithm AVP. The grouped AVP has
the following ABNF grammar:
CHAP-Auth
Calhoun, et al.
::= <
{
{
[
* [
Standards Track
[Page 27]
RFC 4005
5.5.
August 2005
CHAP-Algorithm AVP
CHAP-Ident AVP
The CHAP-Ident AVP (AVP Code 404) is of type OctetString and contains
the 1 octet CHAP Identifier used in the computation of the CHAP
response [PPPCHAP].
5.7.
CHAP-Response AVP
CHAP-Challenge AVP
ARAP-Password AVP
ARAP-Challenge-Response AVP
Calhoun, et al.
Standards Track
[Page 28]
RFC 4005
August 2005
ARAP-Security AVP
The ARAP-Security AVP (AVP Code 73) is of type Unsigned32 and MAY be
present in the AA-Answer message if the Framed-Protocol AVP (see
section 6.10.1) is set to the value of ARAP, and the Result-Code AVP
is set to DIAMETER_MULTI_ROUND_AUTH. See [RADIUSExt] for more
information on the format of this AVP.
5.12.
ARAP-Security-Data AVP
The ARAP-Security AVP (AVP Code 74) is of type OctetString and MAY be
present in the AA-Request or AA-Answer message if the Framed-Protocol
AVP is set to the value of ARAP, and the Result-Code AVP is set to
DIAMETER_MULTI_ROUND_AUTH. This AVP contains the security module
challenge or response associated with the ARAP Security Module
specified in ARAP-Security.
6.
Calhoun, et al.
Standards Track
[Page 29]
RFC 4005
August 2005
Framed-Routing
10 6.10.2 Enumerated | M | P |
| V | Y |
Framed-MTU
12 6.10.3 Unsigned32 | M | P |
| V | Y |
Framed13 6.10.4 Enumerated | M | P |
| V | Y |
Compression
|
|
|
|
|
|
Framed-IP-Address 8 6.11.1 OctetString| M | P |
| V | Y |
Framed-IP-Netmask 9 6.11.2 OctetString| M | P |
| V | Y |
Framed-Route
22 6.11.3 UTF8String | M | P |
| V | Y |
Framed-Pool
88 6.11.4 OctetString| M | P |
| V | Y |
Framed96 6.11.5 Unsigned64 | M | P |
| V | Y |
Interface-Id
|
|
|
|
|
|
Framed-IPv697 6.11.6 OctetString| M | P |
| V | Y |
Prefix
|
|
|
|
|
|
Framed-IPv699 6.11.7 UTF8String | M | P |
| V | Y |
Route
|
|
|
|
|
|
Framed-IPv6-Pool 100 6.11.8 OctetString| M | P |
| V | Y |
Framed-IPX23 6.12.1 UTF8String | M | P |
| V | Y |
Network
|
|
|
|
|
|
Framed-Appletalk- 37 6.13.1 Unsigned32 | M | P |
| V | Y |
Link
|
|
|
|
|
|
Framed-Appletalk- 38 6.13.2 Unsigned32 | M | P |
| V | Y |
Network
|
|
|
|
|
|
Framed-Appletalk- 39 6.13.3 OctetString| M | P |
| V | Y |
Zone
|
|
|
|
|
|
ARAP-Features
71 6.14.1 OctetString| M | P |
| V | Y |
ARAP-Zone-Access 72 6.14.2 Enumerated | M | P |
| V | Y |
Login-IP-Host
14 6.15.1 OctetString| M | P |
| V | Y |
Login-IPv6-Host
98 6.15.2 OctetString| M | P |
| V | Y |
Login-Service
15 6.15.3 Enumerated | M | P |
| V | Y |
Login-TCP-Port
16 6.16.1 Unsigned32 | M | P |
| V | Y |
Login-LAT-Service 34 6.17.1 OctetString| M | P |
| V | Y |
Login-LAT-Node
35 6.17.2 OctetString| M | P |
| V | Y |
Login-LAT-Group
36 6.17.3 OctetString| M | P |
| V | Y |
Login-LAT-Port
63 6.17.4 OctetString| M | P |
| V | Y |
-----------------------------------------|----+-----+----+-----|----|
6.1.
Service-Type AVP
Calhoun, et al.
Standards Track
[Page 30]
RFC 4005
August 2005
The
Login
Framed
Callback Login
Callback Framed
Outbound
Administrative
NAS Prompt
Authenticate Only
Callback NAS Prompt
Call Check
Callback Administrative
Voice
Fax
Modem Relay
IAPP-Register
[IEEE 802.11f]
IAPP-AP-Check
[IEEE 802.11f]
Authorize Only [RADDynAuth]
Calhoun, et al.
Standards Track
[Page 31]
RFC 4005
6.2.
August 2005
Callback-Number AVP
Callback-Id AVP
The Callback-Id AVP (AVP Code 20) is of type UTF8String and contains
the name of a place to be called, to be interpreted by the NAS. This
AVP MAY be present in an authentication and/or authorization
response.
This AVP is not roaming-friendly as it assumes that the Callback-Id
is configured on the NAS. Using the Callback-Number AVP therefore
preferable.
6.4.
Idle-Timeout AVP
The Idle-Timeout AVP (AVP Code 28) is of type Unsigned32 and sets the
maximum number of consecutive seconds of idle connection allowable to
the user before termination of the session or before a prompt is
issued. The default is none, or system specific.
6.5.
Port-Limit AVP
The Port-Limit AVP (AVP Code 62) is of type Unsigned32 and sets the
maximum number of ports the NAS provides to the user. It MAY be used
in an authentication and/or authorization request as a hint to the
server that multilink PPP [PPPMP] service is desired, but the server
is not required to honor the hint in the corresponding response.
6.6.
NAS-Filter-Rule AVP
Calhoun, et al.
Standards Track
[Page 32]
RFC 4005
6.7.
August 2005
Filter-Id AVP
The Filter-Id AVP (AVP Code 11) is of type UTF8String and contains
the name of the filter list for this user. Zero or more Filter-Id
AVPs MAY be sent in an authorization answer.
Identifying a filter list by name allows the filter to be used on
different NASes without regard to filter-list implementation details.
However, this AVP is not roaming friendly, as filter naming differs
from one service provider to another.
In non-RADIUS environments, it is RECOMMENDED that the NAS-FilterRule AVP be used instead.
6.8.
Configuration-Token AVP
QoS-Filter-Rule AVP
(in or out)
(possibly masked)
(lists or ranges)
(no mask or range)
Calhoun, et al.
Standards Track
[Page 33]
RFC 4005
August 2005
meter
dir
proto
options:
DSCP <color>
Color values as defined in [DIFFSERV]. Exact
matching of DSCP values is required (no masks or
ranges).
metering <rate> <color_under> <color_over>
The metering option provides Assured Forwarding,
as defined in [DIFFSERVAF], and MUST be present
if the action is set to meter. The rate option is
the throughput, in bits per second, used
by the access device to mark packets. Traffic
over the rate is marked with the color_over
codepoint, and traffic under the rate is marked
with the color_under codepoint. The color_under
and color_over options contain the drop
preferences and MUST conform to the recommended
codepoint keywords described in [DIFFSERVAF]
(e.g., AF13).
The metering option also supports the strict
limit on traffic required by Expedited
Forwarding, as defined in [DIFFSERVEF]. The
color_over option may contain the keyword "drop"
to prevent forwarding of traffic that exceeds the
rate parameter.
Calhoun, et al.
Standards Track
[Page 34]
RFC 4005
August 2005
Framed-Protocol AVP
PPP
SLIP
AppleTalk Remote Access Protocol (ARAP)
Gandalf proprietary SingleLink/MultiLink protocol
Xylogics proprietary IPX/SLIP
X.75 Synchronous
Framed-Routing AVP
None
Send routing packets
Listen for routing packets
Send and Listen
Framed-MTU AVP
The Framed-MTU AVP (AVP Code 12) is of type Unsigned32 and contains
the Maximum Transmission Unit to be configured for the user, when it
is not negotiated by some other means (such as PPP). This AVP SHOULD
only be present in authorization responses. The MTU value MUST be in
the range from 64 to 65535.
Calhoun, et al.
Standards Track
[Page 35]
RFC 4005
6.10.4.
August 2005
Framed-Compression AVP
None
VJ TCP/IP header compression
IPX header compression
Stac-LZS compression
IP Access Authorization AVPs
The AVPs defined in this section are used when the user requests, or
is being granted, access service to IP.
6.11.1.
Framed-IP-Address AVP
Framed-IP-Netmask AVP
Calhoun, et al.
Standards Track
[Page 36]
RFC 4005
August 2005
is desired, but the server is not required to honor the hint in the
corresponding response. This AVP MUST be present in a response if
the request included this AVP with a value of 0xFFFFFFFF.
6.11.3.
Framed-Route AVP
The Framed-Route AVP (AVP Code 22) is of type UTF8String and contains
the ASCII routing information to be configured for the user on the
NAS. Zero or more of these AVPs MAY be present in an authorization
response.
The string MUST 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 should be used. This 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".
The length specifier may be omitted, in which case it should default
to 8 bits for class A prefixes, to 16 bits for class B prefixes, and
to 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.
6.11.4.
Framed-Pool AVP
The Framed-Pool AVP (AVP Code 88) is of type OctetString and 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 AVP. Address pools are usually
used for IP addresses but can be used for other protocols if the NAS
supports pools for those protocols.
Although specified as type OctetString for compatibility with RADIUS
[RADIUSExt], the encoding of the Data field SHOULD also conform to
the rules for the UTF8String Data Format.
6.11.5.
Framed-Interface-Id AVP
Calhoun, et al.
Standards Track
[Page 37]
RFC 4005
6.11.6.
August 2005
Framed-IPv6-Prefix AVP
Framed-IPv6-Route AVP
Framed-IPv6-Pool AVP
IPX Access
The AVPs defined in this section are used when the user requests, or
is being granted, access to an IPX network service.
Calhoun, et al.
Standards Track
[Page 38]
RFC 4005
6.12.1.
August 2005
Framed-IPX-Network AVP
The AVPs defined in this section are used when the user requests, or
is being granted, access to an AppleTalk network [AppleTalk].
6.13.1.
Framed-AppleTalk-Link AVP
Framed-AppleTalk-Network AVP
Calhoun, et al.
Standards Track
[Page 39]
RFC 4005
6.13.3.
August 2005
Framed-AppleTalk-Zone AVP
The AVPs defined in this section are used when the user requests, or
is being granted, access to the AppleTalk network via the AppleTalk
Remote Access Protocol [ARAP]. They are only present if the FramedProtocol AVP (see section 6.10.1) is set to ARAP. Section 2.2 of RFC
2869 [RADIUSExt] describes the operational use of these attributes.
6.14.1.
ARAP-Features AVP
The ARAP-Features AVP (AVP Code 71) is of type OctetString and MAY be
present in the AA-Accept message if the Framed-Protocol AVP is set to
the value of ARAP. See [RADIUSExt] for more information about the
format of this AVP.
6.14.2.
ARAP-Zone-Access AVP
The ARAP-Zone-Access AVP (AVP Code 72) is of type Enumerated and MAY
be present in the AA-Accept message if the Framed-Protocol AVP is set
to the value of ARAP.
The supported values are listed in [RADIUSTypes] and defined in
[RADIUSExt].
6.15.
Login-IP-Host AVP
Calhoun, et al.
Standards Track
[Page 40]
RFC 4005
August 2005
host is desired, but the Diameter Server is not required to honor the
hint in the AA-Answer.
Two addresses have special significance: all ones and 0. The value
of all ones 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.
6.15.2.
Login-IPv6-Host AVP
Login-Service AVP
Telnet
Rlogin
TCP Clear
PortMaster (proprietary)
LAT
X25-PAD
X25-T3POS
TCP Clear Quiet (suppresses any NAS-generated connect
string)
Calhoun, et al.
Standards Track
[Page 41]
RFC 4005
6.16.
August 2005
TCP Services
The AVPs described in this section MAY be present if the LoginService AVP is set to Telnet, Rlogin, TCP Clear, or TCP Clear Quiet.
6.16.1.
Login-TCP-Port AVP
LAT Services
The AVPs described in this section MAY be present if the LoginService AVP is set to LAT [LAT].
6.17.1.
Login-LAT-Service AVP
Calhoun, et al.
Standards Track
[Page 42]
RFC 4005
6.17.2.
August 2005
Login-LAT-Node AVP
Login-LAT-Group AVP
Login-LAT-Port AVP
Calhoun, et al.
Standards Track
[Page 43]
RFC 4005
August 2005
The String field 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 [ISOLatin].
All LAT string comparisons are case insensitive.
7.
NAS Tunneling
Some NASes support compulsory tunnel services in which the incoming
connection data is conveyed by an encapsulation method to a gateway
elsewhere in the network. This is typically transparent to the
service user, and the tunnel characteristics may be described by the
remote AAA server, based on the users authorization information.
Several tunnel characteristics may be returned, and the NAS
implementation may choose one [RADTunnels], [RADTunlAcct].
+---------------------+
|
AVP Flag rules
|
|----+-----+----+-----|----+
AVP Section
|
|
|SHLD| MUST|
|
Attribute Name Code Defined Value Type |MUST| MAY | NOT| NOT |Encr|
-----------------------------------------|----+-----+----+-----|----|
Tunneling
401
7.1
Grouped
| M | P |
| V | N |
Tunnel-Type
64
7.2
Enumerated | M | P |
| V | Y |
Tunnel-Medium65
7.3
Enumerated | M | P |
| V | Y |
Type
|
|
|
|
|
|
Tunnel-Client66
7.4
UTF8String | M | P |
| V | Y |
Endpoint
|
|
|
|
|
|
Tunnel-Server67
7.5
UTF8String | M | P |
| V | Y |
Endpoint
|
|
|
|
|
|
Tunnel-Password
69
7.6
OctetString| M | P |
| V | Y |
Tunnel-Private81
7.7
OctetString| M | P |
| V | Y |
Group-Id
|
|
|
|
|
|
Tunnel82
7.8
OctetString| M | P |
| V | Y |
Assignment-Id
|
|
|
|
|
|
Tunnel-Preference 83
7.9
Unsigned32 | M | P |
| V | Y |
Tunnel-Client90
7.10
UTF8String | M | P |
| V | Y |
Auth-Id
|
|
|
|
|
|
Tunnel-Server91
7.11
UTF8String | M | P |
| V | Y |
Auth-Id
|
|
|
|
|
|
-----------------------------------------|----+-----+----+-----|----|
7.1.
Tunneling AVP
The Tunneling AVP (AVP Code 401) is of type Grouped and contains the
following AVPs, used to describe a compulsory tunnel service:
[RADTunnels], [RADTunlAcct]. Its data field has the following ABNF
grammar:
Calhoun, et al.
Standards Track
[Page 44]
RFC 4005
Tunneling
7.2.
::= <
{
{
{
{
[
[
[
[
[
[
August 2005
Tunnel-Type AVP
The Tunnel-Type AVP (AVP Code 64) is of type Enumerated and contains
the tunneling protocol(s) to be used (in the case of a tunnel
initiator) or in use (in the case of a tunnel terminator). It MAY be
used in an authorization request as a hint to the server that a
specific tunnel type is desired, but the server is not required to
honor the hint in the corresponding response.
The Tunnel-Type AVP SHOULD also be included in Accounting-Request
messages.
A tunnel initiator is not required to implement any of these tunnel
types. If a tunnel initiator receives a response that contains only
unknown or unsupported Tunnel-Types, the tunnel initiator MUST behave
as though a response were received with the Result-Code indicating a
failure.
The supported values are listed in [RADIUSTypes].
is informational:
1
2
3
4
5
6
7
8
9
10
11
12
13
Calhoun, et al.
Standards Track
[Page 45]
RFC 4005
7.3.
August 2005
Tunnel-Medium-Type AVP
Tunnel-Client-Endpoint AVP
Calhoun, et al.
Standards Track
[Page 46]
RFC 4005
August 2005
Tunnel-Server-Endpoint AVP
Calhoun, et al.
Standards Track
[Page 47]
RFC 4005
7.6.
August 2005
Tunnel-Password AVP
The Tunnel-Password AVP (AVP Code 69) is of type OctetString and may
contain a password to be used to authenticate to a remote server.
The Tunnel-Password AVP contains sensitive information. This value
is not protected in the same manner as RADIUS [RADTunnels].
As required in [BASE], Diameter messages are encrypted by using IPsec
or TLS. The Tunnel-Password AVP SHOULD NOT be used in untrusted
proxy environments without encrypting it by using end-to-end security
techniques, such as CMS Security [DiamCMS].
7.7.
Tunnel-Private-Group-Id AVP
Tunnel-Assignment-Id AVP
Calhoun, et al.
Standards Track
[Page 48]
RFC 4005
August 2005
Note that the same Id may be used to name different tunnels if these
tunnels are between different endpoints.
7.9.
Tunnel-Preference AVP
Calhoun, et al.
Standards Track
[Page 49]
RFC 4005
August 2005
Tunnel-Client-Auth-Id AVP
Tunnel-Server-Auth-Id AVP
NAS Accounting
Applications implementing this specification use Diameter Accounting,
as defined in [BASE], and the AVPs in the following section.
Service-specific AVP usage is defined in the tables in section 10.
If accounting is active, Accounting Request (ACR) messages SHOULD be
sent after the completion of any Authentication or Authorization
Calhoun, et al.
Standards Track
[Page 50]
RFC 4005
August 2005
Accounting-Input-Octets AVP
Calhoun, et al.
Standards Track
[Page 51]
RFC 4005
August 2005
For NAS usage, this AVP indicates how many octets have been received
from the port in the course of this session. It can only be present
in ACR messages with an Accounting-Record-Type of INTERIM_RECORD or
STOP_RECORD.
8.2.
Accounting-Output-Octets AVP
Accounting-Input-Packets AVP
Accounting-Output-Packets AVP
Acct-Session-Time AVP
Acct-Authentic AVP
Calhoun, et al.
Standards Track
[Page 52]
RFC 4005
1
2
3
4
8.7.
August 2005
RADIUS
Local
Remote
Diameter
Accounting-Auth-Method AVP
PAP
CHAP
MS-CHAP-1
MS-CHAP-2
EAP
None
Acct-Delay-Time
Calhoun, et al.
Standards Track
[Page 53]
RFC 4005
8.9.
August 2005
Acct-Link-Count
Acct-Tunnel-Connection AVP
Calhoun, et al.
Standards Track
[Page 54]
RFC 4005
8.11.
August 2005
Acct-Tunnel-Packets-Lost AVP
9.1.
Calhoun, et al.
Standards Track
[Page 55]
RFC 4005
August 2005
Calhoun, et al.
Standards Track
[Page 56]
RFC 4005
August 2005
Calhoun, et al.
Standards Track
[Page 57]
RFC 4005
August 2005
If the Command-Code is set to AA-Answer, the Diameter SessionId AVP is saved in a new RADIUS Class attribute whose format
consists of the string "Diameter/" followed by the Diameter
Session Identifier. This will ensure that the subsequent
Accounting messages, which could be received by any Translation
Agent, would have access to the original Diameter Session
Identifier.
If a Proxy-State attribute was present in the RADIUS request,
the same attribute is added in the response. This information
may be found in the Proxy-Info AVP group, or in a local state
table.
If state information regarding the RADIUS request was saved in
a Proxy-Info AVP or local state table, the RADIUS Identifier
and UDP IP Address and port number are extracted and used in
issuing the RADIUS reply.
Calhoun, et al.
Standards Track
[Page 58]
RFC 4005
9.1.1.
August 2005
Calhoun, et al.
Standards Track
[Page 59]
RFC 4005
August 2005
Origin-Host AVP
Session-Id AVP
Proxy-Info AVP
Any other AVP that MUST be present in the response and
has no corresponding RADIUS attribute.
Calhoun, et al.
Standards Track
[Page 60]
RFC 4005
August 2005
If the RADIUS code is set to Access-Challenge, a Diameter AAAnswer message is created with the Result-Code set to
DIAMETER_MULTI_ROUND_AUTH. If the Session-Timeout AVP is
present in the RADIUS message, its value is inserted into the
Multi-Round-Time-Out AVP.
Any other AVPs that were saved at request time, and that MUST
be present in the response, are added to the message.
Calhoun, et al.
Standards Track
[Page 61]
RFC 4005
9.2.1.
August 2005
Calhoun, et al.
Standards Track
[Page 62]
RFC 4005
August 2005
The AVPs defined in this section SHOULD only be used for backwards
compatibility when a Diameter/RADIUS translation function is invoked
and are not typically originated by Diameter systems during normal
operations.
+---------------------+
|
AVP Flag rules
|
|----+-----+----+-----|----+
AVP Section
|
|
|SHLD| MUST|
|
Attribute Name Code Defined Value Type |MUST| MAY | NOT| NOT|Encr|
-----------------------------------------|----+-----+----+-----|----|
NAS-Identifier
32 9.3.1
UTF8String | M | P |
| V | Y |
NAS-IP-Address
4 9.3.2
OctetString| M | P |
| V | Y |
NAS-IPv6-Address 95 9.3.3
OctetString| M | P |
| V | Y |
State
24 9.3.4
OctetString| M | P |
| V | Y |
Termination295 9.3.5
Enumerated | M | P |
| V | Y |
Cause
|
|
|
|
|
|
Origin-AAA408 9.3.6
Enumerated | M | P |
| V | Y |
Protocol
|
|
|
|
|
|
-----------------------------------------|----+-----+----+-----|----|
9.3.1.
NAS-Identifier AVP
Calhoun, et al.
Standards Track
[Page 63]
RFC 4005
August 2005
In RADIUS it would be possible for a rogue NAS to forge the NASIdentifier attribute. Diameter/RADIUS translation agents SHOULD
attempt to check a received NAS-Identifier attribute against the
source address of the RADIUS packet, by doing an A/AAAA RR query. If
the NAS-Identifier attribute contains an FQDN, then such a query
would resolve to an IP address matching the source address. However,
the NAS-Identifier attribute is not required to contain an FQDN, so
such a query could fail. If it fails, an error should be logged, but
no action should be taken, other than a reverse lookup on the source
address and insert the resulting FQDN into the Route-Record AVP.
Diameter agents and servers SHOULD check whether a NAS-Identifier AVP
corresponds to an entry in the Route-Record AVP. If no match is
found, then an error is logged, but no other action is taken.
9.3.2.
NAS-IP-Address AVP
Calhoun, et al.
Standards Track
[Page 64]
RFC 4005
August 2005
NAS-IPv6-Address AVP
State AVP
The State AVP (AVP Code 24) [RADIUS] is of type OctetString and has
two uses in the Diameter NAS application.
The State AVP MAY be sent by a Diameter Server to a NAS in an AAResponse command that contains a Result-Code of
DIAMETER_MULTI_ROUND_AUTH. If so, the NAS MUST return it unmodified
in the subsequent AA-Request command.
Calhoun, et al.
Standards Track
[Page 65]
RFC 4005
August 2005
Usage
Calhoun, et al.
Standards Track
[Page 66]
RFC 4005
August 2005
The table in this section defines the mapping between TerminationCause AVP and RADIUS Acct-Terminate-Cause causes.
+-----------------------+
|
Value
|
+-----------+-----------+
Cause Value Name
| RADIUS
| Diameter |
------------------------------|-----------+-----------+
User Request
|
1
|
11
|
Lost Carrier
|
2
|
12
|
Lost Service
|
3
|
13
|
Idle Timeout
|
4
|
14
|
Session Timeout
|
5
|
15
|
Admin Reset
|
6
|
16
|
Admin Reboot
|
7
|
17
|
Port Error
|
8
|
18
|
NAS Error
|
9
|
19
|
NAS Request
|
10
|
20
|
NAS Reboot
|
11
|
21
|
Port Unneeded
|
12
|
22
|
Port Preempted
|
13
|
23
|
Port Suspended
|
14
|
24
|
Service Unavailable
|
15
|
25
|
Callback
|
16
|
26
|
User Error
|
17
|
27
|
Host Request
|
18
|
28
|
Supplicant Restart
|
19
|
29
|
Reauthentication Failure
|
20
|
30
|
Port Reinit
|
21
|
31
|
Port Disabled
|
22
|
32
|
------------------------------|-----------+-----------+
[RAD802.1X]
[RAD802.1X]
[RAD802.1X]
[RAD802.1X]
Lost Carrier
Lost Service
Idle Timeout
Session Timeout
Admin Reset
Calhoun, et al.
Standards Track
[Page 67]
RFC 4005
August 2005
Admin Reboot
Port Error
NAS Error
NAS Request
NAS Reboot
Port Unneeded
Port Preempted
Port Suspended
Service Unavailable
Callback
User Error
Host Request
9.3.6.
Origin-AAA-Protocol
Calhoun, et al.
RADIUS
Standards Track
[Page 68]
RFC 4005
9.4.
August 2005
In general, Diameter AVPs that are not RADIUS compatible have code
values greater than 255. The table in the section above shows the
AVPs that can be converted into RADIUS attributes.
Another problem may occur with Diameter AVP values that may be more
than 253 octets in length. Some RADIUS attributes (including but not
limited to (8)Reply-Message, (79)EAP-Message, and (77)Connect-Info)
allow concatenation of multiple instances to overcome this
limitation. If this is not possible, a Result-Code of
DIAMETER_INVALID_AVP_LENGTH should be returned.
9.6.
Calhoun, et al.
Standards Track
[Page 69]
RFC 4005
August 2005
the next two sections will not work in general for those VSAs. RFC
2865 states that a robust implementation SHOULD support the field as
undistinguished octets.
Systems that dont have vendor format knowledge MAY discard such
attributes without knowing a suitable translation. An alternative
format is under consideration [VSA], which proposes encodings that
would preserve the native information and not require vendor
knowledge in the gateway system.
The following sections are an example for translating RADIUS VSAs
that use the example RADIUS format, and Diameter VSAs that have type
codes less than 255, and value field lengths less than 252.
9.6.1.
For Type codes less than 255, the value field length MUST be less
than 252 or the AVP will be discarded. The RADIUS VSA attribute
should consist of the following fields;
RADIUS
RADIUS
RADIUS
RADIUS
RADIUS
Type =
Length
Vendor
Vendor
Vendor
If the Diameter AVP code is greater than 255, then the RADIUS
speaking code may use a Vendor specific field coding, if it knows one
for that vendor. Otherwise, the AVP will be ignored. If it is
flagged as Mandatory, a "DIAMETER_AVP_UNSUPPORTED" Result-Code will
be returned, and the RADIUS message will not be sent.
9.6.2.
Note that the VSAs are considered optional by RADIUS rules, and this
specification does not set the Mandatory flag. If an implementor
desires a VSA be made mandatory because it represents a required
service policy, the RADIUS gateway should have a process to set the
bit on the Diameter side.
Calhoun, et al.
Standards Track
[Page 70]
RFC 4005
August 2005
The following tables present the AVPs used by NAS applications in NAS
messages and specify in which Diameter messages they MAY or MAY NOT
be present. [BASE] messages and AVPs are not described in this
document. Note that AVPs that can only be present within a Grouped
AVP are not represented in this table.
The table uses the following symbols:
0
0+
0-1
1
10.1.
Calhoun, et al.
Standards Track
[Page 71]
RFC 4005
August 2005
+-----------+
| Command |
|-----+-----+
Attribute Name
| AAR | AAA |
------------------------------|-----+-----+
Callback-Id
| 0
| 0-1 |
Callback-Number
| 0-1 | 0-1 |
Called-Station-Id
| 0-1 | 0
|
Calling-Station-Id
| 0-1 | 0
|
CHAP-Auth
| 0-1 | 0
|
CHAP-Challenge
| 0-1 | 0
|
Class
| 0
| 0+ |
Configuration-Token
| 0
| 0+ |
Connect-Info
| 0+ | 0
|
Destination-Host
| 0-1 | 0
|
Destination-Realm
| 1
| 0
|
Error-Message
| 0
| 0-1 |
Error-Reporting-Host
| 0
| 0-1 |
Failed-AVP
| 0+ | 0+ |
Filter-Id
| 0
| 0+ |
Framed-Appletalk-Link
| 0
| 0-1 |
Framed-Appletalk-Network
| 0
| 0+ |
Framed-Appletalk-Zone
| 0
| 0-1 |
Framed-Compression
| 0+ | 0+ |
Framed-Interface-Id
| 0-1 | 0-1 |
Framed-IP-Address
| 0-1 | 0-1 |
Framed-IP-Netmask
| 0-1 | 0-1 |
Framed-IPv6-Prefix
| 0+ | 0+ |
Framed-IPv6-Pool
| 0
| 0-1 |
Framed-IPv6-Route
| 0
| 0+ |
Framed-IPX-Network
| 0
| 0-1 |
Framed-MTU
| 0-1 | 0-1 |
Framed-Pool
| 0
| 0-1 |
Framed-Protocol
| 0-1 | 0-1 |
Framed-Route
| 0
| 0+ |
Framed-Routing
| 0
| 0-1 |
Idle-Timeout
| 0
| 0-1 |
Login-IP-Host
| 0+ | 0+ |
Login-IPv6-Host
| 0+ | 0+ |
Login-LAT-Group
| 0-1 | 0-1 |
Login-LAT-Node
| 0-1 | 0-1 |
Login-LAT-Port
| 0-1 | 0-1 |
Login-LAT-Service
| 0-1 | 0-1 |
Login-Service
| 0
| 0-1 |
Login-TCP-Port
| 0
| 0-1 |
Multi-Round-Time-Out
| 0
| 0-1 |
------------------------------|-----+-----+
Calhoun, et al.
Standards Track
[Page 72]
RFC 4005
August 2005
+-----------+
| Command |
|-----+-----+
Attribute Name
| AAR | AAA |
------------------------------|-----+-----+
NAS-Filter-Rule
| 0
| 0+ |
NAS-Identifier
| 0-1 | 0
|
NAS-IP-Address
| 0-1 | 0
|
NAS-IPv6-Address
| 0-1 | 0
|
NAS-Port
| 0-1 | 0
|
NAS-Port-Id
| 0-1 | 0
|
NAS-Port-Type
| 0-1 | 0
|
Origin-AAA-Protocol
| 0-1 | 0-1 |
Origin-Host
| 1
| 1
|
Origin-Realm
| 1
| 1
|
Origin-State-Id
| 0-1 | 0-1 |
Originating-Line-Info
| 0-1 | 0
|
Password-Retry
| 0
| 0-1 |
Port-Limit
| 0-1 | 0-1 |
Prompt
| 0
| 0-1 |
Proxy-Info
| 0+ | 0+ |
QoS-Filter-Rule
| 0
| 0+ |
Re-Auth-Request-Type
| 0
| 0-1 |
Redirect-Host
| 0
| 0+ |
Redirect-Host-Usage
| 0
| 0-1 |
Redirect-Max-Cache-Time
| 0
| 0-1 |
Reply-Message
| 0
| 0+ |
Result-Code
| 0
| 1
|
Route-Record
| 0+ | 0+ |
Service-Type
| 0-1 | 0-1 |
Session-Id
| 1
| 1
|
Session-Timeout
| 0
| 0-1 |
State
| 0-1 | 0-1 |
Tunneling
| 0+ | 0+ |
User-Name
| 0-1 | 0-1 |
User-Password
| 0-1 | 0
|
------------------------------|-----+-----+
10.2.
The tables in this section are used to show which AVPs defined in
this document are to be present and used in NAS application
Accounting messages. These AVPs are defined in this document, as
well as in [BASE] and [RADIUSAcct].
Calhoun, et al.
Standards Track
[Page 73]
RFC 4005
10.2.1.
August 2005
Calhoun, et al.
Standards Track
[Page 74]
RFC 4005
August 2005
+-----------+
| Command |
|-----+-----+
Attribute Name
| ACR | ACA |
---------------------------------------|-----+-----+
Framed-AppleTalk-Link
| 0-1 | 0
|
Framed-AppleTalk-Network
| 0-1 | 0
|
Framed-AppleTalk-Zone
| 0-1 | 0
|
Framed-Compression
| 0-1 | 0
|
Framed-IP-Address
| 0-1 | 0
|
Framed-IP-Netmask
| 0-1 | 0
|
Framed-IPv6-Prefix
| 0+ | 0
|
Framed-IPv6-Pool
| 0-1 | 0
|
Framed-IPX-Network
| 0-1 | 0
|
Framed-MTU
| 0-1 | 0
|
Framed-Pool
| 0-1 | 0
|
Framed-Protocol
| 0-1 | 0
|
Framed-Route
| 0-1 | 0
|
Framed-Routing
| 0-1 | 0
|
NAS-Filter-Rule
| 0+ | 0
|
NAS-Identifier
| 0-1 | 0-1 |
NAS-IP-Address
| 0-1 | 0-1 |
NAS-IPv6-Address
| 0-1 | 0-1 |
NAS-Port
| 0-1 | 0-1 |
NAS-Port-Id
| 0-1 | 0-1 |
NAS-Port-Type
| 0-1 | 0-1 |
Origin-AAA-Protocol
| 0-1 | 0-1 |
Origin-Host
| 1
| 1
|
Origin-Realm
| 1
| 1
|
Origin-State-Id
| 0-1 | 0-1 |
Originating-Line-Info
| 0-1 | 0
|
Proxy-Info
| 0+ | 0+ |
QoS-Filter-Rule
| 0+ | 0
|
Route-Record
| 0+ | 0+ |
Result-Code
| 0
| 1
|
Service-Type
| 0-1 | 0-1 |
Session-Id
| 1
| 1
|
Termination-Cause
| 0-1 | 0-1 |
Tunnel-Assignment-Id
| 0-1 | 0
|
Tunnel-Client-Endpoint
| 0-1 | 0
|
Tunnel-Medium-Type
| 0-1 | 0
|
Tunnel-Private-Group-Id
| 0-1 | 0
|
Tunnel-Server-Endpoint
| 0-1 | 0
|
Tunnel-Type
| 0-1 | 0
|
User-Name
| 0-1 | 0-1 |
Vendor-Specific-Application-Id
| 0-1 | 0-1 |
---------------------------------------|-----+-----+
Calhoun, et al.
Standards Track
[Page 75]
RFC 4005
10.2.2.
August 2005
Calhoun, et al.
Standards Track
[Page 76]
RFC 4005
August 2005
+-----------+
| Command |
|-----+-----+
Attribute Name
| ACR | ACA |
---------------------------------------|-----+-----+
NAS-Identifier
| 0-1 | 0-1 |
NAS-IP-Address
| 0-1 | 0-1 |
NAS-IPv6-Address
| 0-1 | 0-1 |
NAS-Port
| 0-1 | 0-1 |
NAS-Port-Id
| 0-1 | 0-1 |
NAS-Port-Type
| 0-1 | 0-1 |
Origin-AAA-Protocol
| 0-1 | 0-1 |
Origin-Host
| 1
| 1
|
Origin-Realm
| 1
| 1
|
Origin-State-Id
| 0-1 | 0-1 |
Originating-Line-Info
| 0-1 | 0
|
Proxy-Info
| 0+ | 0+ |
QoS-Filter-Rule
| 0+ | 0
|
Route-Record
| 0+ | 0+ |
Result-Code
| 0
| 1
|
Session-Id
| 1
| 1
|
Service-Type
| 0-1 | 0-1 |
Termination-Cause
| 0-1 | 0-1 |
User-Name
| 0-1 | 0-1 |
Vendor-Specific-Application-Id
| 0-1 | 0-1 |
---------------------------------------|-----+-----+
11.
IANA Considerations
Command Codes
This specification assigns the value 265 from the Command Code
namespace defined in [BASE]. See sections 3.1 and 3.2 for the
assignment of the namespace in this specification.
Calhoun, et al.
Standards Track
[Page 77]
RFC 4005
11.2.
August 2005
AVP Codes
This specification assigns the values 363 - 366 and 400 - 408 from
the AVP Code namespace defined in [BASE]. See sections 4 and 5 for
the assignment of the namespace in this specification. Note that the
values 363 - 366 are jointly, but consistently, assigned in
[DiamMIP]. This document also creates one new namespace to be
managed by IANA, as described in section 11.5.
This specification also specifies the use of AVPs in the 0 - 255
range, which are defined in [RADIUSTypes]. These values are assigned
by the policy in RFC 2865 section 6 [RADIUS] and are amended by RFC
3575 [RADIUSIANA].
11.3.
Application Identifier
As defined in section 5.5, the CHAP-Algorithm AVP (AVP Code 403) uses
the values of the "PPP AUTHENTICATION ALGORITHMS" namespace defined
in [PPPCHAP].
11.5.
Security Considerations
Calhoun, et al.
Standards Track
[Page 78]
RFC 4005
August 2005
This document does not contain a security protocol but does discuss
how PPP authentication protocols can be carried within the Diameter
protocol. The PPP authentication protocols described are PAP and
CHAP.
The use of PAP SHOULD be discouraged, as it exposes users passwords
to possibly non-trusted entities. However, PAP is also frequently
used for use with One-Time Passwords, which do not expose a security
risk.
This document also describes how CHAP can be carried within the
Diameter protocol, which is required for RADIUS backward
compatibility. The CHAP protocol, as used in a RADIUS environment,
facilitates authentication replay attacks.
The use of the EAP authentication protocols described in [DiamEAP]
can offer better security, given a method suitable for the
circumstances.
13.
References
13.1.
Normative References
[BASE]
[DiamTrans]
[RADIUS]
[RADIUSTypes]
[RADIUSIPv6]
[IPv6Addr]
[PPPCHAP]
Calhoun, et al.
Standards Track
[Page 79]
RFC 4005
August 2005
[IANAConsid]
[IANA]
[Keywords]
[ANITypes]
13.2.
Informative References
[RADIUSAcct]
[RADIUSExt]
[RADTunnels]
[RADTunlAcct]
[RADDynAuth]
[RADIUSIANA]
[NASModel]
[NASCriteria]
Calhoun, et al.
Standards Track
[Page 80]
RFC 4005
August 2005
[AAACriteria]
[DiamEAP]
[DiamCMS]
[DiamMIP]
[VSA]
[RAD802.1X]
[CDMA2000]
[AppleTalk]
[ARAP]
[IPX]
[LAT]
Calhoun, et al.
Standards Track
[Page 81]
RFC 4005
August 2005
[DIFFSERV]
[DIFFSERVAF]
[DIFFSERVEF]
[UTF-8]
[ISOLatin]
[PPP]
[PAP]
[L2TP]
[PPPMP]
[PPTP]
Calhoun, et al.
Standards Track
[Page 82]
RFC 4005
14.
August 2005
Acknowledgements
The authors would like to thank Carl Rigney, Allan C. Rubens, William
Allen Simpson, and Steve Willens for their work on the original
RADIUS [RADIUS], from which many of the concepts in this
specification were derived. Thanks, also, to Carl Rigney for
[RADIUSAcct] and [RADIUSExt]; Ward Willats for [RADIUSExt]; Glen
Zorn, Bernard Aboba, and Dave Mitton for [RADTunlAcct] and
[RADIUSIPv6]; and Dory Leifer, John Shriver, Matt Holdrege, and
Ignacio Goyret for their work on [RADTunnels]. This document stole
text and concepts from both [RADTunnels] and [RADIUSExt]. Thanks go
to Carl Williams for providing IPv6-specific text.
The authors would also like to acknowledge the following people for
their contributions in the development of the Diameter protocol:
Bernard Aboba, Jari Arkko, William Bulley, Kuntal Chowdhury, Daniel
C. Fox, Lol Grant, Nancy Greene, Jeff Hagg, Peter Heitman, Paul
Krumviede, Fergal Ladley, Ryan Moats, Victor Muslin, Kenneth Peirce,
Sumit Vakil, John R. Vollbrecht, and Jeff Weisberg.
Finally, Pat Calhoun would like to thank Sun Microsystems, as most of
the effort put into this document was done while he was in their
employ.
Calhoun, et al.
Standards Track
[Page 83]
RFC 4005
August 2005
Authors Addresses
Pat Calhoun
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134
USA
Phone: +1 408-853-5269
EMail: pcalhoun@cisco.com
Glen Zorn
Cisco Systems, Inc.
500 108th Avenue N.E., Suite 500
Bellevue, WA 98004
USA
Phone: 1 425-471-4861
EMail: gwz@cisco.com
David Spence
3259 Bluett Rd.
Ann Arbor, MI 48105
USA
Phone: +1 734 834 6481
EMail: dspence@computer.org
David Mitton
Circular Networks
733 Turnpike St #154
North Andover, MA 01845
EMail: dmitton@circularnetworks.com
Calhoun, et al.
Standards Track
[Page 84]
RFC 4005
August 2005
Calhoun, et al.
Standards Track
[Page 85]