idnits 2.17.1 draft-young-md-query-saml-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 (January 16, 2020) is 1562 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-20) exists of draft-young-md-query-12 -- Obsolete informational reference (is this intentional?): RFC 4844 (Obsoleted by RFC 8729) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group I. Young, Ed. 3 Internet-Draft Independent 4 Intended status: Informational January 16, 2020 5 Expires: July 19, 2020 7 SAML Profile for the Metadata Query Protocol 8 draft-young-md-query-saml-12 10 Abstract 12 This document profiles the Metadata Query Protocol for use with SAML 13 metadata. 15 This document is a product of the Research and Education Federations 16 (REFEDS) Working Group process. 18 Editorial Note (To be removed by RFC Editor before publication) 20 Discussion of this draft takes place on the MDX mailing list 21 (mdx@lists.iay.org.uk), which is accessed from [MDX.list]. 23 XML versions, latest edits and the issues list for this document are 24 available from [md-query]. 26 The changes in this draft are summarized in Appendix A.13. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on July 19, 2020. 45 Copyright Notice 47 Copyright (c) 2020 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (https://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.1. Notation and Conventions . . . . . . . . . . . . . . . . 3 61 2. Request Profile . . . . . . . . . . . . . . . . . . . . . . . 3 62 2.1. Content Type . . . . . . . . . . . . . . . . . . . . . . 3 63 2.2. Identifiers . . . . . . . . . . . . . . . . . . . . . . . 4 64 2.2.1. Unique Identifier . . . . . . . . . . . . . . . . . . 4 65 2.2.2. Transformed Identifier . . . . . . . . . . . . . . . 4 66 2.2.3. Additional Identifiers . . . . . . . . . . . . . . . 5 67 3. Response Profile . . . . . . . . . . . . . . . . . . . . . . 5 68 3.1. Response Cardinality . . . . . . . . . . . . . . . . . . 5 69 3.1.1. No Entity Descriptors Returned . . . . . . . . . . . 5 70 3.1.2. One Entity Descriptor Returned . . . . . . . . . . . 5 71 3.1.3. More Than One Entity Descriptor Returned . . . . . . 5 72 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 73 4.1. Integrity . . . . . . . . . . . . . . . . . . . . . . . . 6 74 4.2. Use of SHA-1 in Transformed Identifiers . . . . . . . . . 6 75 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 76 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 77 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 78 7.1. Normative References . . . . . . . . . . . . . . . . . . 7 79 7.2. Informative References . . . . . . . . . . . . . . . . . 8 80 Appendix A. Change Log (to be removed by RFC Editor before 81 publication) . . . . . . . . . . . . . . . . . . . . 10 82 A.1. draft-young-md-query-saml-00 . . . . . . . . . . . . . . 10 83 A.2. Since draft-young-md-query-saml-00 . . . . . . . . . . . 10 84 A.3. Since draft-young-md-query-saml-01 . . . . . . . . . . . 10 85 A.4. Since draft-young-md-query-saml-02 . . . . . . . . . . . 10 86 A.5. Since draft-young-md-query-saml-03 . . . . . . . . . . . 10 87 A.6. Since draft-young-md-query-saml-04 . . . . . . . . . . . 10 88 A.7. Since draft-young-md-query-saml-05 . . . . . . . . . . . 10 89 A.8. Since draft-young-md-query-saml-06 . . . . . . . . . . . 10 90 A.9. Since draft-young-md-query-saml-07 . . . . . . . . . . . 10 91 A.10. Since draft-young-md-query-saml-08 . . . . . . . . . . . 11 92 A.11. Since draft-young-md-query-saml-09 . . . . . . . . . . . 11 93 A.12. Since draft-young-md-query-saml-10 . . . . . . . . . . . 11 94 A.13. Since draft-young-md-query-saml-11 . . . . . . . . . . . 11 95 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 97 1. Introduction 99 This document profiles the Metadata Query Protocol 100 [I-D.young-md-query] for use with SAML metadata [SAML2Meta]. 102 The Research and Education Federations group ([REFEDS]) is the voice 103 that articulates the mutual needs of research and education identity 104 federations worldwide. It aims to represent the requirements of 105 research and education in the ever-growing space of access and 106 identity management. 108 From time to time REFEDS will wish to publish a document in the 109 Internet RFC series. Such documents will be published as part of the 110 RFC Independent Submission Stream [RFC4844]; however the REFEDS 111 working group sign-off process will have been followed for these 112 documents, as described in the REFEDS Participant's Agreement 113 [REFEDS.agreement]. 115 This document is a product of the REFEDS Working Group process. 117 1.1. Notation and Conventions 119 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 120 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 121 "OPTIONAL" in this document are to be interpreted as described in 122 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 123 capitals, as shown here. 125 This document makes use of the Augmented BNF metalanguage defined in 126 [STD68]. 128 2. Request Profile 130 2.1. Content Type 132 Requests compliant with this profile MUST include the following HTTP 133 header to indicate that the metadata returned should be SAML metadata 134 (see Appendix A of [SAML2Meta]): 136 Accept: application/samlmetadata+xml 138 2.2. Identifiers 140 2.2.1. Unique Identifier 142 Each entity known to the responder MUST be associated with the unique 143 identifier of the entity, corresponding to the "entityID" attribute 144 of the entity's "EntityDescriptor" element in SAML metadata. 146 2.2.2. Transformed Identifier 148 SAML 2.0 [SAML2Core] includes profiles based on the transfer of an 149 "artifact" containing the unique identifier of a SAML entity 150 transformed by means of the SHA-1 [RFC3174] hash algorithm (see 151 [SAML2Bind] sections 3.6 and 3.6.4). 153 In order to support use cases in which clients may be in possession 154 of only such a transformed representation of a SAML entity's unique 155 identifier without any way to establish the original entity 156 identifier, a responder compliant with this profile MUST associate 157 each entity with an identifier matching the "sha1id" production in 158 the following ABNF grammar, and treat such an identifier as 159 equivalent to the corresponding untransformed identifier: 161 SHA1 = %x73 %x68 %x61 %x31 ; lower case "sha1" 162 DIGIT = %x30-39 163 HEXDIGIT = DIGIT | %x61-66 ; lower case a-f 164 sha1id = "{" SHA1 "}" sha1hex 165 sha1hex = 40*HEXDIGIT 167 In the above, the "sha1hex" component encodes the 20-octet (160-bit) 168 binary SHA-1 hash value as a sequence of 40 lower case hexadecimal 169 digits. 171 For example, the identifier 173 http://example.org/service 175 transformed by means of SHA-1 hashing would become 177 {sha1}11d72e8cf351eb6c75c721e838f469677ab41bdb 179 Responder implementations MAY detect malformed SHA-1 transformed 180 identifiers (for example where the string of characters following the 181 "}" contains characters other than hexadecimal digits, or is other 182 than exactly 40 characters in length) and return an HTTP status code 183 of 400 ("bad request"). Alternatively, implementations MAY process 184 these as normal identifiers and return an HTTP status code of 404 185 ("not found") if appropriate. 187 2.2.3. Additional Identifiers 189 Entities MAY also be associated with any number of additional 190 responder-defined identifiers naming arbitrary groups of entities. 192 3. Response Profile 194 3.1. Response Cardinality 196 A request may return information for any number of entities, 197 including none. Responses compliant with this profile MUST use the 198 appropriate representation described below depending on the number of 199 "EntityDescriptor" elements returned. 201 3.1.1. No Entity Descriptors Returned 203 A response which returns no "EntityDescriptor" elements MUST be 204 represented by an HTTP status code of 404 ("not found"). 206 3.1.2. One Entity Descriptor Returned 208 A response which returns a single "EntityDescriptor" element MUST use 209 that element as its document element. The responder MUST NOT make 210 use of a "EntitiesDescriptor" element in this situation (see 211 [SAML2Meta] section 2.3). 213 Such a response MUST include the following HTTP header to indicate 214 that the metadata returned is SAML metadata: 216 Content-Type: application/samlmetadata+xml 218 3.1.3. More Than One Entity Descriptor Returned 220 A response which returns more than one "EntityDescriptor" element 221 MUST consist of a document element which is an "EntitiesDescriptor" 222 element, containing the returned "EntityDescriptor" elements as 223 children. Responses MUST NOT contain nested "EntitiesDescriptor" 224 elements. 226 Such a response MUST include the following HTTP header to indicate 227 that the metadata returned is SAML metadata: 229 Content-Type: application/samlmetadata+xml 231 4. Security Considerations 233 4.1. Integrity 235 As SAML metadata contains information necessary for the secure 236 operation of interacting services it is strongly RECOMMENDED that a 237 mechanism for integrity checking is provided to clients. 239 It is RECOMMENDED that the integrity checking mechanism provided by a 240 responder is a digital signature embedded in the returned metadata 241 document, as defined by [SAML2Meta] section 3. 243 Such digital signatures: 245 o SHOULD use an RSA keypair whose modulus is no less than 2048 bits 246 in length. 248 o MUST NOT use the SHA-1 cryptographic hash algorithm as a digest 249 algorithm. 251 o MUST NOT use the MD5 cryptographic hash algorithm as a digest 252 algorithm. 254 o SHOULD otherwise follow current cryptographic best practices in 255 algorithm selection. 257 4.2. Use of SHA-1 in Transformed Identifiers 259 This profile mandates the availability of an identifier synonym 260 mechanism based on the SHA-1 cryptographic hash algorithm. Although 261 SHA-1 is now regarded as weak enough to exclude it from use in new 262 cryptographic systems, its use in this profile is necessary for full 263 support of the SAML 2.0 standard. 265 The use of SHA-1 in section 3.6.4 of [SAML2Bind], and its resulting 266 use in this protocol, would be vulnerable to an attack in which 267 metadata was introduced into a system by an attacker capable of 268 creating an entity identifier with the same SHA-1 hash as that of an 269 existing entity's identifier. 271 Such an identifier is known as a _second preimage_ of the original, 272 and SHA-1's resistance to discovery of it is referred to as SHA-1's 273 _second-preimage resistance_. 275 As demonstrated by the the [SHAttered] and [Shambles] attacks, the 276 SHA-1 algorithm is known to have weak collision resistance. However, 277 at the time of writing no attacks are known on SHA-1's second- 278 preimage resistance; a result in this area would be required to 279 provide the basis of an attack based on duplicating the SHA-1 hash of 280 an existing identifier. As a result, the use of SHA-1 in SAML and in 281 this protocol is not believed to introduce a security concern. 283 Implementations may guard against the possibility of a future 284 practical attack on the second-preimage resistance of SHA-1 by 285 treating two entities whose "entityID" values have the same SHA-1 286 equivalent as an indicator of malicious intent on the part of the 287 owner of one of the entities. 289 5. IANA Considerations 291 This document has no actions for IANA. 293 6. Acknowledgements 295 The editor would like to acknowledge the following individuals for 296 their contributions to this document: 298 Scott Cantor (The Ohio State University) 300 Leif Johansson (SUNET) 302 Joe St Sauver (University of Oregon) 304 Tom Scavo (Internet2) 306 7. References 308 7.1. Normative References 310 [I-D.young-md-query] 311 Young, I., Ed., "Metadata Query Protocol", draft-young-md- 312 query-12 (work in progress), January 2020. 314 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 315 Requirement Levels", BCP 14, RFC 2119, 316 DOI 10.17487/RFC2119, March 1997, 317 . 319 [RFC3174] Eastlake 3rd, D. and P. Jones, "US Secure Hash Algorithm 1 320 (SHA1)", RFC 3174, DOI 10.17487/RFC3174, September 2001, 321 . 323 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 324 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 325 May 2017, . 327 [SAML2Bind] 328 Cantor, S., Hirsch, F., Kemp, J., Philpott, R., and E. 329 Maler, "Bindings for the Security Assertion Markup 330 Language (SAML) V2.0", OASIS Standard saml-bindings- 331 2.0-os, March 2005. 333 [SAML2Meta] 334 Cantor, S., Moreh, J., Philpott, R., and E. Maler, 335 "Metadata for the Security Assertion Markup Language 336 (SAML) V2.0", OASIS Standard saml-metadata-2.0-os, March 337 2005. 339 [STD68] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 340 Specifications: ABNF", STD 68, RFC 5234, 341 DOI 10.17487/RFC5234, January 2008, 342 . 344 7.2. Informative References 346 [md-query] 347 Young, I., Ed., "md-query Project", 348 . 350 [MDX.list] 351 Young, I., Ed., "MDX Mailing List", 352 . 354 [REFEDS] Research and Education Federations, "REFEDS Home Page", 355 . 357 [REFEDS.agreement] 358 Research and Education Federations, "REFEDS Participant's 359 Agreement", 360 . 362 [RFC4844] Daigle, L., Ed. and Internet Architecture Board, "The RFC 363 Series and RFC Editor", RFC 4844, DOI 10.17487/RFC4844, 364 July 2007, . 366 [SAML2Core] 367 Cantor, S., Kemp, J., Philpott, R., and E. Maler, 368 "Assertions and Protocol for the OASIS Security Assertion 369 Markup Language (SAML) V2.0", OASIS Standard saml-core- 370 2.0-os, March 2005, . 373 [Shambles] 374 "SHA-1 is a Shambles", January 2020, 375 . 377 [SHAttered] 378 "SHAttered", February 2017, . 380 Appendix A. Change Log (to be removed by RFC Editor before publication) 382 A.1. draft-young-md-query-saml-00 384 Initial version. 386 A.2. Since draft-young-md-query-saml-00 388 Added REFEDS RFC stream boilerplate. 390 A.3. Since draft-young-md-query-saml-01 392 Bump reference to the Metadata Query Protocol [I-D.young-md-query]. 394 Rework Section 2.2 to make the role of transformed identifiers 395 clearer. This changes the semantics slightly (malformed transformed 396 identifiers may now result in a 404 return rather than 400) but this 397 gives implementers more latitude in the way that they handle the 398 feature. 400 A.4. Since draft-young-md-query-saml-02 402 Bump reference to the Metadata Query Protocol [I-D.young-md-query]. 404 A.5. Since draft-young-md-query-saml-03 406 Bump reference to the Metadata Query Protocol [I-D.young-md-query]. 408 Added an Editorial Note to help direct readers back to the 409 discussion. 411 A.6. Since draft-young-md-query-saml-04 413 Fix reference to the Metadata Query Protocol [I-D.young-md-query]. 415 A.7. Since draft-young-md-query-saml-05 417 Bump reference to the Metadata Query Protocol [I-D.young-md-query]. 419 A.8. Since draft-young-md-query-saml-06 421 Bump reference to the Metadata Query Protocol [I-D.young-md-query]. 423 A.9. Since draft-young-md-query-saml-07 425 Bump reference to the Metadata Query Protocol [I-D.young-md-query]. 427 A.10. Since draft-young-md-query-saml-08 429 Bump reference to the Metadata Query Protocol [I-D.young-md-query]. 431 Modernise normative language to include [RFC8174]. 433 Improved references to RFCs. 435 A.11. Since draft-young-md-query-saml-09 437 Bump reference to the Metadata Query Protocol [I-D.young-md-query]. 439 A.12. Since draft-young-md-query-saml-10 441 Bump reference to the Metadata Query Protocol [I-D.young-md-query]. 443 Replace citations in the abstract with straight textual mentions, as 444 required by the ID-NITS checklist. 446 A.13. Since draft-young-md-query-saml-11 448 Bump reference to the Metadata Query Protocol [I-D.young-md-query]. 450 Strengthen Section 4.1 so that SHA-1 now MUST NOT be used in the 451 context of digital signatures. This brings the section in line with 452 current best practice recommendations, particularly in light of the 453 [SHAttered] and [Shambles] attacks. 455 Revised Section 4.2 on the use of SHA-1 in transformed identifiers 456 to: 458 o Make clear that this is a SAML-level issue, not one introduced by 459 the query protocol. 461 o Reference the attacks demonstrating SHA-1's weak collision 462 resistance. 464 o Identify second-preimage resistance as the potential source of the 465 attack we'd be concerned about for the query protocol. 467 o Note that SHA-1's second-preimage resistance is at present 468 uncompromised. 470 Author's Address 471 Ian A. Young (editor) 472 Independent 474 EMail: ian@iay.org.uk