INTERNET DRAFT Pat R. Calhoun Category: Standards Track Sun Microsystems, Inc. Title: draft-calhoun-diameter-proxy-01.txt William Bulley Date: August 1998 Merit Network, Inc. DIAMETER Proxy Server Extensions Status of this Memo This document is an individual contribution for consideration by the AAA Working Group of the Internet Engineering Task Force. Comments should be submitted to the diameter@ipass.com mailing list. Distribution of this memo is unlimited. This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at: http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at: http://www.ietf.org/shadow.html. Abstract This DIAMETER Extension defines commands and AVPs that are used when DIAMETER messages must be proxied by DIAMETER Servers. This extension is intended to clearly define how proxying can be done with DIAMETER. Calhoun, Bulley expires February 1999 [Page 1] INTERNET DRAFT August 1998 Table of Contents 1.0 Introduction 1.1 Definitions 1.2 Terminology 2.0 Command Codes 2.1 Domain-Discovery-Request (DDR) 2.2 Domain-Discovery-Answer (DDA) 3.0 DIAMETER AVPs 3.1 Proxy-State 3.2 Digital-Signature 3.3 X509-Certificate 3.4 X509-Certificate-URL 3.5 Next-Hop 4.0 Protocol Definition 4.1 Data Integrity 4.1.1 Using Digital Signatures 4.1.1 Using Mixed Data Integrity AVPs 4.2 AVP Data Encryption 4.2.1 AVP Encryption with Public Keys 4.3 Public Key Cryptography Support 4.3.1 X509-Certificate 4.3.2 X509-Certificate-URL 4.3.3 Static Public Key Configuration 5.0 References 6.0 Acknowledgements 7.0 Author's Address 1.0 Introduction Many services, including ROAMOPS and MobileIP, have a requirement for DIAMETER Server to proxy a request to another DIAMETER Server. The concept of proxying AAA requests was introduced by RADIUS and has been in use for many years. Unfortunately due to the fact that RADIUS only supports hop-by-hop security, where each node has a security association with the next hop, this does introduce some security flaws. Specifically a fraudulent proxy server can modify some portions of an AAA request in order to make the next hop improperly believe that some services were rendered. For example, a DIAMETER Proxy Server could modify an accounting request, such as the number of bytes that a user transfered, and the end system would have no way of determining that this change occured. 1.1 Definitions Calhoun, Bulley expires February 1999 [Page 2] INTERNET DRAFT August 1998 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 Command Codes This document defines the following DIAMETER Commands. All DIAMETER implementations supporting this extension MUST support all of the following commands: Command Name Command Code ----------------------------------- Domain-Discovery-Request 261 Domain-Discovery-Answer 262 2.1 Domain-Discovery-Request (DDR) Description The Domain-Discovery-Request message is used by a DIAMETER device wishing to get contact information about a domain's home authentication server as well as to receive password policy information. This message MUST contain the User-Name attribute in order to pass along the user's domain information. It is not necessary for an implementation to issue a DDR in order to make use of a proxy server. Calhoun, Bulley expires February 1999 [Page 3] INTERNET DRAFT August 1998 The X509-Certificate or the X509-Certificate-URL [2] MUST be present in this message in order to inform the home authentication server of the issuing host's certificate. At least one Extension-Id AVP MUST be present in the DDR in order to inform the peer about the locally supported extensions. Message Format ::= [] [] [] { || ::= [] [] [] [] { || +------+ ------> +------+ | | | | | | | NASB +--------------------+ DIA2 +--------------------+ DIA1 | | | | | | | +------+ <----- +------+ <------ +------+ (Answer) (Answer) In this example NASB generates a Request that is forwarded to DIA2. The Request contains a digital signature AVP which "protects" all mandatory (or non-editable) AVPs within the request. All AVPs which may be modified, or removed appear after the digital signature AVP. Once DIA2 receives the request, it MAY authenticate the request to ensure that it was originated by NASB (verifying the signature is not necessary if the link between NASB and DIA2 is secured using IPSEC). The DIA2 Server SHOULD add the Proxy-State AVP, which contains opaque data that MUST be present in the response and is used to identify state information related to the request or response. If the Proxy- State AVP is already present in the request, it MUST be replaced with DIA2's Proxy-State AVP. This means that the Proxy-State AVP cannot be protected end-to-end. The Server MAY also add other new AVPs to the request. All AVPs that are protected by the Digital-Signature MUST have the 'P' bit set, and all AVPs MUST preceed the Digital-Signature AVP. The message is then forwarded towards the DIA1 server. Since all packets between NASB and DIA1 must flow through DIA2, it is not possible to use IPSEC between them, therefore the digital signature must be present within the DIAMETER protocol itself. NASB and DIA1 do not need to validate the digital signature AVP if the link between themselves and DIA2 is secured using IP Security. This mechanism now provides a method for DIA1 to prove that NASB was the initiator of the request (note that DIAMETER also includes a timestap to prevent replay attacks). It also provides a method of ensuring that DIA2 cannot modify any protected AVPs (such as length of call, etc.). In addition, this same mechanism can be used for end-to-end encryption of AVPs. In the case where NASB needs to encrypt an AVP it is done using asymetric encryption using DIA1's public key. This ensures that only DIA1 can decrypt the AVP. An attack has been identified in this proposal which allows a malicous man in the middle attack as shown in the following diagram. Calhoun, Bulley expires February 1999 [Page 13] INTERNET DRAFT August 1998 (Request) (Request) (Request) +------+ -----> +------+ -----> +------+ -----> +------+ | | | | | | | | | NASB +----------+ DIA2 +----------+ DIA3 +----------+ DIA1 | | | | | | | | | +------+ <----- +------+ <----- +------+ <----- +------+ (Answer) (Answer) (Answer) In this example, DIA3 traps packets generated from DIA2 towards DIA1, removes the AVPs added by DIA2 and inserts its own AVPs (possibly by trying to convince DIA1 to pay DIA3 for the services). This attack can be prevented by supporting a new Next-Hop AVP. In this case when NASB prepares a request it inserts a non-editable Next-Hop AVP which contains DIA2's identitity. DIA2 also adds a Next-Hop AVP with DIA1 as the next hop. This mechanism ensures that a man in the middle cannot alter the packet by overriding the previous hop's additions and signature. DIA1 could easily validate the packet's path with the use of the Next-Hop AVPs. 4.2 Domain Discovery The Domain Discovery message set is very useful in determining the Home authentication server, the password policies for the domain, as a mechanism to retrieve a certificate (or a pointer to a certificate). Note that it is not necessary for a host to issue a Domain Discovery in order to make use of a proxy. A DIAMETER Request MAY be proxied by an intermediate server without the knowledge of the client, however the client will be unable to validate any Digital-Signatures if the home authentication server's certificate or public key is not known. The following example shows a case where DIA1 needs to communicate with DIA3. In this example it is necessary to use DIA2 as a proxy in order for both ISPs to communicate. Although this MAY be desireable in some business models, there are cases where it is beneficial to remove the proxy altogether and allow both DIA3 and DIA1 to communicate in a secure fashion. Calhoun, Bulley expires February 1999 [Page 14] INTERNET DRAFT August 1998 (DD-Request) (DD-Request) +------+ -----> +------+ ------> +------+ | | | | | | | DIA1 +--------------------+ DIA2 +--------------------+ DIA3 | | | | | | | +------+ <----- +------+ <------ +------+ (DD-Response) (DD-Response) The way the Domain Discovery works is that prior to sending out an authentication request DIA1 would issue a Domain Discovery message towards DIA2. This message is protected with the digital signature as well as the Next-Hop AVP. DIA2 would then forward the request to DIA3 including the Next-Hop and the digital signature AVP. When DIA3 receives the request, it MUST save the certificate (or the pointer to the certificate) and respond back including the local password policy, DIA3's certificate, its contact information (i.e. IP address) and protect the response with the digital signature. Note that in all cases the TimeStamp AVP is also present to ensure no replay packets are accepted. When DIA2 receives the packet, it must add the Next-Hop AVP as well as the digital signature AVP. When DIA1 receives the packet it then knows a direct route to communicate with DIA3 since the contact information is present in the response. The fact that both DIA1 and DIA3 can now communicate directly allows both peers to use IPSEC to protect the message exchange (it may be desirable to use the Digital-Signature AVP in instances where records of digitally signed packets must be kept). (Request) +------+ -----> +------+ | | | | | DIA1 +--------------------+ DIA3 | | | | | +------+ <----- +------+ (Answer) In addition, the password policy is also present which can indicate whether DIA3 is willing to accept CHAP, PAP or EAP authentication. Note that the Domain-Discovery-Request/Answer MUST include at least one Extension-Id AVP [2]. 4.3 Data Integrity Calhoun, Bulley expires February 1999 [Page 15] INTERNET DRAFT August 1998 This section will describe how data integrity and non-repudiation is achieved using the Digital-Signature AVP. Note that the Timestamp and Nonce AVPs MUST be present in the message PRIOR to the Digital-Signature AVPs discussed in this section. The Timestamp AVP provides replay protection and the Nonce AVP provides randomness. Any AVPs in a message that is not followed by either the ICV or the Digital-Signature AVPs MUST be ignored. 4.3.1 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 protected 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 unprotected fields to zero (0) prior to calculating the signature. The two unprotected fields are the identifier and the length in the DIAMETER header. The following is an example of a message that include end-to-end security: Calhoun, Bulley expires February 1999 [Page 16] INTERNET DRAFT August 1998 ::= [] The AVP Header's 'P' bit is used to identify which AVPs are considered protected when applying a digital signature to a DIAMETER message. Protected AVPs cannot be changed "en route" since they are protected by the Digital Signature AVP. All AVPs added by a DIAMETER entity MUST appear prior to the Digital Signature AVP that is added (with the exception of the Integrity-Check-Vector AVP). However, only AVPs with the 'P' bit set are used in the digital signature calculation. The Next-Hop AVP indicates the intended recipient of the DIAMETER message. When a DIAMETER message is received with a Next-Hop AVP that does not correspond with the Host-IP-Address that follows, the message MUST be considered invalid and MUST be rejected. The Data field of the Digital-Signature AVP contains the RSA/MD5 signature algorithm as defined in [9]. 4.3.2 Using Mixed Data Integrity AVPs The previous sections described the Integrity-Check-Vector and the Digital-Signature AVP. Since the ICV offers hop-by-hop integrity and the digital signature offers end to end integrity, it is possible to use both AVPs within a single DIAMETER message. The following diagram provides an example where DIAMETER Server 1 (DIA1) communicates with DIA3 using Digital-Signatures through DIA2. In this example ICVs are used between DIA1 and DIA2 as well as between DIA2 and DIA3. -----------------------------> +------+ -----> +------+ -----> +------+ | | | | | | | DIA1 +----------+ DIA2 +----------+ DIA3 | | | | | | | +------+ +------+ +------+ Using the previous diagram, the following message would be sent Calhoun, Bulley expires February 1999 [Page 17] INTERNET DRAFT August 1998 between DIA1 and DIA2: ::= [] DIA2)> The following message would be sent between DIA2 and DIA3: ::= [] DIA3)> Note that in the above example messages the ICV AVP appear after the Digital-Signature AVP. This is necessary since DIA2 above removes the ICV AVP (DIA1->DIA2) and adds its own ICV AVP (DIA2->DIA3). The ICVs provide hop-by-hop security while the Digital-Signature provides integrity of the message between DIA1 and DIA3. +------+ -----> +------+ -----> +------+ | | | | | | |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. 4.4 AVP Encryption with Public Keys AVP encryption using public keys is much more complex than the Calhoun, Bulley expires February 1999 [Page 18] INTERNET DRAFT August 1998 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. 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 4.3. The AVP is encrypted in the method described in [9]. 4.5 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: 4.5.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. 4.5.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. Calhoun, Bulley expires February 1999 [Page 19] INTERNET DRAFT August 1998 4.5.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. 5.0 References [1] Rigney, et alia, "RADIUS", RFC-2138, April 1997 [2] Calhoun, Rubens, "DIAMETER Base Protocol", Internet-Draft, draft-calhoun-diameter-05.txt, August 1998. [3] Rivest, Dusse, "The MD5 Message-Digest Algorithm", RFC 1321, April 1992. [4] Kaufman, Perlman, Speciner, "Network Security: Private Communications in a Public World", Prentice Hall, March 1995, ISBN 0-13-061466-1. [5] Krawczyk, Bellare, Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, January 1997. [6] Calhoun, Bulley, "DIAMETER User Authentication Extensions", draft-calhoun-diameter-authen-03.txt, May 1998. [7] Aboba, Beadles "The Network Access Identifier." RFC 2486. January 1999. [8] Aboba, Zorn, "Criteria for Evaluating Roaming Protocols", RFC 2477, January 1999. [9] Kaliski, "PKCS #1: RSA Encryption Version 1.5", Internet- Draft, draft-hoffman-pkcs-rsa-encrypt-03.txt, October 1997. [10] Calhoun, Zorn, Pan, "DIAMETER Framework", draft-calhoun-diameter-framework-02.txt, Work in Progress, December 1998 [11] Aboba, Vollbrecht, "Proxy Chaining and Policy Implementation in Roaming", draft-ietf-roamops-auth-10.txt, Work in Progress, February 1999. 6.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, , Daniel C. Fox, Lol Grant, Nancy Greene, Peter Heitman, Ryan Moats, Victor Muslin, Kenneth Peirce, Allan Rubens, Sumit Vakil, John R. Vollbrecht, Jeff Weisberg and Glen Zorn 7.0 Author's Address Calhoun, Bulley expires February 1999 [Page 20] INTERNET DRAFT August 1998 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-650-786-7733 Fax: 1-650-786-6445 E-mail: pcalhoun@eng.sun.com William Bulley Merit Network, Inc. 4251 Plymouth Road, Suite C Ann Arbor, Michigan, 48105-2785 USA Phone: 1-734-764-9993 Fax: 1-734-647-3185 E-mail: web@merit.edu Calhoun, Bulley expires February 1999 [Page 21]