idnits 2.17.1 draft-santesson-auth-context-extension-12.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 -- The document date (November 26, 2015) is 3067 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) ** Downref: Normative reference to an Informational RFC: RFC 5912 -- Possible downref: Non-RFC (?) normative reference: ref. 'SAML' -- Possible downref: Non-RFC (?) normative reference: ref. 'XML' -- Possible downref: Non-RFC (?) normative reference: ref. 'Schema1' -- Possible downref: Non-RFC (?) normative reference: ref. 'Schema2' Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Stefan Santesson 3 Intended Status: Standards track (3xA Security) 4 Expires: May 29, 2016 November 26, 2015 6 Authentication Context Certificate Extension 7 draft-santesson-auth-context-extension-12 9 Abstract 11 This document defines an extension to X.509 certificates. The 12 extension defined in this document holds data about how the 13 certificate subject was authenticated by the Certification Authority 14 that issued the certificate in which this extension appears. 16 This document also defines one data structure for inclusion in this 17 Extension. The data structure is designed to hold information when 18 the subject is authenticated using a Security Assertion Markup 19 Language (SAML) assertion. 21 Status of this Memo 23 This Internet-Draft is submitted to IETF in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as 29 Internet-Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/1id-abstracts.html 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html 42 Copyright and License Notice 44 Copyright (c) 2015 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 61 1.2 Deployment . . . . . . . . . . . . . . . . . . . . . . . . 4 62 2. Authentication Context Extension Syntax . . . . . . . . . . . 5 63 3 SAML Authentication Context Information . . . . . . . . . . . . 5 64 3.1 contextInfo Data Structure . . . . . . . . . . . . . . . . 6 65 3.1.1 AuthContextInfo Element . . . . . . . . . . . . . . . 6 66 3.1.2 IdAttributes Element . . . . . . . . . . . . . . . . . 8 67 4 Security Considerations . . . . . . . . . . . . . . . . . . . . 10 68 5 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 10 69 6 References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 70 6.1 Normative References . . . . . . . . . . . . . . . . . . . 10 71 6.2 Informative References . . . . . . . . . . . . . . . . . . 11 72 Appendix A - ASN.1 modules . . . . . . . . . . . . . . . . . . . . 11 73 A.1 ASN.1 1988 Syntax . . . . . . . . . . . . . . . . . . . . . 11 74 A.2 ASN.1 2008 Syntax . . . . . . . . . . . . . . . . . . . . . 12 75 Appendix B - SAML Authentication Context Info XML Schema . . . . . 13 76 B.1 XML Schema . . . . . . . . . . . . . . . . . . . . . . . . 13 77 Appendix C - SAML Authentication Context Info XML Examples . . . . 15 78 C.1 Complete context information and mappings . . . . . . . . . 15 79 C.2 Only mapping information without SAML attribute values . . 16 80 C.3 Authentication context and serialNmber mapping . . . . . . 17 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 83 1 Introduction 85 The primary purpose of this document is to provide a mechanism that 86 allows an application to obtain information that expresses the 87 identity of a subject in an X.509 certificate according to [RFC5280]. 88 The identity is stored either in a subject field attribute, as a 89 subject alternative name, or in a subject directory attribute. 91 The motivation for this work is to enable mapping of identity data 92 between an identity system and a certificate where the identity 93 system and the certificate are using different attributes and data 94 formats to express the identity of the same entity. In such scenario, 95 the certificate subject already has an authenticated identity 96 composed of a set of attributes, or so called claims, that differ 97 from the attributes commonly used to express the identity of a 98 certificate subject, which may be governed by a specific certificate 99 profile limiting the set of certificate attributes. 101 A typical scenario motivating the definition of this extension arises 102 when the source of user authentication and user identity is derived 103 from a SAML [SAML] federation attribute profile. In a SAML 104 federation, the subject presents a SAML assertion in exchange for a 105 certificate that can be uniquely linked to information provided in 106 the original SAML assertion - eg attributes and/or level of assurance 107 indicators. 109 Such certificates are sometimes issued in order to provide the user 110 with a means to create an electronic signature that ties the user to 111 the SAML subject, its attributes and level of assurance indicators. 113 If such certificate needs to conform to a certificate profile such as 114 [RFC3739], then this certificate may have to use a separate set of 115 attributes to express the subject identity. The certificate also may 116 have to employ a different format for attribute values, vs. the set 117 of attributes obtained from the SAML assertion. 119 The extension defined in the document makes it possible to represent 120 information about the authentication context employed when 121 authenticating the subject for the purpose of issuing a certificate. 122 This may include information such as: 124 o The Identity Provider that authenticated the subject. 125 o The level of assurance with which the subject was authenticated. 126 o The trust framework where this level of assurance was defined. 127 o A unique reference to the authentication instant 128 o A mapping between the subject attributes obtained from the SAML 129 assertion used to authenticate the subject, and the subject 130 identity information placed in the issued certificate. 132 One scenario where this information may be useful arises when a user 133 logs in to a service using SAML credentials, and the same user (at 134 some point) is required to sign some information. The service may 135 need to verify that the signature was created by the same user that 136 logged on to the service. Today this is only possible using out-of- 137 band knowledge about the Certification Authority (CA) that issued the 138 certificate and it's practices. However, this approach does not scale 139 to a large number of service providers, identity providers, and CAs. 141 The extension defined here provides better scalability since it 142 requires only the service provider to maintain a list of trusted CAs. 143 All other information about the relationship between the certificate 144 subject, and the SAML authenticated subject is available in the 145 certificate. 147 1.1 Terminology 149 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 150 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 151 document are to be interpreted as described in RFC 2119 [RFC2119]. 153 1.2 Deployment 155 EDITORS NOTE: 156 [This section provided information for better understanding the 157 rationale of the extension. This section can be deleted when the 158 document is published] 160 The extension described in this draft has been defined and deployed 161 in the National Swedish Identity infrastructure (eID) which is based 162 on SAML federated identity. The Swedish infrastructure went live in 163 2013 and provides secure identification of citizens for Swedish 164 government services. A central requirement in these government 165 services is to allow citizens to sign various documents, representing 166 a wide range of declarations and applications. 168 A central part of this infrastructure is therefore to use centralized 169 signature services that allows citizens to sign based on their SAML 170 credentials. Service providers authenticate and understand user 171 identities only under a SAML context within this national 172 infrastructure. Thus this extension allows Service Providers to 173 determine whether a presented signature matches a particular user and 174 whether it meets the security requirements of the service. 176 Through information provided in this extension a service provider 177 may, for example, receive notice that the user logged on using one 178 level of assurance, but presented a signature verifiable using a 179 certificate obtained using a lower level of assurance. In such 180 circumstances the service provider might reject the signature. 182 This extension is therefore fundamental to the function of the 183 Swedish eID infrastructure. 185 2. Authentication Context Extension Syntax 187 The Authentication Context extension has the following syntax: 189 AuthenticationContexts ::= SEQUENCE SIZE (1..MAX) OF 190 AuthenticationContext 192 AuthenticationContext ::= SEQUENCE { 193 contextType UTF8String, 194 contextInfo UTF8String OPTIONAL 195 } 197 This extension holds a sequence of AuthenticationContext information. 198 When present, this extension MUST include at least one 199 AuthenticationContext. 201 The type of authentication context defined in AuthenticationContext 202 is identified by the contextType. The contextType MUST contain a URI 203 that identifies the context type as well as data format and encoding 204 of context information provided in contextInfo. 206 This extension MAY be marked critical. 208 Applications that find an authentication context information type 209 they do not understand MUST ignore it if the extension is non- 210 critical, and MUST reject the certificate if the extension is marked 211 critical. If an application requires that an authentication context 212 exist, and either the extension is absent, or none of the provided 213 authentication contexts can be used, the end user certificate fails 214 validation. 216 This document defines one authentication context information type 217 (Section 3) that is used to provide information about SAML based 218 authentication of the subject that was utilized in the certificate 219 issuance process. Other documents can define other authentication 220 context information types. 222 3 SAML Authentication Context Information 224 The SAML Authentication context information provides a contextType 225 field that can be used to carry information about SAML-based 226 authentication of the certified subject as utilized in the 227 certificate issuance process. 229 The data carried in this authentication context information field is 230 identified by the following XML Schema [Schema1] and [Schema2] name 231 space: 233 http://id.elegnamnden.se/auth-cont/1.0/saci 235 When this URI is specified as contextType, the associated XML data 236 provided in contextInfo MUST be provided as an UTF-8 encoded XML 237 [XML] string. 239 3.1 contextInfo Data Structure 241 The data provided in contextInfo SHALL contain UTF-8 encoded XML in 242 accordance with the XML schema provided in Appendix B. The XML 243 document string in contextInfo MUST NOT include an XML header. That 244 is, the XML document string contains only the root element 245 with it's child elements and 246 . 248 The and elements are outlined in the 249 following subsections. 251 3.1.1 AuthContextInfo Element 253 The element MAY be present. This element contains 254 the following attributes: 256 IdentityProvider (required): The SAML EntityID of the 257 Identity Provider which authenticated the 258 subject. 259 AuthenticationInstant (required): Date and time when the subject 260 was authenticated, expressed according to 261 Appendix B.1. 262 AuthnContextClassRef (required): A URI identifying the 263 AuthnContextClassRef that is provided in the 264 AuthnStatement of the Assertion that was 265 used to authenticate the subject. This URI 266 identifies the context and the level of 267 assurance associated with this instance of 268 authentication. 269 AssertionRef (optional): A unique reference to the SAML 270 Assertion 272 ServiceID (optional): An identifier of the service 273 that verified the SAML assertion. 275 The element may hold any number of child elements 276 of type any (processContents="lax"), providing additional information 277 according to local conventions. Any such elements SHOULD be ignored 278 if not understood. 280 3.1.2 IdAttributes Element 282 The element MAY be present. This element holds a 283 sequence of one or more elements, where each 284 element contains mapping information about one 285 certificate subject attribute or name form present in the 286 certificate. 288 Each element MUST specify the following 289 attributes: 291 Type A string containing one of the enumerated values "rdn", 292 "san" or "sda", specifying the type of certificate attribute 293 or name form for which mapping information is provided: 295 "rdn" Mapping information is provided for an attribute in 296 a Relative Distinguished Name located in the 297 subject field. 298 "san" Mapping information is provided for a name in the 299 Subject Alternative Name extension of the 300 certificate. 301 "sda" Mapping information is provided for an attribute in 302 the Subject Directory Attributes extension. 304 Ref A reference to the specific attribute or name field. This 305 reference is dependent on the value of Type in the following 306 way: 308 "rdn" Ref holds a string representation of the object 309 identifier (OID) of the relative distinguished name 310 attribute. 311 "sda" Ref holds a string representation of the OID of the 312 subject directory attribute attribute. 313 "san" Ref holds a string representation of the explicit 314 tag number of the Subject Alternative Name type 315 (e.g. "1" = e-mail address (rfc822Name) and "2" = 316 dNSName). If the SubjectAlternative name is an 317 otherName, then Ref holds a string representation 318 of the OID defining the otherName form. 320 String representations of object identifiers (OID) in the 321 Ref attribute MUST be represented by a sequence of integers 322 separated by a period. E.g. "2.5.4.32". This string contains 323 only numerals (ASCII 0x30 to 0x39) and periods (ASCII 0x2E), 324 and MUST NOT contain any other characters. 326 Each element MUST contain a 327 element as defined in [SAML]. This SAML attribute element MUST have a 328 Name attribute (specifying its type), MAY have other attributes and 329 MAY have zero or more child elements. A present 330 SAML attribute with absent attribute value limits mapping to the type 331 of SAML attribute that was used to obtain the value stored in the 332 referenced certificate subject attribute or name form, without 333 duplicating the actual attribute value. 335 If an attribute value is present in the SAML attribute, then the 336 value stored in the certificate in the referenced attribute or name 337 form MAY differ in format and encoding from the present SAML 338 attribute value. For example, a SAML attribute value can specify a 339 country expressed as "Sweden" while this country value is stored in 340 the certificate in a countryName attribute using the two letter 341 country code "SE". 343 Several elements MAY be present for the same 344 certificate subject attribute or name form if the certificate 345 contains multiple instances of this attribute or name form where 346 their values were obtained from different SAML attributes. But in 347 such cases it is not defined which present subject attribute or name 348 form maps to which SAML attribute. A certificate-using application 349 MAY attempt to determine this by comparing attribute values stored in 350 this extension with attribute or name values present in the 351 certificate, but this specification does not define any explicit 352 matching rules that would guarantee an unambiguous result. 354 The element may hold any number of child elements 355 of type any (processContents="lax"), providing additional information 356 according to local conventions. Any such elements MAY be ignored if 357 not understood. 359 Note: The element is designed to provide mapping 360 between SAML attributes and certificate subject attributes and 361 name forms where there is a distinct and clear relationship 362 between relevant SAML attributes and corresponding certificate 363 attributes and name forms. This does not cover all aspects of 364 complex mapping situations. If more than one SAML attribute 365 maps to the same certificate attribute or if structured multi 366 valued attributes are split into a range of other attributes 367 and name forms, these situations are not covered. Such complex 368 mapping situations MAY be covered by extending this XML Schema 369 or by defining a more versatile context information schema. 371 4 Security Considerations 373 This extension allows a CA to outsource the process used to identify 374 and authenticate a subject to another trust infrastructure in a 375 dynamic manner that may differ from certificate to certificate. Since 376 the authentication context is explicitly declared in the certificate, 377 one certificate may be issued with a lower level of assurance than 378 another, even though both have the same Issuer. 380 This means that a relying party needs to be aware of the certificate 381 policy under which this CA operates in order to understand when the 382 certificate provides a level of assurance with regard to subject 383 authentication that is higher than the lowest provided level. A 384 relying party that is not capable of understanding the information in 385 the authentication context extension MUST assume that the certificate 386 is issued using the lowest allowed level of assurance declared by the 387 policy. 389 5 IANA Considerations 391 This document contains no actions for IANA. 393 6 References 395 6.1 Normative References 397 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 398 Requirement Levels", BCP 14, RFC 2119, DOI 399 10.17487/RFC2119, March 1997, . 402 [RFC3739] Santesson, S., Nystrom, M., and T. Polk, "Internet 403 X.509 Public Key Infrastructure: Qualified 404 Certificates Profile", RFC 3739, DOI 10.17487/RFC3739, 405 March 2004, . 407 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 408 Housley, R., and W. Polk, "Internet X.509 Public Key 409 Infrastructure Certificate and Certificate Revocation 410 List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, 411 May 2008, . 413 [RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the 414 Public Key Infrastructure Using X.509 (PKIX)", 415 RFC 5912, DOI 10.17487/RFC5912, June 2010, 416 . 418 [SAML] Scot Cantor, John Kemp, Rob Philpott, Eve Maler, 419 "Assertions and Protocols for the OASIS Security 420 Assertion Markup Language (SAML) V2.0", OASIS 421 Standard, 15 March 2005. 423 [XML] Extensible Markup Language (XML) 1.0 (Fifth Edition), 424 http://www.w3.org/TR/REC-xml/#sec-element-content, W3C 425 Recommendation 26 November 2008. 427 [Schema1] H. S. Thompson et al. XML Schema Part 1: Structures, 428 http://www.w3.org/TR/xmlschema-1/, W3C Recommendation, 429 May 2001. 431 [Schema2] P. V. Biron et al. XML Schema Part 2: Datatypes. 432 http://www.w3.org/TR/xmlschema-2/ , W3C 433 Recommendation, May 2001. 435 6.2 Informative References 437 No informational references 439 Appendix A - ASN.1 modules 441 This appendix includes the ASN.1 modules for the Authentication 442 Context extension. Appendix B.1 includes an ASN.1 module that 443 conforms to the 1998 version of ASN.1. Appendix B.2 includes an ASN.1 444 module, corresponding to the module present in B.1, that conforms to 445 the 2008 version of ASN.1. Although a 2008 ASN.1 module is provided, 446 the module in Appendix B.1 remains the normative module as per policy 447 adopted by the PKIX working group for certificate related 448 specifications. 450 A.1 ASN.1 1988 Syntax 452 ACE-88 453 {iso(1) member-body(2) se(752) e-legnamnden(201) 454 id-mod(0) id-mod-auth-context-88(1)} 456 DEFINITIONS EXPLICIT TAGS ::= 458 BEGIN 460 -- EXPORTS ALL -- 462 -- Authentication Context Extension 463 AuthenticationContexts ::= SEQUENCE SIZE (1..MAX) OF 464 AuthenticationContext 466 AuthenticationContext ::= SEQUENCE { 467 contextType UTF8String, 468 contextInfo UTF8String OPTIONAL 469 } 471 e-legnamnden OBJECT IDENTIFIER ::= { iso(1) member-body(2) 472 se(752) 201 } 473 id-eleg-ce OBJECT IDENTIFIER ::= { e-legnamnden 5 } 474 id-ce-authContext OBJECT IDENTIFIER ::= { id-eleg-ce 1 } 476 END 478 A.2 ASN.1 2008 Syntax 480 ACE-08 481 {iso(1) member-body(2) se(752) e-legnamnden(201) 482 id-mod(0) id-mod-auth-context-08(2)} 484 DEFINITIONS EXPLICIT TAGS ::= 485 BEGIN 486 EXPORTS ALL; 487 IMPORTS 489 Extensions{}, EXTENSION 490 FROM PKIX-CommonTypes-2009 -- From [RFC5912] 491 {iso(1) identified-organization(3) dod(6) internet(1) security(5) 492 mechanisms(5) pkix(7) id-mod(0) id-mod-pkixCommon-02(57)}; 494 -- Authentication Context Extension 496 ext-AuthenticationContext EXTENSION ::= { SYNTAX 497 AuthenticationContexts IDENTIFIED BY 498 id-ce-authContext } 500 AuthenticationContexts ::= SEQUENCE SIZE (1..MAX) OF 501 AuthenticationContext 503 AuthenticationContext ::= SEQUENCE { 504 contextType UTF8String, 505 contextInfo UTF8String OPTIONAL 506 } 508 ElegnamndenCertExtensions EXTENSION ::= { 509 ext-AuthenticationContext, ... } 511 e-legnamnden OBJECT IDENTIFIER ::= { iso(1) member-body(2) 512 se(752) 201 } 513 id-eleg-ce OBJECT IDENTIFIER ::= { e-legnamnden 5 } 514 id-ce-authContext OBJECT IDENTIFIER ::= { id-eleg-ce 1 } 516 END 518 Appendix B - SAML Authentication Context Info XML Schema 520 This appendix section B.1 includes an XML Schema ([Schema1] and 521 [Schema2]) for the SAML Authentication context information defined in 522 section 3. 524 IMPORTANT NOTE: The XML Schema in B.1 specifies a URL on row 9 and 10 525 to the SAML schemaLocation (http://docs.oasis- 526 open.org/security/saml/v2.0/saml-schema-assertion- 527 2.0.xsd), which is too long to fit into one row and 528 therefore contains a line-break. This line-break has to 529 be removed before this schema can be successfully 530 compiled. 532 B.1 XML Schema 534 535 541 545 547 548 549 550 551 552 553 555 556 557 559 560 562 564 566 567 568 570 571 572 573 575 576 577 579 580 581 582 584 585 586 587 588 589 590 591 592 593 594 595 596 598 Appendix C - SAML Authentication Context Info XML Examples 600 This appendix provides examples of SAML Authentication Context 601 information according to the schema in Appendix B. 603 C.1 Complete context information and mappings 605 This example provides a complete example with authentication context 606 information as well as mapping information for several subject field 607 attributes as well as a subject alt name. 609 613 619 620 621 624 SE 626 627 628 629 632 200007292386 634 635 636 637 640 John 642 643 644 645 648 Doe 650 651 652 653 656 John Doe 658 659 660 661 664 john.doe@example.com 666 667 668 669 671 C.2 Only mapping information without SAML attribute values 673 This example shows an instance of the SAML Authentication Context 674 information that only provides a mapping table without providing any 675 authentication context information or saml attribute values. 677 680 681 682 683 684 685 686 687 688 689 690 691 692 693 694 695 696 697 698 699 700 702 C.3 Authentication context and serialNmber mapping 704 This example shows an instance of the SAML Authentication Context 705 information, which provides authentication context information and 706 mapping information that specifies the source of the data stored in the 707 serialNumber attribute in the subject field. 709 713 719 720 721 724 200007292386 726 727 728 729 730 Authors' Addresses 732 Stefan Santesson 733 3xA Security AB 734 Scheelev. 17 735 223 70 Lund 736 Sweden 737 EMail: sts@aaa-sec.com