10. AVP Occurrence Tables
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 The AVP MUST NOT be present in the message.
0+ Zero or more instances of the AVP MAY be present in the
0-1 Zero or one instance of the AVP MAY be present in the
1 One instance of the AVP MUST be present in the message.
10.1. AA-Request/Answer AVP Table
The table in this section is limited to the Command Codes defined in
| Command |
Attribute Name | AAR | AAA |
Acct-Interim-Interval | 0 | 0-1 |
ARAP-Challenge-Response | 0 | 0-1 |
ARAP-Features | 0 | 0-1 |
ARAP-Password | 0-1 | 0 |
ARAP-Security | 0-1 | 0-1 |
ARAP-Security-Data | 0+ | 0+ |
ARAP-Zone-Access | 0 | 0-1 |
Auth-Application-Id | 1 | 1 |
Auth-Grace-Period | 0-1 | 0-1 |
Auth-Request-Type | 1 | 1 |
Auth-Session-State | 0-1 | 0-1 |
Authorization-Lifetime | 0-1 | 0-1 |
| 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
This section provides guidance to the Internet Assigned Numbers
Authority (IANA) regarding registration of values related to the
Diameter protocol, in accordance with BCP 26 [IANAConsid].
This document defines values in the namespaces that have been created
and defined in the Diameter Base [BASE]. The IANA Considerations
section of that document details the assignment criteria. Values
assigned in this document, or by future IANA action, must be
coordinated within this shared namespace.
11.1. 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.
11.2. 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 2865section 6 [RADIUS] and are amended by RFC
11.3. Application Identifier
This specification uses the value one (1) in the Application
Identifier namespace as assigned in [BASE]. See section 1.2 above
for more information.
11.4. CHAP-Algorithm AVP Values
As defined in section 5.5, the CHAP-Algorithm AVP (AVP Code 403) uses
the values of the "PPP AUTHENTICATION ALGORITHMS" namespace defined
11.5. Accounting-Auth-Method AVP Values
As defined in section 8.6, the Accounting-Auth-Method AVP (AVP Code
406) defines the values 1 - 5. All remaining values are available
for assignment via IETF Consensus [IANA].
11.6. Origin-AAA-Protocol AVP Values
As defined in section 9.3.6, the Origin-AAA-Protocol AVP (AVP Code
408) defines the value 1. All remaining values are available for
assignment with a "Specification Required" policy [IANAConsid].
12. Security Considerations
This document describes the extension of Diameter for the NAS
application. The security considerations of the Diameter protocol
itself have been discussed in [BASE]. Use of this application of
Diameter MUST take into consideration the security issues and
requirements of the Base protocol.
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
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
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
13.1. Normative References
[BASE] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and
J. Arkko, "Diameter Base Protocol", RFC 3588,
[DiamTrans] Aboba, B. and J. Wood, "Authentication, Authorization
and Accounting (AAA) Transport Profile", RFC 3539,
[RADIUS] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
"Remote Authentication Dial In User Service (RADIUS)",
RFC 2865, June 2000.
[RADIUSTypes] IANA, "RADIUS Types", URL:
[RADIUSIPv6] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6",
RFC 3162, August 2001.
[IPv6Addr] Nerenberg, L., "IMAP4 Binary Content Extension", RFC
3516, April 2003.
[PPPCHAP] Simpson, W., "PPP Challenge Handshake Authentication
Protocol (CHAP)", RFC 1994, August 1996.
[AAACriteria] Aboba, B., Calhoun, P., Glass, S., Hiller, T., McCann,
P., Shiino, H., Zorn, G., Dommety, G., Perkins, C.,
Patil, B., Mitton, D., Manning, S., Beadles, M.,
Walsh, P., Chen, X., Sivalingham, S., Hameed, A.,
Munson, M., Jacobs, S., Lim, B., Hirschman, B., Hsu,
R., Xu, Y., Campbell, E., Baba, S., and E. Jaques,
"Criteria for Evaluating AAA Protocols for Network
Access", RFC 2989, November 2000.
[DiamEAP] Eronen, P., "Diameter EAP Application", Work in
Progress, May 2004.
[DiamCMS] Calhoun, P., Bulley, W., and S. Farrell, "Diameter CMS
Security Application", Work in Progress, March 2002.
[DiamMIP] Calhoun, P., Johansson, T., Perkins, C., Hiller, T.,
and P. McCann "Diameter Mobile IPv4 Application", RFC
4004, August 2005.
[VSA] Mitton, D., "Diameter/RADIUS Vendor Specific AVP
Translation", Work in Progress, April 2005.
[RAD802.1X] Congdon, P., Aboba, B., Smith, A., Zorn, G., and J.
Roese, "IEEE 802.1X Remote Authentication Dial In User
Service (RADIUS) Usage Guidelines", RFC 3580,
[CDMA2000] 3GPP2 "P.S0001-B", Wireless IP Network Standard,
B_v1.0.pdf[AppleTalk] Sidhu, Gursharan; Andrews, Richard F. & Oppenheimer,
Alan B. "Inside AppleTalk", Second Edition, Apple
[ARAP] Apple Remote Access Protocol (ARAP) Version 2.0
External Reference Specification", Apple Computer,
September 1994, R0612LL/B
[IPX] Novell, Inc., "NetWare System Technical Interface
Overview", June 1989, # 883-000780-001
[LAT] Local Area Transport (LAT) Specification V5.0, Digital
Equipment Corp., AA-NL26A-TE, June 1989
[DIFFSERV] Nichols, K., Blake, S., Baker, F., and D. Black,
"Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474,
[DIFFSERVAF] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski,
"Assured Forwarding PHB Group", RFC 2597, June 1999.
[DIFFSERVEF] Davie, B., Charny, A., Bennet, J.C., Benson, K., Le
Boudec, J., Courtney, W., Davari, S., Firoiu, V., and
D. Stiliadis, "An Expedited Forwarding PHB (Per-Hop
Behavior)", RFC 3246, March 2002.
[UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003.
[ISOLatin] ISO 8859. International Standard -- Information
Processing -- 8-bit Single-Byte Coded Graphic
Character Sets -- Part 1: Latin Alphabet No. 1, ISO
[PPP] Simpson, W., "The Point-to-Point Protocol (PPP)", STD
51, RFC 1661, July 1994.
[PAP] Lloyd, B. and W. Simpson, "PPP Authentication
Protocols", RFC 1334, October 1992.
[L2TP] Townsley, W., Valencia, A., Rubens, A., Pall, G.,
Zorn, G., and B. Palter, "Layer Two Tunneling Protocol
"L2TP"", RFC 2661, August 1999.
[PPPMP] Sklower, K., Lloyd, B., McGregor, G., Carr, D., and T.
Coradetti, "The PPP Multilink Protocol (MP)", RFC
1990, August 1996.
[PPTP] Hamzeh, K., Pall, G., Verthein, W., Taarud, J.,
Little, W., and G. Zorn, "Point-to-Point Tunneling
Protocol", RFC 2637, July 1999.
[IEEE 802.11F] IEEE, "Trial-Use Recommended Practice for Multi-Vendor
Access Point Interoperability via an Inter-Access
Point Protocol Across Distribution Systems Supporting
IEEE 802.11 Operation", IEEE 802.11F-2003, June 2003.
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
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134
Phone: +1 408-853-5269
Cisco Systems, Inc.
500 108th Avenue N.E., Suite 500
Bellevue, WA 98004
Phone: 1 425-471-4861
3259 Bluett Rd.
Ann Arbor, MI 48105
Phone: +1 734 834 6481
733 Turnpike St #154
North Andover, MA 01845
Full Copyright Statement
Copyright (C) The Internet Society (2005).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM 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.
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
Funding for the RFC Editor function is currently provided by the