INTERNET-DRAFT Stefan Santesson Intended Status: Informational (3xA Security) Expires: August 16, 2013 February 12, 2013 Authentication Context Certificate Extension draft-santesson-auth-context-extension-01 Abstract This document defines an extension to certificates according to [RFC5280]. The extension defined in this document holds data about how the certificate subject was authenticated by the Certification Authority who issued the certificate where this extension appears. This document also defines one data structure for inclusion in this extension that designed to hold information when the subject is authenticated using a SAML assertion [SAML]. 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 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 Copyright and License Notice Copyright (c) 2013 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 Santesson Expires August 16, 2013 [Page 1] INTERNET DRAFT Authentication Context Extension February 12, 2013 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 . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2 Deployment . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Authentication Context Extension Syntax . . . . . . . . . . . 5 3 SAML Authentication Context Information . . . . . . . . . . . . 5 3.1 authContextInfo object . . . . . . . . . . . . . . . . . . 6 3.2 idAttributes object . . . . . . . . . . . . . . . . . . . . 7 3 Security Considerations . . . . . . . . . . . . . . . . . . . . 9 4 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 9 5 References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 5.1 Normative References . . . . . . . . . . . . . . . . . . . 9 5.2 Informative References . . . . . . . . . . . . . . . . . . 10 Appendix A - ASN.1 modules . . . . . . . . . . . . . . . . . . . . 10 A.1 ASN.1 1988 Syntax . . . . . . . . . . . . . . . . . . . . . 10 A.2 ASN.1 2008 Syntax . . . . . . . . . . . . . . . . . . . . . 11 Appendix B - SAML Authentication Context Data Structures . . . . . 11 B.1 JSON Schema . . . . . . . . . . . . . . . . . . . . . . . . 12 B.2 JAVA Class Declaration . . . . . . . . . . . . . . . . . . 13 B.2 Example . . . . . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 Santesson Expires August 16, 2013 [Page 2] INTERNET DRAFT Authentication Context Extension February 12, 2013 1 Introduction This document addresses some needs that may arise when issuing a certificate from an existing non-certificate based identity infrastructure where the certificate subject already has an authenticated identity composed of a set of attributes, or so called claims, that differ from the attributes that are commonly used to express the identity of a certificate subject. A typical scenario for this is when the basic trust infrastructure is based on a SAML federation, where the subject for some reason needs a certificate that can be traced back to that subjects SAML credentials, both with regard to identity and with regard to level of assurance with which the subject has been authenticated. A reason to issue such certificate may arise if the subject needs a certificate to support signing a document, where the Certification Authority is authenticating the user by means of the SAML federation when issuing that signature certificate. If that signature certificate need to conform to certificate profiles, such as [RFC3739], then this certificate may have to use a separate set of attributes to express the subject identity than the set of attributes obtained from the SAML assertion. The extension defined in the document makes it possible to extract information about the authentication context applied when authenticating the subject for the purpose of issuing a certificate. This may include information such as: o The Identity Provider which authenticated the subject. o The level of assurance with which the subject was authenticated. o The trust framework where this level of assurance was defined. o A unique reference to the authentication instant o A mapping table between the subject attributes obtained from the SAML assertion used to authenticate the subject, and the subject identity information placed in the issued certificate. One scenario where this information may be useful is when a user logs in to a service using SAML credentials, where the same user at some stage is required to sign some information. The service may need to verify that the signature was created by the same user that logged on to the service. This is only possible today using out-of-band knowledge about the CA that issued the certificate and it's practices. This is is however hard to scale and maintain using a large number of service providers, identity providers and CAs. Santesson Expires August 16, 2013 [Page 3] INTERNET DRAFT Authentication Context Extension February 12, 2013 The defined extension provides better scalability since it only requires the service provider to maintain a list of trusted CA:s. All other information abut the relationship between the certificate subject, and the SAML authenticated subject is available in the certificate. 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 [RFC2119]. 1.2 Deployment EDITORS NOTE: [This section provided information for better understanding the rationale of the extension. This section can be deleted is the document is published] The extension defined in this draft has been defined and deployed in the National Swedish Identity infrastructure Eid 2.0 which is based on SAML federated identity. The Swedish infrastructure will go live during 2013 and will provide secure identification of citizens in Swedish government services. A central requirement in these government services is to allow citizens to sign various documents, representing a wide range of declarations and applications. A central part of this infrastructure is therefore to use centralized signature services that allows citizens to sign using their SAML credentials. As service providers authenticate and understands user identities only under a SAML context within this national infrastructure, this extension allows Service Providers to determine whether a presented signature matches a particular user and whether it meets the security requirements of the service. Through information provided in this extension a service provider may for example get notice that the user logged on using one level of assurance, but presented a signature which certificate was issued using a certificate obtained using a lower level of assurance procedure, and thus reject the signature. This extension is therefore fundamental to the function of the Swedish Eid 2.0 infrastructure. Santesson Expires August 16, 2013 [Page 4] INTERNET DRAFT Authentication Context Extension February 12, 2013 2. Authentication Context Extension Syntax The Authentication Context extension has the following syntax: AuthenticationContexts ::= SEQUENCE { authContext AuthenticationContext } AuthenticationContext ::= SEQUENCE { contextType OBJECT IDENTIFIER, mimeType PrintableString (OPTIONAL), contextInfo OCTET STRING } This extension holds a sequence of authContext information. When present, this extension MUST include at least one authContext. The type of statement included is identified by the contextType object identifier. The statement itself is carried in the contextInfo bytes using a data format that is identified by the specified mimeType. If mimeType is absent, then contextInfo MUST hold a DER encoded ASN.1 structure. Implementations of this extension MUST fail gracefully if it encounters an unrecognized mimeType. This document defines one authContext information type (Section 3) that MAY be used to provide information about SAML based authentication. Other documents MAY define other authContext information types. Each contextType MUST define both data format and structure of the data stored in contextInfo. 3 SAML Authentication Context Information The SAML Authentication context information provides a contextType type that MAY be used to carry information about SAML based authentication of the certified subject as part of the certificate issuing process. The data carried in this statement is provided in JSON format, identified by the following mime type: application/json Santesson Expires August 16, 2013 [Page 5] INTERNET DRAFT Authentication Context Extension February 12, 2013 This data structure is identified by the contextType Object Identifier id-ct-saml-ac. id-ct-saml-ac OBJECT IDENTIFIER ::= { id-eleg-ct 1} The JSON data format is used mainly to allow this context information to be extracted and processed in applications that lacks ASN.1 processing capabilities. JSON is easy to deserialize into various data objects both in application and web environments for further comparison with the characteristics of SAML authenticated sessions. The data provided in contextInfo SHALL be the byte representation of an UTF-8 encoded string holding JSON formatted data in accordance with Appendix B. The content of the two JSON objects authContextInfo and idAttributes are outlined in the following subsections. 3.1 authContextInfo object The authContextInfo object MAY be present in the statement. When present, the following conventions SHALL apply to the parameters carried in the authContext object: identityProvider (required): The SAML EntityID of the Identity Provider which authenticated the subject. authenticationInstant (required): Date and time when the subject was authenticated. authnContextClassRef (required): A URI identifying the AuthnContextClassRef that is provided in the AuthnStatement of the Assertion that was used to authenticate the subject. This URI identifies the context and the level of assurance associated with this instance of authentication. assertionRef (optional): A unique reference to the SAML Assertion serviceID (optional): An arbitrary identifier of the service that verified the SAML assertion. Santesson Expires August 16, 2013 [Page 6] INTERNET DRAFT Authentication Context Extension February 12, 2013 3.2 idAttributes object The idAttributes object MAY be present in the statement. When present, this object holds an array of attribute statements, where each object in the array holds information about one SAML attribute value that was included in the certificate as a representation of the certified subject. When present, each attribute statement SHALL comply with the following conventions: name (Optional): An arbitrary friendly name of the attribute. samlAttr (Required): A URI identifying the SAML attribute that contained the value in attrVlaue. attrValue (Required): The attribute value carried in the SAML attribute. certNameType (Required): A string holding one of the enumerated values "rdn", "san" or "sda", having the following meaning: "rdn" The attribute value is placed in the subject field of the certificate in a present Relative Distinguished Name attribute. "san" The attribute value is placed in the Subject Alternative Name extension of the certificate. "sda" The attribute value is stored an a Subject Directory Attributes extension. certRef (Required): A reference to the corresponding attribute or name field where the attribute value is stored in the certificate. The certRef holds a string value which is dependent in the certNameType in the following way: "rdn" A string representation of the OID of the attribute that holds the corresponding attribute value in the subject field. "sda" A string representation of the OID of the attribute that holds the corresponding attribute value in the subject directory attributes extension. "san" A string representation of the explicit tag number of the Subject Alternative Name type (e.g. "1" = e-mail address (rfc822Name) and "2" = dNSName). If the Santesson Expires August 16, 2013 [Page 7] INTERNET DRAFT Authentication Context Extension February 12, 2013 SubjectAlternative name is an otherName, then the certRef holds a string representation of the OID defining the otherName form. String representations of object identifiers (OID) MUST be represented by a sequence of integers separated by a period. E.g. "2.5.4.32". This string MUST NOT contain any white-space or line breaks. SAML attributes name URI (in samlAttr) may also express an OID, but in order to maintain compatibility with SAML attribute definitions, this MUST allways be expressed in URI form. For OIDs this form MUST be a string that starts with "urn:oid:" and ends with a string representation of the OID (e.g. "urn:oid:2.5.4.42"). Santesson Expires August 16, 2013 [Page 8] INTERNET DRAFT Authentication Context Extension February 12, 2013 3 Security Considerations This extension allows a CA to outsource the process to identify and authenticate a subject to another trust infrastructure in a dynamic manner that may differ form certificate to certificate. Since the authentication context is explicitly declared in the certificate, one certificate may be issued with a lower level of assurance than another. This means that the relying party need to be aware of the certificate policy under which this CA operates in order to understand when the certificate provides a level of assurance with regard to subject authentication that is higher than the lowest provided level. A relying party that is not capable of understanding the information in the authentication context extension MUST assume that the certificate is issued using the lowest allowed level of assurance declared by the policy. 4 IANA Considerations This document contains no actions for IANA. 5 References 5.1 Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3739] Santesson, S., Nystrom, M., and T. Polk, "Internet X.509 Public Key Infrastructure: Qualified Certificates Profile", RFC 3739, March 2004. [RFC5280] 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. [RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, June 2010. [SAML] Scot Cantor, John Kemp, Rob Philpott, Eve Maler, "Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML) V2.0", OASIS Standard, 15 March 2005 Santesson Expires August 16, 2013 [Page 9] INTERNET DRAFT Authentication Context Extension February 12, 2013 5.2 Informative References [JSON-SCHEMA] F. Galiegue, K. Zyp, "JSON Schema: core definitions and terminology", draft-zyp-json-schema-04, January 31, 2013. Appendix A - ASN.1 modules This appendix includes the ASN.1 modules for the Authentication Context extension. Appendix B.1 includes an ASN.1 module that conforms to the 1998 version of ASN.1. Appendix B.2 includes an ASN.1 module, corresponding to the module present in B.1, that conforms to the 2008 version of ASN.1. Although a 2008 ASN.1 module is provided, the module in Appendix B.1 remains the normative module as per policy adopted by the PKIX working group for certificate related specifications. A.1 ASN.1 1988 Syntax ACE-88 {iso(1) member-body(2) se(752) e-legitimationsnamnden(201) id-mod(0) id-mod-auth-context-88(1)} DEFINITIONS EXPLICIT TAGS ::= BEGIN IMPORTS -- Certificate Extensions Extensions FROM PKIX1Explicit88 { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-explicit(18) }; -- Authentication Context Extension AuthenticationContexts ::= SEQUENCE { authContext AuthenticationContext } AuthenticationContext ::= SEQUENCE { contextType OBJECT IDENTIFIER, mimeType PrintableString OPTIONAL, contextInfo OCTET STRING } Santesson Expires August 16, 2013 [Page 10] INTERNET DRAFT Authentication Context Extension February 12, 2013 id-eleg-ce OBJECT IDENTIFIER ::= { e-legitimationsnamnden 5 } id-ce-authContext OBJECT IDENTIFIER ::= { id-eleg-ce 1 } END A.2 ASN.1 2008 Syntax ACE-08 {iso(1) member-body(2) se(752) e-legitimationsnamnden(201) id-mod(0) id-mod-auth-context-08(2)} DEFINITIONS EXPLICIT TAGS ::= BEGIN IMPORTS Extensions{}, EXTENSION FROM PKIX-CommonTypes-2009 -- From [RFC5912] {iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-pkixCommon-02(57)} ext-AuthenticationContext EXTENSION ::= { SYNTAX AuthenticationContexts IDENTIFIED BY id-ce-authContext } AuthenticationContexts ::= SEQUENCE SIZE (1..MAX) { authContext AuthenticationContext } AuthenticationContext ::= SEQUENCE { contextType OBJECT IDENTIFIER {{id-ct-saml-ac,...}}, mimeType PrintableString OPTIONAL, contextInfo OCTET STRING } id-eleg-ce OBJECT IDENTIFIER ::= { e-legitimationsnamnden 5 } id-eleg-ct OBJECT IDENTIFIER ::= { e-legitimationsnamnden 6 } id-ce-authContext OBJECT IDENTIFIER ::= { id-eleg-ce 1 } id-ct-saml-ac OBJECT IDENTIFIER ::= { id-eleg-ct 1} END Appendix B - SAML Authentication Context Data Structures This appendix includes data structure definitions for the SAML Authentication context information defined in section 3. Santesson Expires August 16, 2013 [Page 11] INTERNET DRAFT Authentication Context Extension February 12, 2013 Data structure definitions using JSON schema [JSON-SCEMA] is provided in B.1 and a corresponding definition using Java Classes is provided in B.2. As the JSON schema currently is in draft form the definitions provided B.2 is the normative one. B.1 JSON Schema { "type": "object", "$schema": "http://json-schema.org/schema#", "required": false, "properties": { "authContextInfo": { "description": "SAML Authentication Context Information", "type": "object", "required": false, "properties": { "identityProvider": { "type": "string", "required": true }, "authenticationInstant": { "type": "date-time", "required": true }, "authnContextClassRef": { "type": "string", "required": true }, "assertionRef": { "type": "string", "required": false }, "serviceID": { "type": "string", "required": false } } }, "idAttributes": { "description": "Information about subject attributes", "type": "array", "required": false, "items": { "type": "object", "required": false, "properties": { "name": { Santesson Expires August 16, 2013 [Page 12] INTERNET DRAFT Authentication Context Extension February 12, 2013 "type": "string", "required": false }, "samlAttr": { "type": "string", "required": true }, "attrValue": { "type": "string", "required": true }, "certNameType": { "type": "string", "enum": [ "rdn", "san", "sda" ], "required": true }, "certRef": { "type": "string", "required": true } } } } } } B.2 JAVA Class Declaration This section defines the content of the SAML Authentication Context data structure using Java Syntax. The JSON string is obtained by serializing an object of the class AuthContextJsonData to JSON. These Java classes only defines structure, but not whether a particular element is mandatory or optional. Requirements on mandatory or optionally elements is provided in section 3 as well as in the JSON schema provided in section B.1. class AuthContextJsonData { AuthContextInfo authContextInfo; IdAttributes[] idAttributes; } class AuthContextInfo { String identityProvider; Santesson Expires August 16, 2013 [Page 13] INTERNET DRAFT Authentication Context Extension February 12, 2013 Date authenticationInstant; String authnContextClassRef; String assertionRef; String serviceID; } class IdAttributes { String name; String samlAttr; String attrValue; CertNameType certNameType; String certRef; } enum CertNameType { rdn, san, sda; } B.2 Example { "authContextInfo": { "identityProvider": "https://idp.example.com/shibboleth", "authenticationInstant": "Feb 12, 2013 12:34:47 AM", "authnContextClassRef": "urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport", "assertionRef": "_e774ccf2b68ae4324f4ed565bcb9af40", "serviceID": "ca.example.com" }, "idAttributes": [ { "name": "Given Name", "samlAttr": "urn:oid:2.5.4.42", "attrValue": "John", "certNameType": "rdn", "certRef": "2.5.4.42" }, { "name": "Surname", "samlAttr": "urn:oid:2.5.4.4", "attrValue": "Doe", "certNameType": "rdn", "certRef": "2.5.4.4" }, { "name": "Swedish Personnummer", "samlAttr": "urn:oid:1.2.752.29.4.13", Santesson Expires August 16, 2013 [Page 14] INTERNET DRAFT Authentication Context Extension February 12, 2013 "attrValue": "200007292386", "certNameType": "rdn", "certRef": "2.5.4.5" }, { "name": "E-mail", "samlAttr": "urn:oid:0.9.2342.19200300.100.1.3", "attrValue": "john.doe@example.com", "certNameType": "san", "certRef": "1" } ] } Authors' Addresses Stefan Santesson 3xA Security AB Scheelev. 17 223 70 Lund Sweden EMail: sts@aaa-sec.com Santesson Expires August 16, 2013 [Page 15]