idnits 2.17.1 draft-young-md-query-saml-06.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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([SAML2Meta], [I-D.young-md-query]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 13, 2017) is 2660 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-06 -- Obsolete informational reference (is this intentional?): RFC 4844 (Obsoleted by RFC 8729) Summary: 1 error (**), 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 13, 2017 5 Expires: July 17, 2017 7 SAML Profile for the Metadata Query Protocol 8 draft-young-md-query-saml-06 10 Abstract 12 This document profiles the Metadata Query Protocol 13 [I-D.young-md-query] for use with SAML metadata [SAML2Meta]. 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.7. 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 http://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 17, 2017. 45 Copyright Notice 47 Copyright (c) 2017 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 (http://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 . . . . . . . . . . . . . . . . . . . . . . . 3 64 2.2.1. Unique Identifier . . . . . . . . . . . . . . . . . . 3 65 2.2.2. Transformed Identifier . . . . . . . . . . . . . . . 4 66 2.2.3. Additional Identifiers . . . . . . . . . . . . . . . 4 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 . . . . . . . . . . . . . . . . . . . 5 73 4.1. Integrity . . . . . . . . . . . . . . . . . . . . . . . . 5 74 4.2. Use of SHA-1 in Transformed Identifiers . . . . . . . . . 6 75 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 76 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 77 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 78 7.1. Normative References . . . . . . . . . . . . . . . . . . 7 79 7.2. Informative References . . . . . . . . . . . . . . . . . 7 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 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 91 1. Introduction 93 This document profiles the Metadata Query Protocol 94 [I-D.young-md-query] for use with SAML metadata [SAML2Meta]. 96 The Research and Education Federations group ([REFEDS]) is the voice 97 that articulates the mutual needs of research and education identity 98 federations worldwide. It aims to represent the requirements of 99 research and education in the ever-growing space of access and 100 identity management. 102 From time to time REFEDS will wish to publish a document in the 103 Internet RFC series. Such documents will be published as part of the 104 RFC Independent Submission Stream [RFC4844]; however the REFEDS 105 working group sign-off process will have been followed for these 106 documents, as described in the REFEDS Participant's Agreement 107 [REFEDS.agreement]. 109 This document is a product of the REFEDS Working Group process. 111 1.1. Notation and Conventions 113 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 114 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 115 document are to be interpreted as described in RFC 2119 [BCP14]. 117 This document makes use of the Augmented BNF metalanguage defined in 118 [STD68]. 120 2. Request Profile 122 2.1. Content Type 124 Requests compliant with this profile MUST include the following HTTP 125 header to indicate that the metadata returned should be SAML metadata 126 (see Appendix A of [SAML2Meta]): 128 Accept: application/samlmetadata+xml 130 2.2. Identifiers 132 2.2.1. Unique Identifier 134 Each entity known to the responder MUST be associated with the unique 135 identifier of the entity, corresponding to the "entityID" attribute 136 of the entity's "EntityDescriptor" element in SAML metadata. 138 2.2.2. Transformed Identifier 140 SAML 2.0 [SAML2Core] includes profiles based on the transfer of an 141 "artifact" containing the unique identifier of a SAML entity 142 transformed by means of the SHA-1 [RFC3174] hash algorithm (see 143 [SAML2Bind] sections 3.6 and 3.6.4). 145 In order to support use cases in which clients may be in possession 146 of only such a transformed representation of a SAML entity's unique 147 identifier without any way to establish the original entity 148 identifier, a responder compliant with this profile MUST associate 149 each entity with an identifier matching the "sha1id" production in 150 the following ABNF grammar, and treat such an identifier as 151 equivalent to the corresponding untransformed identifier: 153 SHA1 = %x73 %x68 %x61 %x31 ; lower case "sha1" 154 DIGIT = %x30-39 155 HEXDIGIT = DIGIT | %x61-66 ; lower case a-f 156 sha1id = "{" SHA1 "}" sha1hex 157 sha1hex = 40*HEXDIGIT 159 In the above, the "sha1hex" component encodes the 20-octet (160-bit) 160 binary SHA-1 hash value as a sequence of 40 lower case hexadecimal 161 digits. 163 For example, the identifier 165 http://example.org/service 167 transformed by means of SHA-1 hashing would become 169 {sha1}11d72e8cf351eb6c75c721e838f469677ab41bdb 171 Responder implementations MAY detect malformed SHA-1 transformed 172 identifiers (for example where the string of characters following the 173 "}" contains characters other than hexadecimal digits, or is other 174 than exactly 40 characters in length) and return an HTTP status code 175 of 400 ("bad request"). Alternatively, implementations MAY process 176 these as normal identifiers and return an HTTP status code of 404 177 ("not found") if appropriate. 179 2.2.3. Additional Identifiers 181 Entities MAY also be associated with any number of additional 182 responder-defined identifiers naming arbitrary groups of entities. 184 3. Response Profile 186 3.1. Response Cardinality 188 A request may return information for any number of entities, 189 including none. Responses compliant with this profile MUST use the 190 appropriate representation described below depending on the number of 191 "EntityDescriptor" elements returned. 193 3.1.1. No Entity Descriptors Returned 195 A response which returns no "EntityDescriptor" elements MUST be 196 represented by an HTTP status code of 404 ("not found"). 198 3.1.2. One Entity Descriptor Returned 200 A response which returns a single "EntityDescriptor" element MUST use 201 that element as its document element. The responder MUST NOT make 202 use of a "EntitiesDescriptor" element in this situation (see 203 [SAML2Meta] section 2.3). 205 Such a response MUST include the following HTTP header to indicate 206 that the metadata returned is SAML metadata: 208 Content-Type: application/samlmetadata+xml 210 3.1.3. More Than One Entity Descriptor Returned 212 A response which returns more than one "EntityDescriptor" element 213 MUST consist of a document element which is an "EntitiesDescriptor" 214 element, containing the returned "EntityDescriptor" elements as 215 children. Responses MUST NOT contain nested "EntitiesDescriptor" 216 elements. 218 Such a response MUST include the following HTTP header to indicate 219 that the metadata returned is SAML metadata: 221 Content-Type: application/samlmetadata+xml 223 4. Security Considerations 225 4.1. Integrity 227 As SAML metadata contains information necessary for the secure 228 operation of interacting services it is strongly RECOMMENDED that a 229 mechanism for integrity checking is provided to clients. 231 It is RECOMMENDED that the integrity checking mechanism provided by a 232 responder is a digital signature embedded in the returned metadata 233 document, as defined by [SAML2Meta] section 3. 235 Such digital signatures: 237 o SHOULD use an RSA keypair whose modulus is no less than 2048 bits 238 in length. 240 o SHOULD NOT use the SHA-1 cryptographic hash algorithm as a digest 241 algorithm. 243 o MUST NOT use the MD5 cryptographic hash algorithm as a digest 244 algorithm. 246 o SHOULD otherwise follow current cryptographic best practices in 247 algorithm selection. 249 4.2. Use of SHA-1 in Transformed Identifiers 251 This profile mandates the availability of a identifier synonym 252 mechanism based on the SHA-1 cryptographic hash algorithm. Although 253 SHA-1 is now regarded as weak enough to exclude it from use in new 254 cryptographic systems, its use in this profile is necessary for full 255 support of the SAML 2.0 standard. 257 Because the SHA-1 cryptographic hash is not being used within this 258 profile in the context of a digital signature, it is not believed to 259 introduce a security concern over and above that which already exists 260 in SAML due to the possibility of a post-hash collision between 261 entities whose "entityID" attributes hash to the same value. 263 Implementations may guard against this possibility by treating two 264 entities whose "entityID" values have the same SHA-1 equivalent as an 265 indicator of malicious intent on the part of the owner of one of the 266 entities. 268 5. IANA Considerations 270 This document has no actions for IANA. 272 6. Acknowledgements 274 The editor would like to acknowledge the following individuals for 275 their contributions to this document: 277 Scott Cantor (The Ohio State University) 278 Leif Johansson (SUNET) 280 Joe St Sauver (University of Oregon) 282 Tom Scavo (Internet2) 284 7. References 286 7.1. Normative References 288 [BCP14] Bradner, S., "Key words for use in RFCs to Indicate 289 Requirement Levels", BCP 14, RFC 2119, March 1997. 291 [I-D.young-md-query] 292 Young, I., Ed., "Metadata Query Protocol", draft-young-md- 293 query-06 (work in progress), June 2016. 295 [RFC3174] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1 296 (SHA1)", RFC 3174, September 2001. 298 [SAML2Bind] 299 Cantor, S., Hirsch, F., Kemp, J., Philpott, R., and E. 300 Maler, "Bindings for the Security Assertion Markup 301 Language (SAML) V2.0", OASIS Standard saml-bindings- 302 2.0-os, March 2005. 304 [SAML2Meta] 305 Cantor, S., Moreh, J., Philpott, R., and E. Maler, 306 "Metadata for the Security Assertion Markup Language 307 (SAML) V2.0", OASIS Standard saml-metadata-2.0-os, March 308 2005. 310 [STD68] Crocker, D. and P. Overell, "Augmented BNF for Syntax 311 Specifications: ABNF", STD 68, RFC 5234, January 2008. 313 7.2. Informative References 315 [md-query] 316 Young, I., Ed., "md-query Project", 317 . 319 [MDX.list] 320 Young, I., Ed., "MDX Mailing List", 321 . 323 [REFEDS] Research and Education Federations, "REFEDS Home Page", 324 . 326 [REFEDS.agreement] 327 Research and Education Federations, "REFEDS Participant's 328 Agreement", . 331 [RFC4844] Daigle, L. and Internet Architecture Board, "The RFC 332 Series and RFC Editor", RFC 4844, July 2007. 334 [SAML2Core] 335 Cantor, S., Kemp, J., Philpott, R., and E. Maler, 336 "Assertions and Protocol for the OASIS Security Assertion 337 Markup Language (SAML) V2.0", OASIS Standard saml-core- 338 2.0-os, March 2005, . 341 Appendix A. Change Log (to be removed by RFC Editor before publication) 343 A.1. draft-young-md-query-saml-00 345 Initial version. 347 A.2. Since draft-young-md-query-saml-00 349 Added REFEDS RFC stream boilerplate. 351 A.3. Since draft-young-md-query-saml-01 353 Bump reference to the Metadata Query Protocol [I-D.young-md-query]. 355 Rework Section 2.2 to make the role of transformed identifiers 356 clearer. This changes the semantics slightly (malformed transformed 357 identifiers may now result in a 404 return rather than 400) but this 358 gives implementers more latitude in the way that they handle the 359 feature. 361 A.4. Since draft-young-md-query-saml-02 363 Bump reference to the Metadata Query Protocol [I-D.young-md-query]. 365 A.5. Since draft-young-md-query-saml-03 367 Bump reference to the Metadata Query Protocol [I-D.young-md-query]. 369 Added an Editorial Note to help direct readers back to the 370 discussion. 372 A.6. Since draft-young-md-query-saml-04 374 Fix reference to the Metadata Query Protocol [I-D.young-md-query]. 376 A.7. Since draft-young-md-query-saml-05 378 Bump reference to the Metadata Query Protocol [I-D.young-md-query]. 380 Author's Address 382 Ian A. Young (editor) 383 Independent 385 EMail: ian@iay.org.uk