idnits 2.17.1 draft-miller-saag-key-discovery-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 : ---------------------------------------------------------------------------- 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 06, 2015) is 3216 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 4395 (Obsoleted by RFC 7595) == Outdated reference: A later version (-03) exists of draft-abiggs-saag-key-management-service-02 == Outdated reference: A later version (-04) exists of draft-barnes-acme-02 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Miller 3 Internet-Draft S. Nandakumar 4 Intended status: Standards Track Cisco Systems, Inc. 5 Expires: January 7, 2016 July 06, 2015 7 Key Discovery Service 8 draft-miller-saag-key-discovery-00 10 Abstract 12 A typical requirement with any cryptographic key management system is 13 to provide discovery, retrieval, distribution, and management of keys 14 across entities needing to perform the necessary security operations. 15 However there exists no standard mechanism to automatically discovery 16 the keys, but rather the keys are either provisioned statically or 17 shared beforehand via non standard mechanisms. This document defines 18 machanisms for an entity to automatically discover the key(s) 19 associated with other entities using the WebFinger protocol. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on January 7, 2016. 38 Copyright Notice 40 Copyright (c) 2015 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. Locating an Entity's Public Keys . . . . . . . . . . . . . . 3 58 4. Locating a Resource's Key . . . . . . . . . . . . . . . . . . 5 59 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 60 5.1. "key:" URI Scheme . . . . . . . . . . . . . . . . . . . . 6 61 5.1.1. URI Scheme Name . . . . . . . . . . . . . . . . . . . 7 62 5.1.2. Status . . . . . . . . . . . . . . . . . . . . . . . 7 63 5.1.3. URI Scheme Syntax . . . . . . . . . . . . . . . . . . 7 64 5.1.4. URI Scheme Semantics . . . . . . . . . . . . . . . . 7 65 5.1.5. Encoding Considerations . . . . . . . . . . . . . . . 7 66 5.1.6. Applications/Protocols That Use This URI Scheme Name 7 67 5.1.7. Interoperability Considerations . . . . . . . . . . . 8 68 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 69 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 70 7.1. Normative References . . . . . . . . . . . . . . . . . . 8 71 7.2. Informative References . . . . . . . . . . . . . . . . . 9 72 Appendix A. Determining a URI from Encrypted Content for Key 73 Discovery . . . . . . . . . . . . . . . . . . . . . 9 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 76 1. Introduction 78 With the increase in efforts towards ensuring end to end encryption 79 for communications on the Internet, it has become necessary to 80 improve the experience around how cryptographic primitives such as 81 keys and certificates are discovered, distributed, and mananged. 82 Efforts such as [I-D.barnes-acme] attempts to automate aspects of 83 certificate retrieval and manangement, whereas efforts such as 84 [I-D.abiggs-saag-key-management-service] provides mechanisms for 85 dealing with keys required for secure group communications. However, 86 today's standard efforts lack mechanisms for easy discovery of keys 87 associated with an entity or a resource on the Internet. For 88 example, any public key cryptograpy based system relies on being able 89 to have acquired the public key(s) of the target entity in order to 90 establish a secure communication with that entity. For these 91 scenarios, the entities wanting to acquire such keys are either 92 provisioned with the keys statically (as part of the configuration) 93 or distributed by non standard (application specific) means. 95 This document describes mechanisms for entities to automatically 96 discover the cryptographic keys associated with entities (users/ 97 resources) using WebFinger [RFC7033] as the protocol mechanism. Such 98 a mechanism provides an added benefit of separating key discovery 99 from its retrieval and management. 101 The rest of this document is organized as follows. Section 3 shows 102 using WebFinger protocol for entity's public key using an 'acct' URI 103 [RFC7565], followed by Section 4 showing the same procedure for 104 retrieving a secret key for a file resource. 106 2. Terminology 108 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 109 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 110 document are to be interpreted as described in [RFC2119]. 112 3. Locating an Entity's Public Keys 114 The examples below show query and response on the WebFinger resource 115 for retrieving the public key(s), using an 'acct' URI [RFC7565]: 117 Query WebFinger: 119 GET /.well-known/webfinger? 120 resource=acct%3Abilbo.baggins%40hobbiton.example 121 HTTP/1.1 122 Host: hobbiton.example 124 The WebFinger response then includes links to the entity's public 125 keys: 127 HTTP/1.1 200 OK 128 Access-Control-Allow-Origin: hobbiton.example 129 Access-Control-Allow-Methods: GET OPTIONS 130 Content-Type: application/jrd+json 132 { 133 "subject": "acct:bilbo.baggins@hobbiton.example", 134 ... 135 "links": [ 136 ... 137 { 138 "rel": "public-key", 139 "href": "https://hobbiton.example/~bilbo.baggins/ 140 pubkeyset.json", 141 "type": "application/jwk-set+json" 142 } 143 ] 144 } 146 The "rel" value is 'public-key'. The "href" MUST be a HTTPS URI that 147 the entity's public key(s) is retrieved from, formatted as a JWK or 148 JWK-set (as defined in [RFC7517]): 150 { 151 "keys": [ 152 { 153 "kty": "EC", 154 "kid": "bilbo.baggins@hobbiton.example", 155 "use": "sig", 156 "crv": "P-521", 157 "x": "AHKZLLOsCOzz5cY97ewNUajB957y-C-U88c3v13nmGZx6sYl_o 158 JXu9A5RkTKqjqvjyekWF-7ytDyRXYgCF5cj0Kt", 159 "y": "AdymlHvOiLxXkEhayXQnNCvDX4h9htZaCJN34kfmC6pV5OhQHi 160 raVySsUdaQkAgDPrwQrJmbnX9cwlGfP-HqHZR1" 161 }, 162 { 163 "kty": "RSA", 164 "kid": "bilbo.baggins@hobbiton.example", 165 "use": "sig", 166 "n": "n4EPtAOCc9AlkeQHPzHStgAbgs7bTZLwUBZdR8_KuKPEHLd4rH 167 VTeT-O-XV2jRojdNhxJWTDvNd7nqQ0VEiZQHz_AJmSCpMaJMRB 168 SFKrKb2wqVwGU_NsYOYL-QtiWN2lbzcEe6XC0dApr5ydQLrHqk 169 HHig3RBordaZ6Aj-oBHqFEHYpPe7Tpe-OfVfHd1E6cS6M1FZcD 170 1NNLYD5lFHpPI9bTwJlsde3uhGqC0ZCuEHg8lhzwOHrtIQbS0F 171 Vbb9k3-tVTU4fg_3L_vniUFAKwuCLqKnS2BYwdq_mzSnbLY7h_ 172 qixoR7jig3__kRhuaxwUkRz5iaiQkqgc5gHdrNP5zw", 173 "e": "AQAB" 174 }, 175 { 176 "kty": "RSA", 177 "kid": "bilbo.baggins@hobbiton.example", 178 "use": "enc", 179 "e": "AQAB", 180 "n": "uTWZBa8bjLQNJ9cBrdxGV_H_pmHEDuAXpCR1NnyYQYkUGJ8F3a 181 y_OM6sw82fS2ZcAXHpCVYlp30pd4D6BYwwixDt_eSkY-NLhPA3 182 ouE4YwtaUVZYBZT909pISRK4WOr3nXeJ0lltrgPQ7StBR1C776 183 KJnsHbBPdXO7tpAfph9GnjNUJxrpoFmhiZx3hbpEUpsxTsDuB9 184 doVN9cFCpsjPpoiAvkr_Doyckbi1TnR4zwzDQyfSkhNYghFuqh 185 vAQQ8yMQ29HOHYdfON2Z8yCjgAnyJCs1lnywkYaAaZGyxhozXr 186 F6_Np2BHteL_XRNekhY72gt1nRZYCQArjJMACx_3iw" 187 } 188 ] 189 } 191 4. Locating a Resource's Key 193 The example below shows WebFinger query and response for retrieving 194 the secret key associated with a resource controlled by erebor.com, 195 identified using a 'key' URI scheme defined in Section 5.1. The URI 196 to query could have been determined as per Appendix A. 198 Query WebFinger: 200 GET /.well-known/webfinger/ 201 ?resource=key%3Asha-256.GJa85ytSaK1pX6uwyBIEZFRLn5ZjrDd36emx 202 NmAGP_s@erebor.eample 203 HTTP/1.1 204 Host: erebor.example 206 WebFinger Response: The "rel" value is 'secret-key'. The "href" 207 indicates where to retrieve the secret key. 209 HTTP/1.1 200 OK 210 Access-Control-Allow-Origin: hobbiton.example 211 Access-Control-Allow-Methods: GET OPTIONS 212 Content-Type: application/jrd+json 214 { 215 "subject": "key:sha-256.GJa85ytSaK1pX6uwyBIEZFRLn5ZjrDd36emxNmAGP_s 216 @erebor.eample", 217 ... 218 "links": [ 219 ... 220 { 221 "rel": "secret-key", 222 "href": "kms://rivendell.example/key/ 223 c8e84a7d-2ae1-435a-9738-bb00e4c8dc7a", 224 "type": "application/jwk+json" 225 } 226 ] 227 } 229 If "href" is an HTTPS URI, the type SHOULD be "application/jwk+json" 230 or "application/jwk-set+json". Other protocols might use different 231 container formats. 233 5. IANA Considerations 235 5.1. "key:" URI Scheme 237 In accordance with the guidelines and registration procedures for new 238 URI schemes [RFC4395], this section provides the information needed 239 to register the 'key' URI scheme. 241 5.1.1. URI Scheme Name 243 key 245 5.1.2. Status 247 permanent 249 5.1.3. URI Scheme Syntax 251 The 'key' URI syntax is defined here in Augmented Backus-Naur Form 252 (ABNF) [RFC5234], borrowing the 'host' and 'unreserved' rules from 253 [RFC3986]: 255 keyuri = "key" ":" keyid "@" host 256 keyid = 1 * unreserved 258 5.1.4. URI Scheme Semantics 260 The 'key' URI scheme identifies cryptographic keys provided by 261 organizations, identified by domain name. It is used only for 262 identification, not for interaction. A protocol (other than the one 263 specified in this document) that employs the 'key' URI scheme is 264 responsible for specifying how a 'key' URI is dereferenced in the 265 context of that protocol. 267 5.1.5. Encoding Considerations 269 o The keyid consists of unreserved characters as defined in 270 [RFC3986]. 272 o The host consists only of Unicode code points that conform to the 273 rules in [RFC5892]. 275 o Internationalized domain name (IDN) labels are encoded as A-labels 276 [RFC5890]. 278 5.1.6. Applications/Protocols That Use This URI Scheme Name 280 At the time of this writing, only this protocol uses the 'key' URI 281 scheme, in conjunction with WebFinger. However, use is not 282 restricted to this protocol, and the scheme might be considered for 283 use in other protocols. 285 5.1.7. Interoperability Considerations 287 There are no known interoperability concerns related to the use of 288 the 'key' URI scheme. 290 6. Security Considerations 292 As this document is in essence a profile of WebFinger [RFC7033], all 293 of the security considerations from that draft apply. 295 Because anyone with the symmetric secret key can use it for 296 decryption, access to symmetric secret keys SHOULD require 297 authorization. Such authorization enforcement SHOULD be at the URI 298 for the key, and MAY also be enforced on the WebFinger query. 300 7. References 302 7.1. Normative References 304 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 305 Requirement Levels", BCP 14, RFC 2119, March 1997. 307 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 308 Resource Identifier (URI): Generic Syntax", STD 66, RFC 309 3986, January 2005. 311 [RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and 312 Registration Procedures for New URI Schemes", RFC 4395, 313 February 2006. 315 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 316 Specifications: ABNF", STD 68, RFC 5234, January 2008. 318 [RFC5890] Klensin, J., "Internationalized Domain Names for 319 Applications (IDNA): Definitions and Document Framework", 320 RFC 5890, August 2010. 322 [RFC5892] Faltstrom, P., "The Unicode Code Points and 323 Internationalized Domain Names for Applications (IDNA)", 324 RFC 5892, August 2010. 326 [RFC7033] Jones, P., Salgueiro, G., Jones, M., and J. Smarr, 327 "WebFinger", RFC 7033, September 2013. 329 7.2. Informative References 331 [I-D.abiggs-saag-key-management-service] 332 Biggs, A. and S. Cooley, "Key Management Service 333 Architecture", draft-abiggs-saag-key-management-service-02 334 (work in progress), July 2015. 336 [I-D.barnes-acme] 337 Barnes, R., Eckersley, P., Schoen, S., Halderman, A., and 338 J. Kasten, "Automatic Certificate Management Environment 339 (ACME)", draft-barnes-acme-02 (work in progress), May 340 2015. 342 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 343 Encodings", RFC 4648, October 2006. 345 [RFC6234] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms 346 (SHA and SHA-based HMAC and HKDF)", RFC 6234, May 2011. 348 [RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517, May 2015. 350 [RFC7565] Saint-Andre, P., "The 'acct' URI Scheme", RFC 7565, May 351 2015. 353 Appendix A. Determining a URI from Encrypted Content for Key Discovery 355 In most cases, the URI on which to perform key discovery will be 356 known. Chat rooms, conferencing services, and even shared files oft- 357 times have a URI for addressing the resource. Occasionally protected 358 content will be disseminated in a manner that an explicit URI cannot 359 be known or conveyed, but a domain name for where the content 360 originated from might be known. The following is an algorithm that 361 can be used to determine a URI for discoverying the key is such 362 cases. 364 1. Start with the encrypted content, C. 366 2. Perform a SHA-2 [RFC6234] hash (e.g., SHA-256) over the encrypted 367 content, to produce I'. 369 3. Perform the URL-safe Base64 encoding [RFC4648] over I' to produce 370 I. 372 4. Concatenate the following to produce the URI for key discovery, 373 U: 375 * The scheme "key:"; 376 * The name of the hash used in Step 2 (as registerd in the IANA 377 Hash Function Textual Names registry; e.g., "sha-256"), H; 379 * The character "." (U+002E FULL STOP); 381 * The base64url-encoded hash from Step 2, I; 383 * The character "@" (U+0040 COMMERCIAL AT); and 385 * The domain name, D 387 Expressed as an algorithm: 389 U := "key:" || H || "." || BASE64URL(SHA2(C)) || "@" || D 391 For example, suppose one has some encrypted content for which they do 392 not have the key, but is known to come from "erebor.example". If the 393 SHA-256 hash of the encrypted content were (in hex): 395 1896bce72b5268ad695fabb0c8120464544b9f9663ac3777e9e9b13660063feb 397 The URI to use for key discovery is then: 399 key:sha-256.GJa85ytSaK1pX6uwyBIEZFRLn5ZjrDd36emxNmAGP_s@erebor.eample 401 From here, the receiver of the encrypted content uses the calculated 402 URI to perform key discovery for a resource as described in 403 Section 4. 405 Authors' Addresses 407 Matthew Miller 408 Cisco Systems, Inc. 410 Email: mamille2@cisco.com 412 Suhas Nandakumar 413 Cisco Systems, Inc. 415 Email: snandaku@cisco.com