idnits 2.17.1 draft-young-md-query-saml-11.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 (July 21, 2019) is 1739 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-11 -- 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 July 21, 2019 5 Expires: January 22, 2020 7 SAML Profile for the Metadata Query Protocol 8 draft-young-md-query-saml-11 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.12. 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 January 22, 2020. 45 Copyright Notice 47 Copyright (c) 2019 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) . . . . . . . . . . . . . . . . . . . . 9 82 A.1. draft-young-md-query-saml-00 . . . . . . . . . . . . . . 9 83 A.2. Since draft-young-md-query-saml-00 . . . . . . . . . . . 9 84 A.3. Since draft-young-md-query-saml-01 . . . . . . . . . . . 9 85 A.4. Since draft-young-md-query-saml-02 . . . . . . . . . . . 9 86 A.5. Since draft-young-md-query-saml-03 . . . . . . . . . . . 9 87 A.6. Since draft-young-md-query-saml-04 . . . . . . . . . . . 9 88 A.7. Since draft-young-md-query-saml-05 . . . . . . . . . . . 9 89 A.8. Since draft-young-md-query-saml-06 . . . . . . . . . . . 9 90 A.9. Since draft-young-md-query-saml-07 . . . . . . . . . . . 9 91 A.10. Since draft-young-md-query-saml-08 . . . . . . . . . . . 10 92 A.11. Since draft-young-md-query-saml-09 . . . . . . . . . . . 10 93 A.12. Since draft-young-md-query-saml-10 . . . . . . . . . . . 10 94 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 96 1. Introduction 98 This document profiles the Metadata Query Protocol 99 [I-D.young-md-query] for use with SAML metadata [SAML2Meta]. 101 The Research and Education Federations group ([REFEDS]) is the voice 102 that articulates the mutual needs of research and education identity 103 federations worldwide. It aims to represent the requirements of 104 research and education in the ever-growing space of access and 105 identity management. 107 From time to time REFEDS will wish to publish a document in the 108 Internet RFC series. Such documents will be published as part of the 109 RFC Independent Submission Stream [RFC4844]; however the REFEDS 110 working group sign-off process will have been followed for these 111 documents, as described in the REFEDS Participant's Agreement 112 [REFEDS.agreement]. 114 This document is a product of the REFEDS Working Group process. 116 1.1. Notation and Conventions 118 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 119 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 120 "OPTIONAL" in this document are to be interpreted as described in 121 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 122 capitals, as shown here. 124 This document makes use of the Augmented BNF metalanguage defined in 125 [STD68]. 127 2. Request Profile 129 2.1. Content Type 131 Requests compliant with this profile MUST include the following HTTP 132 header to indicate that the metadata returned should be SAML metadata 133 (see Appendix A of [SAML2Meta]): 135 Accept: application/samlmetadata+xml 137 2.2. Identifiers 139 2.2.1. Unique Identifier 141 Each entity known to the responder MUST be associated with the unique 142 identifier of the entity, corresponding to the "entityID" attribute 143 of the entity's "EntityDescriptor" element in SAML metadata. 145 2.2.2. Transformed Identifier 147 SAML 2.0 [SAML2Core] includes profiles based on the transfer of an 148 "artifact" containing the unique identifier of a SAML entity 149 transformed by means of the SHA-1 [RFC3174] hash algorithm (see 150 [SAML2Bind] sections 3.6 and 3.6.4). 152 In order to support use cases in which clients may be in possession 153 of only such a transformed representation of a SAML entity's unique 154 identifier without any way to establish the original entity 155 identifier, a responder compliant with this profile MUST associate 156 each entity with an identifier matching the "sha1id" production in 157 the following ABNF grammar, and treat such an identifier as 158 equivalent to the corresponding untransformed identifier: 160 SHA1 = %x73 %x68 %x61 %x31 ; lower case "sha1" 161 DIGIT = %x30-39 162 HEXDIGIT = DIGIT | %x61-66 ; lower case a-f 163 sha1id = "{" SHA1 "}" sha1hex 164 sha1hex = 40*HEXDIGIT 166 In the above, the "sha1hex" component encodes the 20-octet (160-bit) 167 binary SHA-1 hash value as a sequence of 40 lower case hexadecimal 168 digits. 170 For example, the identifier 172 http://example.org/service 174 transformed by means of SHA-1 hashing would become 176 {sha1}11d72e8cf351eb6c75c721e838f469677ab41bdb 178 Responder implementations MAY detect malformed SHA-1 transformed 179 identifiers (for example where the string of characters following the 180 "}" contains characters other than hexadecimal digits, or is other 181 than exactly 40 characters in length) and return an HTTP status code 182 of 400 ("bad request"). Alternatively, implementations MAY process 183 these as normal identifiers and return an HTTP status code of 404 184 ("not found") if appropriate. 186 2.2.3. Additional Identifiers 188 Entities MAY also be associated with any number of additional 189 responder-defined identifiers naming arbitrary groups of entities. 191 3. Response Profile 193 3.1. Response Cardinality 195 A request may return information for any number of entities, 196 including none. Responses compliant with this profile MUST use the 197 appropriate representation described below depending on the number of 198 "EntityDescriptor" elements returned. 200 3.1.1. No Entity Descriptors Returned 202 A response which returns no "EntityDescriptor" elements MUST be 203 represented by an HTTP status code of 404 ("not found"). 205 3.1.2. One Entity Descriptor Returned 207 A response which returns a single "EntityDescriptor" element MUST use 208 that element as its document element. The responder MUST NOT make 209 use of a "EntitiesDescriptor" element in this situation (see 210 [SAML2Meta] section 2.3). 212 Such a response MUST include the following HTTP header to indicate 213 that the metadata returned is SAML metadata: 215 Content-Type: application/samlmetadata+xml 217 3.1.3. More Than One Entity Descriptor Returned 219 A response which returns more than one "EntityDescriptor" element 220 MUST consist of a document element which is an "EntitiesDescriptor" 221 element, containing the returned "EntityDescriptor" elements as 222 children. Responses MUST NOT contain nested "EntitiesDescriptor" 223 elements. 225 Such a response MUST include the following HTTP header to indicate 226 that the metadata returned is SAML metadata: 228 Content-Type: application/samlmetadata+xml 230 4. Security Considerations 232 4.1. Integrity 234 As SAML metadata contains information necessary for the secure 235 operation of interacting services it is strongly RECOMMENDED that a 236 mechanism for integrity checking is provided to clients. 238 It is RECOMMENDED that the integrity checking mechanism provided by a 239 responder is a digital signature embedded in the returned metadata 240 document, as defined by [SAML2Meta] section 3. 242 Such digital signatures: 244 o SHOULD use an RSA keypair whose modulus is no less than 2048 bits 245 in length. 247 o SHOULD NOT use the SHA-1 cryptographic hash algorithm as a digest 248 algorithm. 250 o MUST NOT use the MD5 cryptographic hash algorithm as a digest 251 algorithm. 253 o SHOULD otherwise follow current cryptographic best practices in 254 algorithm selection. 256 4.2. Use of SHA-1 in Transformed Identifiers 258 This profile mandates the availability of a identifier synonym 259 mechanism based on the SHA-1 cryptographic hash algorithm. Although 260 SHA-1 is now regarded as weak enough to exclude it from use in new 261 cryptographic systems, its use in this profile is necessary for full 262 support of the SAML 2.0 standard. 264 Because the SHA-1 cryptographic hash is not being used within this 265 profile in the context of a digital signature, it is not believed to 266 introduce a security concern over and above that which already exists 267 in SAML due to the possibility of a post-hash collision between 268 entities whose "entityID" attributes hash to the same value. 270 Implementations may guard against this possibility by treating two 271 entities whose "entityID" values have the same SHA-1 equivalent as an 272 indicator of malicious intent on the part of the owner of one of the 273 entities. 275 5. IANA Considerations 277 This document has no actions for IANA. 279 6. Acknowledgements 281 The editor would like to acknowledge the following individuals for 282 their contributions to this document: 284 Scott Cantor (The Ohio State University) 286 Leif Johansson (SUNET) 288 Joe St Sauver (University of Oregon) 290 Tom Scavo (Internet2) 292 7. References 294 7.1. Normative References 296 [I-D.young-md-query] 297 Young, I., Ed., "Metadata Query Protocol", draft-young-md- 298 query-11 (work in progress), January 2019. 300 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 301 Requirement Levels", BCP 14, RFC 2119, 302 DOI 10.17487/RFC2119, March 1997, 303 . 305 [RFC3174] Eastlake 3rd, D. and P. Jones, "US Secure Hash Algorithm 1 306 (SHA1)", RFC 3174, DOI 10.17487/RFC3174, September 2001, 307 . 309 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 310 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 311 May 2017, . 313 [SAML2Bind] 314 Cantor, S., Hirsch, F., Kemp, J., Philpott, R., and E. 315 Maler, "Bindings for the Security Assertion Markup 316 Language (SAML) V2.0", OASIS Standard saml-bindings- 317 2.0-os, March 2005. 319 [SAML2Meta] 320 Cantor, S., Moreh, J., Philpott, R., and E. Maler, 321 "Metadata for the Security Assertion Markup Language 322 (SAML) V2.0", OASIS Standard saml-metadata-2.0-os, March 323 2005. 325 [STD68] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 326 Specifications: ABNF", STD 68, RFC 5234, 327 DOI 10.17487/RFC5234, January 2008, 328 . 330 7.2. Informative References 332 [md-query] 333 Young, I., Ed., "md-query Project", 334 . 336 [MDX.list] 337 Young, I., Ed., "MDX Mailing List", 338 . 340 [REFEDS] Research and Education Federations, "REFEDS Home Page", 341 . 343 [REFEDS.agreement] 344 Research and Education Federations, "REFEDS Participant's 345 Agreement", 346 . 348 [RFC4844] Daigle, L., Ed. and Internet Architecture Board, "The RFC 349 Series and RFC Editor", RFC 4844, DOI 10.17487/RFC4844, 350 July 2007, . 352 [SAML2Core] 353 Cantor, S., Kemp, J., Philpott, R., and E. Maler, 354 "Assertions and Protocol for the OASIS Security Assertion 355 Markup Language (SAML) V2.0", OASIS Standard saml-core- 356 2.0-os, March 2005, . 359 Appendix A. Change Log (to be removed by RFC Editor before publication) 361 A.1. draft-young-md-query-saml-00 363 Initial version. 365 A.2. Since draft-young-md-query-saml-00 367 Added REFEDS RFC stream boilerplate. 369 A.3. Since draft-young-md-query-saml-01 371 Bump reference to the Metadata Query Protocol [I-D.young-md-query]. 373 Rework Section 2.2 to make the role of transformed identifiers 374 clearer. This changes the semantics slightly (malformed transformed 375 identifiers may now result in a 404 return rather than 400) but this 376 gives implementers more latitude in the way that they handle the 377 feature. 379 A.4. Since draft-young-md-query-saml-02 381 Bump reference to the Metadata Query Protocol [I-D.young-md-query]. 383 A.5. Since draft-young-md-query-saml-03 385 Bump reference to the Metadata Query Protocol [I-D.young-md-query]. 387 Added an Editorial Note to help direct readers back to the 388 discussion. 390 A.6. Since draft-young-md-query-saml-04 392 Fix reference to the Metadata Query Protocol [I-D.young-md-query]. 394 A.7. Since draft-young-md-query-saml-05 396 Bump reference to the Metadata Query Protocol [I-D.young-md-query]. 398 A.8. Since draft-young-md-query-saml-06 400 Bump reference to the Metadata Query Protocol [I-D.young-md-query]. 402 A.9. Since draft-young-md-query-saml-07 404 Bump reference to the Metadata Query Protocol [I-D.young-md-query]. 406 A.10. Since draft-young-md-query-saml-08 408 Bump reference to the Metadata Query Protocol [I-D.young-md-query]. 410 Modernise normative language to include [RFC8174]. 412 Improved references to RFCs. 414 A.11. Since draft-young-md-query-saml-09 416 Bump reference to the Metadata Query Protocol [I-D.young-md-query]. 418 A.12. Since draft-young-md-query-saml-10 420 Bump reference to the Metadata Query Protocol [I-D.young-md-query]. 422 Replace citations in the abstract with straight textual mentions, as 423 required by the ID-NITS checklist. 425 Author's Address 427 Ian A. Young (editor) 428 Independent 430 EMail: ian@iay.org.uk