INTERNET DRAFT Pat R. Calhoun
Category: Standards Track Sun Microsystems, Inc.
Title: draft-calhoun-diameter-01.txt Allan Rubens
Date: March 1998 Merit Networks Inc.
DIAMETER
Base Protocol
<draft-calhoun-diameter-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
This original document was named Enhanced RADIUS and was changed at
the request of the WG since this protocol is different from the
former.
This document describes a management protocol used between Network
Access Servers and DIAMETER Servers for authentication, authorization,
and 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.
Table of Contents
1.0 Introduction
1.1 Definitions
2.0 Packet Format
3.0 DIAMETER Attributes Format
4.0 Command Meanings
Calhoun, Rubens expires September 1998 [Page 1]
INTERNET DRAFT March 1998
4.1 Command AVP
4.1.1 Command Name and Command Code
4.1.2 Command-Unrecognized
4.1.3 Device-Reboot-Indication
4.1.4 Device-Reboot-Ack
4.1.5 Device-Feature-Request
4.1.6 Device-Feature-Response
4.2 DIAMETER AVPs
4.2.1 Version-Number
4.2.2 Supported-Extension
4.2.3 Signature
4.2.4 Digital-Signature
4.2.5 Initialization-Vector
4.2.6 Timestamp
4.2.7 Session-Id
5.0 Protocol Definition
5.1 DIAMETER Proxy
5.2 Digital Signatures
6.0 References
7.0 Contacts
1.0 Introduction
Since the RADIUS protocol is being used today for much more than
simple authentication and accounting of dial-up users (i.e.
authentication of WEB clients, etc), a more extensible protocol was
necessary which could support new services being deployed in the
internet and corporate networks.
RADIUS in itself is not an extensible protocol largely due to its very
limited command and attribute address space. In addition, the RADIUS
protocol assumes that there cannot be any unsolicited messages from a
server to a client. In order to support new services it is imperative
that a server be able to send unsolicited messages to clients on a
network, and this is a requirement for any DIAMETER implementation.
This document describes the base DIAMETER protocol. This document in
itself is not complete and MUST be used with an accompanying
applicability extension document.
An example of such a document would be [x] which defines extensions to
the base protocol to support user authentication and [x] which defines
extensions to support accounting.
Calhoun, Rubens expires September 1998 [Page 2]
INTERNET DRAFT March 1998
1.1 Definitions
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.
2.0 DIAMETER Header Format
DIAMETER packets MAY be transmitted over UDP or TCP. Each Service
Extensions draft SHOULD specify the transport layer. The destination
port field for DIAMETER is 1645.
When a reply is generated, the source and destination ports are
reversed.
A summary of the DIAMETER data 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 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attributes ...
+-+-+-+-+-+-+-+-+-+-+-+-+-
Code
The Code field is a one octet field which is used in the RADIUS
Calhoun, Rubens expires September 1998 [Page 3]
INTERNET DRAFT March 1998
protocol to identify the command type. In order to easily
distinguish DIAMETER packets from RADIUS a special value has been
reserved.
This field allows an implementation to support both RADIUS as well
as DIAMETER simply by identifying the first octet in the header.
The Code field MUST be set as follows:
254 DIAMETER packet
Flags
The Flags field is five bits, and is used in order to identify any
options. This field MUST be set initialized to zero. No flags are
defined at this time.
Version
The Version field is three bits, and indicates the version number
which is associated with the packet received. This field MUST be
set to 1 to indicate DIAMETER Version 1.
Length
The Length field is two octets. It indicates the length of the
packet including the header fields. Octets outside the range of the
Length field should be treated as padding and should be ignored on
receipt.
Identifier
The Identifier field is four octets, and aids in matching requests
and replies. The identifier MUST be unique at any given time and
one mechanism to ensure this is to use a monotonically increasing
number. Given the size of the Identifier field it is unlikely that
2^32 requests could be outstanding at any given time.
Attributes
See section 6 for more information of attribute formats.
3.0 DIAMETER Attributes Format
DIAMETER Attributes carry the specific authentication and
authorization information as well as configuration details for the
Calhoun, Rubens expires September 1998 [Page 4]
INTERNET DRAFT March 1998
request and reply.
Some Attributes MAY be listed more than once. The effect of this is
Attribute specific, and is specified by each such attribute
description.
The end of the list of attributes is defined by the length of the
DIAMETER packet minus the length of the header.
A summary of the attribute 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 | Vendor ID (opt) | Value... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Attribute Type
The Type field is two octets. RADIUS reserves the lowest 256
attribute numbers. Up-to-date values of the RADIUS Type field are
specified in the most recent "Assigned Numbers" RFC [2].
DIAMETER will use attribute numbers 257 and above. Vendor Specific
attributes reside within this space when the Vendor Specific bit is
set (see flags). This will allow up to 65535 vendor-specific
attributes (per vendor ID).
Length
The Length field is two octets, and indicates the length of this
Attribute including the Type, Length, Flag, Vendor ID is present
and Value fields. If a packet is received with an Invalid attribute
length, the packet SHOULD be rejected.
Flags
The Flags field indicates how DIAMETER devices MUST react to the
attribute received. The following values are currently supported:
1 - The Device MUST support this attribute. If the attribute
is NOT supported, the device MUST reject the Command.
If this flag is not set, then the device MAY accept the
command regardless of whether or not the particular attribute
is recognized.
Calhoun, Rubens expires September 1998 [Page 5]
INTERNET DRAFT March 1998
2 - If this bit is set, the contents of the attributes are
encrypted. Note that the attribute header is NOT encrypted in
this case. See section 3 for more information.
NOTE That this bit MUST NOT be turned on if the encryption
bit is set in the DIAMETER header which means that all
attributes are encrypted.
128 - If this bit is set, the optional Vendor ID field will be
present. When set, the attribute is a vendor specific
attribute
Vendor ID
Vendor ID is the IANA assigned "SMI Network Management Private
Enterprise Codes" value, encoded in network byte order. The value
0, reserved in this table, corresponds to IETF adopted Attribute
values, defined within this document. Any vendor wishing to
implement DIAMETER extensions can use their own Vendor ID along
with private Attribute values, guaranteeing that they will not
collide with any other vendor's extensions, nor with future IETF
extensions.
Value
The Value field is zero or more octets and contains information
specific to the Attribute. The format and length of the Value
field is determined by the Type and Length fields.
The format of the value field MAY be one of five data types. It is
possible for an attribute to have a structure and this MUST be
defined along with the attribute.
string 0-65526 octets.
address 32 bit value, most significant octet first.
extended
address Address Length is determined from the Length field, most
significant octet first. This is required in order to
support protocols which require an address length greater
than 32 bits (i.e. IPNG). Note that this type is
differentiated from the previous type by the value of
length.
integer 32 bit value, most significant octet first.
Calhoun, Rubens expires September 1998 [Page 6]
INTERNET DRAFT March 1998
time 32 bit value, most significant octet first -- seconds
since 00:00:00 GMT, January 1, 1970.
4.0 Command Meanings
4.1 Command AVP
Description
The Command AVP MUST be the first AVP following the DIAMETER
header. This AVP is used in order to communicate the command
associated with the message. There MUST only be a single Command
AVP within a given message. The format of the AVP is as follows:
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 | Vendor ID (opt) | Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value |
+-+-+-+-+-+-+-+-+
Attribute Type
256 DIAMETER Command
Length
The length of this attribute MUST be at least 7. The exact length
of the AVP is determined by the actual Command and is defined with
each command.
Flags
The flag field MUST have bit 1 (Mandatory Support) set. Bit 2
(Encrypted AVP) SHOULD NOT be set. The optional Vendor ID bit MAY
be set if the command is vendor-specific.
Value
The value field is set to the actual Command (defined later). Note
that each extensions draft MAY define a new set of Commands.
Calhoun, Rubens expires September 1998 [Page 7]
INTERNET DRAFT March 1998
4.1.1 Command Name and Command Code
The following Command types MUST be supported by all DIAMETER
implementations in order to conform to the base protocol
specification.
Command Name: Command-Unrecognized
Command Code: 1
Command Name: Device-Reboot-Indication
Command Code: 2
Command Name: Device-Reboot-Ack
Command Code: 3
Command Name: Device-Feature-Request
Command Code: 4
Command Name: Device-Feature-Response
Command Code: 5
4.1.2 Command-Unrecognized
Messages with the Command-Unrecognized AVP MUST be sent by a DIAMETER
device to inform its peer that a message was received with an
unsupported Command AVP value.
Since there certainly will exist a case where an existing device does
not support a new extension to the DIAMETER protocol, a device which
receives a packet with an unrecognized Command code MUST return a
Command-Unrecognized packet.
A summary of the Command-Unrecognized 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 | Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value |
+-+-+-+-+-+-+-+-+
Attribute Type
256 DIAMETER Command
Calhoun, Rubens expires September 1998 [Page 8]
INTERNET DRAFT March 1998
Length
The length of this attribute MUST be 9.
Flags
The flag field MUST have bit 1 (Mandatory Support) set.
Command Type
The Command Type field MUST be set to 1 (Command-Unrecognized).
4.1.3 Device-Reboot-Indication
Description
The Device-Reboot-Indication message is sent by a DIAMETER device
to inform all of its peers that it has rebooted. The peer MUST
respond to the message with a successful acknowledgement. Note that
a device MUST only send this message once it is ready to receive
packets.
This message is also used by a DIAMETER device in order to exchange
the supported protocol version number as well as all supported
extensions. The originator of this message MUST insert it's highest
supported version number within the DIAMETER header. The response
message MUST include the highest supported version up to and
including the version number within the request.
Similarly the originator of this message MUST include all supported
extensions within the message. The responder MUST include all
supported extensions as long as they were present within the
request message.
In the case where the receiver of this message is a proxy device,
it is responsible for inserting the highest version number which it
supports in the version field before sending the proxy request to
the remote DIAMETER peer. The proxy device may then retain the
version number of the remote peers as received in the message, and
must insert its highest version number (with the limitations
described above) in the response to the initiator.
It is desireable for a DIAMETER device to retain the supported
extensions as well as the version number in order to ensure that
any requests issued to a peer will be processed.
This message MAY contain the Version-Number and Vendor-Name AVPs.
Calhoun, Rubens expires September 1998 [Page 9]
INTERNET DRAFT March 1998
In the case where a DIAMETER device is configured to communicate
with many peers, this message MUST be issued to each peer.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Attribute Type
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 2 (Device-Reboot-Indication).
4.1.4 Device-Reboot-Ack
Description
The Device-Reboot-Ack message is sent by a DIAMETER device to
acknowledge the receipt of the Device-Reboot-Indication message.
The originator of this message MUST include the highest support
version number (up to and including the value in the request) in
the DIAMETER header as well as all supported extensions (as long as
they were present in the requesting message).
This message MAY contain the Version-Number and Vendor-Name AVPs.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Calhoun, Rubens expires September 1998 [Page 10]
INTERNET DRAFT March 1998
| Flags | Command Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Attribute Type
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 3 (Device-Reboot-Ack).
4.1.5 Device-Feature-Request
Description
The Device-Feature-Request message is used in order to request a
peer about it's supported extensions. This message MAY contain the
Version-Number and Vendor-Name AVPs.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Attribute Type
256 DIAMETER Command
Length
The length of this attribute MUST be 7.
Calhoun, Rubens expires September 1998 [Page 11]
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 4 (Device-Feature-Request).
4.1.6 Device-Feature-Response
Description
The Device-Feature-Response message is sent in response to the
Device-Feature-Request message. This message includes all supported
extensions by the responder and MAY contain the Version-Number and
Vendor-Name AVPs.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Attribute Type
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 5 (Device-Feature-Response).
4.2 DIAMETER AVPs
Calhoun, Rubens expires September 1998 [Page 12]
INTERNET DRAFT March 1998
This section will define the mandatory AVPs which MUST be supported
by all DIAMETER implementations. The following AVPs are defined in
this document:
Attribute Name: Version-Number
Attribute Code: 257
Attribute Name: Supported-Extension
Attribute Code: 258
Attribute Name: Signature
Attribute Code: 259
Attribute Name: Digital-Signature
Attribute Code: 260
Attribute Name: Initialization-Vector
Attribute Code: 261
Attribute Name: Timestamp
Attribute Code: 262
Attribute Name: Session-Id
Attribute Code: 263
Attribute Name: X509-Certificate
Attribute Code: 264
Attribute Name: X509-Certificate-URL
Attribute Code: 265
Attribute Name: Vendor-Name
Attribute Code: 266
4.2.1 Version-Number
The Version-Number AVP is used in order to indicate the current
DIAMETER system version number to a peer.
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 | Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Attribute Type
Calhoun, Rubens expires September 1998 [Page 13]
INTERNET DRAFT March 1998
257 Version-Number
Length
The length of this attribute MUST be 7.
Flags
The flag field MUST have bit 1 (Mandatory Support) set.
Value
The value field contains the system version number.
4.2.2 Supported-Extension
The Supported-Extension AVP is used to inform a peer of the supported
extensions. Note that each supported extensions draft MUST have an
identifier assigned. The base protocol is not considered an extension
since its support is mandatory.
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 | Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Attribute Type
258 Supported-Extension
Length
The length of this attribute MUST be 7.
Flags
The flag field MUST have bit 1 (Mandatory Support) set.
Value
Calhoun, Rubens expires September 1998 [Page 14]
INTERNET DRAFT March 1998
The value field contains the extension number.
4.2.3 Signature
The Signature AVP is used for authentication and integrity. The
DIAMETER header as well as all AVPs prior to this AVP is protected by
the Signature.
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 | Value... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Attribute Type
259 Signature
Length
The length of this attribute MUST be at least 7.
Flags
The flag field MUST have bit 1 (Mandatory Support) set.
Value
The value field contains an HMAC-MD5-96[6] of the message up to and
including the attribute type field of this AVP.
4.2.4 Digital-Signature
The Digital-Signature AVP is used for authentication, integrity as
well as non-repudiation. The DIAMETER header as well as all AVPs
prior to this AVP is protected by the Digital-Signature.
Note that for services which use the concept of a proxy server which
forwards the request to a next hop server, the proxy server MUST NOT
modify any attributes found prior to the Digital-Signature AVP. This
ensures that end-to-end security is maintained even through proxy
Calhoun, Rubens expires September 1998 [Page 15]
INTERNET DRAFT March 1998
arrangements.
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 | Value... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Attribute Type
260 Digital-Signature
Length
The length of this attribute MUST be 7.
Flags
The flag field MUST have bit 1 (Mandatory Support) set.
Value
The value field contains the digital signature of the packet up to
and including the attribute type field within this AVP.
4.2.5 Initialization-Vector
The Initialization-Vector AVP MUST be present prior to the Digital-
Signature AVP within a message and is used to ensure randomness
within a message. The content of this AVP MUST be a random 128 bit
value.
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 | Value... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Attribute Type
Calhoun, Rubens expires September 1998 [Page 16]
INTERNET DRAFT March 1998
261 Initialization-Vector
Length
The length of this attribute MUST be 21.
Flags
The flag field MUST have bit 1 (Mandatory Support) set.
Value
The value field contains a random 128 bit value.
4.2.6 Timestamp
The Timestamp field is used in order to enable replay protection of
previous messages. The value of time is the most significant four
octets returned from an NTP server which indicates the number of
seconds expired since Jan. 1, 1970.
This document does not specify the window which an implementation
will accept packets, however it is strongly encouraged to make this
value user configurable with a reasonable default value (i.e. 4
seconds).
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 | Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value |
+-+-+-+-+-+-+-+-+
Attribute Type
262 Timestamp
Length
The length of this attribute MUST be 9.
Calhoun, Rubens expires September 1998 [Page 17]
INTERNET DRAFT March 1998
Flags
The flag field MUST have bit 1 (Mandatory Support) set.
Value
The value field contains the number of seconds since Jan. 1, 1970
when the message was created.
4.2.7 Session-Id
The Session-Id field is used in order to identify a specific session.
All messages pertaining to a specific session MUST include this AVP
and the same value MUST be used throughout the life of a session.
Note that in some applications there is no concept of a session (i.e.
data flow) and this field MAY be used to identify objects other than
a session.
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 | Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value |
+-+-+-+-+-+-+-+-+
Attribute Type
263 Session-Id
Length
The length of this attribute MUST be 9.
Flags
The flag field MUST have bit 1 (Mandatory Support) set.
Value
Calhoun, Rubens expires September 1998 [Page 18]
INTERNET DRAFT March 1998
The value field contains the session identifier assigned to the
session.
4.2.8 X509-Certificate
The X509-Certificate is used in order to send a DIAMETER peer the
local system's X.509 certificate chain, which is used in order to
validate the Digital-Signature attribute.
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 | Value... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Attribute Type
264 X509-Certificate
Length
The length of this attribute MUST be greater than 7.
Flags
The flag field MUST have bit 1 (Mandatory Support) set.
Value
The value field contains the X.509 Certificate Chain.
4.2.9 X509-Certificate-URL
The X509-Certificate-URL is used in order to send a DIAMETER peer a
URL to the local system's X.509 certificate chain, which is used in
order to validate the Digital-Signature attribute.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Calhoun, Rubens expires September 1998 [Page 19]
INTERNET DRAFT March 1998
| Attribute Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Value... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Attribute Type
265 X509-Certificate-URL
Length
The length of this attribute MUST be greater than 7.
Flags
The flag field MUST have bit 1 (Mandatory Support) set.
Value
The value field contains the X.509 Certificate Chain URL.
4.2.10 Vendor-Name
The Vendor-Name attribute is used in order to inform a DIAMETER peer
of the Vendor of the DIAMETER protocol stack. This MAY be used in
order to know which vendor specific attributes may be sent to the
peer.
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 | Value... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Attribute Type
266 Vendor-Name
Length
Calhoun, Rubens expires September 1998 [Page 20]
INTERNET DRAFT March 1998
The length of this attribute MUST be greater than 7.
Flags
The flag field MUST have bit 1 (Mandatory Support) set.
Value
The value field contains the vendor name.
5.0 Protocol Definition
This section will describe how the base protocol works (or is at
least an attempt to).
5.1 Digital Signatures
In the case of a simple peer to peer relationship the use of IPSEC is
sufficient for data integrity and non-repudiation. However there are
instances where a peer must communicate with another peer through the
use of a proxy server. IPSEC does not provide a mechanism to protect
traffic when two peers must use an intermediary node to communicate
at the application layer.
In these cases the Digital Signature AVP may be used.
Note that Digital Signatures only protect the DIAMETER header as well
as all AVPs found prior to the digital signature. It is thefore
possible to have AVPs following the digital signature and these are
considered unprotected.
Since some fields within the DIAMETER header will change "en route"
towards the final DIAMETER destination, it is necessary to set the
mutable fields to zero (0) prior to calculating the signature. The
two mutable fields are the identifier and the length.
The Timestamp attribute provides replay protection and this AVP MUST
be present prior to the Digital Signature AVP. In addition the
Initialization Vector AVP MUST also be present prior to the Digital
Signature AVP in order to provide some randomness.
5.2 Signatures
The use of the Signature AVP requires a pre-configured shared secret.
Although this mechanism does not scale as well as the Digital
Signature, it may be desireable to use this mechanism in the case
Calhoun, Rubens expires September 1998 [Page 21]
INTERNET DRAFT March 1998
where asymetric technology is not required.
Note that in the case where two DIAMETER nodes need to communicate
through an intermediate node (i.e. Proxy) it does not offer any end-
to-end data integrity or encryption as each node must re-compute the
signature AVP.
The Timestamp attribute provides replay protection and this AVP MUST
be present prior to the Signature AVP. In addition the Initialization
Vector AVP MUST also be present prior to the Signature AVP in order
to provide some randomness.
6.0 References
[1] Rigney, et alia, "RADIUS", RFC-2058, Livingston, January 1997
[2] Reynolds, J., and J. Postel, "Assigned Numbers", RFC 1700,
USC/Information Sciences Institute, October 1994.
[3] Postel, J., "User Datagram Protocol", RFC 768, USC/Information
Sciences Institute, August 1980.
[4] Rivest, R., and S. Dusse, "The MD5 Message-Digest Algorithm",
MIT Laboratory for Computer Science and RSA Data Security,
Inc., RFC 1321, April 1992.
[5] Kaufman, C., Perlman, R., and Speciner, M., "Network Security:
Private Communications in a Public World", Prentice Hall,
March 1995, ISBN 0-13-061466-1.
[6] Krawczyk, H., Bellare, M., Canetti, R., "HMAC: Keyed-Hashing
for Message Authentication", RFC 2104, January 1997.
7.0 Author's Address
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
Allan C. Rubens
Merit Network, Inc.
4251 Plymouth Rd.
Ann Arbor, MI 48105-2785
Calhoun, Rubens expires September 1998 [Page 22]
INTERNET DRAFT March 1998
Phone: 1-734-647-0417
E-Mail: acr@merit.edu
Calhoun, Rubens expires September 1998 [Page 23]