idnits 2.17.1 draft-young-md-query-saml-00.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 (December 29, 2013) is 3770 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 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). 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 December 29, 2013 5 Expires: July 2, 2014 7 SAML Profile for the Metadata Query Protocol 8 draft-young-md-query-saml-00 10 Abstract 12 This document profiles the Metadata Query Protocol 13 [I-D.young-md-query] for use with SAML metadata [SAML2Meta]. 15 Status of This Memo 17 This Internet-Draft is submitted in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF). Note that other groups may also distribute 22 working documents as Internet-Drafts. The list of current Internet- 23 Drafts is at http://datatracker.ietf.org/drafts/current/. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 This Internet-Draft will expire on July 2, 2014. 32 Copyright Notice 34 Copyright (c) 2013 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents 39 (http://trustee.ietf.org/license-info) in effect on the date of 40 publication of this document. Please review these documents 41 carefully, as they describe your rights and restrictions with respect 42 to this document. 44 Table of Contents 46 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 47 1.1. Notation and Conventions . . . . . . . . . . . . . . . . 2 48 2. Request Profile . . . . . . . . . . . . . . . . . . . . . . . 2 49 2.1. Content Type . . . . . . . . . . . . . . . . . . . . . . 2 50 2.2. Identifiers . . . . . . . . . . . . . . . . . . . . . . . 3 51 3. Response Profile . . . . . . . . . . . . . . . . . . . . . . 4 52 3.1. Response Cardinality . . . . . . . . . . . . . . . . . . 4 53 3.1.1. No Entity Descriptors Returned . . . . . . . . . . . 4 54 3.1.2. One Entity Descriptor Returned . . . . . . . . . . . 4 55 3.1.3. More Than One Entity Descriptor Returned . . . . . . 4 56 4. Security Considerations . . . . . . . . . . . . . . . . . . . 4 57 4.1. Integrity . . . . . . . . . . . . . . . . . . . . . . . . 4 58 4.2. Use of SHA-1 in Transformed Identifiers . . . . . . . . . 5 59 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 60 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 61 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 62 7.1. Normative References . . . . . . . . . . . . . . . . . . 6 63 7.2. Informative References . . . . . . . . . . . . . . . . . 6 64 Appendix A. Change Log (to be removed by RFC Editor before 65 publication) . . . . . . . . . . . . . . . . . . . . 6 66 A.1. draft-young-md-query-saml-00 . . . . . . . . . . . . . . 6 68 1. Introduction 70 This document profiles the Metadata Query Protocol 71 [I-D.young-md-query] for use with SAML metadata [SAML2Meta]. 73 1.1. Notation and Conventions 75 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 76 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 77 document are to be interpreted as described in RFC 2119 [BCP14]. 79 This document makes use of the Augmented BNF metalanguage defined in 80 [STD68]. 82 2. Request Profile 84 2.1. Content Type 86 Requests compliant with this profile MUST include the following HTTP 87 header to indicate that the metadata returned should be SAML metadata 88 (see Appendix A of [SAML2Meta]): 90 Accept: application/samlmetadata+xml 92 2.2. Identifiers 94 Each identifier in a request may be either: 96 o The unique identifier of an entity, corresponding to the 97 "entityID" attribute of the entity's "EntityDescriptor" element in 98 SAML metadata, or 100 o The responder-defined identifier of an arbitrary group of 101 entities. 103 SAML 2.0 [SAML2Core] includes profiles based on the transfer of an 104 "artifact" containing the unique identifier of a SAML entity 105 transformed by means of the SHA-1 [RFC3174] hash algorithm (see 106 [SAML2Bind] sections 3.6 and 3.6.4). 108 In order to support use cases in which clients may be in possession 109 of only such a transformed representation of a SAML entity's unique 110 identifier without any way to establish the original entity 111 identifier, a responder compliant with this profile MUST accept an 112 extended identifier matching the "sha1id" production in the following 113 ABNF grammar as as equivalent to the corresponding untransformed 114 identifier: 116 SHA1 = %x73 %x68 %x61 %x31 ; lower case "sha1" 117 DIGIT = %x30-39 118 HEXDIGIT = DIGIT | %x61-66 ; lower case a-f 119 sha1id = "{" SHA1 "}" sha1hex 120 sha1hex = 40*HEXDIGIT 122 In the above, the "sha1hex" component encodes the 20-octet (160-bit) 123 binary SHA-1 hash value as a sequence of 40 lower case hexadecimal 124 digits. 126 For example, the identifier 128 http://example.org/service 130 transformed by means of SHA-1 hashing would become 132 {sha1}11d72e8cf351eb6c75c721e838f469677ab41bdb 134 Malformed SHA-1 transformed extended identifiers, for example where 135 the string of characters following the "}" contains characters other 136 than hexadecimal digits, or is other than exactly 40 characters in 137 length, MUST result in an HTTP status code of 400 ("bad request"). 139 3. Response Profile 141 3.1. Response Cardinality 143 A request may return information for any number of entities, 144 including none. Responses compliant with this profile MUST use the 145 appropriate representation described below depending on the number of 146 "EntityDescriptor" elements returned. 148 3.1.1. No Entity Descriptors Returned 150 A response which returns no "EntityDescriptor" elements MUST be 151 represented by an HTTP status code of 404 ("not found"). 153 3.1.2. One Entity Descriptor Returned 155 A response which returns a single "EntityDescriptor" element MUST use 156 that element as its document element. The responder MUST NOT make 157 use of a "EntitiesDescriptor" element in this situation (see 158 [SAML2Meta] section 2.3). 160 Such a response MUST include the following HTTP header to indicate 161 that the metadata returned is SAML metadata: 163 Content-Type: application/samlmetadata+xml 165 3.1.3. More Than One Entity Descriptor Returned 167 A response which returns more than one "EntityDescriptor" element 168 MUST consist of a document element which is an "EntitiesDescriptor" 169 element, containing the returned "EntityDescriptor" elements as 170 children. Responses MUST NOT contain nested "EntitiesDescriptor" 171 elements. 173 Such a response MUST include the following HTTP header to indicate 174 that the metadata returned is SAML metadata: 176 Content-Type: application/samlmetadata+xml 178 4. Security Considerations 180 4.1. Integrity 182 As SAML metadata contains information necessary for the secure 183 operation of interacting services it is strongly RECOMMENDED that a 184 mechanism for integrity checking is provided to clients. 186 It is RECOMMENDED that the integrity checking mechanism provided by a 187 responder is a digital signature embedded in the returned metadata 188 document, as defined by [SAML2Meta] section 3. 190 Such digital signatures: 192 o SHOULD use an RSA keypair whose modulus is no less than 2048 bits 193 in length. 195 o SHOULD NOT use the SHA-1 cryptographic hash algorithm as a digest 196 algorithm. 198 o MUST NOT use the MD5 cryptographic hash algorithm as a digest 199 algorithm. 201 o SHOULD otherwise follow current cryptographic best practices in 202 algorithm selection. 204 4.2. Use of SHA-1 in Transformed Identifiers 206 This profile mandates the availability of a identifier synonym 207 mechanism based on the SHA-1 cryptographic hash algorithm. Although 208 SHA-1 is now regarded as weak enough to exclude it from use in new 209 cryptographic systems, its use in this profile is necessary for full 210 support of the SAML 2.0 standard. 212 Because the SHA-1 cryptographic hash is not being used within this 213 profile in the context of a digital signature, it is not believed to 214 introduce a security concern over and above that which already exists 215 in SAML due to the possibility of a post-hash collision between 216 entities whose "entityID" attributes hash to the same value. 218 Implementations may guard against this possibility by treating two 219 entities whose "entityID" values have the same SHA-1 equivalent as an 220 indicator of malicious intent on the part of the owner of one of the 221 entities. 223 5. IANA Considerations 225 This document has no actions for IANA. 227 6. Acknowledgements 229 The editor would like to acknowledge the following individuals for 230 their contributions to this document: 232 Scott Cantor (The Ohio State University) 233 Leif Johansson (SUNET) 235 Joe St Sauver (University of Oregon) 237 Tom Scavo (Internet2) 239 7. References 241 7.1. Normative References 243 [BCP14] Bradner, S., "Key words for use in RFCs to Indicate 244 Requirement Levels", BCP 14, RFC 2119, March 1997. 246 [I-D.young-md-query] 247 Young, I., Ed., "Metadata Query Protocol", draft-young-md- 248 query-01 (work in progress), December 2013. 250 [RFC3174] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1 251 (SHA1)", RFC 3174, September 2001. 253 [SAML2Bind] 254 Cantor, S., Hirsch, F., Kemp, J., Philpott, R., and E. 255 Maler, "Bindings for the Security Assertion Markup 256 Language (SAML) V2.0", OASIS Standard saml- 257 bindings-2.0-os, March 2005. 259 [SAML2Meta] 260 Cantor, S., Moreh, J., Philpott, R., and E. Maler, 261 "Metadata for the Security Assertion Markup Language 262 (SAML) V2.0", OASIS Standard saml-metadata-2.0-os, March 263 2005. 265 [STD68] Crocker, D. and P. Overell, "Augmented BNF for Syntax 266 Specifications: ABNF", STD 68, RFC 5234, January 2008. 268 7.2. Informative References 270 [SAML2Core] 271 Cantor, S., Kemp, J., Philpott, R., and E. Maler, 272 "Assertions and Protocol for the OASIS Security Assertion 273 Markup Language (SAML) V2.0", OASIS Standard saml- 274 core-2.0-os, March 2005, . 277 Appendix A. Change Log (to be removed by RFC Editor before publication) 279 A.1. draft-young-md-query-saml-00 280 Initial version. 282 Author's Address 284 Ian A. Young (editor) 285 Independent 287 EMail: ian@iay.org.uk