Internet Draft Jesse Walker Expiration: December 2000 Intel File: draft-jwalker-cops-cms-00.txt CMS over COPS Last Updated: May 31, 2000 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. To view the entire list of current Internet-Drafts, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). Copyright (C) The Internet Society (2000). All Rights Reserved. Abstract This memo describes how to use TLS to secure COPS connections over the Internet. Please send comments on this document to the rap@iphighway.com mailing list. 1. Introduction COPS [RFC2748] was designed to distribute cleartext policy information from a centralized Policy Decision Point (PDP) to a set of Policy Enforcement Points (PEP) in the Internet. COPS has native security mechanisms to protect the per-hop integrity of the deployed policy. However, COPS has no end-to-end integrity mechanism, and it offers no way to protect the long-term integrity of policy cached at a PEP. Walker et al. [Page 1] Internet Draft CMS Over COPS May 2000 CMS [CMS] was designed to provide a general security encapsulation mechanism, within the context of store-and-forward systems such as e- mail. As such, it is well suited to the end-to-end integrity problem. This document describes how to use CMS over COPS to provide end-to- end security features. This is abbreviated CMS/COPS. 1.1. Requirements Terminology Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and "MAY" that appear in this document are to be interpreted as described in [RFC2119]. 2. Certificate Requirements Certificates used by COPS itself MUST conform to the PKIX profile [PKIX]. CMS/COPS implementations MUST be PKIX clients, and MUST support a secure mechanism to acquire the root certificate authorities for any certificate chains they consume. If a subjectAltName extension of type dNSName or iPAddress is present in the certificate, that MUST be used as the server identity. Otherwise, the most specific Common Name attribute in the Subject attribute of the certificate MUST be used. Matching is performed using the matching rules specified by [PKIX]. If more than one identity of a given type is present in the certificate (e.g. more than one dNSName name, a match in any one of the set is considered acceptable.), the client uses the first name to match. Names may contain the wildcard character * which is considered to match any single domain name component or component fragment. E.g. *.a.com matches foo.a.com but not bar.foo.a.com. f*.com matches foo.com but not bar.com. In some cases the information identifying the COPS will only be an IP address. In this case, the subjectAltName MUST be present in the certificate, and it MUST include an iPAddress format matching the expected name of the PEP. 3. CMS Object Encapsulation within COPS CMS objects transferred from client to server (PEP to PDP) are encapsulated in a COPS ClientSI object with C-Type=3. CMS objects transferred from server to client (PDP to PEP) are encapsulated in a COPS Decision object with C-Type=6. The data encapsulated must conform to the COPS for Provisioning specification [COPSPR]. The type of CMS object transported in either of these two encapsulations is the DER encoding of a CMS object of type ContentInfo. See [CMS]. 4. PIB Object Encapsulation within CMS Sometimes it is necessary to transfer signed information between client and server, e.g., so that an audit of already distributed Walker et al. Expires December 2000 [Page 2] Internet Draft CMS Over COPS May 2000 policy can identify the issuer, or provide long term integrity protection on cached objects, or some similar function. In this type of circumstance, the signature is part of the policy, not the transport protocol used to convey the information between the client and server. COPS uses CMS objects to provide this and other end-to- end security functions. This section defines the encoding of [COPSPR] defined objects (herein referred to as PIB objects) within a CMS object. 4.1. PIB Objects The Encapsulated-PIBList object is used to encapsulate COPS PIB objects into a CMS of type ContentInfo. This type of a body is identified by id-cops-encap-pib-list OBJECT IDENTIFIER ::= { xxxx x } The ASN.1 structure corresponding to this new content type is Encapsulated-PIBList ::= SEQUENCE { encapsulatedItem SEQUENCE OF SIZE(0..MAX) OF COPSObject } COPSObject ::= CHOICE { rule PIBProvisioningRuleId, prefix PIBProvisioningPrefixId, instance PIBProvisioningInstance, pGError PIBGlobalProvisioningError, pCError PIBClassProvisioningError } PIBSelector ::= INTEGER(0..255) PIBProvisioningRuleId ::= SEQUENCE { sNum PIBSelector, sType PIBSelector, policyRuleId OBJECT IDENTIFIER } PIBProvisioningPrefixId ::= SEQUENCE { sNum PIBSelector, sType PIBSelector, prefixId OBJECT IDENTIFIER } PIBProvisioningInstance ::= SEQUENCE { sNum PIBSelector, sType PIBSelector, value OCTET STRING -- Or EXPLICIT SEQUENCE Defined by PIB } PIBGlobalProvisioningError ::= SEQUENCE { Walker et al. Expires December 2000 [Page 3] Internet Draft CMS Over COPS May 2000 sNum PIBSelector, sType PIBSelector, eCode PIBCode, eSubCode PIBCode } PIBClassProvisioningError ::= SEQUENCE { sNum PIBSelector, sType PIBSelector, eCode PIBCode, eSubCode PIBCode } PIBCode ::= INTEGER(0..65535) Encapsulated-PIBList objects are DER encoded to conform with CMS. The meaning of the attributes in these objects is the following: encapsulatedItem.This is a sequence of one or more COPS PIB objects. When used for COPS-PR, a CMS object encodes at most one PIBList object. A PIBObject is one of the following object types: rule. This conveys the identity of a policy instance (PRID), encoded as a PIBProvisioningRuleId. prefix. This conveys the prefix of an aggregated family (class) of policy rules, encoded as a PIBProvisioningPrefixId. instance. This encodes the content of a COPS "BER Encoded Policy Instance Data" (EPD) object. pGError. This conveys global provisioning error information, encoded as a PIBGlobalProvisioningError. pCError. This conveys PRC class provisioning error information, encoded as a PIBClassProvisioningError. All the encoded PIB Objects consist of the following attributes: sNum. This is the COPS-PR S-Number of the encoded data, as it appears in a PIB object. This, together with the sType, identifies the COPS message construction being encoded. sType. This is the COPS-PR S-Type of the encoded data, as it appears in a PIB object. This, together with the sNum, identifies the COPS message construction being encoded. Walker et al. Expires December 2000 [Page 4] Internet Draft CMS Over COPS May 2000 PIBProvisioningRuleId consists of the following additional attributes: policyRule.This is the OBJECT IDENTIFIER of the policy rule being communicated. PIBProvisioningPrefixId consists of the following attributes: prefixRule.This is an OBJECT IDENTIFIER identifying a set of policies being provisioned. All rule instances sharing the same prefix are specified by this object. PIBProvisioningInstance consists of the following attributes: value. This is DER encoded data value of a "BER Encoded Policy Instance Data" (EPD) object [COPS-PR]. That is, the COPS- PR PRC value. The PRC value in a COPS-PR message is BER encoded. This ASN.1 data object is then DER encoded as a SEQUENCE for inclusion in the PIBData object, to accommodate the requirements for CMS. PIBGlobalProvisioningError consists of the following attributes: eCode. This is the primary COPS-PR error code. eSubCode. This is the secondary COPS-PR error code (sub-code). PIBClassProvisioningError consists of the following attributes: eCode. This is the primary COPS-PR error code. eSubCode. This is the secondary COPS-PR error code (sub-code). 4.2. CMS Cryptographic Operations The COPS CMS object MAY utilize the SignedData type, EncryptedData type, or both. When using either, the eContent attribute within the encapContentInfo attribute is encoded as defined by Encapsulated- PIBList. Where PIBData are encapsulated within a COPS CMS object, the eContentType of the EncryptedContentInfo MUST be id-data [CMS]. The signing and encryption algorithms supported MUST be those specified in sections 2.2 and 2.3 of [CMS]. A COPS CMS object MAY contain both public key certificates (Certificate) and attribute certificates (AttributeCertificate). Conforming implementations MUST NOT support other legacy certificate formats. Implementations MUST support the Certificate structure, and SHOULD support AttributeCertificate structure as defined in the PKIX attribute certificate profile [PKIX-ATTRIBUTE]. Walker et al. Expires December 2000 [Page 5] Internet Draft CMS Over COPS May 2000 4.3. CMS Object Verification An implementation SHOULD verify the signature of a signed COPS CMS object on receipt. In this case, the eContent attribute of the EncapsulatedContentInfo structure MUST NOT be absent. The signature is computed over the entire Encapsulated-PIBList content of the CMS object. If the signature cannot be verified correctly, a COPS Error object with error code set to CMS Authentication Failure (Error-Code 16) MUST be returned. When an implementation receives a COPS CMS object containing encrypted Encapsulated-PIBList within the CMS EnvelopedData, then 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 MUST indicate an error. If the recipient is in the RecipientInfos and an error occurs during decryption, then the recipient MUST indicate an error. A COPS CMS object MAY also contain a certs-only CMS structure, or a Certificate Management Message structure, both of which are degenerate forms of CMS structure containing only PKI related information. This use of the CMS object thus can be used to "push" public key and attribute certificates and CRLs using COPS, or to support certificate enrollment. This can 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 object containing a certs-only CMS structure. The recipient of such a CMS object MUST NOT use the PKI related information without first verifying it, e.g. by checking that issuer's are trusted, signatures verify, etc. When the CMS object contains certificates in the certificates attribute of the SignedData, a CRL MAY also be provided in the crls attribute of the SignedData. Implementations MAY use such CRLs to assist in determining whether a certificate has been revoked. Optionally, COPS implementations MAY check the status of certificates using another mechanism, such as Online Certificate Status Protocol [OCSP]. 5. Security Considerations This entire document concerns security. 6. Acknowledgements This document is loosely based on [STRONG-CRYPTO] by Pat Calhoun, William Bully, and Stephen Farrell. Discussions with David Durham, Keith McCloghrie, and Ylian Sainte-Hillaire also lead to improvements in this document. 7. References Walker et al. Expires December 2000 [Page 6] Internet Draft CMS Over COPS May 2000 [CMS] R. Housley, "Cryptographic Message Syntax", RFC 2630, June 1999. [COPS] D. Durham, J. Boyle, R. Cohen, S. Herzog, R. Rajan, A. Sastry, " The COPS (Common Open Policy Service) Protocol", RFC 2748, January 2000 [COPSPR] Reichmeyer, F., Herzog, S., Chan, K.H., Seligson, J., Durham, D., Yavatkar, R., Gai, S., McCloghrie, K., Smith, A., "COPS Usage for Policy Provisioning", IETF , March 2000. [PKIX] Housley, Ford, Polk, Solo, "Internet X.509 Public Key Infrastructure Certificate and CRL Profile", RFC 2459, January 1999. [PKIX-ATTRIBUTE] S. Farrell, R. Housley, "An Internet Attribute Certificate Profile for Authorization", draft-ietf-pkix-ac509prof- 03.txt, IETF work in progress, May 2000. [RFC2026] Bradner, S., "The Internet Standards Process - Revision 3", RFC 2026, October 1996 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [STRONG-CRYPTO] draft-calhoun-diameter-strong-crypto-xx.txt 8. Author Addresses Jesse R. Walker Intel Corporation 2111 N.E. 25th Avenue Hillsboro, OR 97214 USA jesse.walker@intel.com 9. Full Copyright Statement Copyright (C) The Internet Society (2000). 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 restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. In addition, the ASN.1 modules presented in Appendices A and B may be used in whole or in part without inclusion of the copyright notice. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process Walker et al. Expires December 2000 [Page 7] Internet Draft CMS Over COPS May 2000 shall be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Walker et al. Expires December 2000 [Page 8]