HTTP/1.1 200 OK Date: Mon, 08 Apr 2002 23:04:03 GMT Server: Apache/1.3.20 (Unix) Last-Modified: Mon, 27 Apr 1998 14:30:00 GMT ETag: "2e7ea0-ecf8-35449668" Accept-Ranges: bytes Content-Length: 60664 Connection: close Content-Type: text/plain INTERNET DRAFT Pat R. Calhoun Category: Standards Track Sun Microsystems, Inc. Title: draft-calhoun-diameter-02.txt Allan C. Rubens Date: March 1998 Ascend Communications 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 The DIAMETER base protocol is intended to provide a framework for any services which require AAA/Policy support. The protocol is inteded to be flexible enough to allow services to add building blocks to DIAMETER in order to meet their requirements. This draft MUST be supported by all DIAMETER implementations, regardless of the specific underlying service. Calhoun, Rubens expires September 1998 [Page 1] INTERNET DRAFT March 1998 Table of Contents 1.0 Introduction 1.1 Definitions 2.0 Packet Format 3.0 DIAMETER AVP Format 4.0 DIAMETER AVPs 4.1 DIAMETER-Command AVP 4.1.1 Command-Unrecognized 4.1.2 Device-Reboot-Indication 4.1.3 Device-Reboot-Ack 4.1.4 Device-Feature-Request 4.1.5 Device-Feature-Response 4.2 Host-IP-Address 4.3 Host-Name 4.4 Version-Number 4.5 Supported-Extension 4.6 Integrity-Check-Vector 4.7 Digital-Signature 4.8 Initialization-Vector 4.9 Timestamp 4.10 Session-Id 4.11 X509-Certificate 4.12 X509-Certificate-URL 4.13 Vendor-Name 4.14 Firmware-Revision 5.0 Protocol Definition 5.1 Data Integrity 5.1.1 Using Integrity-Check-Vector 5.1.2 Using Digital Signatures 5.1.3 Using Mixed Data Integrity AVPs 5.2 AVP Data Encryption 5.2.1 AVP Encryption with Shared Secrets 5.2.2 AVP Encryption with Public Keys 5.3 Public Key Cryptography Support 5.3.1 X509-Certificate 5.3.2 X509-Certificate-URL 5.3.3 Static Public Key Configuration 6.0 References 7.0 Acknowledgements 8.0 Author's Address 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. Calhoun, Rubens expires September 1998 [Page 2] INTERNET DRAFT March 1998 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 [8] which defines extensions to the base protocol to support user authentication and [x] which defines extensions to support accounting. 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. For UDP, when a reply is generated the source and destination ports are reversed. Calhoun, Rubens expires September 1998 [Page 3] INTERNET DRAFT March 1998 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RADIUS PCC |PKT Flags| Ver | Packet Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Attributes ... +-+-+-+-+-+-+-+-+-+-+-+-+- RADIUS PCC (Packet Compatibility Code) The RADIUS PCC field is a one octet field which is used for RADIUS backward compatibility. In order to easily distinguish DIAMETER packets from RADIUS a special value has been reserved and allows an implementation to support both protocols concurently using the first octet in the header. The RADIUS PCC field MUST be set as follows: 254 DIAMETER packet PKT Flags The Packet 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. Packet Length The Packet Length field is two octets. It indicates the length of the packet including the header fields. For messages received via UDP, 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. Calhoun, Rubens expires September 1998 [Page 4] INTERNET DRAFT March 1998 Attributes See section 3.0 for more information of attribute formats. 3.0 DIAMETER AVP Format DIAMETER Attributes carry the specific authentication and authorization information as well as configuration details for the 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. Each AVP MUST be padded to align on a 32 bit boundary. Although this is not problematic for most attribute types, it does require that AVP of string and data type be padded accordingly. The Padding size can be deduced using the following formula: padding_size = Length % 4 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Length | AVP Flags | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vendor ID (opt) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data... +-+-+-+-+-+-+-+-+ AVP Code The AVP Code field is four octets. The first 256 AVP numbers are reserved for backward RADIUS compatibility. Up-to-date values of the RADIUS Type field are specified in the most recent "Assigned Numbers" RFC [2]. AVP numbers 257 and above are used for DIAMETER. Each service MUST allocate AVP numbers through the IANA. Calhoun, Rubens expires September 1998 [Page 5] INTERNET DRAFT March 1998 If the Vendor ID bit is set the AVP Code is allocated from the vendor's private address space. AVP Length The AVP Length field is two octets, and indicates the length of this Attribute including the Address Type, AVP Length, AVP Flags, Reserved, Vendor ID if present and the AVP data. If a packet is received with an Invalid attribute length, the packet SHOULD be rejected. AVP Flags The AVP Flags field informs the DIAMETER host how each attribute must be handled. The following values are currently defined: Mandatory-Support 1 The receiver MUST support this attribute. If the attribute is NOT supported, the device MUST reject the Command. If this flag is not set, then the receiver MAY accept the command regardless of whether or not the particular attribute is recognized. SS-Encrypted-Data 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 5.2 for more information. PK-Encrypted-Data 4 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 5.2 for more information. Vendor-Specific-AVP 8 If this bit is set, the optional Vendor ID field will be present in the AVP header and the AVP Code MUST be treated accordingly. Reserved The Reserved field MUST be set to zero (0). Vendor ID The optional four octet Vendor ID field contains the the IANA assigned "SMI Network Management Private Enterprise Codes" value, encoded in network byte order. 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. Calhoun, Rubens expires September 1998 [Page 6] INTERNET DRAFT March 1998 The value 0, reserved in this protocol, corresponds to IETF adopted Attribute values, defined within this document and MUST NOT be used in an AVP since it is implied with the absence of the Vendor- Specific-AVP bit. Data The Data field is zero or more octets and contains information specific to the Attribute. The format and length of the Data field is determined by the AVP Code and AVP Length fields. The format of the value field MAY be one of six data types. It is possible for an attribute to have a structure and this MUST be defined along with the attribute. Data 0-65526 octets of arbitrary data. String 0-65526 octets of string data in some agreed upon char set. Address 32 bit or 48 bit value, most significant octet first. The length of the attribute is determined by the flag field. Integer32 32 bit value, most significant octet first. Integer64 64 bit value, most significant octet first. Time 32 bit value, most significant octet first -- seconds since 00:00:00 GMT, January 1, 1970. 4.0 DIAMETER AVPs This section will define the mandatory AVPs which MUST be supported by all DIAMETER implementations. Note the first 256 AVP numbers are reserved for RADIUS compatibility. The following AVPs are defined in this document: Calhoun, Rubens expires September 1998 [Page 7] INTERNET DRAFT March 1998 Attribute Name Attribute Code ----------------------------------- DIAMETER-Command 256 Host-IP-Address 4 Host-Name 32 Supported-Extension 258 Integrity-Check-Vector 259 Digital-Signature 260 Initialization-Vector 261 Timestamp 262 Session-Id 263 X509-Certificate 264 X509-Certificate-URL 265 Vendor-Name 266 Firmware-Revision 267 4.1 DIAMETER-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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Length | AVP Flags | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Command Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ AVP Code 256 DIAMETER-Command AVP Length The length of this attribute MUST be at least 10. The exact length of the AVP is determined by the actual Command and is defined with each command. AVP 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 Calhoun, Rubens expires September 1998 [Page 8] INTERNET DRAFT March 1998 be set if the command is vendor-specific. Reserved The Reserved field MUST be set to zero (0). Command Code The Command Code field contains the command number. The following commands are defined in this document: The following commands MUST be supported by all DIAMETER implementations in order to conform to the base protocol specification: Command Name Command Code ----------------------------------- Command-Unrecognized 256 Device-Reboot-Indication 257 Device-Reboot-Ack 258 Device-Feature-Query 259 Device-Feature-Response 260 4.1.1 Command-Unrecognized Description 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Length | AVP Flags | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Command Code | Unrecognized Command Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Calhoun, Rubens expires September 1998 [Page 9] INTERNET DRAFT March 1998 AVP Code 256 DIAMETER Command AVP Length The length of this attribute MUST be 12. AVP Flags The flag field MUST have bit 1 (Mandatory Support) set. Command Code The Command Code field MUST be set to 256 (Command-Unrecognized). Unrecognized Command Code The Unrecognized Command Code field MUST contain the Command Code that resulted in this message. 4.1.2 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 Calhoun, Rubens expires September 1998 [Page 10] INTERNET DRAFT March 1998 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, Vendor-Name and Supported-Extension AVPs. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Length | AVP Flags | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Command Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ AVP Code 256 DIAMETER Command AVP Length The length of this attribute MUST be 10. AVP Flags The flag field MUST have bit 1 (Mandatory Support) set. Command Code The Command Code field MUST be set to 257 (Device-Reboot- Indication). 4.1.3 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). Calhoun, Rubens expires September 1998 [Page 11] INTERNET DRAFT March 1998 This message MAY contain the Version-Number, Vendor-Name and Supported-Extension 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Length | AVP Flags | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Command Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ AVP Code 256 DIAMETER Command AVP Length The length of this attribute MUST be 10. AVP Flags The flag field MUST have bit 1 (Mandatory Support) set. Command Code The Command Code field MUST be set to 258 (Device-Reboot-Ack). 4.1.4 Device-Feature-Query Description The Device-Feature-Query message is used in order to query a peer about it's supported extensions. This message MAY contain the Version-Number, Vendor-Name and Supported-Extension 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Length | AVP Flags | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Command Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ AVP Code Calhoun, Rubens expires September 1998 [Page 12] INTERNET DRAFT March 1998 256 DIAMETER Command AVP Length The length of this attribute MUST be 10. AVP Flags The flag field MUST have bit 1 (Mandatory Support) set. Command Code The Command Code field MUST be set to 259 (Device-Feature-Request). 4.1.5 Device-Feature-Response Description The Device-Feature-Response message is sent in response to the Device-Feature-Query message. This message includes all supported extensions by the responder and MAY contain the Version-Number, Vendor-Name and Supported-Extension 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Length | AVP Flags | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Command Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ AVP Code 256 DIAMETER Command AVP Length The length of this attribute MUST be 10. AVP Flags The flag field MUST have bit 1 (Mandatory Support) set. Command Code The Command Code field MUST be set to 260 (Device-Feature- Response). Calhoun, Rubens expires September 1998 [Page 13] INTERNET DRAFT March 1998 4.2 Host-IP-Address Description The Host-IP-Address attribute is used to inform a DIAMETER peer of the sender's identity. 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 | AVP Flags | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ AVP Code 4 Host-IP-Address AVP Length The length of this attribute MUST be at least 12. AVP Flags The flag field MUST have bit 1 (Mandatory Support) set. Address The Address field contains the sender's IP address. 4.3 Host-Name Description The Host-Name attribute is used to inform a DIAMETER peer of the sender's identity. 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 | AVP Flags | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | String ... +-+-+-+-+-+-+-+-+ Calhoun, Rubens expires September 1998 [Page 14] INTERNET DRAFT March 1998 AVP Code 32 Host-Name AVP Length The length of this attribute MUST be at least 9. AVP Flags The flag field MUST have bit 1 (Mandatory Support) set. String The String field is one or more octets, and should be unique to the DIAMETER host. It is strongly encouraged that the Host Name follow the NAI [8] conventions. 4.4 Version-Number Description 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Length | AVP Flags | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Integer32 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ AVP Code 257 Version-Number AVP Length The length of this attribute MUST be 12. AVP Flags The flag field MUST have bit 1 (Mandatory Support) set. Integer32 Calhoun, Rubens expires September 1998 [Page 15] INTERNET DRAFT March 1998 The Integer32 field contains the system version number. 4.5 Supported-Extension Description 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. Each DIAMETER Extension draft will be assigned an extension number by the IANA. The value of the extension number is passed along in this AVP. There MAY be more than one Supported-Extension AVP within a DIAMETER message. 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 | AVP Flags | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Integer32 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ AVP Code 258 Supported-Extension AVP Length The length of this attribute MUST be 12. AVP Flags The flag field MUST have bit 1 (Mandatory Support) set. Integer32 The Integer32 field contains the supported extension number as defined in the extension's document. 4.6 Integrity-Check-Vector Description The Integrity-Check-Vector AVP is used for hop-by-hop Calhoun, Rubens expires September 1998 [Page 16] INTERNET DRAFT March 1998 authentication and integrity, and is not recommended for use with untrusted proxy servers. The DIAMETER header as well as all AVPs up to and including the AVP Code field of this AVP is protected by the ICV. The ICV is generated in the method described in section 5.1.1. All DIAMETER implementations MUST support this AVP. 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 | AVP Flags | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data ... +-+-+-+-+-+-+-+-+ AVP Code 259 Integrity-Check-Vector AVP Length The length of this attribute MUST be at least 9. AVP Flags The flag field MUST have bit 1 (Mandatory Support) set. Data The Data field contains an HMAC-MD5-96[6] of the message up to and including the attribute type field of this AVP. 4.7 Digital-Signature Description The Digital-Signature AVP is used for authentication, integrity as well as non-repudiation. The DIAMETER header as well as all AVPs up to and including the AVP Code field of 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 Calhoun, Rubens expires September 1998 [Page 17] INTERNET DRAFT March 1998 through proxy arrangements. The Digital-Signature is generated in the method described in section 5.1.2. All DIAMETER implementations SHOULD support this AVP. 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 | AVP Flags | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data ... +-+-+-+-+-+-+-+-+ AVP Code 260 Digital-Signature AVP Length The length of this attribute MUST be at least 9. AVP Flags The flag field MUST have bit 1 (Mandatory Support) set. Address The Address field contains the address of the DIAMETER host which generated the Digital-Signature. Data The Data field contains the digital signature of the packet up to and including the attribute type field within this AVP. 4.8 Initialization-Vector Description The Initialization-Vector AVP MUST be present prior to the Digital- Signature and Integrity-Check-Vector AVPs within a message and is used to ensure randomness within a message. The content of this AVP MUST be a random 128 bit value. Calhoun, Rubens expires September 1998 [Page 18] INTERNET DRAFT March 1998 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 | AVP Flags | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data ... +-+-+-+-+-+-+-+-+ AVP Code 261 Initialization-Vector AVP Length The length of this attribute MUST be 24. AVP Flags The flag field MUST have bit 1 (Mandatory Support) set. Data The Data field contains a random 128 bit value. 4.9 Timestamp Description 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Length | AVP Flags | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Time | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Calhoun, Rubens expires September 1998 [Page 19] INTERNET DRAFT March 1998 AVP Code 262 Timestamp AVP Length The length of this attribute MUST be 12. AVP Flags The flag field MUST have bit 1 (Mandatory Support) set. Time The Time field contains the number of seconds since Jan. 1, 1970 when the message was created. 4.10 Session-Id Description 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Length | AVP Flags | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Integer32 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ AVP Code 263 Session-Id AVP Length The length of this attribute MUST be 12. AVP Flags Calhoun, Rubens expires September 1998 [Page 20] INTERNET DRAFT March 1998 The flag field MUST have bit 1 (Mandatory Support) set. Integer32 The Integer32 field contains the session identifier assigned to the session. 4.11 X509-Certificate Description 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. Section 5.3 contains more information about the use of certificates. 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 | AVP Flags | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data ... +-+-+-+-+-+-+-+-+ AVP Code 264 X509-Certificate AVP Length The length of this attribute MUST be at least 9. AVP Flags The flag field MUST have bit 1 (Mandatory Support) set. Data The Data field contains the X.509 Certificate Chain. 4.12 X509-Certificate-URL Description Calhoun, Rubens expires September 1998 [Page 21] INTERNET DRAFT March 1998 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. Section 5.3 contains more information about the use of certificates. 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 | AVP Flags | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | String ... +-+-+-+-+-+-+-+-+ AVP Code 265 X509-Certificate-URL AVP Length The length of this attribute MUST be at least 9. AVP Flags The flag field MUST have bit 1 (Mandatory Support) set. String The String field contains the X.509 Certificate Chain URL. 4.13 Vendor-Name Description 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. It is also envisioned that the combination of the Vendor-Name and the Firmware-Revision AVPs can provide very useful debugging information. 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 22] INTERNET DRAFT March 1998 | AVP Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Length | AVP Flags | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | String ... +-+-+-+-+-+-+-+-+ AVP Code 266 Vendor-Name AVP Length The length of this attribute MUST be at least 9. AVP Flags The flag field MUST have bit 1 (Mandatory Support) set. String The String field contains the vendor name. 4.14 Firmware-Revision Description The Firmware-Revision AVP is used to inform a DIAMETER peer of the firmware revision of the issuing device. For devices which do not have a firmware revision (general purpose computers running DIAMETER software modules, for instance), the revision of the DIAMETER software module may be reported instead. 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 | AVP Flags | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Integer32 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ AVP Code 267 Firmware-Revision AVP Length Calhoun, Rubens expires September 1998 [Page 23] INTERNET DRAFT March 1998 The length of this attribute MUST be at least 12. AVP Flags The flag field MUST have bit 1 (Mandatory Support) set. Integer32 The Integer32 field contains the firmware revision number of the issuing device. 5.0 Protocol Definition This section will describe how the base protocol works (or is at least an attempt to). 5.1 Data Integrity This section will describe how data integrity is achieved using the Data Integrity AVPs. Note that the Timestamp and Initialization-Vector AVPs MUST be present in the message PRIOR to any of the Data Integrity AVPs discussed in this section. 5.1.1 Using Integrity Check Vector The use of the Integrity-Check-Vector 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 where asymetric technology is not required or available. 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 Integrity-Check-Vector AVP. The Data field of the AVP contains an HMAC-MD5-96[6] of the message up to and including the attribute type field of the AVP. Using the example code provided in [6], the following call would be used to generate the ICV: hmac_md5(DiameterMessage, MessageLength, Secret, Secretlength, Output) The Timestamp attribute provides replay protection and this AVP MUST be present prior to the Integrity-Check-Vector AVP. In addition the Calhoun, Rubens expires September 1998 [Page 24] INTERNET DRAFT March 1998 Initialization Vector AVP MUST also be present prior to the Integrity- Check-Vector AVP in order to provide some randomness. 5.1.2 Using 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 therefore the Digital-Signature AVP MUST be used. The following diagram shows an example of a router initiating a DIAMETER message to DIA1. Once DIA1 has finished processing the message it adds its signature and forwards the message to the non- trusted DIA2 proxy server. If DIA2 needs to add or change any muteable AVPs it SHOULD add its digital signature before forwarding the message to DIA3. +------+ -----> +------+ -----> +------+ -----> +------+ | | | | | non- | | | |router+----------+ DIA1 +----------+trustd+----------+ DIA3 + | | | | | DIA2 | | | +------+ <----- +------+ <----- +------+ <----- +------+ 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. Note that Digital Signatures only protect the DIAMETER header as well as all AVPs found prior to the digital signature. It is therefore possible to have AVPs following the digital signature and these are considered unprotected. The Data field of the Digital-Signature AVP contains the RSA/MD5 signature algorithm as defined in [9]. 5.1.3 Using Mixed Data Integrity AVPs Both previous sections describe the differences between the Integrity- Check-Vector and the Digital-Signature AVP. Note that it is valid to Calhoun, Rubens expires September 1998 [Page 25] INTERNET DRAFT March 1998 use both within a single DIAMETER message. In the case where an intermediate DIAMETER server is used to reach the end DIAMETER Server, the Integrity-Check-Vector AVP provides hop-by- hop integrity and requires that each set of DIAMETER peers share a secret. The Digital-Signature AVP provides end-to-end integrity and requires knowledge of all parties public keys. If both AVPs co-exist within a single DIAMETER message, it is necessary to ensure that the Digital-Signature appears prior to the Integrity-Check-Vector since the ICV will be removed by the next hop. +------+ -----> +------+ -----> +------+ | | | | | | |router+----------+ DIA1 +----------+ DIA2 + | | | | | | +------+ <----- +------+ <----- +------+ There are cases, such as in remote access, where the device initiating the DIAMETER request does not have the processing power to generate Digital-Signatures as required by the protocol. In such an arrangement, there normally exists a first hop DIAMETER Server (DIA1) which acts as a proxy to relay the request to the final authenticating DIAMETER server (DIA2). It is valid for the first hop server to remove the Integrity-Check-Vector AVP inserted by the router and replace it with a Digital-Signature AVP. 5.2 AVP Data Encryption DIAMETER supports two methods of encrypting AVP data. One is using a shared secret and the other is used with private keys. This feature can be used to encrypt sensitive data such as user ID's and passwords. The Encryption bits MUST NOT be set in the Command Type or Initialization-Vector AVPs. 5.2.1 AVP Encryption with Shared Secrets This method of encrypting AVP data is the simplest to use and MUST be supported by all DIAMETER implementations. However, local policy MAY determine that the use of this mechanism is not permitted. The SS-Encrypted-Data bit MUST only be set if a shared secret exists between both DIAMETER peers. If the SS-Encrypted-Data bit is set in any DIAMETER AVP, the Initialization-Vector AVP MUST be present prior Calhoun, Rubens expires September 1998 [Page 26] INTERNET DRAFT March 1998 to the first encrypted AVP. The length of the AVP value to be encrypted is first encoded in the following Subformat: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length of ClearText Data | ClearText Data ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Padding ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length The Length field contains the length of the decrypted data. ClearText Data Data of AVP that is to be obscured. Padding Random additional octets used to obscure length of the ClearText Data. The resulting subformat MAY be padded to a multiple of 16 octets in length. For example, if the ClearText Data to be obscured is a string containing 6 characters (e.g. password 'foobar'), then 8 + n * 16 octects of padding would be applied. Padding does NOT alter the value placed in the Length of the ClearText Data, only the length of the AVP itself. Next, An MD5 hash is performed on the concatenation of: - the 2 octet Command Code of the AVP - the shared authentication secret - an arbitrary length random vector The value of the random vector used in this hash is passed in the Data field of a Initialization-Vector AVP. This Initialization-Vector AVP must be placed in the message by the sender before any hidden AVPs. The same IV may be used for more than one hidden AVP in the same message. If a different IV is used for the hiding of subsequent AVPs then a new Initialization-Vector AVP must be placed before the first AVP to which it applies. The MD5 hash value is then XORed with the first 16 octet or less segment of the AVP Subformat and placed in the Data field of the AVP. If the AVP Subformat is less than 16 octets, the Subformat is Calhoun, Rubens expires September 1998 [Page 27] INTERNET DRAFT March 1998 transformed as if the Value field had been padded to 16 octets before the XOR, but only the actual octets present in the Subformat are modified, and the length of the AVP is not altered. If the Subformat is longer than 16 octets, a second one-way MD5 hash is calculated over a stream of octets consisting of the shared secret followed by the result of the first XOR. That hash is XORed with the second 16 octet or less segment of the Subformat and placed in the corresponding octets of the Data field of the AVP. If necessary, this operation is repeated, with each XOR result being used along with the shared secret to generate the next hash to XOR the next segment of the value with. This technique results in the content of the AVP being obscured, although the length of the AVP is still known. On receipt, the IV is taken from the last Initialization-Vector AVP encountered in the message prior to the AVP to be decrypted. The above process is then reversed to yield the original value. For more details on this hiding method, consult RFC2138 [1]. Please note that in the case where the DIAMETER message needs to be processed by an intermediate non-trusted DIAMETER server (also known as a proxy server, depicted as DIA2 in the figure below) the AVP needs to be decrypted using Shared-Secret-1 and re-encrypted by DIA2 using Shared-Secret-2. (Shared-Secret-1) (Shared-Secret-2) +------+ -----> +------+ ------> +------+ | | | | | | | DIA1 +-------------------+ DIA2 +-------------------+ DIA3 + | | | | | | +------+ +------+ +------+ Unfortunately in this case the non-trusted server DIA2 has access to sensitive information (such as a password). 5.2.2 AVP Encryption with Public Keys AVP encryption using public keys is much more complex than the previously decribed method, yet it is desirable to use it in cases where the DIAMETER message will be processed by an untrusted intermediate node (proxy). Public Key encryption SHOULD be supported, however it is permissible for a low powered device initiating the DIAMETER message to use shared secret encryption with the first hop (proxy) DIAMETER server, which would decrypt and encrypt using the Public Key method. Calhoun, Rubens expires September 1998 [Page 28] INTERNET DRAFT March 1998 The PK-Encrypted-Data bit MUST only be set if the final DIAMETER host is aware of the sender's public key. This information can be relayed in three different methods as described in section 5.3. The AVP is encrypted in the method described in [9]. 5.3 Public Key Cryptography Support A DIAMETER peer's public key is required in order to validate a message which includes the the Digital-Signature AVP. There are three possibilities on retrieving public keys: 5.3.1 X509-Certificate A message which includes a Digital-Signature MAY include the X509- Certificate AVP. Given the size of a typical certificate, this is very wasteful and in most cases DIAMETER peers would cache such information in order to minimize per packet processing overhead. It is however valid for a DIAMETER host to provide its X509- Certificate in certain cases, such as when issuing the Device-Reboot- Indication. It is envisioned that the peer would validate and cache the certificate at that time. 5.3.2 X509-Certificate-URL The X509-Certificate-URL is a method for a DIAMETER host sending a message that includes the Digital-Signature to provide a pointer to its certificate. Upon receiving such a message a DIAMETER host MAY choose to retrieve the certificate if it is not locally cached. Of course the process of retrieving and validating a certificate is lengthy and will require the initiator of the message to retransmit the request. However once cached the certificate can be used until it expires. 5.3.3 Static Public Key Configuration Given that using certificates requires a PKI infrastructure which is very costly, it is also possible to use this technology by locally configuring DIAMETER peers public keys. Note that in a network involving many DIAMETER proxies this may not scale well. 6.0 References Calhoun, Rubens expires September 1998 [Page 29] INTERNET DRAFT March 1998 [1] Rigney, et alia, "RADIUS", RFC-2138, Livingston, April 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] P. Calhoun, "DIAMETER User Authentication Extensions", draft-calhoun-diameter-authen-01.txt, March 1998. [8] B. Aboba, M. Beadles, "Network Address Identifier", draft-ietf-roamops-nai-10.txt, February 1998. [9] B. Kaliski, "PKCS #1: RSA Encryption Version 1.5", draft-hoffman-pkcs-rsa-encrypt-03.txt, October 1997. 7.0 Acknowledgements The Authors would like to acknowledge the following people for their contribution in the development of the DIAMETER protocol: Bernard Aboba, Jari Arkko, William Bulley, Daniel C. Fox, Lol Grant, Nancy Greene, Peter Heitman, Ryan Moats, Victor Muslin, Kenneth Peirce, Sumit Vakil, John R. Vollbrecht, Jeff Weisberg and Glen Zorn 8.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 Ascend Communications 1678 Broadway Calhoun, Rubens expires September 1998 [Page 30] INTERNET DRAFT March 1998 Ann Arbor, MI 48105-1812 USA Phone: 1-734-647-0417 E-Mail: acr@del.com Calhoun, Rubens expires September 1998 [Page 31]