Individual Contribution Pat R. Calhoun Internet-Draft Sun Microsystems, Inc. Category: Standards Track Stephen Farrell <draft-ietf-aaa-diameter-cms-sec-00.txt> Baltimore Technologies William Bulley Merit Network, Inc. June 2001 Diameter CMS Security Application Status of this Memo 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. Distribution of this memo is unlimited. Copyright (C) The Internet Society 2001. All Rights Reserved. Abstract The Diameter base protocol leverages either IPsec or TLS for integrity and confidentiality between two Diameter peers, and allows the peers to communicate through relay and proxy agents. Relay agents perform message routing, and other than routing AVPs, do not modify Diameter messages. Proxy agents, on the other hand, implement policy enforcement, and actively modify Diameter messages. Calhoun, Bulley, Farrell expires December 2001 [Page 1]
Internet-Draft June 2001 This Diameter application describes how a security association is established by two peers through agents, and how authentication and confidentiality is achieved using a mixture of symmetric and asymmetric transforms, by encapsulating Cryptographic Message Syntax (CMS) data within AVPs. CMS is also used to carry X.509 certificates. Table of Contents 1.0 Introduction 1.1 Establishing Security Relationship through relay agents 1.2 Establishing Security Relationship through proxy agents 1.3 Using Redirector agents in lieu of DSA 1.4 When to use DSAs 1.5 Who can authorize users 1.6 Requirements language 1.7 Advertising application support 2.0 AVP Format 3.0 Key Management 3.1 Usage Scenario 3.2 Certificate Requirements 3.3 Algorithms 3.4 Reuse of CMS Content Encryption Keys 4.0 Command-Codes Values 4.1 Diameter-Security-Association-Request 4.2 Diameter-Security-Association-Answer 4.3 Proxy-Diameter-Security-Association-Request 4.4 Proxy-Diameter-Security-Association-Answer 5.0 Diameter Security Association Message Flow 6.0 Diameter Security AVPs 6.1 CMS-Signed-Data AVP 6.2 CMS-Encrypted-Data AVP 6.3 CMS-Cert AVP 6.4 Local-CA-Info AVP 6.4.1 CA-Name AVP 6.4.2 Key-Hash AVP 6.5 OCSP-Nonce AVP 6.6 AAA-Server-Certs AVP 6.7 OCSP-Responses AVP 6.8 CA-Chain AVP 6.9 Expected-Signed-AVP AVP 6.10 Expected-Encrypted-AVP AVP 6.11 AVP-Code AVP 6.12 OCSP-Request AVP 6.13 DSAR-Target-Domain AVP 7.0 Result-Code AVP Values 7.1 Transient Failures 7.2 Permanent Failures Calhoun, Bulley, Farrell expires December 2001 [Page 2]
Internet-Draft June 2001 8.0 IANA Considerations 8.1 Command Codes 8.2 AVP Codes 8.3 Result-Code AVP Values 8.4 Application Identifier 8.5 OCSP-Request AVP Values 9.0 Security Considerations 10.0 References 11.0 Acknowledgements 12.0 Authors' Addresses 13.0 Full Copyright Statement 14.0 Expiration Date Calhoun, Bulley, Farrell expires December 2001 [Page 3]
Internet-Draft June 2001 1.0 Introduction The Diameter base protocol [1] leverages either IPsec or TLS for integrity and confidentiality between two Diameter peers. However, the Diameter protocol also allows peers to communicate through relay and proxy agents, and in such environments security information is lost at each agent. Relay agents perform message routing, and other than routing AVPs, do not modify Diameter messages. Proxy agents, on the other hand, implement policy enforcement, and actively modify Diameter messages. See [1] for a more comprehensive definition of the role of relay and proxy agents. 1.1 Establishing Security Relationship through relay agents The ROAMOPS Working Group has defined a set of requirements in [10] to allow for Diameter peers to communicate securely through Relay agents. This requirement calls for AVP integrity and confidentiality between two peers communicating through Relay agents. Figure 1 provides an example of two Diameter peers establishing a Diameter Security Association (DSA) through Relay agents. The participants of a DSA are the peers where the DSA setup messages terminate. In this example, the participants of the DSA would the NAS (access device), and the Home Server. mno.net mno.net xyz.net abc.com +------+ <----> +------+ <----> +------+ <----> +------+ | | TLS |Relay | IPSec |Relay | IPSec | Home | | NAS | | | | | | | | | | 1 | | 2 | |Server| +------+ +------+ +------+ +------+ <--------------------------------------------> Diameter Security Association Figure 1: Diameter Security Association When one or more agents are used between two communicating Diameter peers, the use of hop-by-hop security mechanisms (e.g. TLS, IPSec) is unsuitable, since Diameter messages are processed at the application layer at each agent. Therefore, an alternative mechanism is required to protect portions of the message at the application layer. Allowing for a security association to be established through Diameter relays allows the participants of the DSA to detect whether protected AVPs have been modified en-route, and hides sensitive data Calhoun, Bulley, Farrell expires December 2001 [Page 4]
Internet-Draft June 2001 from intermediate agents. Furthermore, the Mobile IP and NASREQ Working Groups have stated in [6, 7, 8] that non-repudiation of Diameter data, such as Accounting related AVPs, is necessary. Figure 2 provides an example of a message sent by an access device (NAS), through Diameter relay agents, to its intended destination, the home server. In this example, Relay 2 modifies the contents of the foo AVP, perhaps due to mis-configuration, or maliciously. This specification would allow the participants of the DSA to detect such a problem, as long as the AVP being modified was protected. (Request) (Request) (Request) [AVP(foo)=x] [AVP(foo)=x] [AVP(foo)=y] +------+ -----> +------+ -----> +------+ -----> +------+ | | |Relay | |Relay | | Home | | NAS | | | | | | | | | | 1 | | 2 | |Server| +------+ <----- +------+ <----- +------+ <----- +------+ (Answer) (Answer) (Answer) [AVP(foo)=b] [AVP(foo)=b] [AVP(foo)=a] Figure 2: Diameter agent modifying AVP This document defines the Diameter commands that are used to establish a DSA through Diameter agents, and specifies how encapsulating CMS objects [3] in Diameter AVPs can provide authentication, integrity and confidentiality. The CMS object MAY also be used to transport X.509 certificates and revocation lists. Establishing a DSA through relay agents requires that the initiator issue a Diameter Security Association Request (DSAR) message. In the example provided in figure 1, NAS would issue the DSAR with the Destination-Realm AVP set to abc.com. The Home Server would process the request, and respond by issuing a Diameter Security Association Answer (DSAA) message. If the DSAA message contains a Result-Code indicating success, the DSA is established between the NAS and the home server. Once the DSA is established, the participants MAY apply digital signatures to protect one or more AVP within a message. In the example provided in Figure 2, the Foo AVP would be protected by the digital signature, and any modification of the AVP by the relay agents, would be detected when the signature validation algorithm would fail by either participant. 1.2 Establishing Security Relationship through proxy agents Calhoun, Bulley, Farrell expires December 2001 [Page 5]
Internet-Draft June 2001 As previously discussed, proxy agents typically modify Diameter messages to implement policy enforcement. An example of a proxy server would be an aggregating server, which typically sits one Diameter hop away from the access device, and enforces policy in order to protect the access device from receiving AVPs that could cause harm (e.g. excessive number of filters, unsupported tunneling protocol). Although in theory such checks could be performed on the access device, these devices are typically embedded systems, and not easily configurable. The proxy agent's behavior, on the other hand, is typically under control of the network operator. Diameter messages between two participants of a DSA would fail authentication if a proxy agent were to modify any protected AVPs. Therefore proxy agents MUST NOT permit DSAs to be established through it. mno.net mno.net xyz.net abc.com +------+ +------+ +------+ +------+ | | |Proxy | |Relay | | Home | | NAS | | | | | | | | | |Agent | |Agent | |Server| +------+ +------+ +------+ +------+ -------------> (DSAR) Destination-Realm = abc.com <------------- (DSAA) Result-Code = DIAMETER_CAN_ACT_AS_CMS_PROXY -------------> (PDSR) ESSR-Target-Domain = abc.com ----------------------------> (DSAR) Destination-Realm = abc.com <---------------------------- (DSAA) Result-Code = DIAMETER_SUCCESS <------------- (PDSA) Result-Code = DIAMETER_SUCCESS Figure 3: Establishing Security through Proxy Agent When an DSAR is received by a proxy agent, it has two options. First, if MAY simply deny all DSA Setup Requests (DSAR) through it by responding with the DSAA Result-Code AVP set to DIAMETER_NO_CMS_THROUGH_PROXY. The access device can then determine whether it is willing to provide service, based on its local policy. Calhoun, Bulley, Farrell expires December 2001 [Page 6]
Internet-Draft June 2001 Alternatively, it MAY reject the DSAR, but set the Result-Code AVP to DIAMETER_CAN_ACT_AS_CMS_PROXY, informing the initiator of the DSAR that it is a proxy agent, but is willing to establish the DSA on its behalf. The DSAA MUST be signed by the proxy agent, and include its certificate, to allow the access device to validate the originator of the DSAA. At this point, the access device MUST determine whether the proxy agent is a trusted agent, and it is willing to allow the agent to provide such service. For instance, the access device MAY be configured to ONLY accept DSAA with this result code from proxy agents within its own domain. Note that an access device MAY be configured to always issue a PDSR to its aggregating proxy, reducing the number of round trips. Similarly, an aggregating proxy MAY be configured to initiate an DSAR regardless of whether a PDSR was sent by the access device. Allowing the first hop agent to use establish the DSA with the home server MAY reduce the current concerns that the cryptographic operations resulting from this specification MAY overburden embedded access devices. 1.3 Using Redirector agents in lieu of DSA When a redirect agent is used, allowing the access device, or first hop relay or proxy agent, to communicate directly with the home server. In such configurations, the hop-by-hop security mechanisms specified in the base protocol MAY be sufficient. However, there are certain business models where signing of select Diameter AVPS (e.g. accounting) MAY be desired. Figure 4 shows an example where the relay agent contacts the redirect agent to retrieve the necessary information for it to communicate directly with the home server. The response from the redirect agent MAY include the certificates of the home servers, encoded within the CMS-Cert AVP. Calhoun, Bulley, Farrell expires December 2001 [Page 7]
Internet-Draft June 2001 +------+ | | | DRD | | | +------+ ^ | 2. Request | | 3. Redirection | | Notification | v +------+ ---------> +------+ <--------> +------+ | | 1. Request | | 4. DSAR/DSAA | | | NAS | | DRL | | HMS | | | 6. Answer | | 5. Request/Answer | | +------+ <--------- +------+ <--------> +------+ mno.net mno.net abc.com Figure 4: DSA Setup following redirect The CMS specification allows for Diameter AVPs to be countersigned, which MAY prove useful in business models that require both parties to sign accounting data. This scheme provides some assurance that both parties agreed to the accounting data, which MAY be used for settlement purposes. 1.4 When to use DSAs Given that asymmetric transform operations are expensive, access devices and/or Diameter agents MAY wish to restrict establishment of a DSA to cases where the participants belong to a different administrative domain. 1.5 Who can authorize users In this specification, we define how a Diameter Security Association is established at the application layer to secure AVPs within a message. However, it is important to note that one of participants of a DSA (specifically the one in the home network) MUST belong to the same realm as the user being authorized. This limitation will prevent bigco.com from authorizing (or rather declining authorization) for users at smallco.com. The realm of the participants is found in the subjectAltName field of the Diameter server's X.509 certificate. 1.6 Requirements language Calhoun, Bulley, Farrell expires December 2001 [Page 8]
Internet-Draft June 2001 In this document, the key words "MAY", "MUST", "MUST NOT", "optional", "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as described in [5]. 1.7 Advertising application support Diameter nodes conforming to this specification MAY advertise support by including the value of two (2) in the Auth-Application-Id or the Acct-Application-Id AVP of the Capabilities-Exchange-Request and Capabilities-Exchange-Answer command [1]. 2.0 AVP Format The Diameter base protocol [1] details the AVP header, which includes the 'P' bit, but does not specify how the 'P' bit is used. The 'P' bit, known as the protected AVP bit, is used to indicate whether the AVP is protected by a digital signature. When set, the AVP is protected and the contents cannot be changed by agents without detection. 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V M P r r r r r| AVP Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vendor-ID (opt) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data ... +-+-+-+-+-+-+-+-+ Figure 5: Diameter AVP Header All Diameter specifications MUST specify whether the 'P' bit can be set or not, as is done in section 4.5 of [1] and section 6 below. AVPs that are designed to be changed at each hop (such as the Proxy- Info AVP) MUST NOT allow the 'P' bit to be set. 3.0 Key Management For DSA origin authentication, CMS itself already provides sufficient key management without the need for additional specification. Basically, the originating Diameter node signs and includes whatever certificates are necessary for validation of the digital signature. Calhoun, Bulley, Farrell expires December 2001 [Page 9]
Internet-Draft June 2001 However, for encryption of AVPs more work is needed. In order to be able to encrypt AVPs for a recipient, the originating Diameter node must have a copy of the recipient's public key. There are many well- known key retrieval schemes (e.g. using LDAP [16]), however, in order to simplify Diameter implementations a specific Diameter key distribution mechanism is defined here. Another issue that must be addressed is how a Diameter node is to "know" that certain AVPs are required to be secured within CMS objects. This is communicated in the Diameter Security Association Request/Answer messages, listed in section 4.0. Finally, this section addresses the certificate profile to be used for this Diameter application, which is a simplified profile of [4]. 3.1 Usage Scenario When a Diameter node is about to send a message, it must determine whether a DSA should be established or not. We assume the Diameter node knows the user's realm, perhaps through the User-Name AVP. In the present discussion we assume that the Diameter node has not cached any information. Where information can be cached this is noted. We use Diameter Security Association Request (DSAR) and Diameter Security Association Answer (DSAA) messages to establish a DSA, which specifies which AVPs should be authenticated and/or encrypted, as well as which public key(s) to use. The originating node sends the DSAR message to a server in the destination realm. The DSAR message contains: - the realm part of the user's NAI - the list of direct trust CA's that the originating Diameter node has configured into it for certificate validation. A "direct trust" CA is one that the node is willing to use as the "top" of a certificate chain, sometimes confusingly known as a "root CA." - a list of AVPs that expected to be protected (and how) for this realm - (optionally) a flag indicating that the originating Diameter node wishes to receive certificate status information (using OCSP messages) in which case a nonce to be used by the destination Diameter node in OCSP requests MAY also be supplied. See [9] for details of the certificate status protocol and messages. Calhoun, Bulley, Farrell expires December 2001 [Page 10]
Internet-Draft June 2001 The destination node returns the DSAA message which contains: - TTL for this SA (seconds) - a chain of CA certificates (possibly empty) - public key certificates for the AAA servers in the realm, all of which MUST validate up to one of the CA's contained in the ESSR message, via the chain of CA certificates above; - a list of AVPs that expected to be protected (and how) for this realm - (optionally, if nonce received and OCSP supported) a list of OCSP responses for the certificates in question, each of which uses the nonce from the ESSR message [Issue: If one OCSP responder is used, do we need to append to the nonce for each request?] The originating Diameter node now has to check the response. Any failure results in error messages and auditing and not sending the Diameter message. Checks: - the certificate chain selected is cryptographically correct, passes the (relevant parts of the) rfc2459 path validation algorithm and terminates at a CA mentioned in the DSAR message - the realm part of the user's NAI must occur as a subjectAltName (with the dNSName option) in the AAA server's certificate. This dNSName MUST be of the form "Diameter-<XXX>.<domain>" where <domain> is the FQDN's domain component and <XXX> can be anything (e.g. "Diameter-1.baltimore.com", "Diameter- west.sun.com") chosen by the AAA server administrator. - the DSAA message MUST be digitally signed and the signature MUST be validated and the signer's certificate chain MUST terminate as a CA mentioned in the DSAR message If certificate status (revocation) is an issue for the Diameter node, then the DSAR message MAY contain a nonce value. The idea is that the sender of the DSAA makes OCSP requests on behalf of the Diameter node and returns the OCSP responses to the Diameter node as part of the DSAR message. The use of the nonce value ensures that the sender of the DSAA cannot return cached or otherwise fake OCSP responses to the Diameter node. The nonce value is to be (the beginning of) the nonce in the OCSP response. [Issue The reason for "beginning" above is that an OCSP responder might produce an error if presented with the same Calhoun, Bulley, Farrell expires December 2001 [Page 11]
Internet-Draft June 2001 nonce more than once.] The DSAR MAY be signed. If the originating node has a private key and protection expectations for AVPs are specified, then the DSAR SHOULD be signed. The DSAA MUST be signed by a Diameter agent or server within the user's realm, to prevent an intermediate node from modifying the protection expectations for AVPs. If confidentiality or digital signature is required, then the originating node prepares the CMS related AVPs as required. 3.2 Certificate Requirements Certificates used for the purposes of Diameter MUST conform to the PKIX profile [4], and MUST also include a Diameter node's FQDN, which is typically added in the Host-Name AVP [1], as one of the values of the subjectAltName extension of the Certificate. The FQDN is to be encoded as an dNSName within the subjectAltName. For Diameter nodes (capable of acting as recipients for confidentiality), the FQDN MUST be of the form "Diameter- <xxx>.<realm>". Other Diameter nodes MAY use this naming scheme. Note that this naming constraint is for PKI purposes only, and in no way restricts a Diameter's host name. These names are used for two purposes: 1. Where a Diameter node is verifying a signature it needs to be able to compare the identity of the signer against the identity in the Host-Name AVP. 2. Where a Diameter node is encrypting AVPs, it needs to be able to ensure that it uses a public key for the intended recipient. This requires comparing the identity in a Certificate against the FQDN of the intended recipient (which is assumed to be known). In either case, the presence of the required FQDN as an dNSName value in the subjectAltName extension of a verified public key certificate satisfies the matching requirement. Note that there MAY also be other values in the subjectAltName extension, (either using dNSName or other elements of the CHOICE), these can be safely ignored, but implementations MUST be able to handle their presence. Calhoun, Bulley, Farrell expires December 2001 [Page 12]
Internet-Draft June 2001 Note also that the PKIX profile [4], section 4.1.2.6, specifies the rules for the relationship between the subjectAltName extension and the subject field of public key certificates. [Issue: Future versions of this draft may specify a restricted profile of [4] in order to simplify implementation.] 3.3 Algorithms For all uses of CMS in this specification the mandatory to implement algorithms are as follows: - Asymmetric: RSA - Hashing: SHA-1 - Signature: RSAwithSHA1 - Symmetric Encryption: 3DES At some point in future, AES will replace 3DES. 3.4 Reuse of CMS Content Encryption Keys Once a CMS-Encrypted-Data AVP has been exchanged between two Diameter peers, then they share a symmetric cryptographic key (the content encryption key) which can be used to encrypt further Diameter AVPs between the peers by using the scheme specified in [15]. The peers MUST first take part in an DSAR/DSAA exchange in order to distribute the required asymmetric keys. Note that the use of symmetric keys does not provide "non- repudiation". [15] leaves open some issues, namely how to handle loss of a shared secret (say following a peer re-boot) and for how long to continue to use a shared secret (the maximum number of decryptions required). Where a Diameter node receives a CMS-Encrypted-Data AVP, but doesn't have the required shared secret, that node should return the DIAMETER_KEY_UNKNOWN error message. The peer may then use the DSAR/DSAA exchange to rebuild their Diameter security association. [ed: removed the text on using a cached asymmetric key to re- establish the SA, since it really wasn't clear how that would work] In [15], the default value for the maximum number of decryptions allowed (CEKMaxDecrypts) when re-using a content encryption key is 100. In general this default SHOULD be used, but if a Diameter node "knows" that more than one CMS-Encrypted-Data AVP will be exchanged Calhoun, Bulley, Farrell expires December 2001 [Page 13]
Internet-Draft June 2001 between the nodes (based on the Expected-Encrypted-AVP settings exchanged during the DSAR/DSAA exchange) then the CEKMaxDecrypts setting MAY be set higher. Diameter nodes MUST be able to support a maxDecrypts setting of 1000. [Issue: Are there reasonable expectations for the highest MUST support for maxDecrypts? Does the CMS protocol allow for time based expiration as opposed to number of encryptions?] 4.0 Command-Codes Values This section defines new Command-Code [1] values that MUST be supported by all Diameter implementations that conform to this specification. The following Command Codes are currently defined in this document: Command-Name Abbrev. Code Reference -------------------------------------------------------- Diameter-Security- DSAR 304 4.1 Association-Request Diameter-Security- DSAA 304 4.2 Association-Answer Proxy-Diameter-Security- PDSR 305 4.3 Association-Request Proxy-Diameter-Security- PDSA 305 4.4 Association-Answer 4.1 Diameter-Security-Association-Request The Diameter-Security-Association-Request command, indicated by the Command-Code field set to 304 and the 'R' bit set in the message flags field, is sent by a Diameter node to establish a Diameter Security Association. Message Format Calhoun, Bulley, Farrell expires December 2001 [Page 14]
Internet-Draft June 2001 <DSAR> ::= < Diameter-Header: 304, REQUEST > { Origin-Host } { Origin-Realm } { Destination-Realm } + { Local-CA-info } { Auth-Application-Id } * { OCSP-Request } [ Destination-Host ] * [ Expected-Signed-AVP ] * [ Expected-Encrypted-AVP ] * [ OCSP-Nonce ] 0*1[ CMS-Signed-Data ] [ Origin-State-Id ] * [ AVP ] * [ Proxy-Info ] * [ Route-Record ] 4.2 Diameter-Security-Association-Answer The Diameter-Security-Association-Answer command, indicated by the Command-Code field set to 304, with the 'R' bit in the Command Flags cleared, in response to a DSAR. Message Format <DSAA> ::= < Diameter-Header: 304 > { Origin-Host } { Origin-Realm } 0*1{ CA-Chain } + { AAA-Server-Certs } * { OCSP-Responses } { Destination-Host } { Auth-Application-Id } * [ Expected-Signed-AVP ] * [ Expected-Encrypted-AVP ] [ CMS-Signed-Data ] [ Origin-State-Id ] * [ AVP ] * [ Proxy-Info ] * [ Route-Record ] 4.3 Proxy-Diameter-Security-Assocation-Request The Proxy-Diameter-Security-Association-Request command, indicated by the Command-Code field set to 305 and the 'R' bit set in the Command Flags field, is sent by a Diameter node to request that a downstream Calhoun, Bulley, Farrell expires December 2001 [Page 15]
Internet-Draft June 2001 proxy establishes an Security Association with a server in a given domain on its behalf. Message Format <PDSR> ::= < Diameter-Header: 304, REQUEST > { Origin-Host } { Origin-Realm } { Destination-Realm } { Auth-Application-Id } { DSAR-Target-Domain } 0*1[ CMS-Signed-Data ] [ Origin-State-Id ] * [ AVP ] * [ Proxy-Info ] * [ Route-Record ] 4.4 Proxy-Diameter-Security-Association-Answer The Proxy-Diameter-Security-Association-Answer command, indicated by the Command-Code field set to 305 and the 'R' bit cleared in the Command Flags field, is sent by a Diameter node in response to an PDSR message. Message Format <PDSA> ::= < Diameter-Header: 304 > { Origin-Host } { Origin-Realm } { Destination-Host } { Auth-Application-Id } * [ Expected-Signed-AVP ] * [ Expected-Encrypted-AVP ] 0*1[ CMS-Signed-Data ] [ Origin-State-Id ] * [ AVP ] * [ Proxy-Info ] * [ Route-Record ] 5.0 Diameter Security Association Message Flow This section contains an example of a NAS in domain xyz.com, communicating with its local relay agent, which in turn communicates with a server in ABC.COM's network. In the following example, once the initial capabilities exchange is complete, the NAS receives a request for access from alice@abc.com, which causes the DSA setup to Calhoun, Bulley, Farrell expires December 2001 [Page 16]
Internet-Draft June 2001 be initiated, followed by the application-specific authentication request. Although the example doesn't specifically use bi-directional CMS authentication and encryption, this feature is supported. +-------+ +-------+ +---------+ | NAS | | Relay | | abc.com | | | | Agent | |Home Srv | +-------+ +-------+ +---------+ | | | |CER apps 1, 2 | | (a) |------------------->| | |CAA apps -1 | | (b) |<-------------------| | | . |CER apps 1, 2 | (c) | |<-------------------| | |CEA apps -1 | (d) | |------------------->| ->| User alice@abc.com | | (e) | Requests Access | | | | | | DSAR | | | Dest-Realm=abc.com | | | CMS-Cert | | (f) |--------------------+------------------->| | | DSAA | | | Origin-Host=foo | | | CMS-Cert | (g) |<-------------------+--------------------| | Auth-Request + | | | CMS-Signed-Data | | | Dest-Host=foo | | (h) |--------------------+------------------->| | | Auth-Answer + | | | CMS-Encrypted-Data | (i) |<-------------------+--------------------| Figure 6: Example of a DSA Setup (a) NAS sends a CER message to its relay agent indicating that it supports applications 1 (NASREQ) and 2 (CMS Security). (b) The proxy server sends a CEA message to the NAS indicating that it is a relay supporting all Diameter applications. (c) ABC.COM's Home Server sends a CER message to a proxy server indicating that it supports applications 1 (NASREQ) and 2 (CMS Security). Calhoun, Bulley, Farrell expires December 2001 [Page 17]
Internet-Draft June 2001 (d) The proxy server sends a CEA message to ABC.COM's Home Server indicating that it is a relay supporting all Diameter applications. (e) The NAS receives a request for access from a user (alice@abc.com). (f) The NAS issues an DSAR message, with the Destination-Realm AVP set to abc.com, and its certificate in the CMS-Cert AVP. The DSAR includes the set of AVPs that the NAS expects to be encrypted, in the event that the home server returns messages that contain these AVPs. (g) ABC.COM's Home Server processes the DSAR message, and replies with the DSAA message. The DSAA also includes the set of AVPs that the home server is expecting to be authenticated, as well as its certificate in the CMS-Cert AVP. (h) The NAS issues an authentication request with the Destination-Host AVP set to the value of the Origin-Host AVP in the DSAA. The message includes the CMS-Signed-AVP, which authenticates the AVPs that were requested by the Home Server in the DSAA. (i) The Home Server successfully authenticates the user, and returns a reply, which includes the CMS-Encrypted-Data AVP, whose contents include the AVPs that were specified by the NAS in the DSAR. 6.0 CMS Security AVPs This section contains AVPs that are used to establish a Diameter Security Association, and to transport CMS objects. Calhoun, Bulley, Farrell expires December 2001 [Page 18]
Internet-Draft June 2001 +---------------------+ | AVP Flag rules | |----+-----+----+-----|----+ AVP Section | | |SHLD| MUST|MAY | Attribute Name Code Defined Value Type |MUST| MAY | NOT| NOT|Encr| -----------------------------------------|----+-----+----+-----|----| AAA-Server-Certs 351 6.6 OctetString| M | P | | V | N | AVP-Code 352 6.11 Unsigned32 | M | P | | V | N | CA-Chain 353 6.8 OctetString| M | P | | V | N | CA-Name 349 6.4.1 OctetString| M | P | | V | N | CMS-Cert 354 6.3 OctetString| M | | | P,V | N | CMS-Encrypted- 355 6.2 OctetString| M | P | | V | N | Data | | | | | | CMS-Signed-Data 310 6.1 OctetString| M | | | P,V | N | Key-Hash 350 6.4.2 OctetString| M | P | | V | N | DSAR-Target- 360 6.13 OctetString| M | P | | V | N | Domain | | | | | | Expected-Signed- 356 6.9 Grouped |M,P | | | V | N | AVP | | | | | | Expected- 357 6.10 Grouped |M,P | | | V | N | Encrypted-AVP | | | | | | Local-CA-Info 348 6.4 Grouped | M | P | | V | N | OCSP-Nonce 358 6.5 OctetString| M | P | | V | N | OCSP-Request 361 6.12 Unsigned32 | M | P | | V | N | OCSP-Responses 359 6.7 OctetString| M | P | | V | N | 6.1 CMS-Signed-Data AVP The CMS-Signed-Data AVP (AVP Code 310) is of type OctetString and contains the Basic Encoding Rules (BER) encoding of a CMS object [3] of type ContentInfo. The profile of CMS algorithm and structure usage is as specified in the S/MIME v3 message specification [11]. This means that where a set of AVPs is protected using CMS, the set MUST first be encoded according to MIME encoding rules specified below. This method of encapsulating AVPs allows existing S/MIME toolkits to be used without changes in order to provide authentication within the Diameter application layer. To package a set of AVPs as a MIME type, AVPs with the 'P' bit are first concatenated in the order in which they occur in the Diameter message, including padding. The result is used as input into the signing process. Note that the AVPs themselves are not encapsulated within the CMS-Signed-Data AVP. Instead, the digest value within the SignedData structure contains the digest produced in the signature process. Multiple Diameter entities MAY add their signatures to an existing Calhoun, Bulley, Farrell expires December 2001 [Page 19]
Internet-Draft June 2001 CMS-Signed-Data AVP using the countersignature attribute, defined in section 11.4 of [3]. The countersignature attribute requires that the signatures occur sequentially, meaning that each signature covers the existing signatures in the CMS object. The initial signature, and any additional countersignatures, MUST cover the exact same set of AVPs, in the order they are present in the message. Note that the CMS-Signed-Data AVP MUST NOT be used in the generation of the signature, and therefore MUST NOT have its 'P' bit set. If a receiver detects that the contents of the CMS-Signed-Data AVP are invalid, it SHOULD return the new Result-Code AVP value defined in section 7.0. When AVPs are to be both encrypted and signed, the CMS-Encrypted-Data AVP MUST be created first. The resulting CMS object MUST then be MIME encoded producing an application/pkcs7-mime MIME type which is then used as the content of the EnvelopedData. This means that signing is "outside" encryption. The eContent field of the EncapsulatedContentInfo structure MUST be absent since the authentication covers data outside of the object. The signature is computed over all AVPs with the 'P' bit enabled. The order of the AVPs MUST be preserved and the computation begins with the first AVP immediately following the Diameter header. If the signature cannot be verified correctly, a response with the Result- Code AVP set to DIAMETER_INVALID_AUTH [1] MUST be returned. No more than one CMS-Signed-Data AVP MUST be present in any given Diameter message. 6.2 CMS-Encrypted-Data AVP The CMS-Encrypted-Data AVP (AVP Code 355) is of type OctetString and contains the Basic Encoding Rules (BER) encoding of a CMS object [3] of type ContentInfo. The entire AVP MUST be input to the encryption process, in network byte order, including any padding. All AVPs to be encrypted are concatenated, and the encryptor is free to order AVPs in whatever way it chooses. The value is then encrypted and used as the value of the EncryptedContent field within CMSEnvelopedData. If a receiver detects that the contents of the CMS-Data AVP is invalid, it SHOULD return the new Result-Code AVP value defined in Calhoun, Bulley, Farrell expires December 2001 [Page 20]
Internet-Draft June 2001 section 7.0. When AVPs are to be both encrypted and authenticated, the CMS- Encrypted-Data AVP MUST be created first. Where AVPs are encapsulated within a CMS-Encrypted-Data AVP, the eContentType of the EncapsulatedContentInfo MUST be id-data [11]. CMS-Encrypted-Data MAY contain more than one CMS object, that is, implementations MUST be able to add a new CMS-Encrypted-Data AVP value and also MUST be able to decrypt all CMS-Encrypted-Data AVP values which are encrypted for them. When a conforming implementation receives a Diameter message which contains encrypted AVPs within a CMS EnvelopedData, the recipient MUST check to see if it is on the list of recipients specified in the RecipientInfos of the EnvelopedData. If not, the recipient MAY choose to process the message or indicate an error. If the recipient is in the RecipientInfos and an error occurs during decryption, then the recipient MUST indicate an error. Diameter nodes SHOULD implement content encryption key re-use (see section 3.4 above). Zero or more CMS-Encrypted-Data AVP MAY be present in any Diameter message. 6.3 CMS-Cert AVP The CMS-Cert AVP (AVP Code 354) is of type OctetString and contains a "certs-only" CMS structure which is a degenerate form of CMS structure containing only PKI related information (see section 3.6 of [11] for details of the CMS certs-only structure). The CMS-Cert AVP contains one or more public key certificates (Certificate) and MAY optionally contains attribute certificates (AttributeCertificate) as allowed by CMS. Other legacy formats supported by CMS MUST NOT be used. Support for use of the Certificate structure is REQUIRED, while implementations MAY support use of the AttributeCertificate structure as defined in the PKIX attribute certificate profile [12]. The latter allows Diameter implementations to include a certificate from a trusted party that they are authorized to emit the AVPs contained in the message. This use of the CMS-Cert AVP can be used to "push" public key and Calhoun, Bulley, Farrell expires December 2001 [Page 21]
Internet-Draft June 2001 attribute certificates and CRLs using Diameter, which MAY be useful in environments where repositories (e.g. LDAP servers) are either not used or not available (e.g. due to crossing a domain boundary). Conforming implementations MUST be able to emit a certs-only CMS structure which contains relevant PKI related information and MUST be able to process a CMS-Cert AVP which contains a certs-only CMS structure. Of course, the recipient of such a certs-only CMS structure SHOULD NOT use the PKI related information without first verifying it, e.g. by checking that issuer's are trusted, signatures verify etc. A CRL [4] MAY also be provided in the crls field of the SignedData, which MAY be used to assist in determining whether a certificate has been revoked. Optionally, the Diameter node MAY check the status of certificates using another mechanism, such as Online Certificate Status Protocol (OCSP) [9]. 6.4 Local-CA-Info AVP The Local-CA-Info AVP (AVP Code 348) is of type Grouped. The Grouped Data field has the following ABNF grammar: Local-CA-Info ::= < AVP Header: 348 > { CA-Name } { Key-Hash } 6.4.1 CA-Name AVP The CA-Name AVP (AVP Code 349) is of type OctetString, encoded in the UTF-8 [24] format. The AVP contains the DN (in LDAP string syntax) of the Certificate Authority, e.g. "CN=CA;O=Baltimore Technologies;C=IE". 6.4.2 Key-Hash AVP The Key-Hash AVP (AVP Code 350) is of type OctetString, and contains a SHA-1 hash of the key. The hash MUST be calculated over the representation of the CA public key which would be present in an X.509 public key certificate, specifically, the input for the hash algorithm MUST be the DER encoding of a SubjectPublicKeyInfo representation of the key. Note: This includes the AlgorithmIdentifier as well as the BIT STRING. The rules given in [4] for encoding keys MUST be followed. Since this AVP is used for indexing and not for security (since Calhoun, Bulley, Farrell expires December 2001 [Page 22]
Internet-Draft June 2001 Diameter nodes SHOULD validate certificates), there is no need to support more than one hash algorithm here. 6.5 OCSP-Nonce AVP The OCSP-Nonce AVP (AVP Code 358) is of type OctetString, and contains a random value (RECOMMENDED 128 bits) generated by the Diameter node. 6.6 AAA-Server-Certs AVP The AAA-Server-Certs AVP (AVP Code 351) is of type OctetString and contains the certificates of the AAA Servers in the home domain. Note: this AVP contains no CA certificates, just those for AAA servers. 6.7 OCSP-Responses AVP The OCSP-Responses AVP (AVP Code 359) is of type OctetString, and contains an OCSP response message from an OCSP responder. If the OCSP-Request AVP indicating a response was required in the corresponding request message, the OCSP-Response AVP MUST be present. Furthermore, the OCSP-Request AVP MAY request a fresh OCSP response message, which MUST also include the OCSP-Nonce AVP. 6.8 CA-Chain AVP The CA-Chain AVP (AVP Code 353) is of type OctetString, and contains a certificate chain, from one of the nominated locally trusted CAs down to the (one and only) CA which has issued the end entity certificates in the AAA-Server-Certs AVP. To produce this AVP in an DSAA message, one (and only one) of the Local-CA-info values from the corresponding DSAR message is selected (call this the "top" CA for the purposes of this description). This AVP then contains a certificate path (in order) from the "top" CA down to the (one and only) CA which has issued all the end entity certificates in the AAA-Servers-AVP. The (typically self-signed), certificate of the "top" CA MAY be included, or MAY be omitted. [Issue: Whether the "top" CA cert should be included or not can be determined later.] Calhoun, Bulley, Farrell expires December 2001 [Page 23]
Internet-Draft June 2001 6.9 Expected-Signed-AVP AVP The Expected-Signed-AVP AVP (AVP Code 356) is of type Grouped. The Grouped Data field has the following ABNF grammar: Expected-Signed-AVP ::= < AVP Header: 356 > { AVP-Code } [ Vendor-Id ] The Expected-Signed-AVP AVP contains an AVP code, which if sent by the peer, MUST be authenticated via the CMS-Signed-Data AVP. Vendor-Specific AVPs are represented by including the optional Vendor-Id AVP. If this AVP is present in the DSAR or DSAA, it MUST be authenticated using the CMS-Signed-Data AVP. 6.10 Expected-Encrypted-AVP AVP The Expected-Encrypted-AVP AVP (AVP Code 357) is of type Grouped. The Grouped Data field has the following ABNF grammar: Expected-Encrypted-AVP ::= < AVP Header: 357 > { AVP-Code } [ Vendor-Id ] The Expected-Encrypted-AVP AVP contains an AVP code, which if sent by the peer, MUST be encrypted in the CMS-Encrypted-Data AVP. Vendor- Specific AVPs are represented by including the optional Vendor-Id AVP. If this AVP is present in the DSAR or DSAA, it MUST be authenticated using the CMS-Signed-Data AVP. 6.11 AVP-Code AVP The AVP-Code AVP (AVP Code 352) is of type Unsigned32, and contains the AVP Code of the AVP that is to be authenticated or encrypted. 6.12 OCSP-Request AVP The OCSP-Request AVP (AVP Code 361) is of type Unsigned32, and specifies whether the sender wishes to receive an OCSP response. The following values are defined: Calhoun, Bulley, Farrell expires December 2001 [Page 24]
Internet-Draft June 2001 NO_OCSP_RESPONSE 0 The sender does not wish to receive an OCSP Response. OCSP_RESPONSE 1 The sender wishes to receive an OCSP Response, and is willing to accept a stale response. OCSP_FRESH_RESPONSE 2 The sender wishes to receive a fresh OCSP Response. When this value is set, the OCSP-Nonce AVP MUST be present. 6.13 DSAR-Target-Domain AVP The DSAR-Target-Domain AVP (AVP Code 360) is of type OctetString, and contains the Destination-Realm of the resulting DSAR sent by a non- transparent proxy. 7.0 Result-Code AVP Values This section defines new Result-Code [1] values that MUST be supported by all Diameter implementations that conform to this specification. 7.1 Transient Failures Errors that fall within the transient failures category are used to inform a peer that the request could not be satisfied at the time it was received, but MAY be able to satisfy the request in the future. DIAMETER_KEY_UNKNOWN 4007 This error code is returned when a CMS-Signed-Data or CMS- Encrypted-Data AVP is received that was generated using a key that is not locally recognized. This error could be caused if one of the participants of a DSA lost a previously agreed upon key, perhaps as a result of a reboot. 7.2 Permanent Failures Errors that fall within the permanent failures category are used to inform the peer that the request failed, and should not be attempted again. DIAMETER_INVALID_CMS_DATA 5018 This error code is returned when a CMS-Data AVP is received Calhoun, Bulley, Farrell expires December 2001 [Page 25]
Internet-Draft June 2001 with an invalid ContentInfo object. DIAMETER_NO_CMS_THROUGH_PROXY 5019 This error code is returned when a non-transparent proxy receives an DSAR message to state that it doesn't allow a DSA through it since it plans to modify AVPs. DIAMETER_CAN_ACT_AS_CMS_PROXY 5020 This error code is returned when a non-transparent proxy receives an DSAR message, and although it doesn't allow a DSA through it, it is willing to initiate a DSA on behalf of the access device. 8.0 IANA Considerations This section contains the namespaces that have either been created in this specification, or the values assigned to existing namespaces managed by IANA. 8.1 Command Codes This specification assigns the value 304 from the Command Code namespace defined in [1]. See section 4.0 for the assignment of the namespace in this specification. 8.2 AVP Codes This specification assigns the values 348-361 from the AVP Code namespace defined in [1]. See section 6.0 for the assignment of the namespace in this specification. 8.3 Result-Code AVP Values This specification assigns the values 4007, 5018-5020 from the Result-Code AVP (AVP Code 268) value namespace defined in [1]. See section 7.0 for the assignment of the namespace in this specification. 8.4 Application Identifier This specification assigns the value two (2) to the Application Identifier namespace defined in [1]. See section 1.6 for more information. Calhoun, Bulley, Farrell expires December 2001 [Page 26]
Internet-Draft June 2001 8.5 OCSP-Request AVP Values As defined in Section 6.12, the OCSP-Request AVP (AVP Code 361) defines the values 0-2. All remaining values are available for assignment via IETF Consensus [12]. 9.0 Security Considerations This document describes how CMS security can be achieved in the Diameter protocol by allowing S/MIME Cryptographic Message Syntax [3] objects to be carried as a Diameter AVP. Section 6.3 states that a certificate received in a CMS-Cert AVP SHOULD NOT be used prior to cert verification. In most cases, the verification will be according to the rules specified in [4], however, some communities have indicated that they wish to be allowed to specify alternative certificate verification mechanisms, hence the "SHOULD NOT" rather than the more typical "MUST NOT". The authors do however strongly RECOMMEND that the verification procedures specified in [4] are always applied, regardless of whatever other verification mechanisms are in use. 10.0 References [1] P. Calhoun, H. Akhtar, J. Arkko, E. Guttman, A. Rubens, "Diame- ter Base Protocol", draft-ietf-aaa-diameter-05.txt, IETF work in progress, June 2001. [2] Kaufman, Perlman, Speciner, "Network Security: Private Communi- cations in a Public World", Prentice Hall, March 1995, ISBN 0- 13-061466-1. [3] R. Housley, "Cryptographic Message Syntax", RFC 2630, June 1999. [4] Housley, Ford, Polk, Solo, "Internet X.509 Public Key Infras- tructure Certificate and CRL Profile", RFC 2459, January 1999. [5] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [6] M. Beadles, D. Mitton, "Criteria for Evaluating Network Access Server Protocols", draft-ietf-nasreq-criteria-05.txt, IETF work in progress, June 2000. [7] T. Hiller et al., "Cdma2000 Wireless Data Requirements for AAA", Calhoun, Bulley, Farrell expires December 2001 [Page 27]
Internet-Draft June 2001 draft-hiller-cdma2000-AAA-02.txt, IETF work in progress, Sep- tember 2000. [8] S. Glass, S. Jacobs, C. Perkins, "Mobile IP Authentication, Authorization, and Accounting Requirements". RFC 2977. October 2000. [9] Myers, Ankney, Malpani, Galperin, Adams, "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol (OCSP)", RFC 2560, June 1999. [10] Aboba, Zorn, "Criteria for Evaluating Roaming Protocols", RFC 2477, January 1999. [11] B. Ramsdell, "S/MIME v2 Message Specification", RFC2633, June 1999. [12] S. Farrell, R. Housley, "An Internet Attribute Certificate Pro- file for Authorization", draft-ietf-pkix-ac509prof-06.txt, IETF work in progress, January 2001. [13] P. Calhoun, W. Bulley, G. Zorn, "Diameter NASREQ Application", draft-ietf-aaa-Diameter-nasreq-05.txt, IETF work in progress, June 2001. [14] P. Calhoun, C. Perkins, "Diameter Mobile IP Application", draft-ietf-aaa-Diameter-mobileip-05.txt, IETF work in progress, June 2001. [15] Farrell, Turner, "Reuse of CMS Content Encryption Keys", draft- ietf-smime-rcek-02.txt, IETF work in progress, May 2001. [16] Boyen, Howes, Richard, "Internet X.509 Public Key Infrastructure Operational Protocols - LDAPv2", RFC 2559, April 1999. 11.0 Acknowledgements The authors would also like to acknowledge the following people for their contribution in the development of this specification: Bernard Aboba, Jari Arkko and Steven Bellovin 12.0 Authors' Addresses Questions about this memo can be directed to: Calhoun, Bulley, Farrell expires December 2001 [Page 28]
Internet-Draft June 2001 Pat R. Calhoun Network and Security Research Center, Sun Labs 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 Stephen Farrell Baltimore Technologies 39 Parkgate Street, Dublin 8, IRELAND Phone: +353-1-881-6000 Fax: +353-1-881-7000 E-Mail: stephen.farrell@baltimore.ie William Bulley Merit Network, Inc. Building One, Suite 2000 4251 Plymouth Road Ann Arbor, Michigan, 48105-2785 USA Phone: +1 734-764-9993 Fax: +1 734-647-5185 E-mail: web@merit.edu 13.0 Full Copyright Statement Copyright (C) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restric- tion of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this docu- ment itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Inter- net organizations, except as needed Calhoun, Bulley, Farrell expires December 2001 [Page 29]
Internet-Draft June 2001 for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards pro- cess must be followed, or as required to translate it into languages other than English. The limited permis- sions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information con- tained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRAN- TIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WAR- RANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 14.0 Expiration Date This memo is filed as <draft-ietf-aaa-diameter-cms-sec-00.txt> and expires in December 2001. Calhoun, Bulley, Farrell expires December 2001 [Page 30]
