idnits 2.17.1 draft-young-md-query-saml-01.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 (April 22, 2014) is 3649 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-01 -- 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 April 22, 2014 5 Expires: October 24, 2014 7 SAML Profile for the Metadata Query Protocol 8 draft-young-md-query-saml-01 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 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on October 24, 2014. 35 Copyright Notice 37 Copyright (c) 2014 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 50 1.1. Notation and Conventions . . . . . . . . . . . . . . . . 3 51 2. Request Profile . . . . . . . . . . . . . . . . . . . . . . . 3 52 2.1. Content Type . . . . . . . . . . . . . . . . . . . . . . 3 53 2.2. Identifiers . . . . . . . . . . . . . . . . . . . . . . . 3 54 3. Response Profile . . . . . . . . . . . . . . . . . . . . . . 4 55 3.1. Response Cardinality . . . . . . . . . . . . . . . . . . 4 56 3.1.1. No Entity Descriptors Returned . . . . . . . . . . . 4 57 3.1.2. One Entity Descriptor Returned . . . . . . . . . . . 4 58 3.1.3. More Than One Entity Descriptor Returned . . . . . . 4 59 4. Security Considerations . . . . . . . . . . . . . . . . . . . 5 60 4.1. Integrity . . . . . . . . . . . . . . . . . . . . . . . . 5 61 4.2. Use of SHA-1 in Transformed Identifiers . . . . . . . . . 5 62 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 63 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 64 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 65 7.1. Normative References . . . . . . . . . . . . . . . . . . 6 66 7.2. Informative References . . . . . . . . . . . . . . . . . 7 67 Appendix A. Change Log (to be removed by RFC Editor before 68 publication) . . . . . . . . . . . . . . . . . . . . 8 69 A.1. Since draft-young-md-query-saml-00 . . . . . . . . . . . 8 70 A.2. draft-young-md-query-saml-00 . . . . . . . . . . . . . . 8 72 1. Introduction 74 This document profiles the Metadata Query Protocol 75 [I-D.young-md-query] for use with SAML metadata [SAML2Meta]. 77 The Research and Education Federations group ([REFEDS]) is the voice 78 that articulates the mutual needs of research and education identity 79 federations worldwide. It aims to represent the requirements of 80 research and education in the ever-growing space of access and 81 identity management. 83 From time to time REFEDS will wish to publish a document in the 84 Internet RFC series. Such documents will be published as part of the 85 RFC Independent Submission Stream [RFC4844]; however the REFEDS 86 working group sign-off process will have been followed for these 87 documents, as described in the REFEDS Participant's Agreement 88 [REFEDS.agreement]. 90 This document is a product of the REFEDS Working Group process. 92 1.1. Notation and Conventions 94 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 95 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 96 document are to be interpreted as described in RFC 2119 [BCP14]. 98 This document makes use of the Augmented BNF metalanguage defined in 99 [STD68]. 101 2. Request Profile 103 2.1. Content Type 105 Requests compliant with this profile MUST include the following HTTP 106 header to indicate that the metadata returned should be SAML metadata 107 (see Appendix A of [SAML2Meta]): 109 Accept: application/samlmetadata+xml 111 2.2. Identifiers 113 Each identifier in a request may be either: 115 o The unique identifier of an entity, corresponding to the 116 "entityID" attribute of the entity's "EntityDescriptor" element in 117 SAML metadata, or 119 o The responder-defined identifier of an arbitrary group of 120 entities. 122 SAML 2.0 [SAML2Core] includes profiles based on the transfer of an 123 "artifact" containing the unique identifier of a SAML entity 124 transformed by means of the SHA-1 [RFC3174] hash algorithm (see 125 [SAML2Bind] sections 3.6 and 3.6.4). 127 In order to support use cases in which clients may be in possession 128 of only such a transformed representation of a SAML entity's unique 129 identifier without any way to establish the original entity 130 identifier, a responder compliant with this profile MUST accept an 131 extended identifier matching the "sha1id" production in the following 132 ABNF grammar as as equivalent to the corresponding untransformed 133 identifier: 135 SHA1 = %x73 %x68 %x61 %x31 ; lower case "sha1" 136 DIGIT = %x30-39 137 HEXDIGIT = DIGIT | %x61-66 ; lower case a-f 138 sha1id = "{" SHA1 "}" sha1hex 139 sha1hex = 40*HEXDIGIT 140 In the above, the "sha1hex" component encodes the 20-octet (160-bit) 141 binary SHA-1 hash value as a sequence of 40 lower case hexadecimal 142 digits. 144 For example, the identifier 146 http://example.org/service 148 transformed by means of SHA-1 hashing would become 150 {sha1}11d72e8cf351eb6c75c721e838f469677ab41bdb 152 Malformed SHA-1 transformed extended identifiers, for example where 153 the string of characters following the "}" contains characters other 154 than hexadecimal digits, or is other than exactly 40 characters in 155 length, MUST result in an HTTP status code of 400 ("bad request"). 157 3. Response Profile 159 3.1. Response Cardinality 161 A request may return information for any number of entities, 162 including none. Responses compliant with this profile MUST use the 163 appropriate representation described below depending on the number of 164 "EntityDescriptor" elements returned. 166 3.1.1. No Entity Descriptors Returned 168 A response which returns no "EntityDescriptor" elements MUST be 169 represented by an HTTP status code of 404 ("not found"). 171 3.1.2. One Entity Descriptor Returned 173 A response which returns a single "EntityDescriptor" element MUST use 174 that element as its document element. The responder MUST NOT make 175 use of a "EntitiesDescriptor" element in this situation (see 176 [SAML2Meta] section 2.3). 178 Such a response MUST include the following HTTP header to indicate 179 that the metadata returned is SAML metadata: 181 Content-Type: application/samlmetadata+xml 183 3.1.3. More Than One Entity Descriptor Returned 185 A response which returns more than one "EntityDescriptor" element 186 MUST consist of a document element which is an "EntitiesDescriptor" 187 element, containing the returned "EntityDescriptor" elements as 188 children. Responses MUST NOT contain nested "EntitiesDescriptor" 189 elements. 191 Such a response MUST include the following HTTP header to indicate 192 that the metadata returned is SAML metadata: 194 Content-Type: application/samlmetadata+xml 196 4. Security Considerations 198 4.1. Integrity 200 As SAML metadata contains information necessary for the secure 201 operation of interacting services it is strongly RECOMMENDED that a 202 mechanism for integrity checking is provided to clients. 204 It is RECOMMENDED that the integrity checking mechanism provided by a 205 responder is a digital signature embedded in the returned metadata 206 document, as defined by [SAML2Meta] section 3. 208 Such digital signatures: 210 o SHOULD use an RSA keypair whose modulus is no less than 2048 bits 211 in length. 213 o SHOULD NOT use the SHA-1 cryptographic hash algorithm as a digest 214 algorithm. 216 o MUST NOT use the MD5 cryptographic hash algorithm as a digest 217 algorithm. 219 o SHOULD otherwise follow current cryptographic best practices in 220 algorithm selection. 222 4.2. Use of SHA-1 in Transformed Identifiers 224 This profile mandates the availability of a identifier synonym 225 mechanism based on the SHA-1 cryptographic hash algorithm. Although 226 SHA-1 is now regarded as weak enough to exclude it from use in new 227 cryptographic systems, its use in this profile is necessary for full 228 support of the SAML 2.0 standard. 230 Because the SHA-1 cryptographic hash is not being used within this 231 profile in the context of a digital signature, it is not believed to 232 introduce a security concern over and above that which already exists 233 in SAML due to the possibility of a post-hash collision between 234 entities whose "entityID" attributes hash to the same value. 236 Implementations may guard against this possibility by treating two 237 entities whose "entityID" values have the same SHA-1 equivalent as an 238 indicator of malicious intent on the part of the owner of one of the 239 entities. 241 5. IANA Considerations 243 This document has no actions for IANA. 245 6. Acknowledgements 247 The editor would like to acknowledge the following individuals for 248 their contributions to this document: 250 Scott Cantor (The Ohio State University) 252 Leif Johansson (SUNET) 254 Joe St Sauver (University of Oregon) 256 Tom Scavo (Internet2) 258 7. References 260 7.1. Normative References 262 [BCP14] Bradner, S., "Key words for use in RFCs to Indicate 263 Requirement Levels", BCP 14, RFC 2119, March 1997. 265 [I-D.young-md-query] 266 Young, I., Ed., "Metadata Query Protocol", draft-young-md- 267 query-01 (work in progress), December 2013. 269 [RFC3174] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1 270 (SHA1)", RFC 3174, September 2001. 272 [SAML2Bind] 273 Cantor, S., Hirsch, F., Kemp, J., Philpott, R., and E. 274 Maler, "Bindings for the Security Assertion Markup 275 Language (SAML) V2.0", OASIS Standard saml- 276 bindings-2.0-os, March 2005. 278 [SAML2Meta] 279 Cantor, S., Moreh, J., Philpott, R., and E. Maler, 280 "Metadata for the Security Assertion Markup Language 281 (SAML) V2.0", OASIS Standard saml-metadata-2.0-os, March 282 2005. 284 [STD68] Crocker, D. and P. Overell, "Augmented BNF for Syntax 285 Specifications: ABNF", STD 68, RFC 5234, January 2008. 287 7.2. Informative References 289 [REFEDS.agreement] 290 Research and Education Federations, "REFEDS Participant's 291 Agreement", . 294 [REFEDS] Research and Education Federations, "REFEDS Home Page", 295 . 297 [RFC4844] Daigle, L. and Internet Architecture Board, "The RFC 298 Series and RFC Editor", RFC 4844, July 2007. 300 [SAML2Core] 301 Cantor, S., Kemp, J., Philpott, R., and E. Maler, 302 "Assertions and Protocol for the OASIS Security Assertion 303 Markup Language (SAML) V2.0", OASIS Standard saml- 304 core-2.0-os, March 2005, . 307 Appendix A. Change Log (to be removed by RFC Editor before publication) 309 A.1. Since draft-young-md-query-saml-00 311 Added REFEDS RFC stream boilerplate. 313 A.2. draft-young-md-query-saml-00 315 Initial version. 317 Author's Address 319 Ian A. Young (editor) 320 Independent 322 EMail: ian@iay.org.uk