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 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]