One document matched: draft-calhoun-diameter-authent-04.txt
Differences from draft-calhoun-diameter-authent-03.txt
INTERNET DRAFT Pat R. Calhoun
Category: Standards Track Sun Microsystems, Inc.
Title: draft-calhoun-diameter-authent-04.txt William Bulley
Date: July 1998 Merit Network, Inc.
DIAMETER
User Authentication Extensions
<draft-calhoun-diameter-authent-04.txt>
Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as ``work in progress.''
To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or
ftp.isi.edu (US West Coast).
Abstract
DIAMETER is a Policy and AAA protocol which can be used for a variety
of services. This document defines DIAMETER messages that are used
for the authentication, authorization and accounting of users.
A considerable amount of effort was put into the design of this
protocol to ensure that an implementation could support both DIAMETER
and RADIUS concurrently.
Calhoun expires January 1999 [Page 1]
INTERNET DRAFT July 1998
Table of Contents
1.0 Introduction
1.1 Specification of Requirements
2.0 Command Codes
2.1 Domain-Discovery-Request
2.2 Domain-Discovery-Answer
2.3 AA-Request
2.4 AA-Answer
2.5 AA-Challenge-Ind
3.0 DIAMETER AVPs
3.1 User-Name
3.2 User-Password
3.3 CHAP-Password
3.4 NAS-Port
3.5 Service-Type
3.6 Framed-Protocol
3.7 Framed-IP-Address
3.8 Framed-IP-Netmask
3.9 Framed-Routing
3.10 Filter-Id
3.11 Framed-MTU
3.12 Framed-Compression
3.13 Login-IP-Host
3.14 Login-Service
3.15 Login-TCP-Port
3.16 Reply-Message
3.17 Callback-Number
3.18 Callback-Id
3.19 Framed-Route
3.20 Framed-IPX-Network
3.21 State
3.22 Class
3.23 Vendor-Specific
3.24 Session-Timeout
3.25 Idle-Timeout
3.26 Termination-Action
3.27 Called-Station-Id
3.28 Calling-Station-Id
3.29 Proxy-State
3.30 Login-LAT-Service
3.31 Login-LAT-Node
3.32 Login-LAT-Group
3.33 Framed-AppleTalk-Link
3.34 Framed-AppleTalk-Network
3.35 Framed-AppleTalk-Zone
3.36 CHAP-Challenge
3.37 NAS-Port-Type
Calhoun expires January 1999 [Page 2]
INTERNET DRAFT July 1998
3.38 Port-Limit
3.39 Login-LAT-Port
3.40 Filter-Rule
3.41 Framed-Password-Policy
3.42 Table of Attributes
4.0 Protocol Definition
4.1 Feature Advertisement/Discovery
4.2 Authorization Procedure
4.3 Integration with Resource-Management
4.4 RADIUS Proxies
4.5 DIAMETER Proxies
4.6 Domain Discovery
5.0 References
6.0 Acknowledgements
7.0 Authors' Addresses
1.0 Introduction
This document describes the DIAMETER User Authentication Extensions
that can be used for a variety of services including Dial-up users
via NAS, WWW User Authentication, Firewall User Authentication[5][6].
This document describes Authentication/Authorization messages as well
as a set of messages which allow DIAMETER hosts to bypass proxies.
Since Most of the AVPs found in this document was copied from the
RADIUS protocol[1], it is possible to have both RADIUS and DIAMETER
servers read the same dictionary and users files. The backward
compatibility that DIAMETER offers is intended to facilitate
deployment.
The Extension number for this draft is two (2). This value is used in
the Extension-Id AVP as defined in [2].
1.1 Specification of Requirements
In this document, several words are used to signify the requirements
of the specification. These words are often capitalized.
MUST This word, or the adjective "required", means that the
definition is an absolute requirement of the
specification.
MUST NOT This phrase means that the definition is an absolute
prohibition of the specification.
Calhoun expires January 1999 [Page 3]
INTERNET DRAFT July 1998
SHOULD This word, or the adjective "recommended", means that
there may exist valid reasons in particular circumstances
to ignore this item, but the full implications must be
understood and carefully weighed before choosing a
different course.
MAY This word, or the adjective "optional", means that this
item is one of an allowed set of alternatives. An
implementation which does not include this option MUST
be prepared to interoperate with another implementation
which does include the option.
2.0 Command Codes
This document defines the following DIAMETER Commands. All DIAMETER
implementations supporting this extension MUST support all of the
following commands:
Command Name Command Code
-----------------------------------
Domain-Discovery-Request 261
Domain-Discovery-Answer 262
AA-Request 263
AA-Answer 264
AA-Challenge-Ind 265
2.1 Domain-Discovery-Request (DDR)
Description
The Domain-Discovery-Request message is used by a DIAMETER device
wishing to get contact information about a domain's home
authentication server as well as to receive password policy
information. This message MUST contain the User-Name attribute in
order to pass along the user's domain information.
The X509-Certificate or the X509-Certificate-URL [2] MUST be
present in this message in order to inform the home authentication
server of the issuing host's certificate.
Message Format
<Domain-Discovery-Req> ::= <DIAMETER Header>
<Domain-Discovery-Req Command AVP>
<Host-IP-Address AVP>
[<Host-Name AVP>]
Calhoun expires January 1999 [Page 4]
INTERNET DRAFT July 1998
<User-Name AVP>
[<X509-Certificate AVP>]
[<X509-Certificate-URL AVP>]
<Timestamp AVP>
<Initialization-Vector AVP>
{<Integrity-Check-Vector AVP> ||
<Digital-Signature AVP }
AVP Format
A summary of the Domain-Discovery-Request packet 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Length | Reserved |U|T|V|E|H|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Command Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Code
256 DIAMETER Command
AVP Length
The length of this attribute MUST be 12.
AVP Flags
The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending
upon the security model used. The 'V', 'T' and the 'U' bits
MUST NOT be set.
Command Type
The Command Type field MUST be set to 261 (Domain-Discovery-
Request).
2.2 Domain-Discovery-Answer (DDA)
Description
The Domain-Discovery-Answer message is sent in response to the
Calhoun expires January 1999 [Page 5]
INTERNET DRAFT July 1998
Domain-Discovery-Request message by the domain's Home
authentication server. The message MUST contain either the Host-
Name or Host-IP-Address and either the X509-Certificate or the
X509-Certificate-URL attribute and SHOULD contain at least one
Framed-Password-Policy AVP.
The absence of any Framed-Password-Policy AVPs means that the
issuer will only accept CHAP and PAP.
The Domain-Discovery-Answer message MUST include the Result-Code
AVP to indicate whether the request was successful or not. The
following Error Codes are defined for this command:
DIAMETER_ERROR_UNKNOWN_DOMAIN 1
This error code is used to indicate to the initiator of the
request that the requested domain is unknown and cannot be
resolved.
DIAMETER_ERROR_BAD_CERT 2
This error code is used to indicate that the X509-
Certificate or the X509-Certificate-URL in the Domain-
Discovery-Request was invalid.
DIAMETER_ERROR_CANNOT_REPLY 3
This error code is returned when either an intermediate
DIAMETER node or the home authentication server cannot reply
to DIAMETER messages directly. This could be that the
policy of an intermediate DIAMETER server does not permit
direct contact and therefore requires proxying. It could
also signify that the home authentication server does not
have public key support.
Message Format
<Domain-Discovery-Answer> ::= <DIAMETER Header>
<Domain-Disc-Answer Command AVP>
<Host-IP-Address AVP>
[<Host-Name AVP>]
<Framed-Password-Policy AVP>
[<X509-Certificate AVP>]
[<X509-Certificate-URL AVP>]
<Timestamp AVP>
<Initialization-Vector AVP>
{<Integrity-Check-Vector AVP> ||
<Digital-Signature AVP }
AVP Format
Calhoun expires January 1999 [Page 6]
INTERNET DRAFT July 1998
A summary of the Domain-Discovery-Answer packet 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Length | Reserved |U|T|V|E|H|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Command Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Code
256 DIAMETER Command
AVP Length
The length of this attribute MUST be 12.
AVP Flags
The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending
upon the security model used. The 'V', 'T' and the 'U' bits
MUST NOT be set.
Command Type
The Command Type field MUST be set to 262 (Domain-Discovery-
Answer).
2.3 AA-Request (AAR)
Description
The AA-Request message is used in order to request authentication
and authorization for a given user.
If Authentication is requested the User-Name attribute MUST be
present. If only Authorization is required it is possible to
authorize based on DNIS and ANI instead. However, it is not
possible to authenticate using a User-Name AVP and later
requesting authorization based on DNIS using the same Session-Id
(although the inverse is legal).
Note that the flag field MAY be used in this command in order to
Calhoun expires January 1999 [Page 7]
INTERNET DRAFT July 1998
indicate that either Authentication-Only or Authorization-Only is
required for the request. If the Authentication-Only bit is set
the response MUST NOT include any authorization information. Both
the Authenticate and Authorize bits MUST NOT be set at the same
time. To ensure that a user is both authenticated and authorized,
neither flag is set.
The AA-Request message MUST include a unique Session-Id AVP. If
The AA-Request is a result of a successful AA-Challenge-Ind the
Session-Id MUST be identical to the one provided in the initial
AA-Request.
Message Format
Section 3.42 contains a complete list of all valid AVPs for this
message.
<AA-Request> ::= <DIAMETER Header>
<AA-Request Command AVP>
<Session-Id AVP>
<Host-IP-Address AVP>
[<Host-Name AVP>]
{<User-Name AVP> ||
<Called-Station-Id AVP }
<Miscellaneous AVPs>
<Timestamp AVP>
<Initialization-Vector AVP>
{<Integrity-Check-Vector AVP> ||
<Digital-Signature AVP }
AVP Format
A summary of the AA-Request packet 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Length | Reserved |U|T|V|E|H|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Command Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Code
256 DIAMETER Command
Calhoun expires January 1999 [Page 8]
INTERNET DRAFT July 1998
AVP Length
The length of this attribute MUST be 12.
AVP Flags
The AVP Flags field MUST have bit one (Mandatory Support) set.
In addition, the following bits may be used (note these bits
are mutually exclusive):
Authenticate-Only 32
The Authentication-Only bit is set to indicate that only
authentication of the user is requested and that no
authorization information should be returned in the
response.
Authorize-Only 64
The Authorization-Only bit is set to indicate that only
authorization of the user is requested and that no
authentication is required.
Command Type
The Command Type field MUST be set to 263 (AA-Request).
2.4 AA-Answer (AAA)
Description
The AA-Answer message is used in order to indicate that
Authentication and/or authorization was successful. If
authorization was requested a list of AVPs with the authorization
information MUST be attached to the message (see section 3.42).
The AA-Answer message MUST include the Session-Id AVP that was
present in the AA-Request. The AA-Answer MUST also include the
Host-Name AVP and the Result-Code AVP to indicate the status of
the session. The following error codes are defined for this
message:
DIAMETER_ERROR_UNKNOWN_DOMAIN 1
This error code is used to indicate to the initiator of the
request that the requested domain is unknown and cannot be
resolved.
DIAMETER_ERROR_USER_UNKNOWN 2
This error code is used to indicate to the initiator that
Calhoun expires January 1999 [Page 9]
INTERNET DRAFT July 1998
the username request is not valid.
DIAMETER_ERROR_BAD_PASSWORD 3
This error code indicates that the password provided is
invalid.
DIAMETER_ERROR_CANNOT_AUTHORIZE 4
This error code is used to indicate that the user cannot be
authorized due to the fact that the user has expended the
servers local resources. This could be a result that the
server believes that the user already has an active session,
or that the user has already spent the number of credits in
his/her account, etc.
Note that the flag field MUST be set to the same value that was
found in the AA-Request message.
Message Format
Section 3.42 contains a complete list of all valid AVPs for this
message.
<AA-Answer> ::= <DIAMETER Header>
<AA-Answer Command AVP>
<Session-Id AVP>
<Result-Code AVP>
<Host-IP-Address AVP>
[<Host-Name AVP>]
<Miscellaneous AVPs>
<Timestamp AVP>
<Initialization-Vector AVP>
{<Integrity-Check-Vector AVP> ||
<Digital-Signature AVP }
AVP Format
A summary of the AA-Answer packet 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Length | Reserved |U|T|V|E|H|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Command Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Calhoun expires January 1999 [Page 10]
INTERNET DRAFT July 1998
Code
256 DIAMETER Command
AVP Length
The length of this attribute MUST be 12.
AVP Flags
The AVP Flags field MUST have bit one (Mandatory Support) set.
In addition, the following bits may be used (note these bits
are mutually exclusive):
Authenticate-Only 32
The Authentication-Only bit is set to indicate that only
authentication of the user is requested and that no
authorization information should be returned in the
response.
Authorize-Only 64
The Authorization-Only bit is set to indicate that only
authorization of the user is requested and that no
authentication is required.
Command Type
The Command Type field MUST be set to 264 (AA-Answer).
2.5 AA-Challenge-Ind (AACI)
Description
If the DIAMETER server desires to send the user a challenge
requiring a response, then the DIAMETER server MUST respond to the
AA-Request by transmitting a packet with the Code field set to 265
(AA-Challenge-Ind).
The message MAY have one or more Reply-Message AVP, and MAY have a
single State AVP, or none. No other AVPs are permitted in an AA-
Challenge-Ind other than the Integrity-Check-Vector or Digital-
Signature AVP as defined in [2].
On receipt of an AA-Challenge-Ind, the Identifier field is matched
with a pending AA-Request. Invalid packets are silently discarded.
The receipt of a valid AA-Challenge-Ind indicates that a new AA-
Calhoun expires January 1999 [Page 11]
INTERNET DRAFT July 1998
Request SHOULD be sent. The NAS MAY display the text message, if
any, to the user, and then prompt the user for a response. It
then sends its original Acess-Request with a new request ID, with
the User-Password AVP replaced by the user's response (encrypted),
and including the State AVP from the AA-Challenge-Ind, if any.
Only zero or one instances of the State Attribute can be present
in an AA-Request.
A NAS which supports PAP MAY forward the Reply-Message to the
dialin client and accept a PAP response which it can use as though
the user had entered the response. If the NAS cannot do so, it
should treat the AA-Challenge-Ind as though it had received an
AA-Answer with a Result-Code AVP set to a value other than
DIAMETER_SUCCESS instead.
It is preferable to use EAP [5] instead of the AA-Challenge-Ind,
yet it has been maintained for backward compatibility.
The AA-Challenge-Ind message MUST include the Session-Id AVP that
was present in the AA-Request and MUST include the same flag value
that was found in the AA-Request.
Section 3.42 contains a complete list of all valid AVPs for this
message.
AA-Challenge-Ind ::= <DIAMETER Header>
<AA-Challenge-Ind Command AVP>
<Session-Id AVP>
<Result-Code AVP>
<Host-IP-Address AVP>
[<Host-Name AVP>]
<Reply-Message AVPs>
<Timestamp AVP>
<Initialization-Vector AVP>
{<Integrity-Check-Vector AVP> ||
<Digital-Signature AVP }
AVP Format
A summary of the AA-Challenge-Ind packet 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Length | Reserved |U|T|V|E|H|M|
Calhoun expires January 1999 [Page 12]
INTERNET DRAFT July 1998
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Command Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Code
256 DIAMETER Command
AVP Length
The length of this attribute MUST be 12.
AVP Flags
The AVP Flags field MUST have bit one (Mandatory Support) set.
In addition, following bits may be used (note these bits are
mutually exclusive):
Authenticate-Only 32
The Authentication-Only bit is set to indicate that only
authentication of the user is requested and that no
authorization information should be returned in the
response.
Authorize-Only 64
The Authorization-Only bit is set to indicate that only
authorization of the user is requested and that no
authentication is required.
Command Type
The Command Type field MUST be set to 265 (AA-Challenge-Ind).
3.0 DIAMETER AVPs
This section will define the mandatory AVPs which MUST be supported
by all DIAMETER implementations supporting this extension. The
following AVPs are defined in this document:
Attribute Name Attribute Code
-----------------------------------
User-Name 1
User-Password 2
CHAP-Password 3
NAS-IP-Address 4
NAS-Port 5
Service-Type 6
Calhoun expires January 1999 [Page 13]
INTERNET DRAFT July 1998
Framed-Protocol 7
Framed-IP-Address 8
Framed-IP-Netmask 9
Framed-Routing 10
Filter-Id 11
Framed-MTU 12
Framed-Compression 13
Login-IP-Host 14
Login-Service 15
Login-TCP-Port 16
Reply-Message 18
Callback-Number 19
Callback-Id 20
Framed-Route 22
Framed-IPX-Network 23
State 24
Class 25
Vendor-Specific 26
Session-Timeout 27
Idle-Timeout 28
Termination-Action 29
Called-Station-Id 30
Calling-Station-Id 31
NAS-Identifier 32
Proxy-State 33
Login-LAT-Service 34
Login-LAT-Node 35
Login-LAT-Group 36
Framed-AppleTalk-Link 37
Framed-AppleTalk-Network 38
Framed-AppleTalk-Zone 39
CHAP-Challenge 60
NAS-Port-Type 61
Port-Limit 62
Login-LAT-Port 63
Filter-Rule 280
Framed-Password-Policy 281
3.1 User-Name
Description
This Attribute indicates the name of the user to be authenticated.
It is normally used in AA-Request packets, but MAY be present in
the AA-Answer message.
A summary of the User-Name Attribute format is shown below. The
Calhoun expires January 1999 [Page 14]
INTERNET DRAFT July 1998
fields are transmitted from left to right.
AVP Format
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Length | Reserved |U|T|V|E|H|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| String ...
+-+-+-+-+-+-+-+-+
Type
1 for User-Name.
AVP Length
The length of this attribute MUST be at least 9.
AVP Flags
The 'M' bit MUST be set. The 'H' MAY be set, but the 'E' bit
MUST NOT be set since proxy servers would have no knowledge of
the user's domain. The 'V', 'T' and the 'U' bits MUST NOT be
set.
String
The String field is one or more octets. All DIAMETER systems
SHOULD support User-Name lengths of at least 63 octets. The
format of the User-Name SHOULD follow the format defined in
[3].
3.2 User-Password
Description
This Attribute indicates the password of the user to be
authenticated, or the user's input following an AA-Challenge. It
is only used in AA-Request packets.
This AVP MUST be encrypted using one of the methods described in
[2]. The use of this AVP with shared secret encryption is strongly
discouraged by the author due to the security implications in a
Calhoun expires January 1999 [Page 15]
INTERNET DRAFT July 1998
proxy environment, yet the support of this attribute has been
retained for RADIUS backward compability.
A summary of the User-Password Attribute format is shown below.
The fields are transmitted from left to right.
AVP Format
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Length | Reserved |U|T|V|E|H|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data ...
+-+-+-+-+-+-+-+-+
Type
2 for User-Password.
AVP Length
The length of this attribute MUST be at least 24 and MUST be no
larger than 136.
AVP Flags
The 'M' bit MUST be set. Either the 'H' or the 'E' bit MUST be
set depending upon the security model used. The 'V', 'T' and
the 'U' bits MUST NOT be set.
The AVP Flags field MUST have bit one (Mandatory Support) set.
One of the AVP Encryption bits MUST be set.
Data
The Data field is between 16 and 128 octets long, inclusive.
3.3 CHAP-Password
Description
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 AA-Request packets.
Calhoun expires January 1999 [Page 16]
INTERNET DRAFT July 1998
If the CHAP-Password Attribute is found in a message, the CHAP-
Challenge Attribute (60) MUST be present as well.
A summary of the CHAP-Password Attribute format is shown below.
The fields are transmitted from left to right.
AVP Format
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Length | Reserved |U|T|V|E|H|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CHAP Ident | Data ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
3 for CHAP-Password.
AVP Length
The length of this attribute MUST be 25.
AVP Flags
The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending
upon the security model used. The 'V', 'T' and the 'U' bits
MUST NOT be set.
CHAP Ident
This field is one octet, and contains the CHAP Identifier from
the user's CHAP Response.
Data
The Data field is 16 octets, and contains the CHAP Response
from the user.
3.4 NAS-Port
Description
This Attribute indicates the physical port number of the NAS which
Calhoun expires January 1999 [Page 17]
INTERNET DRAFT July 1998
is authenticating the user. It is normally only used in AA-Request
messages (see section x for more info). 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 AA-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.
AVP Format
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Length | Reserved |U|T|V|E|H|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Integer32 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
5 for NAS-Port.
AVP Length
The length of this attribute MUST be 12.
AVP Flags
The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending
upon the security model used. The 'V', 'T' and the 'U' bits
MUST NOT be set.
Integer32
The Integer32 field is four octets.
3.5 Service-Type
Description
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 AA-Request and AA-Answer messages. A NAS is not required
Calhoun expires January 1999 [Page 18]
INTERNET DRAFT July 1998
to implement all of these service types, and MUST treat unknown or
unsupported Service-Types as though an AA-Answer with a Result-
Code other than DIAMETER-SUCCESS had been received instead.
A summary of the Service-Type Attribute format is shown below. The
fields are transmitted from left to right.
AVP Format
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Length | Reserved |U|T|V|E|H|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Integer32 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
6 for Service-Type.
AVP Flags
The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending
upon the security model used. The 'V', 'T' and the 'U' bits
MUST NOT be set.
AVP Length
The length of this attribute MUST be 12.
Integer32
The Integer32 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
The service types are defined as follows when used in an
Calhoun expires January 1999 [Page 19]
INTERNET DRAFT July 1998
AA-Answer. When used in an AA-Request, they should be
considered to be a hint to the DIAMETER 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
calledback, 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 AA-Answer (typically
used by proxy servers rather than the
NAS itself).This SHOULD NOT be used in
DIAMETER, yet it is maintained for
backward compatibility.
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.
3.6 Framed-Protocol
Description
Calhoun expires January 1999 [Page 20]
INTERNET DRAFT July 1998
This Attribute indicates the framing to be used for framed access.
It MAY be used in both AA-Request and AA-Answer messages.
A summary of the Framed-Protocol Attribute format is shown below.
The fields are transmitted from left to right.
AVP Format
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Length | Reserved |U|T|V|E|H|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Integer32 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
7 for Framed-Protocol.
AVP Length
The length of this attribute MUST be 12.
AVP Flags
The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending
upon the security model used. The 'V', 'T' and the 'U' bits
MUST NOT be set.
Integer32
The Integer32 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
3.7 Framed-IP-Address
Description
This Attribute indicates the address to be configured for the
Calhoun expires January 1999 [Page 21]
INTERNET DRAFT July 1998
user. It MAY be used in AA-Request messages 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.
AVP Format
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Length | Reserved |U|T|V|E|H|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
8 for Framed-IP-Address.
AVP Length
The length of this attribute MUST be 12.
AVP Flags
The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending
upon the security model used. The 'V', 'T' and the 'U' bits
MUST NOT be set.
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.
3.8 Framed-IP-Netmask
Description
Calhoun expires January 1999 [Page 22]
INTERNET DRAFT July 1998
This Attribute indicates the IP netmask to be configured for the
user when the user is a router to a network. It MUST be used in
AA-Answer messages if the Framed-IP-Address AVP was returned with
a value other than 0xFFFFFFFF. It MAY be used in an AA-Request
message 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.
AVP Format
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Length | Reserved |U|T|V|E|H|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
9 for Framed-IP-Netmask.
AVP Length
The length of this attribute MUST be 12.
AVP Flags
The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending
upon the security model used. The 'V', 'T' and the 'U' bits
MUST NOT be set.
Address
The Address field is four octets specifying the IP netmask of
the user.
3.9 Framed-Routing
Description
This Attribute indicates the routing method for the user, when the
user is a router to a network. It is only used in AA-Answer
Calhoun expires January 1999 [Page 23]
INTERNET DRAFT July 1998
messages.
A summary of the Framed-Routing Attribute format is shown below.
The fields are transmitted from left to right.
AVP Format
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Length | Reserved |U|T|V|E|H|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Integer32 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
10 for Framed-Routing.
AVP Length
The length of this attribute MUST be 12.
AVP Flags
The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending
upon the security model used. The 'V', 'T' and the 'U' bits
MUST NOT be set.
Integer32
The Integer32 field is four octets.
0 None
1 Send routing packets
2 Listen for routing packets
3 Send and Listen
3.10 Filter-Id
Description
This Attribute indicates the name of the filter list for this
user. Zero or more Filter-Id attributes MAY be sent in an AA-
Answer message.
Calhoun expires January 1999 [Page 24]
INTERNET DRAFT July 1998
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 since filter
naming differs from one service provider to another.
It is strongly encouraged to support the Filter-Rule AVP instead.
A summary of the Filter-Id Attribute format is shown below. The
fields are transmitted from left to right.
AVP Format
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Length | Reserved |U|T|V|E|H|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| String ...
+-+-+-+-+-+-+-+-+
Type
11 for Filter-Id.
AVP Length
The length of this attribute MUST be at least 9.
AVP Flags
The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending
upon the security model used. The 'V', 'T' and the 'U' bits
MUST NOT be set.
String
The String 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 displayable ASCII
characters from the range 32 through 126 decimal.
3.11 Framed-MTU
Description
Calhoun expires January 1999 [Page 25]
INTERNET DRAFT July 1998
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 is only used in AA-Answer messages.
A summary of the Framed-MTU Attribute format is shown below. The
fields are transmitted from left to right.
AVP Format
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Length | Reserved |U|T|V|E|H|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Integer32 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
12 for Framed-MTU.
AVP Length
The length of this attribute MUST be 12.
AVP Flags
The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending
upon the security model used. The 'V', 'T' and the 'U' bits
MUST NOT be set.
Integer32
The Integer32 field is four octets. Despite the size of the
field, values range from 64 to 65535.
3.12 Framed-Compression
Description
This Attribute indicates a compression protocol to be used for the
link. It MAY be used in AA-Answer packets. It MAY be used in an
AA-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.
Calhoun expires January 1999 [Page 26]
INTERNET DRAFT July 1998
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.
AVP Format
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Length | Reserved |U|T|V|E|H|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Integer32 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
13 for Framed-Compression.
AVP Length
The length of this attribute MUST be 12.
AVP Flags
The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending
upon the security model used. The 'V', 'T' and the 'U' bits
MUST NOT be set.
Integer32
The Integer32 field is four octets.
0 None
1 VJ TCP/IP header compression [7]
2 IPX header compression
3.13 Login-IP-Host
Description
This Attribute indicates the system with which to connect the
user, when the Login-Service Attribute is included. It MAY be used
Calhoun expires January 1999 [Page 27]
INTERNET DRAFT July 1998
in AA-Answer messages. It MAY be used in an AA-Request message 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.
AVP Format
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Length | Reserved |U|T|V|E|H|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
14 for Login-IP-Host.
AVP Length
The length of this attribute MUST be 12.
AVP Flags
The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending
upon the security model used. The 'V', 'T' and the 'U' bits
MUST NOT be set.
Address
The Address field is four octets. The value 0xFFFFFFFF
indicates that the NAS SHOULD allow the user to select an
address. The value zero 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.
3.14 Login-Service
Description
This Attribute indicates the service which should be used to
connect the user to the login host. It is only used in AA-Answer
Calhoun expires January 1999 [Page 28]
INTERNET DRAFT July 1998
messages.
A summary of the Login-Service Attribute format is shown below.
The fields are transmitted from left to right.
AVP Format
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Length | Reserved |U|T|V|E|H|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Integer32 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
15 for Login-Service.
AVP Length
The length of this attribute MUST be 12.
AVP Flags
The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending
upon the security model used. The 'V', 'T' and the 'U' bits
MUST NOT be set.
Integer32
The Integer32 field is four octets.
0 Telnet
1 Rlogin
2 TCP Clear
3 PortMaster (proprietary)
4 LAT
3.15 Login-TCP-Port
Description
This Attribute indicates the TCP port with which the user is to be
connected, when the Login-Service Attribute is also present. It is
Calhoun expires January 1999 [Page 29]
INTERNET DRAFT July 1998
only used in AA-Answer packets.
A summary of the Login-TCP-Port Attribute format is shown below.
The fields are transmitted from left to right.
AVP Format
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Length | Reserved |U|T|V|E|H|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Integer32 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
16 for Login-TCP-Port.
AVP Length
The length of this attribute MUST be 12.
AVP Flags
The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending
upon the security model used. The 'V', 'T' and the 'U' bits
MUST NOT be set.
Integer32
The Integer32 field is four octets. Despite the size of the
field, values range from zero to 65535.
3.16 Reply-Message
Description
This Attribute indicates text which MAY be displayed to the user.
When used in an AA-Answer message with a successful Result-Code
AVP it indicates the success message. When found in the same
message with a Result-Code other than DIAMETER-SUCCESS it contains
the failure message.
Calhoun expires January 1999 [Page 30]
INTERNET DRAFT July 1998
It MAY indicate a dialog message to prompt the user before another
AA-Request attempt.
When used in an AA-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.
AVP Format
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Length | Reserved |U|T|V|E|H|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| String ...
+-+-+-+-+-+-+-+-+
Type
18 for Reply-Message.
AVP Length
The length of this attribute MUST be at least 9.
AVP Flags
The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending
upon the security model used. The 'V', 'T' and the 'U' bits
MUST NOT be set.
String
The String 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 displayable ASCII
characters from the range 10, 13, and 32 through 126 decimal.
Mechanisms for extension to other character sets are beyond the
scope of this specification.
Calhoun expires January 1999 [Page 31]
INTERNET DRAFT July 1998
3.17 Callback-Number
Description
This Attribute indicates a dialing string to be used for callback.
It MAY be used in AA-Answer packets. It MAY be used in an AA-
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.
AVP Format
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Length | Reserved |U|T|V|E|H|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| String ...
+-+-+-+-+-+-+-+-+
Type
19 for Callback-Number.
AVP Length
The length of this attribute MUST be at least 9.
AVP Flags
The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending
upon the security model used. The 'V', 'T' and the 'U' bits
MUST NOT be set.
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.
Calhoun expires January 1999 [Page 32]
INTERNET DRAFT July 1998
3.18 Callback-Id
Description
This Attribute indicates the name of a place to be called, to be
interpreted by the NAS. It MAY be used in AA-Answer messages.
This AVP is not roaming friendly since it assumes that the
Callback-Id is configured on the NAS. It is therefore preferable
to use the Callback-Number AVP instead.
A summary of the Callback-Id Attribute format is shown below. The
fields are transmitted from left to right.
AVP Format
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Length | Reserved |U|T|V|E|H|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| String ...
+-+-+-+-+-+-+-+-+
Type
20 for Callback-Id.
AVP Length
The length of this attribute MUST be at least 9.
AVP Flags
The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending
upon the security model used. The 'V', 'T' and the 'U' bits
MUST NOT be set.
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.
Calhoun expires January 1999 [Page 33]
INTERNET DRAFT July 1998
3.19 Framed-IP-Route
Description
This Attribute provides routing information to be configured for
the user on the NAS. It is used in the AA-Answer message and can
appear multiple times.
A summary of the Framed-Route Attribute format is shown below. The
fields are transmitted from left to right.
AVP Format
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Length | Reserved |U|T|V|E|H|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| String ...
+-+-+-+-+-+-+-+-+
Type
22 for Framed-IP-Route.
AVP Length
The length of this attribute MUST be at least 9.
AVP Flags
The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending
upon the security model used. The 'V', 'T' and the 'U' bits
MUST NOT be set.
String
It 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.
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".
The length specifier may be omitted in which case it should
default to 8 bits for class A prefixes, 16 bits for class B
Calhoun expires January 1999 [Page 34]
INTERNET DRAFT July 1998
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.
3.20 Framed-IPX-Network
Description
This Attribute indicates the IPX Network number to be configured
for the user. It is used in AA-Answer messages.
A summary of the Framed-IPX-Network Attribute format is shown
below. The fields are transmitted from left to right.
AVP Format
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Length | Reserved |U|T|V|E|H|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Integer32 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
23 for Framed-IPX-Network.
AVP Length
The length of this attribute MUST be 12.
AVP Flags
The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending
upon the security model used. The 'V', 'T' and the 'U' bits
MUST NOT be set.
Integer32
The Integer32 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
Calhoun expires January 1999 [Page 35]
INTERNET DRAFT July 1998
the NAS should select an address 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.
3.21 State
Description
This Attribute is available to be sent by the server to the client
in an AA-Challenge and MUST be sent unmodified from the client to
the server in the new AA-Request reply to that challenge, if any.
In either usage, no interpretation by the client should be made.
A packet may have only 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.
AVP Format
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Length | Reserved |U|T|V|E|H|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data ...
+-+-+-+-+-+-+-+-+
Type
24 for State.
AVP Length
The length of this attribute MUST be at least 9.
AVP Flags
The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending
upon the security model used. The 'V', 'T' and the 'U' bits
MUST NOT be set.
String
Calhoun expires January 1999 [Page 36]
INTERNET DRAFT July 1998
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.
3.22 Class
Description
This Attribute is available to be sent by the server to the client
in an AA-Answer and should be sent unmodified by the client to the
accounting server as part of the Accounting-Request message if
accounting is supported. No interpretation by the client should be
made.
A summary of the Class Attribute format is shown below. The fields
are transmitted from left to right.
AVP Format
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Length | Reserved |U|T|V|E|H|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data ...
+-+-+-+-+-+-+-+-+
Type
25 for Class.
AVP Length
The length of this attribute MUST be at least 9.
AVP Flags
The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending
upon the security model used. The 'V', 'T' and the 'U' bits
MUST NOT be set.
Calhoun expires January 1999 [Page 37]
INTERNET DRAFT July 1998
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.
3.23 Vendor-Specific
Description
This AVP is not supported in DIAMETER. Vendor Specific Attributes
are used by enabling the Vendor-Specific bit in the AVP header.
3.24 Session-Timeout
Description
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 AA-Answer or AA-Challenge.
A summary of the Session-Timeout Attribute format is shown
below. The fields are transmitted from left to right.
AVP Format
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Length | Reserved |U|T|V|E|H|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Integer32 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
27 for Session-Timeout.
AVP Length
Calhoun expires January 1999 [Page 38]
INTERNET DRAFT July 1998
The length of this attribute MUST be 12.
AVP Flags
The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending
upon the security model used. The 'V', 'T' and the 'U' bits
MUST NOT be set.
Integer32
The Integer32 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.
A value of zero means that this session has an unlimited number
of seconds before termination or prompt.
3.25 Idle-Timeout
Description
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 AA-Answer or AA-Challenge.
A summary of the Idle-Timeout Attribute format is shown below. The
fields are transmitted from left to right.
AVP Format
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Length | Reserved |U|T|V|E|H|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Integer32 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
28 for Idle-Timeout.
AVP Length
The length of this attribute MUST be 12.
Calhoun expires January 1999 [Page 39]
INTERNET DRAFT July 1998
AVP Flags
The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending
upon the security model used. The 'V', 'T' and the 'U' bits
MUST NOT be set.
Integer32
The Integer32 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.
3.26. Termination-Action
Description
This Attribute is not supported in DIAMETER.
3.27 Called-Station-Id
Description
This Attribute allows the NAS to send in the AA-Request message
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 AA-Request packets.
If the Authorization-Only flag is set in the message and the
User-Name AVP is absent, the DIAMETER Server MUST perform
authorization based on this field. This can be used by a NAS to
request whether a call should be answered based on the DNIS.
A summary of the Called-Station-Id Attribute format is shown
below. The fields are transmitted from left to right.
AVP Format
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Length | Reserved |U|T|V|E|H|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Calhoun expires January 1999 [Page 40]
INTERNET DRAFT July 1998
| String ...
+-+-+-+-+-+-+-+-+
Type
30 for Called-Station-Id.
AVP Length
The length of this attribute MUST be at least 9.
AVP Flags
The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending
upon the security model used. The 'V', 'T' and the 'U' bits
MUST NOT be set.
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. Printable ASCII is 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.
3.28 Calling-Station-Id
Description
This Attribute allows the NAS to send in the AA-Request packet the
phone number that the call came from, using Automatic Number
Identification (ANI) or similar technology. It is only used in
AA-Request packets.
If the Authorization-Only flag is set in the message and the
User-Name AVP is absent, the DIAMETER Server must perform
authorization based on this field. This can be used by a NAS to
request whether a call should be answered based on the ANI.
A summary of the Calling-Station-Id Attribute format is shown
below. The fields are transmitted from left to right.
Calhoun expires January 1999 [Page 41]
INTERNET DRAFT July 1998
AVP Format
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Length | Reserved |U|T|V|E|H|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| String ...
+-+-+-+-+-+-+-+-+
Type
31 for Calling-Station-Id.
AVP Length
The length of this attribute MUST be at least 9.
AVP Flags
The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending
upon the security model used. The 'V', 'T' and the 'U' bits
MUST NOT be set.
String
The String field is one or more octets, containing the phone
number that the user placed the call from.
The actual format of the information is site or application
specific. Printable ASCII is 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.
3.29 Proxy-State
Description
This Attribute is available to be sent by a proxy server to
another server when forwarding an AA-Request and MUST be returned
unmodified in the AA-Answer, or AA-Challenge.
Calhoun expires January 1999 [Page 42]
INTERNET DRAFT July 1998
This attribute should be removed by the proxy server before the
response is forwarded to the NAS, and SHOULD therefore not be
protected by the Integrity-Check-Vector or the Digital-Signature.
A summary of the Proxy-State Attribute format is shown below. The
fields are transmitted from left to right.
AVP Format
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Length | Reserved |U|T|V|E|H|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data ...
+-+-+-+-+-+-+-+-+
Type
33 for Proxy-State.
AVP Length
The length of this attribute MUST be at least 9.
AVP Flags
The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending
upon the security model used. The 'V', 'T' and the 'U' bits
MUST NOT be set.
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.
3.30 Login-LAT-Service
Description
Calhoun expires January 1999 [Page 43]
INTERNET DRAFT July 1998
This Attribute indicates the system with which the user is to be
connected by LAT. It MAY be used in AA-Answer packets, but only
when LAT is specified as the Login-Service. It MAY be used in an
AA-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.
AVP Format
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Length | Reserved |U|T|V|E|H|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| String ...
+-+-+-+-+-+-+-+-+
Type
34 for Login-LAT-Service.
AVP Length
The length of this attribute MUST be at least 9.
AVP Flags
The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending
upon the security model used. The 'V', 'T' and the 'U' bits
MUST NOT be set.
Calhoun expires January 1999 [Page 44]
INTERNET DRAFT July 1998
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 [8]. All LAT string
comparisons are case insensitive.
3.31 Login-LAT-Node
Description
This Attribute indicates the Node with which the user is to be
automatically connected by LAT. It MAY be used in AA-Answer
packets, but only when LAT is specified as the Login-Service. It
MAY be used in an AA-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.
AVP Format
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Length | Reserved |U|T|V|E|H|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| String ...
+-+-+-+-+-+-+-+-+
Type
35 for Login-LAT-Node.
AVP Length
The length of this attribute MUST be at least 9.
AVP Flags
The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending
upon the security model used. The 'V', 'T' and the 'U' bits
MUST NOT be set.
Calhoun expires January 1999 [Page 45]
INTERNET DRAFT July 1998
String
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.
3.32 Login-LAT-Group
Description
This Attribute contains a string identifying the LAT group codes
which this user is authorized to use. It MAY be used in AA-Answer
packets, but only when LAT is specified as the Login-Service. It
MAY be used in an AA-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.
AVP Format
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Length | Reserved |U|T|V|E|H|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data ...
+-+-+-+-+-+-+-+-+
Type
36 for Login-LAT-Group.
Calhoun expires January 1999 [Page 46]
INTERNET DRAFT July 1998
AVP Length
The length of this attribute MUST be 40.
AVP Flags
The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending
upon the security model used. The 'V', 'T' and the 'U' bits
MUST NOT be set.
Data
The Data 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.
3.33 Framed-AppleTalk-Link
Description
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 AA-Answer 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.
AVP Format
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Length | Reserved |U|T|V|E|H|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Integer32 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
37 for Framed-AppleTalk-Link.
Calhoun expires January 1999 [Page 47]
INTERNET DRAFT July 1998
AVP Length
The length of this attribute MUST be 12.
AVP Flags
The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending
upon the security model used. The 'V', 'T' and the 'U' bits
MUST NOT be set.
Integer32
The Integer32 field is four octets. Despite the size of the
field, values range from zero to 65535. The special value of
zero indicates that this is an unnumbered serial link. A value
of one to 65535 means that the serial line between the NAS and
the user should be assigned that value as an AppleTalk network
number.
3.34 Framed-AppleTalk-Network
Description
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 AA-Answer 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.
AVP Format
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Length | Reserved |U|T|V|E|H|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Integer32 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
38 for Framed-AppleTalk-Network.
Calhoun expires January 1999 [Page 48]
INTERNET DRAFT July 1998
AVP Length
The length of this attribute MUST be 12.
AVP Flags
The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending
upon the security model used. The 'V', 'T' and the 'U' bits
MUST NOT be set.
Integer32
The Integer32 field is four octets. Despite the size of the
field, values range from zero to 65535. The special value zero
indicates that the NAS should assign a network for the user,
using its default cable range. A value between one and 65535
(inclusive) indicates the AppleTalk Network the NAS should
probe to find an address for the user.
3.35 Framed-AppleTalk-Zone
Description
This Attribute indicates the AppleTalk Default Zone to be used for
this user. It is only used in AA-Answer 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.
AVP Format
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Length | Reserved |U|T|V|E|H|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data ...
+-+-+-+-+-+-+-+-+
Type
39 for Framed-AppleTalk-Zone.
AVP Length
Calhoun expires January 1999 [Page 49]
INTERNET DRAFT July 1998
The length of this attribute MUST be at least 9.
AVP Flags
The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending
upon the security model used. The 'V', 'T' and the 'U' bits
MUST NOT be set.
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.
3.36 CHAP-Challenge
Description
This Attribute contains the CHAP Challenge sent by the NAS to a
PPP Challenge-Handshake Authentication Protocol (CHAP) user. It is
only used in AA-Request packets.
A summary of the CHAP-Challenge Attribute format is shown below.
The fields are transmitted from left to right.
AVP Format
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Length | Reserved |U|T|V|E|H|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data ...
+-+-+-+-+-+-+-+-+
Type
60 for CHAP-Challenge.
AVP Length
The length of this attribute MUST be at least 24.
Calhoun expires January 1999 [Page 50]
INTERNET DRAFT July 1998
AVP Flags
The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending
upon the security model used. The 'V', 'T' and the 'U' bits
MUST NOT be set.
Data
The Data field contains the CHAP Challenge.
3.37 NAS-Port-Type
Description
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 AA-
Request packets. Either NAS-Port (5) or NAS-Port-Type or both
SHOULD be present in an AA-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.
AVP Format
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Length | Reserved |U|T|V|E|H|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Integer32 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
61 for NAS-Port-Type.
AVP Length
The length of this attribute MUST be 12.
AVP Flags
The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending
Calhoun expires January 1999 [Page 51]
INTERNET DRAFT July 1998
upon the security model used. The 'V', 'T' and the 'U' bits
MUST NOT be set.
Integer32
The Integer32 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 to authenticate himself as an Outbound-User, the AA-
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
3.38 Port-Limit
Description
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 AA-Answer packet. It is intended for use in
conjunction with Multilink PPP [9] 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.
AVP Format
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Length | Reserved |U|T|V|E|H|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Integer32 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
Calhoun expires January 1999 [Page 52]
INTERNET DRAFT July 1998
62 for Port-Limit.
AVP Length
The length of this attribute MUST be 12.
AVP Flags
The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending
upon the security model used. The 'V', 'T' and the 'U' bits
MUST NOT be set.
Integer32
The Integer32 field is four octets, containing a 32-bit
unsigned integer with the maximum number of ports this user
should be allowed to connect to on the NAS.
3.39 Login-LAT-Port
Description
This Attribute indicates the Port with which the user is to be
connected by LAT. It MAY be used in AA-Answer packets, but only
when LAT is specified as the Login-Service. It MAY be used in an
AA-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.
AVP Format
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Length | Reserved |U|T|V|E|H|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| String ...
+-+-+-+-+-+-+-+-+
Type
63 for Login-LAT-Port.
Calhoun expires January 1999 [Page 53]
INTERNET DRAFT July 1998
AVP Length
The length of this attribute MUST be at least 9.
AVP Flags
The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending
upon the security model used. The 'V', 'T' and the 'U' bits
MUST NOT be set.
String
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.
3.40 Filter-Rule
Description
This Attribute provides filter rules that need to be configured on
the NAS for the user. It is used in the AA-Answer message and can
appear multiple times.
A summary of the Filter-Rule Attribute format is shown below. The
fields are transmitted from left to right.
AVP Format
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Length | Reserved |U|T|V|E|H|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| String ...
+-+-+-+-+-+-+-+-+
Type
280 for Filter-Rule.
AVP Length
Calhoun expires January 1999 [Page 54]
INTERNET DRAFT July 1998
The length of this attribute MUST be at least 9.
AVP Flags
The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending
upon the security model used. The 'V', 'T' and the 'U' bits
MUST NOT be set.
String
The String field MUST contain a filter rule in the following
format: "permit (offset=value AND offset=value) OR
offset=value" or "deny (offset=value AND offset=value) OR
offset=value".
3.41 Framed-Password-Policy
Description
This Attribute is used to indicate to a peer what types of
authentication are supported by the issuing DIAMETER peer. More
than one Framed-Password-Policy AVP MAY be present in the Domain-
Discovery-Answer message.
A summary of the User-Name Attribute format is shown below. The
fields are transmitted from left to right.
AVP Format
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Length | Reserved |U|T|V|E|H|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Integer32 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
281 for Framed-Password-Policy.
AVP Length
The length of this attribute MUST be 12.
Calhoun expires January 1999 [Page 55]
INTERNET DRAFT July 1998
AVP Flags
The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending
upon the security model used. The 'V', 'T' and the 'U' bits
MUST NOT be set.
Integer32
The Integer32 field contains the supported authentication
schemes supported. The following values are supported:
PAP 1
CHAP 2
MS-CHAP 3
EAP 4
SPAP 5
3.42 Table of Attributes
The following table provides a guide to which attributes may be found
in which kinds of packets, and in what quantity.
AA Succ Fail Chal Disc-Req Disc-Rsp # Attribute
Req Answ Answ Req
0-1 0-1 0 0 1 0-1 1 User-Name
0-1 0 0 0 0 0 2 User-Password [*1]
0-1 0 0 0 0 0 3 CHAP-Password [*1]
0-1 0 0 0 0 0 4 NAS-IP-Address
0-1 0 0 0 0 0 5 NAS-Port
0-1 0-1 0 0 0 0 6 Service-Type
0-1 0-1 0 0 0 0 7 Framed-Protocol
0-1 0-1 0 0 0 0 8 Framed-IP-Address
0-1 0-1 0 0 0 0 9 Framed-IP-Netmask
0 0-1 0 0 0 0 10 Framed-Routing
0 0+ 0 0 0 0 11 Filter-Id
0 0-1 0 0 0 0 12 Framed-MTU
0+ 0+ 0 0 0 0 13 Framed-Compression
0+ 0+ 0 0 0 0 14 Login-IP-Host
0 0-1 0 0 0 0 15 Login-Service
0 0-1 0 0 0 0 16 Login-TCP-Port
0 0+ 0+ 0+ 0 0 18 Reply-Message
0-1 0-1 0 0 0 0 19 Callback-Number
0 0-1 0 0 0 0 20 Callback-Id
0 0+ 0 0 0 0 22 Framed-Route
0 0-1 0 0 0 0 23 Framed-IPX-Network
0-1 0-1 0 0-1 0 0 24 State
0 0+ 0 0 0 0 25 Class
Calhoun expires January 1999 [Page 56]
INTERNET DRAFT July 1998
0 0-1 0 0-1 0-1 0-1 27 Session-Timeout
0 0-1 0 0-1 0-1 0-1 28 Idle-Timeout
0 0-1 0 0 0 0 29 Termination-Action
0-1 0 0 0 0 0 30 Called-Station-Id
0-1 0 0 0 0 0 31 Calling-Station-Id
0-1 0 0 0 0 0 32 NAS-Identifier
0+ 0+ 0+ 0+ 0+ 0+ 33 Proxy-State
0-1 0-1 0 0 0 0 34 Login-LAT-Service
0-1 0-1 0 0 0 0 35 Login-LAT-Node
0-1 0-1 0 0 0 0 36 Login-LAT-Group
0 0-1 0 0 0 0 37 Framed-AppleTalk-Link
0 0+ 0 0 0 0 38 Framed-AppleTalk-Net.
0 0-1 0 0 0 0 39 Framed-AppleTalk-Zone
0-1 0 0 0 0 0 60 CHAP-Challenge
0-1 0 0 0 0 0 61 NAS-Port-Type
0-1 0-1 0 0 0 0 62 Port-Limit
0-1 0-1 0 0 0 0 63 Login-LAT-Port
0 0+ 0 0 0 0 280 Filter-Rule
0 0 0 0 0+ 0+ 281 Framed-Password-Pol.
AA Succ Fail Chal Disc-Req Disc-Rsp # Attribute
Req Answ Answ Req
[*1] An AA-Request MUST NOT contain both a User-Password and a
CHAP-Password AVP.
The 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.
1 Exactly one instance of this attribute MUST be present
in
packet.
4.0 Protocol Definition
This section will outline how the DIAMETER Authentication Extension
can be used.
4.1 Feature Advertisement/Discovery
As defined in [2], the Reboot-Ind and Device-Feature-Query messages
can be used to inform a peer about locally supported DIAMETER
Extensions. In order to advertise support of this extension, the
Calhoun expires January 1999 [Page 57]
INTERNET DRAFT July 1998
Extension-Id AVP must be transmitted with a value of two (2).
4.2 Authorization Procedure
This specification allows two different types of Authorization
procedures. The first method is identical to the way RADIUS works
today and requires the AA-Request to contain the UserName as well as
either the Password or the CHAP-Password AVPs.
The second method is used by NASes that send AA-Request whenever they
receive an incoming call and want to get authorization from the
DIAMETER Server to answer the call. In this case the AA-Request
contains the NAS-IP-Address, the Calling-Station-Id and the Called-
Station-Id AVPs.
In this case the DIAMETER Server can lookup the combination of the
Calling-Station-Id and the Called-Station-Id in order to ensure that
the pair are authorized as per the local policy.
4.3 Integration with Resource-Management
Document [10] specifies the Resource-Token AVP that is used to carry
information required for a DIAMETER server to rebuild its state
information in the event of a crash or some other event that would
cause the server to loose its state information.
When creating the Resource-Token AVP, the following AVPs MUST be
present, in addition to the AVPs listed in [10]; the UserName AVP,
the NAS-IP- Address, the NAS-Port. Any additional AVP MAY be included
if the AVP is a resource that is being managed (i.e. Framed-IP-
Address in the case where the DIAMETER Server is allocating IP
Addresses out of a centrally managed address pool).
4.4 RADIUS Proxies
In today's dial up networks the RADIUS protocol is used to
authentication, authorize and perform accounting for dial-up users.
However, it has become common practice to make use of RADIUS Servers
known as proxies.
The use of proxies has become widespread especially with the
popularity of Internet Roaming[4]. In this example a user has a
single user account with a local service provider. When this user
roams outside of the ISP's service area, it is possible for the user
to connect to another service provider (see [4] for more detail).
Calhoun expires January 1999 [Page 58]
INTERNET DRAFT July 1998
In this scenario, the new service provider (ISPB) provides internet
access for the user through a NAS (NASB). ISPB owns an authentication
server (RADB), which proxies the authentication request to the user's
original provider's authentication server (RADA).
(Access-Request) (Access-Request)
+------+ -----> +------+ ------> +------+
| | | | | |
| NASB +--------------------+ RADB +--------------------+ RADA |
| | | | | |
+------+ <----- +------+ <------ +------+
(Access-Accept) (Access-Accept)
The example shown above NASB generates an authentication request on
behalf of the dial-in user to the RADB Authentication server. In this
case, the user's identity would include a domain identifier [3] that
would enable RADB to identify the authentication server (i.e.
user@ISPA.com).
The RADB server then forwards the request to RADA which authenticates
the user based on information found within the request. If
successfully authenticated the RADA server returns a successful
response along with authorization information. If the user
authentication fails RADA replies with a failed response.
In the past this model has caused much concern over it's security
implication. The model is much worse in the when there exists an
intermediate provider between ISPB and ISPA (say ISPC). The following
diagram depicts such an example where RADB must forward any requests
for RADA through RADC.
(Accounting-Request) (Accounting-Request)
+------+ -----> +------+ ------> +------+
| | | | | |
| RADB +--------------------+ RADC +--------------------+ RADA |
| | | | | |
+------+ <----- +------+ <------ +------+
(Accounting-Response) (Accounting-Response)
The problem with the above scenario is that complete trust is placed
in RADC (and hence ISPC) since it is very simple to modify any
attributes found within the request or the response. The example
shows an accounting request sent from RADB to RADA through RADC. The
following is a list of a few attacks which can be generated by a
malicious proxy:
- Generating Accounting Records by replaying old
authentication/accounting records. In this example it is very
Calhoun expires January 1999 [Page 59]
INTERNET DRAFT July 1998
simple for RADC to simple retain old packets and replay then at a
later date. This will cause RADA to "pay" for services which were
never rendered.
- Modify Attributes within the request or response. In this case
RADC can modify attributes, such as the length of the call, that
would fool RADA into believing the call was longer than in
reality.
- Stealing PAP Passwords is another problem with today's proxies.
In the current model PAP passwords are encrypted using a shared
secret which is shared between each hop in the proxy chain. In
this case each hop has the opportunity to decrypt, and possibly
save for future use, the user's password.
Given the problems identified above with the current proxy model it
is necessary to create a mechanism which allows for non-repudiation,
end-to-end data integrity as well as end-to-end encryption. Given the
current encryption technology this can only be achieved with the use
of asymetric encryption and digital signatures.
4.5 DIAMETER Proxies
The DIAMETER protocol also makes use of proxies in order to keep the
existing arrangements while migrating from RADIUS to DIAMETER.
However since DIAMETER makes use of asymetric encryption and digital
signatures it solves many of the problems shown above.
(AA-Request) (AA-Request)
+------+ -----> +------+ ------> +------+
| | | | | |
| NASB +--------------------+ DIA2 +--------------------+ DIA1 |
| | | | | |
+------+ <----- +------+ <------ +------+
(AA-Answer) (AA-Answer)
In this example NASB generates an AA-Request that is forwarded to
DIA2. The AA-Request contains a digital signature AVP which
"protects" all mandatory (or non-editable) AVPs within the request.
All AVPs which may be modified, or removed appear after the digital
signature AVP. Once DIA2 receives the request, it MAY authenticate
the request to ensure that it was originated by NASB (verifying the
signature is not necessary if the link between NASB and DIA2 is
secured using IPSEC).
The DIA2 Server may then add new attributes to the request. All
mandatory AVPs MUST be present prior to the non mandatory AVPs and
Calhoun expires January 1999 [Page 60]
INTERNET DRAFT July 1998
MUST be preceeded by a Digital Signature AVP (using DIA2's private
key). Note that all non-mandatory AVPs added to the packet by NASB
must appear after DIA2's digital signature AVP. The message is then
forwarded towards the DIA1 server.
Since all packets between NASB and DIA1 must flow through DIA2, it is
not possible to use IPSEC between both hosts. Therefore DIA1 MUST
validate NASB's digital signature AVP. However it is not necessary to
validate DIA2's digital signature if the link between DIA2 and DIA1
is secured using IPSEC.
This mechanism now provides a method for DIA1 to prove that NASB was
the initiator of the request (note that DIAMETER also includes a
timestap to prevent replay attacks). It also provides a method of
ensuring that DIA2 cannot modify any "non-editable" attributes (such
as length of call, etc).
In addition, this same mechanism can be used for end-to-end
encryption of AVPs. In the case where NASB needs to encrypt an AVP it
is done using asymetric encryption using DIA1's public key. This
ensures that only DIA1 can decrypt the AVP.
An attack has been identified in this proposal which allows a
malicous man in the middle attack as shown in the following diagram.
(AA-Request) (AA-Request) (AA-Request)
+------+ -----> +------+ -----> +------+ -----> +------+
| | | | | | | |
| NASB +----------+ DIA2 +----------+ DIA3 +----------+ DIA1 |
| | | | | | | |
+------+ <----- +------+ <----- +------+ <----- +------+
(AA-Answer) (AA-Answer) (AA-Answer)
In this example, DIA3 traps packets generated from DIA2 towards DIA1,
removes the AVPs added by DIA2 and inserts its own AVPs (posibly by
trying to convince DIA1 to pay DIA3 for the services). This attack
can be prevented by supporting a new Next-Hop AVP. In this case when
NASB prepares a request it inserts a non-editable Next-Hop AVP which
contains DIA2's identitity. DIA2 also adds a Next-Hop AVP with DIA1
as the next hop.
This mechanism ensures that a man in the middle cannot alter the
packet by overriding the previous hop's additions and signature. DIA1
could easily validate the packet's path with the use of the Next-Hop
AVPs.
4.6 Domain Discovery
Calhoun expires January 1999 [Page 61]
INTERNET DRAFT July 1998
The Domain Discovery message set is very useful in determining the
Home authentication server, the password policies for the domain, as
a mechanism to retrieve a certificate (or a pointer to a
certificate).
The following example shows a case where DIA1 needs to communicate
with DIA3. In this example it is necessary to use DIA2 as a proxy in
order for both ISPs to communicate. Although this MAY be desireable
in some business models, there are cases where it is beneficial to
remove the proxy altogether and allow both DIA3 and DIA1 to
communicate in a secure fashion.
(DD-Request) (DD-Request)
+------+ -----> +------+ ------> +------+
| | | | | |
| DIA1 +--------------------+ DIA2 +--------------------+ DIA3 |
| | | | | |
+------+ <----- +------+ <------ +------+
(DD-Response) (DD-Response)
The way the Domain Discovery works is that prior to sending out an
authentication request DIA1 would issue a Domain Discovery message
towards DIA2. This message is protected with the digital signature as
well as the Next-Hop AVP. DIA2 would then forward the request to DIA3
including the Next-Hop and the digital signature AVP.
When DIA3 receives the request, it MUST save the certificate (or the
pointer to the certificate) and respond back including the local
password policy, DIA3's certificate, it's contact information (i.e.
IP address) and protect the response with the digital signature.
Note that in all cases the TimeStamp AVP is also present to ensure no
reply packets are accepted.
When DIA2 receives the packet, it must add the Next-Hop AVP as well
as the digital signature AVP. When DIA1 receives the packet it then
knows a direct route to communicate with DIA3 since the contact
information is present in the response. The fact that both DIA1 and
DIA3 can now communicate directly allows both peers to use IPSEC to
protect the message exchange (note that it MAY be desirable to also
use the digital signature in order to keep the information in the
DIAMETER logs).
(AA-Request)
+------+ -----> +------+
| | | |
| DIA1 +--------------------+ DIA3 |
| | | |
Calhoun expires January 1999 [Page 62]
INTERNET DRAFT July 1998
+------+ <----- +------+
(AA-Answer)
In addition, the password policy is also present which can indicate
whether DIA3 is willing to accept CHAP, PAP or EAP authentication.
Note that the Domain-Discovery-Request/Answer MAY include the
Supported-Extension AVPs [2].
5.0 References
[1] Rigney, et alia, "RADIUS", RFC-2138, Livingston, April 1997
[2] Calhoun, Rubens, "DIAMETER Base Protocol", Internet-Draft,
draft-calhoun-diameter-03.txt, May 1998.
[3] Aboba, Beadles, "Network Address Identifier", Internet-
Draft, draft-ietf-roamops-nai-10.txt, February 1998.
[4] Aboba, Zorn, "Dialup Roaming Requirements", Internet-Draft,
July 1997.
[5] Calhoun, Rubens, Aboba, "DIAMETER Extensible Authentication
Protocol Extensions", Internet-Draft, draft-calhoun-
diameter-eap-01.txt, March 1998.
[6] Calhoun, Haag, Zorn, "EAP Authentication for SOCKS
Version 5", draft-ietf-aft-socks-eap-00.txt, March 1998.
[7] Jacobson, "Compressing TCP/IP headers for low-speed serial
links", RFC 1144, February 1990.
[8] ISO 8859. International Standard -- Information Processing --
8-bit Single-Byte Coded Graphic Character Sets -- Part 1: Latin
Alphabet No. 1, ISO 8859-1:1987.
<URL:http://www.iso.ch/cate/d16338.html>
[9] Sklower, Lloyd, McGregor, Carr, "The PPP Multilink Protocol
(MP)", RFC 1717, November 1994.
[10] Calhoun, Greene, "DIAMETER Resource Management Extension",
Internet-Draft, draft-calhoun-diameter-res-mgmt-01.txt,
May 1998.
[11] Calhoun, Zorn, Pan, "DIAMETER Framework", Internet-
Draft, draft-calhoun-diameter-framework-00.txt, May 1998
Calhoun expires January 1999 [Page 63]
INTERNET DRAFT July 1998
6.0 Acknowledgements
The Author wishes to thank Carl Rigney since much of the text in the
document was shamefully copied from [1] as well as the following
people for their help in the development of this protocol:
Nancy Greene, Ryan Moats
7.0 Authors' Addresses
Questions about this memo can be directed to:
Pat R. Calhoun
Technology Development
Sun Microsystems, Inc.
15 Network Circle
Menlo Park, California, 94025
USA
Phone: 1-650-786-7733
Fax: 1-650-786-6445
E-mail: pcalhoun@eng.sun.com
William Bulley
Merit Network, Inc.
4251 Plymouth Road, Suite C
Ann Arbor, Michigan, 48105-2785
USA
Phone: 1-734-764-9993
Fax: 1-734-647-3185
E-mail: web@merit.edu
Calhoun expires January 1999 [Page 64]
| PAFTECH AB 2003-2026 | 2026-04-22 05:11:00 |