Network Working Group M. King
INTERNET-DRAFT M. Tebo
Intended Status: Proposed Standard W. Brown
Expires: June 2012 D. Silver
C. Louden
Protiviti Government Services
P. Patterson
Carillon Information Security Inc.
December 27, 2011
claimSigning Extended Key Usage (EKU)
draft-king-pkix-claimsigning-extn-03
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 June 27, 2012 [Page 1]
INTERNET DRAFT claimSigning Extended Key Usage December 27, 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 June 27, 2012.
Copyright and License Notice
Copyright (c) <year> 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 . . . . . . . . . . . . . . . . . . . 7
3. claimSigning Extended Key Usage Value . . . . . . . . . . . . 7
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 June 27, 2012 [Page 2]
INTERNET DRAFT claimSigning Extended Key Usage December 27, 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. Examples of the types of tokens being signed
include Attribute Certificates and SAML Assertions.
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). Today it is common
practice to accept Certificates which contain the server auth
Extended Key Usage, since the server frequently also supports TLS and
they are reusing the same certificate. However since these
certificates are so pervasive it means server auth does not clearly
differentiate a service on a server which is permitted to sign
claims. 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. While X.509
certificatessigned by CAs when issuing user and device identity or
King, et al. Expires June 27, 2012 [Page 3]
INTERNET DRAFT claimSigning Extended Key Usage December 27, 2011
subordinate CA certificates contain claims, there are already good
methods in place to indicate that the Certificate holder is permitted
to sign X.509 Identity Certificates, since those cases are covered by
key usage bits (namely keyCertSign and basicConstraints). However,
there currently lacks a clear method to indicate that the holder of a
given certificate is permitted to sign other types of claims.
A Signed Claim is a digitally signed claim about a particular subject
where the signer is vouching for the veracity of the claim.
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
King, et al. Expires June 27, 2012 [Page 4]
INTERNET DRAFT claimSigning Extended Key Usage December 27, 2011
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.
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
King, et al. Expires June 27, 2012 [Page 5]
INTERNET DRAFT claimSigning Extended Key Usage December 27, 2011
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,
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. Furthermore,
since it is a barrier to establishment of a Federation to stand up
a dedicated CA, the author's foresee a situation developing where
Commercial CAs issue certificates to IDPs in a given Federation,
and since obtaining common OIDs between such CAs is improbable,
tying the existence of a given OID asserted in the
certificatePolicies extension will mean that Relying Parties will
have to map between these, creating an untenable and unsupportable
environment for deployers of small federations.
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, and gives
a simple method for Relying Parties to determine that a server is
allowed to sign claims. This also removes the need for an arbitrary
"any Federation" OID object, since there may exist situations where
the Relying Party just wants to know it is talking to a valid IDP,
without regards to any other framework or Federation rules.
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.
King, et al. Expires June 27, 2012 [Page 6]
INTERNET DRAFT claimSigning Extended Key Usage December 27, 2011
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
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 June 27, 2012 [Page 7]
INTERNET DRAFT claimSigning Extended Key Usage December 27, 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 June 27, 2012 [Page 8]
INTERNET DRAFT claimSigning Extended Key Usage December 27, 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 June 27, 2012 [Page 9]
INTERNET DRAFT claimSigning Extended Key Usage December 27, 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 June 27, 2012 [Page 10]
INTERNET DRAFT claimSigning Extended Key Usage December 27, 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 June 27, 2012 [Page 11]
INTERNET DRAFT claimSigning Extended Key Usage December 27, 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 June 27, 2012 [Page 12]
INTERNET DRAFT claimSigning Extended Key Usage December 27, 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 June 27, 2012 [Page 13]