Network Working Group M. King INTERNET-DRAFT M. Tebo Intended Status: Proposed Standard W. Brown Expires: April 2012 D. Silver C. Louden Protiviti Government Services P. Patterson Carillon Information Security Inc. October 28, 2011 claimSigning Extended Key Usage (EKU) draft-king-pkix-claimsigning-extn-02 Abstract This document specifies an Extended Key Usage (EKU) value which indicates that the certificate holder is authorized to sign security tokens to assert claims, or attributes, about a subject. When a certificate that asserts the claimSigning EKU signs a claim, the owner of the service holding that certificate is asserting that a statement about the subject is true. For example, a IdP secure token service (STS) would use an X.509 certificate containing the claimSigning EKU to sign SAML assertions containing an identifier and attributes about a user. This EKU value would allow for a separation between the designation that a given Identity belongs within a given Federation, and the empowerment of that entity within the federation to sign claims.. This approach allows for greater flexibility for the operators of Federated systems and for Certification Authorities and avoids the overloading of other, already established methods (such as Assurance Level designation via certificatePolicy OID). Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. 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 King, et al. Expires April 30, 2012 [Page 1] INTERNET DRAFT claimSigning Extended Key Usage October 28, 2011 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/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on October 14, 2011. Copyright and License Notice Copyright (c) IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2 claimSigning Use Cases . . . . . . . . . . . . . . . . . . 4 1.3 Approach . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Abstract Syntax Notation . . . . . . . . . . . . . . . . . . . 6 3. claimSigning Extended Key Usage Value . . . . . . . . . . . . 6 4. Using the claimSinging EKU in a Certificate . . . . . . . . . 8 5. Implications for a Certification Authority . . . . . . . . . . 8 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 8. Copyright Notice . . . . . . . . . . . . . . . . . . . . . . . 10 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 9.1 Normative References . . . . . . . . . . . . . . . . . . . 10 9.2 Informative References . . . . . . . . . . . . . . . . . . 11 Appendix A - ASN.1 Structures and OIDs . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 King, et al. Expires April 30, 2012 [Page 2] INTERNET DRAFT claimSigning Extended Key Usage October 28, 2011 1 Introduction A Claim Signer is software or a service (i.e., a device) that packages and digitally signs statements about particular subjects (i.e., claims) in the form of security tokens. Claim Signing services are used in a number of applications. Examples of these services include Backend Attribute Exchange (BAE), SAML and other assertion protocols. The Claim Signer conveys that it is certified to issue claims by using a certificate that asserts the claimSigning Extended Key Usage (EKU) X.509 certificate extension. The presence of the claimSigning EKU simply indicates that the certificate is to be used for the purpose of signing claims (just as a certificate that asserts certSigning key usage indicates that the certificate is intended to be used for signing Identity Certificates). This approach supports Federated environments provides the ability to decouple Identity Assurance from the permission to issue claims and allows for a greater amount of flexibility, both for the operators of Federated systems, and for Certification Authorities This document defines an extended key usage (EKU) value [PROFILE] for specifying the applicability of a certificate to be used with a Claim Signing service. As such, in addition to providing rules for processing certificates that assert the claimSigning EKU Object Identifier (OID), this memo also provides guidance to issuers of certificates for use with Claim Signing. 1.1 Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [KEYWORDS]. Additionally, the following terms are defined: A Claim is a statement about a particular subject. Statements may include values that represent identity, attributes, keys, or other identifiers that are related to a particular subject. Claims do not include X.509 certificates signed by CAs when issuing user, device, or subordinate CA certificates, since those cases are covered by key usage bits (namely keyCertSign and basicConstraints). A Signed Claim is a digitally signed claim about a particular subject where the signer is vouching for the veracity of the claim. King, et al. Expires April 30, 2012 [Page 3] INTERNET DRAFT claimSigning Extended Key Usage October 28, 2011 A Claim Signer is software or a service (i.e. a device) that packages and digitally signs claims in the form of security tokens. The claim signer conveys the authority to assert the veracity of signed claims by using a certificate that asserts the claimSigning EKU. An Identity Provider (IdP) is a particular type of Claim Signer that signs one or more claims containing an assertion of identity, and possibly includes further attributes as claims that may be used by the consumer of that set of claims to make an authorization decision. 1.2 claimSigning Use Cases Two use cases are presented below to further describe how the claimSigning EKU is expected to be used. Federated Single Sign On Use Case 1. A Relying Party (RP) relies on SAML Assertions from an Identity Provider (IdP) to grant access to a protected resource. 2. The IdP authenticates the user and generates a SAML Assertion containing claims (email address, first-name, etc.) about the end user. 3. The IdP digitally signs the SAML Assertion using an X.509 certificate that contains the claimSigning EKU and sends the Assertion to the RP. 4. As part of the signature validation process the RP checks that the certificate used to sign the assertion contains the claim signing EKU. NOTE: For this use case that most CAs issuing certificates to servers include serverAuth (and sometimes clientAuth) in the device certificate. According to the rules for processing certificates that are in [PROFILE], an RP implementing a strict interpretation of [PROFILE] would reject the assertion, since the signing of SAML assertions is not an Authentication of the server (rather it is a signing "intent" operation). In other words, an RP that sees clientAuth or serverAuth but not the claimSigning EKU on a SAML assertion will fail to validate the signature. Attribute Authority use case: 1. An Attribute Authority (AA) is issued a certificate containing the claimSigning EKU. King, et al. Expires April 30, 2012 [Page 4] INTERNET DRAFT claimSigning Extended Key Usage October 28, 2011 2. The AA then issues attribute certificates, which contain claims (clearance level, professional certifications, etc.) about a security principle 3. An attribute certificate is then presented to an RP to convey this claim information 4. As part of the signature validation process the RP verifies that the AA's certificate contains the claimSigning EKU. 5. If the EKU is present and the signature validates, the RP then knows the AA is authorized to sign Attribute Certificates. NOTE: This is similar to the certSigning key usage bit, which is used to identify the certificate issued to a CA that is to be used for signing Identity Certificates. 1.3 Approach The value of using an Extended Key Usage value, instead of other methods for identifying that a given device is authorized to sign claims is that this allows for a separation between the designation that a given Identity belongs within a given Federation, and the empowerment of that entity within the federation to sign claims. Other methods (such as using a certificatePolicy OID value as a de facto key usage flag) suffer from the need to then have a dedicated policy OID for each and every assurance level possible within the federation. This is compounded by the inability to separate the identity binding and key protection aspects of normal certificatePolicy OID identified assurance levels, from the federation membership, attribute assurance, and Identity Provider / Attribute Authority operating rules that apply to that particular claim signer. Overloading other, already established methods (such as Assurance Level designation via certificatePolicy OID) would lead to an unnecessary tangling of the Certificate Policy used by the issuing Certification Authority, and the Operating Rules established by the Federation Trust Framework Provider. Consider the following: An Identity Provider has been proofed to a very high level, and their keys are stored in hardware, thus fulfilling the requirements for a given assurance level of identity binding by the Certification Authority (for the sake of this exercise, we will call this "medium-hardware" identity assurance). However, due to other reasons (lack of certain controls in attribute validation, King, et al. Expires April 30, 2012 [Page 5] INTERNET DRAFT claimSigning Extended Key Usage October 28, 2011 for instance), the Trust Framework Provider is only willing to vouch for this Identity Provider to being able to satisfy a relatively low level of attribute assurance (let's call that "Level 2"). As you can see, the possible combinations and permutations between Certificate Policy compliance and Trust Framework Provider accreditation could lead to an OID explosion on the part of the Certification Authority. Furthermore, if you tightly couple the certificatePolicy OID value to the permission to sign claims, having a single Identity Provider that operates in multiple federations becomes rather unnecessarily complex. By decoupling the Identity Assurance from the permission to issue claims (which the CA can easily gather from an attestation from the Trust Framework Provider), the approach suggested in this document allows for a greater amount of flexibility, both for the operators of Federated systems, and for Certification Authorities. As stated elsewhere in this document, it is acknowledged that there is still a need for Federation Realm identification, but this is out of scope of the present document. 2. Abstract Syntax Notation All X.509 certificate [X.509] extensions are defined using ASN.1 [X.680, X.690]. 3. claimSigning Extended Key Usage Value RFC 5280 [PROFILE] specifies the extended key usage (EKU) X.509 certificate extension. The EKU extension indicates one or more purposes for which the certificate may be used. The EKU extension can be used in conjunction with the key usage extension, which indicates the intended purpose of the certified public key. The EKU extension syntax is repeated here for convenience: ExtKeyUsageSyntax ::= SEQUENCE SIZE (1..MAX) of KeyPurposeID KeyPurposeID ::= OBJECT IDENTIFIER King, et al. Expires April 30, 2012 [Page 6] INTERNET DRAFT claimSigning Extended Key Usage October 28, 2011 This specification defines one KeyPurposeID value for use in transactions where Claim Signing is required. Inclusion of the Claim Signing value in the EKU indicates that the certificate is appropriate for use by an entity who intends to assert the veracity of a signed claim. id-kp OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) 3 } id-kp-claimSigning OBJECT IDENTIFIER ::= { id-kp TBD } The EKU extension MAY, at the option of the certificate issuer, be either critical or non-critical. Certificate-using applications MAY require the EKU extension to be present in a certificate, and they MAY require a particular KeyPurposeId value to be present (such as id-kp-claimSigning) within the EKU extension. King, et al. Expires April 30, 2012 [Page 7] INTERNET DRAFT claimSigning Extended Key Usage October 28, 2011 4. Using the claimSinging EKU in a Certificate In order to determine whether the usage of a certificate is intended to serve as a claimSigning certificate only, implementations MUST perform the steps given below as a part of the certificate validation: A conformant implementation MUST examine the Extended Key Usage value(s): If the certificate does not contain any EKU values (i.e., the Extended Key Usage extension does not exist), it is a matter of local policy whether or not to accept the certificate for use as a claimSigning certificate. Note that since certificates that do not follow this specification will not have the id-kp-claimSigning EKU value local policies might accept certificates for use as a claimSigning certificate to improve interoperability. If the certificate contains the id-kp-claimSigning EKU value, then implementations of this specification MUST consider the certificate valid for the purposes of signing claims. Otherwise the Relying Party may be exposed to the risks identified in the Security Considerations section below. If the certificate does not contain the id-kp-claimSigning EKU value, but does contain the id-kp-anyExtendedKeyUsage EKU value, it is a matter of local policy whether or not to consider the certificate acceptable for use as a claimSigning certificate. If the EKU extension exists, but does not contain either the id- kp-claimSigning or id-kp-anyExtendedKeyUsage EKU values, the application MUST NOT accept the certificate for use as a claimSigning certificate. 5. Implications for a Certification Authority The procedures and practices employed by a conformant CA MUST ensure that the holder of the private key associated with the public key in the Certificate is authorized to sign claims within a particular community of interest before populating the certificate with the id- kp-claimSigning EKU value. How a given community of interest determines authorization should be specified in the CA Certificate Policy or other agreements within the community and is out of scope for this document. When a conformant Certification Authority (CA) includes this EKU King, et al. Expires April 30, 2012 [Page 8] INTERNET DRAFT claimSigning Extended Key Usage October 28, 2011 value, it SHALL set the digitalSignature keyUsage bit. A conformant CA SHOULD NOT set the nonRepudiation, keyEncipherment, keyAgreement or dataEncipherment keyUsage bits. Furthermore, by declaring that this key pair is used for signature by issuing a Certificate with this EKU, a CA SHALL NOT escrow or cause the private key associated with this certificate to be escrowed. If the claimSigning EKU extension value is asserted, then no additional EKU KeyPurposeId values SHALL be asserted. 6. Security Considerations This memo defines an EKU X.509 certificate extension that conveys to Relying Parties that the certificate holder is certified to issue claims. The procedures and practices employed by the CA MUST ensure that the correct values for the EKU are inserted in each certificate that is issued. Relying parties may accept or reject a particular certificate for an intended use based on the information provided in the extension. Incorrect representation of the information in the extension could cause the relying party to reject an otherwise appropriate certificate or accept a certificate that ought to be rejected. Relying Party applications are encouraged to require this particular OID to be asserted in order to accept a signed claim as valid. Since the attribute assertions which are signed by the holders of Private keys which have corresponding Public Keys in Certificates which assert id-kp-claimSigning are used to provide an attestation of Identity, or a attestation of a particular attribute that is associated with an Identity, it is imperative that the Private Keys be kept using methods as strict as, or better than the assurance level of the identities which are being asserted. Since the criteria for management of the private key of the server's Identity Certificate may be different from the requirements for the protection and management of the key used to sign attribute assertions therefore, the same Certificate should not be used as both a server Identity Certificate and a claimSigner certificate. Furthermore, the server name itself (as opposed to the Identity Provider) may change over time, or even be deployed in a manner that disassociates the interface facing the Subscriber from the server signing the attribute assertion, as is the case in many "Reverse Proxy" situations. It is recommended that the two functions be kept distinct. This also has operational impacts, in cases where the CP requires two person control for the Private Key of an Identity King, et al. Expires April 30, 2012 [Page 9] INTERNET DRAFT claimSigning Extended Key Usage October 28, 2011 Provider, but leaves the Device certificates somewhat less constrained. In such a case, the Identity Provider server may have an automatic restart capability or an automated failover process allowing it to display a secure interface (using the Device Certificate) indicating the issue to Relying Parties and Subscribers, while waiting for the conditions to be met for two person control of the Identity Provider Service. Since the Certificate which asserts id-kp-claimSigning, is in fact, a signature certificate, good practice dictates that the corresponding private key never be escrowed, even if any of the encryption key usages are asserted in the same certificate. Escrowing the private key could lead to questions about the veracity of claims originating from that Identity Provider. 7. IANA Considerations Certificate extended key usage values are identified by object identifiers (OIDs). The OIDs used in this document were assigned from an arc delegated by the IANA. No further action by the IANA is necessary for this document or any anticipated updates [RFC5513]. 8. Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. 9. References 9.1 Normative References [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [PROFILE] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008. [X.509] ITU-T. Recommendation X.509: The Directory - Authentication Framework. 2000. [X.680] ITU-T Recommendation X.680: Information Technology - Abstract Syntax Notation One, 1997. [X.690] ITU-T Recommendation X.690: Information Technology - King, et al. Expires April 30, 2012 [Page 10] INTERNET DRAFT claimSigning Extended Key Usage October 28, 2011 Abstract Syntax Notation One Encoding Rules, 2002. 9.2 Informative References [RFC5513] Farrel, A., "IANA Considerations for Three Letter Acronyms", RFC 5513, April 1 2009. King, et al. Expires April 30, 2012 [Page 11] INTERNET DRAFT claimSigning Extended Key Usage October 28, 2011 Appendix A - ASN.1 Structures and OIDs BEGIN -- OID Arcs id-kp OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) 3 } -- Extended Key Usage Values id-kp-claimSigning OBJECT IDENTIFIER ::= { id-kp TBD } END Authors' Addresses Matt King Protiviti Government Services 1640 King St., Suite 400 Alexandria, VA 22314 Phone: 410-271-5624 Email: Matthew.King@pgs.protiviti.com Matt Tebo Protiviti Government Services 1640 King St., Suite 400 Alexandria, VA 22314 Phone: 301-312-5852 Email: Matt.Tebo@pgs.protiviti.com Wendy Brown Protiviti Government Services 1640 King St., Suite 400 Alexandria, VA 22314 Phone: 703-965-2990 Email: Wendy.Brown@pgs.protiviti.com King, et al. Expires April 30, 2012 [Page 12] INTERNET DRAFT claimSigning Extended Key Usage October 28, 2011 Dave Silver Protiviti Government Services 1640 King St., Suite 400 Alexandria, VA 22314 Phone: 703-597-5114 Email: Dave.Silver@pgs.protiviti.com Chris Louden Protiviti Government Services 1640 King St., Suite 400 Alexandria, VA 22314 Phone: 703-447-7431 Email: Chris.Louden@pgs.protiviti.com Patrick Patterson Carillon Information Security Inc. 356 Joseph Carrier Vaudreuil-Dorion, QC J7V5V5 Canada Phone: +1 514 485 0789 Email: ppatterson@carillon.ca King, et al. Expires April 30, 2012 [Page 13]