One document matched: draft-calhoun-diameter-authent-01.txt
Differences from draft-calhoun-diameter-authent-00.txt
INTERNET DRAFT Pat R. Calhoun
Category: Standards Track Sun Microsystems, Inc.
Title: draft-calhoun-diameter-authent-01.txt
Date: March 1998
DIAMETER
User Authentication Extensions
<draft-calhoun-diameter-authent-01.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.
Internet-Drafts may be updated, replaced, or obsoleted by other
documents at any time. It is not appropriate to use Internet-Drafts
as reference material or to cite them other than as a ``working
draft'' or ``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 ds.internic.net, nic.nordu.net, ftp.nisc.sri.com, or
munnari.oz.au.
Abstract
DIAMETER is a management protocol used between Network Access Servers
and DIAMETER Servers for authentication, authorization, accounting of
dial-up 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 at the same time.
This document details the RADIUS authentication messages and how they
may be used with the DIAMETER protocol.
Table of Contents
1.0 Introduction
1.1 Specification of Requirements
2.0 Command Name and Command Code
3.0 Command Meanings
3.1 Domain-Discovery-Request
3.2 Domain-Discovery-Response
Calhoun expires September 1998 [Page 1]
INTERNET DRAFT March 1998
3.3 Authentication-Request
3.4 Authentication-Success
3.5 Authentication-Failure
4.0 Protocol Definition
4.1 RADIUS Proxies
4.2 DIAMETER Proxies
4.2 Domain Discovery
5.0 References
6.0 Authors' Addresses
1.0 Introduction
This document specifies extensions to the original RADIUS[1]
authentication messages.
There exists a scenario where services providers wish to proxy the
authentication of a user to a remote DIAMETER Server, yet wishes to
perform the authorization for the said user.
There are also many instances where a NAS may wish to simply
authenticate a user and not have any authorization assigned to the
request.
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.
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.
Calhoun expires September 1998 [Page 2]
INTERNET DRAFT March 1998
2.0 Command Name and Command Code
Command Name: Domain-Discovery-Request
Command Code: 6
Command Name: Domain-Discovery-Response
Command Code: 7
Command Name: Authentication-Request
Command Code: 8
Command Name: Authentication-Success
Command Code: 9
Command Name: Authentication-Failure
Command Code: 10
3.0 Command Meanings
3.1 Domain-Discovery-Request
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.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Command Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Code
256 DIAMETER Command
Length
The length of this attribute MUST be 7.
Calhoun expires September 1998 [Page 3]
INTERNET DRAFT March 1998
Flags
The flag field MUST have bit 1 (Mandatory Support) set.
Command Type
The Command Type field MUST be set to 6 (Domain-Discovery-Request).
3.2 Domain-Discovery-Response
Description
The Domain-Discovery-Response message is sent in response to the
Domain-Discovery-Request message by the domain's Home
authentication server. The message MUST contain either the X509-
Certificate or the X509-Certificate-URL attribute and MAY contain
the Password-Policy attribute.
A summary of the Domain-Discovery-Response 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Command Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Code
256 DIAMETER Command
Length
The length of this attribute MUST be 7.
Flags
The flag field MUST have bit 1 (Mandatory Support) set.
Command Type
The Command Type field MUST be set to 7 (Domain-Discovery-
Response).
Calhoun expires September 1998 [Page 4]
INTERNET DRAFT March 1998
3.3 Authentication-Request
Description
The Authentication-Request message is used in order to request
authentication and authorization for a given user. Note that this
command does not require the presence of a user name as the
credentials used MAY be a telephone number (i.e. DNIS, ANI)
instead.
Note that the flag field MAY be used in this command in order to
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. At least
one of the Authenticate/Authorize flag bits MUST be set.
A summary of the Authentication-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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Command Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Code
256 DIAMETER Command
Length
The length of this attribute MUST be 7.
Flags
The flag field MUST have bit 1 (Mandatory Support) set. In
addition, the following bits may be used (note these bits are
mutually exclusive):
bit 3 - Authenticate-Only
bit 4 - Authorize-Only
Command Type
The Command Type field MUST be set to 8 (Authentication-Request).
Calhoun expires September 1998 [Page 5]
INTERNET DRAFT March 1998
3.4 Authentication-Success
Description
The Authentication-Success message is used in order to indicate
that Authentication (or authorization) was successful. If
authorization was requested a list of AVPs with the authorization
information MUST be attached to the message (see [1]).
Note that the flag field MUST be set to the same value that was
found in the Authentication-Request message.
A summary of the Access-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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Command Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Code
256 DIAMETER Command
Length
The length of this attribute MUST be 7.
Flags
following bits may be used (note these bits are mutually
exclusive):
bit 3 - Authenticate-Only
bit 4 - Authorize-Only
Command Type
The Command Type field MUST be set to 9 (Authentication-Success).
3.5 Authentication-Failure
Description
Calhoun expires September 1998 [Page 6]
INTERNET DRAFT March 1998
The Authentication-Failure message is used in order to indicate
that Authentication (or authorization) was unsuccessful. The list
of AVPs that may be attached to this message can be found in [1].
Note that the flag field MUST be set to the same value that was
found in the Authentication-Request message.
A summary of the Access-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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Command Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Code
256 DIAMETER Command
Length
The length of this attribute MUST be 7.
Flags
following bits may be used (note these bits are mutually
exclusive):
bit 3 - Authenticate-Only
bit 4 - Authorize-Only
Command Type
The Command Type field MUST be set to 10 (Authentication-Failure).
4.0 Protocol Definition
This section will outline how the DIAMETER Authentication Extension
can be used.
4.1 RADIUS Proxies
In today's dial up networks the RADIUS protocol is used to
Calhoun expires September 1998 [Page 7]
INTERNET DRAFT March 1998
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 his ISPs service area, it is possible for the user
to connect to another service provider (see [4] for more details).
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 authentication 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 model where 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)
Calhoun expires September 1998 [Page 8]
INTERNET DRAFT March 1998
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
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. fool RADA into believing that
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.2 DIAMETER Proxies
The DIAMETER protocol also the 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.
(Access-Request) (Access-Request)
+------+ -----> +------+ ------> +------+
| | | | | |
| NASB +--------------------+ DIA2 +--------------------+ DIA1 +
| | | | | |
+------+ <----- +------+ <------ +------+
(Access-Accept) (Access-Accept)
In this example NASB generates an Authentication-Request that is
forwarded to DIA2. The Authentication-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
Calhoun expires September 1998 [Page 9]
INTERNET DRAFT March 1998
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
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 RADB 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 RADA 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.
(Access-Request) (Access-Request) (Access-Request)
+------+ -----> +------+ -----> +------+ -----> +------+
| | | | | | | |
| NASB +----------+ DIA2 +----------+ DIA3 +----------+ DIA1 +
| | | | | | | |
+------+ <----- +------+ <----- +------+ <----- +------+
(Access-Accept) (Access-Accept) (Access-Accept)
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
Calhoun expires September 1998 [Page 10]
INTERNET DRAFT March 1998
AVPs.
4.3 Domain Discovery
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 DIA2 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 is now
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).
(Authentication-Request)
+------+ -----> +------+
Calhoun expires September 1998 [Page 11]
INTERNET DRAFT March 1998
| | | |
| DIA1 +--------------------+ DIA3 +
| | | |
+------+ <----- +------+
(Authentication-Response)
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-Request/Response MAY include the Features-
Supported AVPs.
5.0 References
[1] Rigney, et alia, "RADIUS", RFC-2058, Livingston, January 1997
[2] P. R. Calhoun, A. Rubens, "DIAMETER Base Protocol",
draft-calhoun-diameter-00.txt, February 1998.
[3] B. Aboba. "The Network Access Identifier." Internet-Draft,
August 1997.
[4] Aboba, Zorn, "Dialup Roaming Requirements", Internet-Draft,
July 1997.
6.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-847-548-9587
Fax: 1-650-786-6445
E-mail: pcalhoun@toast.net
Calhoun expires September 1998 [Page 12]
| PAFTECH AB 2003-2026 | 2026-04-22 05:11:06 |