idnits 2.17.1 draft-ietf-xmpp-posh-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 : ---------------------------------------------------------------------------- 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 (September 9, 2015) is 3151 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2818 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 5785 (Obsoleted by RFC 8615) ** Obsolete normative reference: RFC 6125 (Obsoleted by RFC 9525) ** Obsolete normative reference: RFC 7159 (Obsoleted by RFC 8259) ** Obsolete normative reference: RFC 7230 (Obsoleted by RFC 9110, RFC 9112) ** Obsolete normative reference: RFC 7231 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 7525 (Obsoleted by RFC 9325) == Outdated reference: A later version (-11) exists of draft-ietf-xmpp-dna-10 -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 6555 (Obsoleted by RFC 8305) -- Obsolete informational reference (is this intentional?): RFC 7538 (Obsoleted by RFC 9110) Summary: 8 errors (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 XMPP Working Group M. Miller 3 Internet-Draft Cisco Systems, Inc. 4 Intended status: Standards Track P. Saint-Andre 5 Expires: March 12, 2016 &yet 6 September 9, 2015 8 PKIX over Secure HTTP (POSH) 9 draft-ietf-xmpp-posh-06 11 Abstract 13 Experience has shown that it is difficult to deploy proper PKIX 14 certificates for TLS in multi-tenant environments. As a result, 15 domains hosted in such environments often deploy applications using 16 certificates that identify the hosting service, not the hosted 17 domain. Such deployments force end users and peer services to accept 18 a certificate with an improper identifier, resulting in degraded 19 security. This document defines two methods that make it easier to 20 deploy certificates for proper server identity checking in non-HTTP 21 application protocols. While these methods were developed for use in 22 the Extensible Messaging and Presence Protocol (XMPP) as a Domain 23 Name Association (DNA) prooftype, they might also be usable in other 24 non-HTTP application protocols. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on March 12, 2016. 43 Copyright Notice 45 Copyright (c) 2015 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 3. Obtaining Verification Material . . . . . . . . . . . . . . . 4 63 3.1. Source Domain Possesses PKIX Certificate Information . . 5 64 3.2. Source Domain References PKIX Certificate . . . . . . . . 8 65 3.3. Performing Verification . . . . . . . . . . . . . . . . . 9 66 4. Secure Delegation . . . . . . . . . . . . . . . . . . . . . . 9 67 5. Order of Operations . . . . . . . . . . . . . . . . . . . . . 9 68 6. Caching Results . . . . . . . . . . . . . . . . . . . . . . . 11 69 7. Guidance for Server Operators . . . . . . . . . . . . . . . . 11 70 8. Guidance for Protocol Authors . . . . . . . . . . . . . . . . 12 71 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 72 9.1. Well-Known URI . . . . . . . . . . . . . . . . . . . . . 12 73 9.2. POSH Service Names . . . . . . . . . . . . . . . . . . . 13 74 10. Security Considerations . . . . . . . . . . . . . . . . . . . 14 75 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 76 11.1. Normative References . . . . . . . . . . . . . . . . . . 14 77 11.2. Informative References . . . . . . . . . . . . . . . . . 16 78 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 17 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 81 1. Introduction 83 We begin with a thought experiment. 85 Imagine that you work on the operations team of a hosting company 86 that provides instances of the hypothetical "Secure Protocol for 87 Internet Content Exchange" (SPICE) service for ten thousand different 88 customer organizations. Each customer wants their instance to be 89 identified by the customer's domain name (e.g., bar.example.com), not 90 the hosting company's domain name (e.g., hosting.example.net). 92 In order to properly secure each customer's SPICE instance via 93 Transport Layer Security (TLS) [RFC5246], you need to obtain and 94 deploy PKIX certificates [RFC5280] containing identifiers such as 95 bar.example.com, as explained in the "CertID" specification 97 [RFC6125]. Unfortunately, you can't obtain and deploy such 98 certificates because: 100 o Certification authorities won't issue such certificates to you 101 because you work for the hosting company, not the customer 102 organization. 104 o Customers won't obtain such certificates and then give them (plus 105 the associated private keys) to you because their legal department 106 is worried about liability. 108 o You don't want to install such certificates (plus the associated 109 private keys) on your servers because your legal department is 110 worried about liability, too. 112 o Even if your legal department is happy, this still means managing 113 one certificate for each customer across the infrastructure, 114 contributing to a large administrative load. 116 Given your inability to obtain and deploy public keys / certificates 117 containing the right identifiers, your back-up approach has always 118 been to use a certificate containing hosting.example.net as the 119 identifier. However, more and more customers and end users are 120 complaining about warning messages in user agents and the inherent 121 security issues involved with taking a "leap of faith" to accept the 122 identity mismatch between the Source Domain (bar.example.com) and the 123 Delegated Domain (hosting.example.net) [RFC6125]. 125 This situation is both insecure and unsustainable. You have 126 investigated the possibility of using DNS Security [RFC4033] and DNS- 127 Based Authentication of Named Entities (DANE) [RFC6698] to solve the 128 problem. However, your customers and your operations team have told 129 you that it will be several years before they will be able to deploy 130 DNSSEC and DANE for all of your customers (because of tooling 131 updates, slow deployment of DNSSEC at some top-level domains, etc.). 132 The product managers in your company are pushing you to find a method 133 that can be deployed more quickly to overcome the lack of proper 134 server identity checking for your hosted customers. 136 One possible approach that your team has investigated is to ask each 137 customer to provide the public key / certificate for its SPICE 138 service at a special HTTPS URI on their website 139 ("https://bar.example.com/.well-known/posh/spice.json" is one 140 possibility). This could be a public key that you generate for the 141 customer, but because the customer hosts it via HTTPS, any user agent 142 can find that public key and check it against the public key you 143 provide during TLS negotiation for the SPICE service (as one added 144 benefit, the customer never needs to hand you a private key). 146 Alternatively, the customer can redirect requests for that special 147 HTTPS URI to an HTTPS URI at your own website, thus making it 148 explicit that they have delegated the SPICE service to you. 150 The approach sketched out above, called POSH ("PKIX Over Secure 151 HTTP"), is explained in the remainder of this document. While this 152 approach was developed for use in the Extensible Messaging and 153 Presence Protocol (XMPP) as a prooftype for Domain Name Associations 154 (DNA) [I-D.ietf-xmpp-dna], it can be applied to any non-HTTP 155 application protocol. 157 2. Terminology 159 This document inherits security terminology from [RFC5280]. The 160 terms "Source Domain", "Delegated Domain", "Derived Domain", and 161 "Reference Identifier" are used as defined in the "CertID" 162 specification [RFC6125]. 164 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 165 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 166 "OPTIONAL" in this document are to be interpreted as described in 167 [RFC2119]. 169 Additionally, this document uses the following terms: 171 POSH client: A client that uses the application service and that 172 uses POSH to obtain material for verifying the service's identity. 174 POSH server: A server that hosts the application service and that 175 uses POSH to provide material for verifying its identity. 177 3. Obtaining Verification Material 179 Server identity checking (see [RFC6125]) involves three different 180 aspects: 182 1. A proof of the POSH server's identity (in PKIX, this takes the 183 form of a PKIX end-entity certificate [RFC5280]). 185 2. Rules for checking the certificate (which vary by application 186 protocol, although [RFC6125] attempts to harmonize those rules). 188 3. The material that a POSH client uses to verify the POSH server's 189 identity or check the POSH server's proof (in PKIX, this takes 190 the form of chaining the end-entity certificate back to a trusted 191 root and performing all validity checks as described in 192 [RFC5280], [RFC6125], and the relevant application protocol 193 specification). 195 When POSH is used, the first two aspects remain the same: the POSH 196 server proves its identity by presenting a PKIX certificate [RFC5280] 197 and the certificate is checked according to the rules defined in the 198 appropriate application protocol specification (such as [RFC6120] for 199 XMPP). However, the POSH client obtains the material it will use to 200 verify the server's proof by retrieving a JSON document [RFC7159] 201 containing hashes of the PKIX certificate over HTTPS ([RFC7230] and 202 [RFC2818]) from a well-known URI [RFC5785] at the Source Domain. 203 POSH servers MUST use HTTPS. This means that the POSH client MUST 204 verify the certificate of the HTTPS service at the Source Domain in 205 order to securely "bootstrap" into the use of POSH; specifically, the 206 rules of [RFC2818] apply to this "bootstrapping" step to provide a 207 secure basis for all subsequent POSH operations. 209 A PKIX certificate is retrieved over secure HTTP in the following 210 way. 212 1. The POSH client performs an HTTPS GET request at the Source 213 Domain to the path "/.well-known/posh.{servicedesc}.json". The 214 value of "{servicedesc}" is application-specific; see Section 8 215 of this document for more details. For example, if the 216 application protocol is the hypothetical SPICE service, then 217 "{servicedesc}" could be "spice"; thus if an application client 218 were to use POSH to verify an application server for the Source 219 Domain "bar.example.com", the HTTPS GET request would be as 220 follows: 222 GET /.well-known/posh/spice.json HTTP/1.1 223 Host: bar.example.com 225 2. The Source Domain HTTPS server responds in one of three ways: 227 * If it possesses PKIX certificate information for the requested 228 path, it responds as detailed in Section 3.1. 230 * If it has a reference to where the PKIX certificate 231 information can be obtained, it responds as detailed in 232 Section 3.2. 234 * If it does not have any PKIX certificate information or a 235 reference to such information for the requested path, it 236 responds with an HTTP 404 Not Found status code [RFC7231]. 238 3.1. Source Domain Possesses PKIX Certificate Information 240 If the Source Domain HTTPS server possesses the certificate 241 information, it responds to the HTTPS GET request with a success 242 status code and the message body set to a JSON document [RFC7159]; 243 the document is "fingerprints document", i.e., a JSON object with the 244 following members: 246 o A "fingerprints" member whose value is a JSON array of fingerprint 247 descriptors (the member MUST include at least one fingerprint 248 descriptor). 250 o An "expires" member whose value is a JSON number specifying the 251 number of seconds after which the POSH client ought to consider 252 the key information to be stale (further explained under 253 Section 6). 255 The JSON document returned MUST NOT contain a "url" member as 256 described in Section 3.2. 258 Each included fingerprint descriptor is a JSON object, where each 259 member name is the textual name of a hash function (as listed in 260 [HASH-NAMES]) and its associated value is the base 64 encoded 261 fingerprint hash generated using the named hash function (where the 262 encoding adheres to the definition in Section 4 of [RFC4648] and 263 where the padding bits are set to zero). 265 The fingerprint hash for a given hash algorithm is generated by 266 performing the named hash function over the DER encoding of the PKIX 267 X.509 certifiate. (This implies that if the certificate expires or 268 is revoked, the fingerprint value will be out of date.) 270 As an example of the fingerprint format, a "sha-256" fingerprint is 271 generated by performing the SHA-256 hash function over the DER 272 encoding of the PKIX certificate, as illustrated below. Note that 273 whitespace is added to the content portion of the HTTP response for 274 readability, but is not reflected in the Content-Length. 276 Example Fingerprints Response 278 HTTP/1.1 200 OK 279 Content-Type: application/json 280 Content-Length: 195 282 { 283 "fingerprints": [ 284 { 285 "sha-256": "4/mggdlVx8A3pvHAWW5sD+qJyMtUHgiRuPjVC48N0XQ=", 286 "sha-512": "25N+1hB2Vo42l9lSGqw+n3BKFhDHsyork8ou+D9B43TXeJ 287 1J81mdQEDqm39oR/EHkPBDDG1y5+AG94Kec0xVqA==" 288 } 289 ], 290 "expires": 604800 291 } 293 The "expires" value is a hint regarding the expiration of the keying 294 material. It MUST be a non-negative integer. If the "expires" 295 member has value of 0 (zero), a POSH client MUST consider the 296 verification material to be invalid. See Section 6 for how to 297 reconcile this "expires" member with the reference's "expires" 298 member. 300 To indicate alternate PKIX certificates (such as when an existing 301 certificate will soon expire), the returned fingerprints member MAY 302 contain multiple fingerprint descriptors. The fingerprints SHOULD be 303 ordered with the most relevant certificate first as determined by the 304 application service operator (e.g., the renewed certificate), 305 followed by the next most relevant certificate (e.g., the certificate 306 soonest to expire). Here is an example (note that whitespace is 307 added for readability): 309 { 310 "fingerprints": [ 311 { 312 "sha-256": "4/mggdlVx8A3pvHAWW5sD+qJyMtUHgiRuPjVC48N0XQ", 313 "sha-512": "25N+1hB2Vo42l9lSGqw+n3BKFhDHsyork8ou+D9B43TXe 314 J1J81mdQEDqm39oR/EHkPBDDG1y5+AG94Kec0xVqA==" 315 }, 316 { 317 "sha-256": "otyLADSKjRDjVpj8X7/hmCAD5C7Qe+PedcmYV7cUncE=", 318 "sha-512": "MbBD+ausTGJisEXKSynROWrMfHP2xvBnmI79Pr/KXnDyLN 319 +13Jof8/Uq9fj5HZG8Rk1E2fclcivpGdijUsvHRg==" 320 } 321 ], 322 "expires": 806400 323 } 324 Matching on any of these fingerprints is acceptable. 326 Rolling over from one hosting provider to another is best handled by 327 updating the relevant SRV records, not primarily by updating the POSH 328 documents themselves. 330 3.2. Source Domain References PKIX Certificate 332 If the Source Domain HTTPS server has a reference to the certificate 333 information, it responds to the HTTPS GET request with a success 334 status code and message body set to a JSON document. The document is 335 a "reference document", i.e., a JSON object with the following 336 members: 338 o A "url" member whose value is a JSON string specifying the HTTPS 339 URI where POSH clients can obtain the actual certificate 340 information. The URI can be a well-known POSH URI as described in 341 Section 8, but it need not be. (For historical reasons, the 342 member name is "url", not "uri".) 344 o An "expires" member whose value is a JSON number specifying the 345 number of seconds after which the POSH client ought to consider 346 the delegation to be stale (further explained under Section 6). 348 Example Reference Response 350 HTTP/1.1 200 Ok 351 Content-Type: application/json 352 Content-Length: 82 354 { 355 "url":"https://hosting.example.net/.well-known/posh/spice.json", 356 "expires":86400 357 } 359 In order to process a reference response, the client performs an 360 HTTPS GET request for the URI specified in the "url" member value. 361 The HTTPS server for the URI to which the client has been referred 362 responds to the request with a JSON document containing fingerprints 363 as described in Section 3.1. The document retrieved from the 364 location specified by the "url" member MUST NOT itself be a reference 365 document (i.e., containing a "url" member instead of a "fingerprints" 366 member), in order to prevent circular delegations. 368 Note: See Section 10 for discussion about HTTPS redirects. 370 The "expires" value is a hint regarding the expiration of the Source 371 Domain's delegation of service to the Delegated Domain. It MUST be a 372 non-negative integer. If the "expires" member has a value of 0 373 (zero), a POSH client MUST consider the delegation invalid. See 374 Section 6 for guidelines about reconciling this "expires" member with 375 the "expires" member of the fingerprints document. 377 3.3. Performing Verification 379 The POSH client compares the PKIX information presented by the POSH 380 server against each fingerprint descriptor object in the POSH 381 reference document, until a match is found using the hash functions 382 that the client supports, or until the collection of POSH 383 verification material is exhausted. If none of the fingerprint 384 descriptor objects match the POSH server PKIX information, the POSH 385 client SHOULD reject the connection (however, the POSH client might 386 still accept the connection if other verification methods are 387 successful, such as DANE [RFC6698]). 389 4. Secure Delegation 391 The delegation from the Source Domain to the Delegated Domain can be 392 considered secure if the credentials offered by the POSH server match 393 the verification material obtained by the client, regardless of how 394 the material was obtained. 396 5. Order of Operations 398 In order for the POSH client to perform verification of reference 399 identifiers without potentially compromising data, POSH operations 400 MUST be complete before any application-layer data is exchanged for 401 the Source Domain. In cases where the POSH client initiates an 402 application-layer connection, the client SHOULD perform all POSH 403 retrievals before initiating a connection (naturally this is not 404 possible in cases where the POSH client receives instead of initiates 405 an application-layer connection). For application protocols that use 406 DNS SRV (including queries for TLSA records in concert with SRV 407 records as described in [I-D.ietf-dane-srv]), the POSH operations 408 ideally ought to be done in parallel with resolving the SRV records 409 and the addresses of any targets, similar to the "happy eyeballs" 410 approach for IPv4 and IPv6 [RFC6555]. 412 The following diagram illustrates the possession flow: 414 POSH Source POSH 415 Client Domain Server 416 ------ ------ ------ 417 | | | 418 | POSH Request | | 419 |------------------------->| | 420 | | | 421 | Return POSH fingerprints | | 422 |<-------------------------| | 423 | | 424 | Service TLS Handshake | 425 |<===================================================>| 426 | | 427 | Service Data | 428 |<===================================================>| 429 | | 431 Figure 1: Order of Events for Possession Flow 433 While the following diagram illustrates the reference flow: 435 POSH Source Delegated POSH 436 Client Domain Domain Server 437 ------ ------ ------ ------ 438 | | | | 439 | POSH Request | | | 440 |----------------->| | | 441 | | | | 442 | Return POSH url | | | 443 |<-----------------| | | 444 | | | 445 | POSH Request | | 446 |-------------------------------->| | 447 | | | 448 | Return POSH fingerprints | | 449 |<--------------------------------| | 450 | | 451 | Service TLS Handshake | 452 |<===================================================>| 453 | | 454 | Service Data | 455 |<===================================================>| 456 | | 458 Figure 2: Order of Events for Reference Flow 460 6. Caching Results 462 The POSH client MUST NOT cache results (reference or fingerprints) 463 indefinitely. If the Source Domain returns a reference, the POSH 464 client MUST use the lower of the two "expires" values when 465 determining how long to cache results (i.e., if the reference 466 "expires" value is lower than the fingerprints "expires" value, honor 467 the reference "expires" value). Once the POSH client considers the 468 results stale, it needs to perform the entire POSH operation again 469 starting with the HTTPS GET request to the Source Domain. The POSH 470 client MAY use a lower value than any provided in the "expires" 471 member(s), or not cache results at all. 473 The foregoing considerations apply to handling of the "expires" 474 values in POSH documents; naturally a POSH client MUST NOT consider 475 an expired PKIX certificate to be valid, in accordance with 476 [RFC5280]. 478 The POSH client SHOULD NOT rely on HTTP caching mechanisms, instead 479 using the expiration hints provided in the POSH reference document or 480 fingerprints document. To that end, the HTTPS servers for Source 481 Domains and Derived Domains SHOULD specify a 'Cache-Control' header 482 indicating a very short duration (e.g., max-age=60) or "no-cache" to 483 indicate that the response (redirect, reference, or fingerprints) is 484 not appropriate to cache at the HTTP layer. 486 7. Guidance for Server Operators 488 POSH is intended to ease the operational burden of securing 489 application services, especially in multi-tenant environments. It 490 does so by obviating the need to obtain certificates for hosted 491 domains, so that an operator can obtain a certificate only for its 492 hosting service (naturally, this certificate needs to be valid 493 according to [RFC5280] and contain the proper identifier(s) in 494 accordance with [RFC6125] and the relevant application protocol 495 specification). 497 However, in order to use POSH, an operator does need to coordinate 498 with its customers so that the appropriate POSH documents are 499 provided via HTTPS at a well-known URI at each customer's domain 500 (i.e., at the Source Domain), thus ensuring delegation to the 501 operator's hosting service (i.e., the Delegated Domain). Because 502 correct hosting of the POSH document at the Source Domain is 503 essential for successful functioning of the POSH "chain", errors at 504 the Source Domain will result in authentication problems, certificate 505 warnings, and other operational issues. 507 Furthermore, if the POSH document is a reference document instead of 508 a fingerprints document, the operational burden is further decreased 509 because the operator does not need to provision its customers with 510 updated POSH documents when the certificate for the Delegated Domain 511 expires or is replaced. 513 8. Guidance for Protocol Authors 515 Protocols that use POSH are expected to register with the POSH 516 Service Names registry defined under Section 9.2. 518 For POSH-using protocols that rely on DNS SRV records [RFC2782], the 519 service name SHOULD be same as the DNS SRV "Service". As an example, 520 the POSH service name for XMPP server-to-server connections would be 521 "xmpp-server" because [RFC6120] registers a DNS SRV "Service" of 522 "xmpp-server". One example of the resulting well-known URI would be 523 "https://example.com/.well-known/posh/xmpp-server.json". 525 For other POSH-using protocols, the service name MAY any unique 526 string or identifier for the protocol, which might be a service name 527 registered with the IANA in accordance with [RFC6335] or which might 528 be an unregistered name. As an example, the well-known URI for the 529 hypothetical SPICE application might be "spice". 531 9. IANA Considerations 533 9.1. Well-Known URI 535 The IANA is requested to register "posh" in the Well-Known URI 536 Registry as defined by [RFC5785]. The completed template follows. 538 URI suffix: posh 540 Change controller: IETF 542 Specification: [[ this document ]] 544 Related information: The suffix "posh" is expected to be followed by 545 an additional path component consisting of a service name (say, 546 "spice") and a file extension of ".json", resulting in a full path 547 of, for instance, "/.well-known/posh/spice.json". Registration of 548 service names shall be requested by developers of the relevant 549 application protocols. 551 9.2. POSH Service Names 553 The IANA is requested to establish a registry for POSH service names 554 within the Uniform Resource Identifier (URI) Schemes group of 555 registries. 557 The IANA registration policy [RFC5226] is Expert Review or IETF 558 Review (this was chosen instead of the more liberal policy of First 559 Come First Served to help ensure that POSH serices are defined in 560 ways that are consistent with this specification). One or more 561 Designated Experts are to be appointed by the IESG or their delegate. 563 Registration requests are to be sent to the posh@ietf.org mailing 564 list for review and comment, with an appropriate subject (e.g., 565 "Request for POSH service name: example"). 567 Before a period of 14 days has passed, the Designated Expert(s) will 568 either approve or deny the registration request, communicating this 569 decision both to the review list and to IANA. Denials should include 570 an explanation and, if applicable, suggestions as to how to make the 571 request successful. Registration requests that are undetermined for 572 a period longer than 21 days can be brought to the IESG's attention 573 (using the iesg@iesg.org mailing list) for resolution. 575 9.2.1. Registration Template 577 Service name: The name requested, relative to "/.well-known/posh/"; 578 e.g., a service name of "example" would result in a well-known URI 579 such as "https://example.com/.well-known/posh/example.json". 581 Change controller: For Standards-Track RFCs, state "IETF". In all 582 other cases, provide the name and email address of the responsible 583 party. Other details (e.g., postal address or website URI) may 584 also be included. 586 Definition and usage: A brief description that defines the service 587 name and mentions where and how it is used (e.g., in the context 588 of a particular application protocol). 590 Specification: Optionally, reference to a document that specifies 591 the service or application protocol that uses the service name, 592 preferably including a URI that can be used to retrieve a copy of 593 the document. An indication of the relevant sections may also be 594 included, but is not required. 596 10. Security Considerations 598 This document supplements but does not supersede the security 599 considerations provided in specifications for application protocols 600 that decide to use POSH (e.g., [RFC6120] and [RFC6125] for XMPP). 601 Specifically, the security of requests and responses sent via HTTPS 602 depends on checking the identity of the HTTP server in accordance 603 with [RFC2818] as well as following the most modern best practices 604 for TLS as specified in [RFC7525]. Additionally, the security of 605 POSH can benefit from other HTTP hardening protocols, such as HSTS 606 [RFC6797] and key pinning [RFC7469], especially if the POSH client 607 shares some information with a common HTTPS implementation (e.g., 608 platform-default web browser). 610 Note well that POSH is used by a POSH client to obtain the public key 611 of a POSH server to which it might connect for a particular 612 application protocol such as IMAP or XMPP. POSH does not enable a 613 hosted domain to transfer private keys to a hosting service via 614 HTTPS. POSH also does not enable a POSH server to engage in 615 certificate enrollment with a certification authority via HTTPS, as 616 is done in Enrollment over Secure Transport [RFC7030]. 618 A web server at the Source Domain might redirect an HTTPS request to 619 another HTTPS URI. The location provided in the redirect response 620 MUST specify an HTTPS URI. Source domains SHOULD use only temporary 621 redirect mechanisms, such as HTTP status codes 302 (Found) and 307 622 (Temporary Redirect) [RFC7231]. Clients MAY treat any redirect as 623 temporary, ignoring the specific semantics for 301 (Moved 624 Permanently) [RFC7231] and 308 (Permanent Redirect) [RFC7538]. To 625 protect against circular references, it is RECOMMENDED that POSH 626 clients follow no more than 10 redirects, although applications or 627 implementations can require that fewer redirects be followed. 629 Hash function agility is an important quality to ensure secure 630 operations in the face of attacks against the fingerprints obtained 631 within verification material. Because POSH verification material is 632 relatively short-lived compared to long-lived credentials such as 633 PKIX end-entity certificates (at least as typically deployed), 634 entities that deploy POSH are advised to swap out POSH documents if 635 the hash functions are found to be subject to realistic attacks. 637 11. References 639 11.1. Normative References 641 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 642 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 643 RFC2119, March 1997, 644 . 646 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, DOI 10.17487/ 647 RFC2818, May 2000, 648 . 650 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 651 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 652 . 654 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 655 (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/ 656 RFC5246, August 2008, 657 . 659 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 660 Housley, R., and W. Polk, "Internet X.509 Public Key 661 Infrastructure Certificate and Certificate Revocation List 662 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 663 . 665 [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known 666 Uniform Resource Identifiers (URIs)", RFC 5785, DOI 667 10.17487/RFC5785, April 2010, 668 . 670 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 671 Verification of Domain-Based Application Service Identity 672 within Internet Public Key Infrastructure Using X.509 673 (PKIX) Certificates in the Context of Transport Layer 674 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 675 2011, . 677 [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 678 Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 679 2014, . 681 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 682 Protocol (HTTP/1.1): Message Syntax and Routing", RFC 683 7230, DOI 10.17487/RFC7230, June 2014, 684 . 686 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 687 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, DOI 688 10.17487/RFC7231, June 2014, 689 . 691 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 692 "Recommendations for Secure Use of Transport Layer 693 Security (TLS) and Datagram Transport Layer Security 694 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 695 2015, . 697 11.2. Informative References 699 [I-D.ietf-dane-srv] 700 Finch, T., Miller, M., and P. Saint-Andre, "Using DNS- 701 Based Authentication of Named Entities (DANE) TLSA Records 702 with SRV Records", draft-ietf-dane-srv-14 (work in 703 progress), April 2015. 705 [I-D.ietf-xmpp-dna] 706 Saint-Andre, P., Miller, M., and P. Hancke, "Domain Name 707 Associations (DNA) in the Extensible Messaging and 708 Presence Protocol (XMPP)", draft-ietf-xmpp-dna-10 (work in 709 progress), March 2015. 711 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 712 specifying the location of services (DNS SRV)", RFC 2782, 713 DOI 10.17487/RFC2782, February 2000, 714 . 716 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 717 Rose, "DNS Security Introduction and Requirements", RFC 718 4033, DOI 10.17487/RFC4033, March 2005, 719 . 721 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 722 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 723 DOI 10.17487/RFC5226, May 2008, 724 . 726 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence 727 Protocol (XMPP): Core", RFC 6120, DOI 10.17487/RFC6120, 728 March 2011, . 730 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 731 Cheshire, "Internet Assigned Numbers Authority (IANA) 732 Procedures for the Management of the Service Name and 733 Transport Protocol Port Number Registry", BCP 165, RFC 734 6335, DOI 10.17487/RFC6335, August 2011, 735 . 737 [RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with 738 Dual-Stack Hosts", RFC 6555, DOI 10.17487/RFC6555, April 739 2012, . 741 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 742 of Named Entities (DANE) Transport Layer Security (TLS) 743 Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 744 2012, . 746 [RFC6797] Hodges, J., Jackson, C., and A. Barth, "HTTP Strict 747 Transport Security (HSTS)", RFC 6797, DOI 10.17487/ 748 RFC6797, November 2012, 749 . 751 [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., 752 "Enrollment over Secure Transport", RFC 7030, DOI 753 10.17487/RFC7030, October 2013, 754 . 756 [RFC7469] Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning 757 Extension for HTTP", RFC 7469, DOI 10.17487/RFC7469, April 758 2015, . 760 [RFC7538] Reschke, J., "The Hypertext Transfer Protocol Status Code 761 308 (Permanent Redirect)", RFC 7538, DOI 10.17487/RFC7538, 762 April 2015, . 764 [HASH-NAMES] 765 "Hash Function Textual Names", 766 . 769 Appendix A. Acknowledgements 771 Thanks to Thijs Alkemade, Philipp Hancke, Joe Hildebrand, and Tobias 772 Markmann for their implementation feedback, and to Dave Cridland, 773 Chris Newton, Max Pritikin, and Joe Salowey for their input on the 774 specification. 776 During IESG review, Stephen Farrell, Barry Leiba, and Kathleen 777 Moriarty provided helpful input that resulted in improvements in the 778 document. 780 Thanks also to Dave Cridland as document shepherd, Joe Hildebrand as 781 working group chair, and Ben Campbell as area director. 783 Peter Saint-Andre wishes to acknowledge Cisco Systems, Inc., for 784 employing him during his work on earlier draft versions of this 785 document. 787 Authors' Addresses 789 Matthew Miller 790 Cisco Systems, Inc. 791 1899 Wynkoop Street, Suite 600 792 Denver, CO 80202 793 USA 795 Email: mamille2@cisco.com 797 Peter Saint-Andre 798 &yet 800 Email: peter@andyet.com 801 URI: https://andyet.com/