idnits 2.17.1 draft-king-pkix-claimsigning-extn-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 148 has weird spacing: '...gitally sign...' == Line 149 has weird spacing: '... signer conv...' == Line 150 has weird spacing: '...ificate tha...' == Line 406 has weird spacing: '...ational impac...' -- The document date (December 27, 2011) is 4503 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. King 3 INTERNET-DRAFT M. Tebo 4 Intended Status: Proposed Standard W. Brown 5 Expires: June 2012 D. Silver 6 C. Louden 7 Protiviti Government Services 8 P. Patterson 9 Carillon Information Security Inc. 10 December 27, 2011 12 claimSigning Extended Key Usage (EKU) 13 draft-king-pkix-claimsigning-extn-03 15 Abstract 17 This document specifies an Extended Key Usage (EKU) value which 18 indicates that the certificate holder is authorized to sign security 19 tokens to assert claims, or attributes, about a subject. 21 When a certificate that asserts the claimSigning EKU signs a claim, 22 the owner of the service holding that certificate is asserting that a 23 statement about the subject is true. For example, a IdP secure token 24 service (STS) would use an X.509 certificate containing the 25 claimSigning EKU to sign SAML assertions containing an identifier and 26 attributes about a user. This EKU value would allow for a separation 27 between the designation that a given Identity belongs within a given 28 Federation, and the empowerment of that entity within the federation 29 to sign claims.. This approach allows for greater flexibility for 30 the operators of Federated systems and for Certification Authorities 31 and avoids the overloading of other, already established methods 32 (such as Assurance Level designation via certificatePolicy OID). 34 Status of this Memo 36 This Internet-Draft is submitted to IETF in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF), its areas, and its working groups. Note that 41 other groups may also distribute working documents as 42 Internet-Drafts. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 49 The list of current Internet-Drafts can be accessed at 50 http://www.ietf.org/1id-abstracts.html 52 The list of Internet-Draft Shadow Directories can be accessed at 53 http://www.ietf.org/shadow.html 55 This Internet-Draft will expire on June 27, 2012. 57 Copyright and License Notice 59 Copyright (c) IETF Trust and the persons identified as the 60 document authors. All rights reserved. 62 This document is subject to BCP 78 and the IETF Trust's Legal 63 Provisions Relating to IETF Documents 64 (http://trustee.ietf.org/license-info) in effect on the date of 65 publication of this document. Please review these documents 66 carefully, as they describe your rights and restrictions with respect 67 to this document. Code Components extracted from this document must 68 include Simplified BSD License text as described in Section 4.e of 69 the Trust Legal Provisions and are provided without warranty as 70 described in the Simplified BSD License. 72 Table of Contents 74 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 75 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 76 1.2 claimSigning Use Cases . . . . . . . . . . . . . . . . . . 4 77 1.3 Approach . . . . . . . . . . . . . . . . . . . . . . . . . 5 78 2. Abstract Syntax Notation . . . . . . . . . . . . . . . . . . . 7 79 3. claimSigning Extended Key Usage Value . . . . . . . . . . . . 7 80 4. Using the claimSinging EKU in a Certificate . . . . . . . . . 8 81 5. Implications for a Certification Authority . . . . . . . . . . 8 82 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 83 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 84 8. Copyright Notice . . . . . . . . . . . . . . . . . . . . . . . 10 85 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 86 9.1 Normative References . . . . . . . . . . . . . . . . . . . 10 87 9.2 Informative References . . . . . . . . . . . . . . . . . . 11 88 Appendix A - ASN.1 Structures and OIDs . . . . . . . . . . . . . . 12 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 91 1 Introduction 93 A Claim Signer is software or a service (i.e., a device) that 94 packages and digitally signs statements about particular subjects 95 (i.e., claims) in the form of security tokens. Claim Signing 96 services are used in a number of applications. Examples of these 97 services include Backend Attribute Exchange (BAE), SAML and other 98 assertion protocols. Examples of the types of tokens being signed 99 include Attribute Certificates and SAML Assertions. 101 The Claim Signer conveys that it is certified to issue claims by 102 using a certificate that asserts the claimSigning Extended Key Usage 103 (EKU) X.509 certificate extension. The presence of the claimSigning 104 EKU simply indicates that the certificate is to be used for the 105 purpose of signing claims (just as a certificate that asserts 106 certSigning key usage indicates that the certificate is intended to 107 be used for signing Identity Certificates). Today it is common 108 practice to accept Certificates which contain the server auth 109 Extended Key Usage, since the server frequently also supports TLS and 110 they are reusing the same certificate. However since these 111 certificates are so pervasive it means server auth does not clearly 112 differentiate a service on a server which is permitted to sign 113 claims. This approach supports Federated environments provides the 114 ability to decouple Identity Assurance from the permission to issue 115 claims and allows for a greater amount of flexibility, both for the 116 operators of Federated systems, and for Certification Authorities 118 This document defines an extended key usage (EKU) value [PROFILE] for 119 specifying the applicability of a certificate to be used with a Claim 120 Signing service. As such, in addition to providing rules for 121 processing certificates that assert the claimSigning EKU Object 122 Identifier (OID), this memo also provides guidance to issuers of 123 certificates for use with Claim Signing. 125 1.1 Terminology 127 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 128 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 129 document are to be interpreted as described in RFC 2119 [KEYWORDS]. 131 Additionally, the following terms are defined: 133 A Claim is a statement about a particular subject. Statements may 134 include values that represent identity, attributes, keys, or other 135 identifiers that are related to a particular subject. While X.509 136 certificatessigned by CAs when issuing user and device identity or 137 subordinate CA certificates contain claims, there are already good 138 methods in place to indicate that the Certificate holder is permitted 139 to sign X.509 Identity Certificates, since those cases are covered by 140 key usage bits (namely keyCertSign and basicConstraints). However, 141 there currently lacks a clear method to indicate that the holder of a 142 given certificate is permitted to sign other types of claims. 144 A Signed Claim is a digitally signed claim about a particular subject 145 where the signer is vouching for the veracity of the claim. 147 A Claim Signer is software or a service (i.e. a device) that packages 148 and digitally signs claims in the form of security tokens. The 149 claim signer conveys the authority to assert the veracity of signed 150 claims by using a certificate that asserts the claimSigning EKU. 152 An Identity Provider (IdP) is a particular type of Claim Signer that 153 signs one or more claims containing an assertion of identity, and 154 possibly includes further attributes as claims that may be used by 155 the consumer of that set of claims to make an authorization decision. 157 1.2 claimSigning Use Cases 159 Two use cases are presented below to further describe how the 160 claimSigning EKU is expected to be used. 162 Federated Single Sign On Use Case 164 1. A Relying Party (RP) relies on SAML Assertions from an 165 Identity Provider (IdP) to grant access to a protected resource. 167 2. The IdP authenticates the user and generates a SAML Assertion 168 containing claims (email address, first-name, etc.) about the end 169 user. 171 3. The IdP digitally signs the SAML Assertion using an X.509 172 certificate that contains the claimSigning EKU and sends the 173 Assertion to the RP. 175 4. As part of the signature validation process the RP checks 176 that the certificate used to sign the assertion contains the 177 claim signing EKU. 179 NOTE: For this use case that most CAs issuing certificates to 180 servers include serverAuth (and sometimes clientAuth) in the 181 device certificate. According to the rules for processing 182 certificates that are in [PROFILE], an RP implementing a strict 183 interpretation of [PROFILE] would reject the assertion, since 184 the signing of SAML assertions is not an Authentication of the 185 server (rather it is a signing "intent" operation). In other 186 words, an RP that sees clientAuth or serverAuth but not the 187 claimSigning EKU on a SAML assertion will fail to validate the 188 signature. 190 Attribute Authority use case: 192 1. An Attribute Authority (AA) is issued a certificate containing 193 the claimSigning EKU. 195 2. The AA then issues attribute certificates, which contain 196 claims (clearance level, professional certifications, etc.) about 197 a security principle 199 3. An attribute certificate is then presented to an RP to convey 200 this claim information 202 4. As part of the signature validation process the RP verifies 203 that the AA's certificate contains the claimSigning EKU. 205 5. If the EKU is present and the signature validates, the RP then 206 knows the AA is authorized to sign Attribute Certificates. 208 NOTE: This is similar to the certSigning key usage bit, which 209 is used to identify the certificate issued to a CA that is to 210 be used for signing Identity Certificates. 212 1.3 Approach 214 The value of using an Extended Key Usage value, instead of other 215 methods for identifying that a given device is authorized to sign 216 claims is that this allows for a separation between the designation 217 that a given Identity belongs within a given Federation, and the 218 empowerment of that entity within the federation to sign claims. 219 Other methods (such as using a certificatePolicy OID value as a de 220 facto key usage flag) suffer from the need to then have a dedicated 221 policy OID for each and every assurance level possible within the 222 federation. This is compounded by the inability to separate the 223 identity binding and key protection aspects of normal 224 certificatePolicy OID identified assurance levels, from the 225 federation membership, attribute assurance, and Identity Provider / 226 Attribute Authority operating rules that apply to that particular 227 claim signer. Overloading other, already established methods (such as 228 Assurance Level designation via certificatePolicy OID) would lead to 229 an unnecessary tangling of the Certificate Policy used by the issuing 230 Certification Authority, and the Operating Rules established by the 231 Federation Trust Framework Provider. 233 Consider the following: 235 An Identity Provider has been proofed to a very high level, and 236 their keys are stored in hardware, thus fulfilling the requirements 237 for a given assurance level of identity binding by the 238 Certification Authority (for the sake of this exercise, we will 239 call this "medium-hardware" identity assurance). However, due to 240 other reasons (lack of certain controls in attribute validation, 241 for instance), the Trust Framework Provider is only willing to 242 vouch for this Identity Provider to being able to satisfy a 243 relatively low level of attribute assurance (let's call that "Level 244 2"). 246 As you can see, the possible combinations and permutations between 247 Certificate Policy compliance and Trust Framework Provider 248 accreditation could lead to an OID explosion on the part of the 249 Certification Authority. Furthermore, if you tightly couple the 250 certificatePolicy OID value to the permission to sign claims, 251 having a single Identity Provider that operates in multiple 252 federations becomes rather unnecessarily complex. Furthermore, 253 since it is a barrier to establishment of a Federation to stand up 254 a dedicated CA, the author's foresee a situation developing where 255 Commercial CAs issue certificates to IDPs in a given Federation, 256 and since obtaining common OIDs between such CAs is improbable, 257 tying the existence of a given OID asserted in the 258 certificatePolicies extension will mean that Relying Parties will 259 have to map between these, creating an untenable and unsupportable 260 environment for deployers of small federations. 262 By decoupling the Identity Assurance from the permission to issue 263 claims (which the CA can easily gather from an attestation from the 264 Trust Framework Provider), the approach suggested in this document 265 allows for a greater amount of flexibility, both for the operators 266 of Federated systems, and for Certification Authorities, and gives 267 a simple method for Relying Parties to determine that a server is 268 allowed to sign claims. This also removes the need for an arbitrary 269 "any Federation" OID object, since there may exist situations where 270 the Relying Party just wants to know it is talking to a valid IDP, 271 without regards to any other framework or Federation rules. 273 As stated elsewhere in this document, it is acknowledged that there 274 is still a need for Federation Realm identification, but this is 275 out of scope of the present document. 277 2. Abstract Syntax Notation 279 All X.509 certificate [X.509] extensions are defined using ASN.1 280 [X.680, X.690]. 282 3. claimSigning Extended Key Usage Value 284 RFC 5280 [PROFILE] specifies the extended key usage (EKU) X.509 285 certificate extension. The EKU extension indicates one or more 286 purposes for which the certificate may be used. The EKU extension 287 can be used in conjunction with the key usage extension, which 288 indicates the intended purpose of the certified public key. The EKU 289 extension syntax is repeated here for convenience: 291 ExtKeyUsageSyntax ::= SEQUENCE SIZE (1..MAX) of KeyPurposeID 293 KeyPurposeID ::= OBJECT IDENTIFIER 295 This specification defines one KeyPurposeID value for use in 296 transactions where Claim Signing is required. Inclusion of the Claim 297 Signing value in the EKU indicates that the certificate is 298 appropriate for use by an entity who intends to assert the veracity 299 of a signed claim. 301 id-kp OBJECT IDENTIFIER ::= 302 { iso(1) identified-organization(3) dod(6) internet(1) 303 security(5) mechanisms(5) pkix(7) 3 } 305 id-kp-claimSigning OBJECT IDENTIFIER ::= { id-kp TBD } 307 The EKU extension MAY, at the option of the certificate issuer, be 308 either critical or non-critical. 310 Certificate-using applications MAY require the EKU extension to be 311 present in a certificate, and they MAY require a particular 312 KeyPurposeId value to be present (such as id-kp-claimSigning) within 313 the EKU extension. 315 4. Using the claimSinging EKU in a Certificate 317 In order to determine whether the usage of a certificate is intended 318 to serve as a claimSigning certificate only, implementations MUST 319 perform the steps given below as a part of the certificate 320 validation: 322 A conformant implementation MUST examine the Extended Key Usage 323 value(s): 325 If the certificate does not contain any EKU values (i.e., the 326 Extended Key Usage extension does not exist), it is a matter of 327 local policy whether or not to accept the certificate for use as a 328 claimSigning certificate. Note that since certificates that do 329 not follow this specification will not have the id-kp-claimSigning 330 EKU value local policies might accept certificates for use as a 331 claimSigning certificate to improve interoperability. 333 If the certificate contains the id-kp-claimSigning EKU value, then 334 implementations of this specification MUST consider the 335 certificate valid for the purposes of signing claims. Otherwise 336 the Relying Party may be exposed to the risks identified in the 337 Security Considerations section below. 339 If the certificate does not contain the id-kp-claimSigning EKU 340 value, but does contain the id-kp-anyExtendedKeyUsage EKU value, 341 it is a matter of local policy whether or not to consider the 342 certificate acceptable for use as a claimSigning certificate. 344 If the EKU extension exists, but does not contain either the id- 345 kp-claimSigning or id-kp-anyExtendedKeyUsage EKU values, the 346 application MUST NOT accept the certificate for use as a 347 claimSigning certificate. 349 5. Implications for a Certification Authority 351 The procedures and practices employed by a conformant CA MUST ensure 352 that the holder of the private key associated with the public key in 353 the Certificate is authorized to sign claims within a particular 354 community of interest before populating the certificate with the id- 355 kp-claimSigning EKU value. How a given community of interest 356 determines authorization should be specified in the CA Certificate 357 Policy or other agreements within the community and is out of scope 358 for this document. 360 When a conformant Certification Authority (CA) includes this EKU 361 value, it SHALL set the digitalSignature keyUsage bit. A conformant 362 CA SHOULD NOT set the nonRepudiation, keyEncipherment, keyAgreement 363 or dataEncipherment keyUsage bits. Furthermore, by declaring that 364 this key pair is used for signature by issuing a Certificate with 365 this EKU, a CA SHALL NOT escrow or cause the private key associated 366 with this certificate to be escrowed. 368 If the claimSigning EKU extension value is asserted, then no 369 additional EKU KeyPurposeId values SHALL be asserted. 371 6. Security Considerations 373 This memo defines an EKU X.509 certificate extension that conveys to 374 Relying Parties that the certificate holder is certified to issue 375 claims. 377 The procedures and practices employed by the CA MUST ensure that the 378 correct values for the EKU are inserted in each certificate that is 379 issued. Relying parties may accept or reject a particular certificate 380 for an intended use based on the information provided in the 381 extension. Incorrect representation of the information in the 382 extension could cause the relying party to reject an otherwise 383 appropriate certificate or accept a certificate that ought to be 384 rejected. Relying Party applications are encouraged to require this 385 particular OID to be asserted in order to accept a signed claim as 386 valid. 388 Since the attribute assertions which are signed by the holders of 389 Private keys which have corresponding Public Keys in Certificates 390 which assert id-kp-claimSigning are used to provide an attestation of 391 Identity, or a attestation of a particular attribute that is 392 associated with an Identity, it is imperative that the Private Keys 393 be kept using methods as strict as, or better than the assurance 394 level of the identities which are being asserted. Since the criteria 395 for management of the private key of the server's Identity 396 Certificate may be different from the requirements for the protection 397 and management of the key used to sign attribute assertions 398 therefore, the same Certificate should not be used as both a server 399 Identity Certificate and a claimSigner certificate. 401 Furthermore, the server name itself (as opposed to the Identity 402 Provider) may change over time, or even be deployed in a manner that 403 disassociates the interface facing the Subscriber from the server 404 signing the attribute assertion, as is the case in many "Reverse 405 Proxy" situations. It is recommended that the two functions be kept 406 distinct. This also has operational impacts, in cases where the CP 407 requires two person control for the Private Key of an Identity 408 Provider, but leaves the Device certificates somewhat less 409 constrained. In such a case, the Identity Provider server may have 410 an automatic restart capability or an automated failover process 411 allowing it to display a secure interface (using the Device 412 Certificate) indicating the issue to Relying Parties and Subscribers, 413 while waiting for the conditions to be met for two person control of 414 the Identity Provider Service. 416 Since the Certificate which asserts id-kp-claimSigning, is in fact, a 417 signature certificate, good practice dictates that the corresponding 418 private key never be escrowed, even if any of the encryption key 419 usages are asserted in the same certificate. Escrowing the private 420 key could lead to questions about the veracity of claims originating 421 from that Identity Provider. 423 7. IANA Considerations 425 Certificate extended key usage values are identified by object 426 identifiers (OIDs). The OIDs used in this document were assigned 427 from an arc delegated by the IANA. No further action by the IANA is 428 necessary for this document or any anticipated updates [RFC5513]. 430 8. Copyright Notice 432 Copyright (c) 2011 IETF Trust and the persons identified as the 433 document authors. All rights reserved. 435 9. References 437 9.1 Normative References 439 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 440 Requirement Levels", BCP 14, RFC 2119, March 1997. 442 [PROFILE] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 443 Housley, R., and W. Polk, "Internet X.509 Public Key 444 Infrastructure Certificate and Certificate Revocation List 445 (CRL) Profile", RFC 5280, May 2008. 447 [X.509] ITU-T. Recommendation X.509: The Directory - 448 Authentication Framework. 2000. 450 [X.680] ITU-T Recommendation X.680: Information Technology - 451 Abstract Syntax Notation One, 1997. 453 [X.690] ITU-T Recommendation X.690: Information Technology - 454 Abstract Syntax Notation One Encoding Rules, 2002. 456 9.2 Informative References 458 [RFC5513] Farrel, A., "IANA Considerations for Three Letter 459 Acronyms", RFC 5513, April 1 2009. 461 Appendix A - ASN.1 Structures and OIDs 463 BEGIN 465 -- OID Arcs 467 id-kp OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 468 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 3 } 470 -- Extended Key Usage Values 472 id-kp-claimSigning OBJECT IDENTIFIER ::= { id-kp TBD } 474 END 476 Authors' Addresses 478 Matt King 479 Protiviti Government Services 480 1640 King St., Suite 400 481 Alexandria, VA 22314 483 Phone: 410-271-5624 484 Email: Matthew.King@pgs.protiviti.com 486 Matt Tebo 487 Protiviti Government Services 488 1640 King St., Suite 400 489 Alexandria, VA 22314 491 Phone: 301-312-5852 492 Email: Matt.Tebo@pgs.protiviti.com 494 Wendy Brown 495 Protiviti Government Services 496 1640 King St., Suite 400 497 Alexandria, VA 22314 499 Phone: 703-965-2990 500 Email: Wendy.Brown@pgs.protiviti.com 501 Dave Silver 502 Protiviti Government Services 503 1640 King St., Suite 400 504 Alexandria, VA 22314 506 Phone: 703-597-5114 507 Email: Dave.Silver@pgs.protiviti.com 509 Chris Louden 510 Protiviti Government Services 511 1640 King St., Suite 400 512 Alexandria, VA 22314 514 Phone: 703-447-7431 515 Email: Chris.Louden@pgs.protiviti.com 517 Patrick Patterson 518 Carillon Information Security Inc. 519 356 Joseph Carrier 520 Vaudreuil-Dorion, QC J7V5V5 521 Canada 523 Phone: +1 514 485 0789 524 Email: ppatterson@carillon.ca