Internet Draft Pat R. Calhoun
Category: Experimental US Robotics Access Corp.
expires in six months Allan Rubens
Merit Network Inc.
March 1997
DIAMETER
Authentication Extensions
<draft-calhoun-diameter-authent-00.txt>
Status of this Memo
Distribution of this memo is unlimited.
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 ds.internic.net (US East Coast), nic.nordu.net
(Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific
Rim).
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.
Calhoun, Rubens expires in six months [Page 1]
DRAFT DIAMETER March 1997
1. 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, Rubens expires in six months [Page 2]
DRAFT DIAMETER March 1997
2. Command Name and Command Code
Command Name: Access-Request
Command Code: 1
Command Name: Access-Accept
Command Code: 2
3. Command Meanings
3.1 Access-Request
Description
The Access-Request message is used by RADIUS/DIAMETER in order to
request that a user be authenticated. See [1] for more details.
The differences in the message used in RADIUS and the one for
DIAMETER are the flags which may be used with the message. If the
Authenticate-Only bit is set, then the Server which is
authenticating the user MUST NOT return any authorization
information.
Similarly if the Authorize-Only bit is set, the Client is
requesting that authorization information be returned for the user.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Flags | Ver | Command |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Authenticator |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Message Integrity Code |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attributes ...
+-+-+-+-+-+-+-+-+-+-+-+-+-
Calhoun, Rubens [Page 3]
DRAFT DIAMETER Authentication Extensions March 1997
Code
254 for DIAMETER.
Flags
The Following bits MAY be used in the Access-Request:
0x1 - (Bit 12) TimeStamp is included in the Authenticator Field.
0x2 - (Bit 11) All attributes in packets are encrypted.
0x4 - (Bit 10) Authenticate-Only
0x8 - (Bit 9) Authorize-Only
See [2] for more information on the encryption algorithm used.
Version
MUST be set to 2
Command
1 for Access-Request
Identifier
The Identifier field MUST be changed whenever the content of the
Attributes field changes, and whenever a valid reply has been
received for a previous request. For retransmissions, the
Identifier MAY remain unchanged.
Length
The total length of the message, including this header.
Authenticator
The Authenticator field is a random 16 octet value. If the
Timestamp option is supported, the first four octets contain a
timestamp of when the packet was sent from the peer.
Message Integrity Code
This field contains an MD5 hash of the following:
MD5( packet | Shared Secret )
Calhoun, Rubens [Page 4]
DRAFT DIAMETER Authentication Extensions March 1997
Attributes
The attributes in this message should be sent as defined in [1].
3.1 Access-Accept
Description
The Access-Accept message is used by RADIUS/DIAMETER in order to
request that a user be authenticated. See [1] for more details.
The differences in the message used in RADIUS and the one for
DIAMETER are the flags which may be used with the message. The
Access-Accept SHOULD contain the SAME flags which were set in the
original Access-Request. The failure to do so implies that the
Server does not support the feature.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Flags | Ver | Command |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Authenticator |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Message Integrity Code |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attributes ...
+-+-+-+-+-+-+-+-+-+-+-+-+-
Code
254 for DIAMETER.
Calhoun, Rubens [Page 5]
DRAFT DIAMETER Authentication Extensions March 1997
Flags
The Following bits MAY be used in the Access-Request:
0x1 - (Bit 12) TimeStamp is included in the Authenticator Field.
0x2 - (Bit 11) All attributes in packets are encrypted.
0x4 - (Bit 10) User Authenticated Only
0x8 - (Bit 9) User Authorized Only
See [2] for more information on the encryption algorithm used.
Version
MUST be set to 2
Command
2 for Access-Accept
Identifier
The Identifier field is a copy of the Identifier field of the
Access-Request.
Length
The total length of the message, including this header.
Authenticator
The Authenticator field is a random 16 octet value. If the
Timestamp option is supported, the first four octets contain a
timestamp of when the packet was sent from the peer.
Message Integrity Code
This field contains an MD5 hash of the following:
MD5( packet | Shared Secret )
Attributes
The attributes in this message should be sent as defined in [1].
Calhoun, Rubens [Page 6]
DRAFT DIAMETER Authentication Extensions March 1997
4. References
[1] Rigney, et alia, "RADIUS", RFC-2058, Livingston, January 1997
[2] Calhoun, Rubens, "DIAMETER", Internet-Draft, March 1997.
5. Authors' Addresses
Pat R. Calhoun
US Robotics Access Corp.
8100 N. McCormick Blvd.
Skokie, IL 60076-2999
Phone: 847-342-6898
EMail: pcalhoun@usr.com
Allan C. Rubens
Merit Network, Inc.
4251 Plymouth Rd.
Ann Arbor, MI 48105-2785
Phone: 313-647-0417
EMail: acr@merit.edu
Calhoun, Rubens expires in six months [Page 7]