idnits 2.17.1 draft-erb-lurk-rsalg-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 document seems to lack an Introduction section. ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 239 has weird spacing: '...Version versi...' == Line 240 has weird spacing: '... Type type;...' == Line 256 has weird spacing: '..._header heade...' == Line 273 has weird spacing: '..._header heade...' == Line 309 has weird spacing: '..._header heade...' == (3 more instances...) -- The document date (May 28, 2016) is 2890 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) -- Missing reference section? 'RFC2119' on line 426 looks like a reference -- Missing reference section? 'RFC5246' on line 431 looks like a reference Summary: 3 errors (**), 0 flaws (~~), 7 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Erb 3 Internet-Draft R. Salz 4 Intended status: Standards Track Akamai Technologies 5 Expires: November 29, 2016 May 28, 2016 7 A PFS-preserving protocol for LURK 8 draft-erb-lurk-rsalg-01 10 Abstract 12 This document defines a protocol between a content provider and an 13 external key owner that enables the provider to act as a TLS 14 termination end-point for the key owner, without having the key 15 actually being provisioned at the provider. 17 The protocol between the two preserves forward secrecy, and is also 18 designed to prevent the use of the key owner as a general-purpose 19 signing oracle which would make it complicit in attacks against uses 20 of the very keys it is trying to protect. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on November 29, 2016. 39 Copyright Notice 41 Copyright (c) 2016 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Goals and Non-Goals . . . . . . . . . . . . . . . . . . . . . 3 58 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 3 59 3.1. Setup . . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3.2. Server Key Exchange . . . . . . . . . . . . . . . . . . . 3 61 3.3. RSALG . . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 3.3.1. Implementation Note - Modified Bleichenbacher Attack 4 63 3.3.2. Implementation Note - Hash Calculation . . . . . . . 4 64 3.4. Session Ticket Key Request . . . . . . . . . . . . . . . 5 65 4. LURK Message Formats . . . . . . . . . . . . . . . . . . . . 5 66 4.1. Setup Response Message . . . . . . . . . . . . . . . . . 6 67 4.2. Setup Response Message . . . . . . . . . . . . . . . . . 6 68 4.3. Request Message . . . . . . . . . . . . . . . . . . . . . 7 69 4.4. Session Ticket Request . . . . . . . . . . . . . . . . . 9 70 4.5. Response Message . . . . . . . . . . . . . . . . . . . . 9 71 5. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 10 72 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 73 7. Normative References . . . . . . . . . . . . . . . . . . . . 10 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 76 1. Terminology 78 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 79 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 80 document are to be interpreted as described in RFC 2119 [RFC2119]. 82 Three entities are involved in this protocol, although only two 83 actually 85 participate in the protocol exchanges: 87 Client <-----> Server <----> KeyOwner 89 The "KeyOwner" is an entity holding a Certificate and associated 90 private Key, typically bound to an identity such as a DNS name. 92 The "server" acts on behalf of the KeyOwner, such as terminating TLS 93 connections. From external appearances, such as TLS peer name 94 verification, the server is indistinguishable from the KeyOwner. 96 The "client" is the end-entity that initiates a connection to the 97 server. 99 2. Goals and Non-Goals 101 It is not a goal to protect against an active attacker who can 102 decrypt or actively MiTM any of the traffic. 104 It is not a goal to protect Client-Server traffic in the event of a 105 full compromise of a KeyOwner private key. 107 This protocol can support Client-Server communications from SSLv3 up 108 through TLS 1.2. (TLS 1.3 will have to be evaluated at a later 109 date.) 111 Past Client-Server communications must remain private in the event 112 that a Server is compromised (Perfect Forward Secrecy). For Server 113 Key Exchange signing requests, this is not an issue. For RSA 114 decryption requests used by the TLS_RSA_* cipher suites, the "RSALG" 115 message exchanges described below provide PFS protection. 117 The protocol should not become a generic signing oracle, even if it 118 is suboptimal with regard to network bandwidth utilization. This is 119 done by not simply signing values, but by computing the full 120 signature hash at the KeyOwner. 122 3. Protocol Overview 124 Communication between the Server and KeyOwner MUST be over a 125 mutually-authenticated TLS connection that uses PFS key exchange. 126 TLS 1.2 or later SHOULD be used. 128 3.1. Setup 130 A Server can contact a KeyOwner at any time to request the state of 131 the KeyOwner. When a Server is notified of a state change in a 132 KeyOwner response message, it MUST then request the state of the 133 KeyOwner. 135 3.2. Server Key Exchange 137 A KeyOwner will sign requests on behalf of the Server for the 138 signature required for the Server Key Exchange Message. This message 139 includes the client and server random values and key parameters. 141 3.3. RSALG 143 The basic premise of RSALG is that in the TLS_RSA_* handshakes: 145 o The KeyOwner will not decrypt the PMS and provide it back to the 146 Server. Instead, the KeyOwner will full compute the Master Secret 147 (via the PRF function) and provide that. 149 o The Server will choose a random ephemeral value, N, and provide a 150 cryptographically-hashed value of (such as SHA256(N)) as its 151 Server Random value. The Server sends N to KeyOwner which then 152 computes the same hashed value and uses that hash as its input to 153 the PRF. 155 An attacker who later gains access to KeyOwner would be unable to 156 derive the same Master Secret. This attacker would be able to see 157 the Client Random, Server Random and encrypted PMS, but would be 158 unable to replay this to KeyOwner unless they could reverse the 159 cryptographic hash function used to compute the server random. 161 3.3.1. Implementation Note - Modified Bleichenbacher Attack 163 If an attacker can gain access to a Server, they could mount a 164 Bleichenbacher attack against it (REF NEEDED). The standard SSL/TLS 165 defense against the Bleichenbacher attack (generating a string of 166 random bytes) is not effective here, since an attacker could generate 167 two requests with identical inputs and learn information about the 168 validity of the padding by seeing whether it gets a consistent output 169 in both cases. This is possible because the attacker also controls 170 (the input to) the server random. 172 To avoid this variation on the Bleichenbacher attack, KeyOwner should 173 compute the HMAC-SHA-384 over the PRF inputs as its "invalid" 174 response, using a private key as the hash key, to ensure that the 175 output is a deterministic function of the input and cannot be 176 calculated by the attacker. This private key must be globally unique 177 per keypair, therefore the RSA private key being used to decrypt the 178 PMS is an obvious choice. 180 The PRF inputs to the HMAC-SHA-384 described above are the encrypted 181 PMS, client version and server version. 183 3.3.2. Implementation Note - Hash Calculation 185 In TLS 1.2 and earlier, the first four bytes of a server random value 186 are actually a timestamp. An implementation must use those four 187 bytes as an input to the hash function as described above, then 188 overwrite them as input to the PRF calculated by the KeyOwner and the 189 Server Random value provided to the Client. 191 Example: 193 server_random = N 194 server_random[0..3] = get_time() 196 Server communicates server_random to KeyOwner 198 Both Server and KeyOwner compute the following: 200 saved_time = server_random[0..3] 201 server_random = sha256(server_random) 202 server_random[0..3] = saved_time 204 3.4. Session Ticket Key Request 206 A Server that supports TLS session tickets for multiple KeyOwners 207 SHOULD ensure that the ticket encryption keys are secure in the face 208 of various compromises. Using a hash of the private key as one of 209 the inputs to the session ticket KDF ensures that the traffic for 210 KeyOwner is protected against compromise of, or malicious behavior 211 by, other input parts to the session ticket KDF. It also limits the 212 extent to which compromise of a particular session ticket key effects 213 the Server acting on behalf of multiple KeyOwners. 215 After receiving a request, the KeyOwner computes an HMAC over a 216 server-supplied salt and a fixed string using the private key for the 217 certificate specified in the request as the hash key. 219 The fixed string is set by the KeyOwner, for example "LURK SESSION 220 TICKET". 222 session_ticket_secret = HMAC-SHA-384(private_key, 223 server_salt + fixed_string) 225 4. LURK Message Formats 227 The formats below are described using the TLS Presentation Language. 229 The following message header appears at the start of every message: 231 enum { 232 one(1), (255) 233 } Version 234 enum { 235 setup_request(0), setup_response(1), 236 request(2), session_ticket_request(3), response(4), (255) 237 } Type 238 struct { 239 Version version; 240 Type type; 241 uint16 length; 242 } lurk_msg_header; 244 version The version of this protocol. 246 type The message type. Details defined below. 248 length Length of the entire message, including header, in bytes. 250 4.1. Setup Response Message 252 A setup request message, requesting the state of the KeyOwner looks 253 like this: 255 struct { 256 lurk_msg_header header; 257 uint64 id; 258 } setup_request; 260 id A unique identifier to allow pipelining and match requests and 261 responses. 263 4.2. Setup Response Message 265 A setup response message, returning the state of the KeyOwner looks 266 like this: 268 struct { 269 uint8 purpose<32>; 270 opaque ASN.1Cert<1..2^24-1>; 271 } certificate; 272 struct { 273 lurk_msg_header header; 274 uint64 id; 275 SignatureAndHashAlgorithm 276 supported_signature_algorithms<2..2^16-2>; 277 certificate certificate_list<0..2^24-1>; 278 uint8 state<32>; 279 } setup_response; 281 id A unique identifier to allow pipelining and match requests and 282 responses. 284 supported_signature_algorithms A list of supported signature hash 285 algorithms that the KeyOwner supports (see RFC5246, section 286 7.4.1.4.1). TODO: TLSv1.3 considerations 288 certificate_list A list of certificate that are supported by the 289 KeyOwner. The purpose field is a value that MUST be pre- 290 configured by the Server and KeyOwner so a Server can have context 291 of where to use the corresponding ASN.1Cert. An example pre- 292 configuration of the purpose field is: purpose = sha256(hostname) 294 state A hash of the current state of the server. A KeyOwner MUST 295 provide this value in every response message and MUST update the 296 value to let a Server know to send a setup_request message. This 297 value MUST be consistant across multiple KeyOwners with identical 298 configurations. An example of this value: state = 299 sha256(supported_signature_algorithms + certificate_list) 301 4.3. Request Message 303 A request message looks like this: 305 enum { 306 rsalg(0), server_kx(1), (255) 307 } ReqType 308 struct { 309 lurk_msg_header header; 310 uint64 id; 311 ReqType op_type; 312 uint8 cert<32>; 313 uint16 client_version; 314 uint16 server_version; 315 uint8 client_random<32>; 316 uint8 server_random<32>; 317 SignatureAndHashAlgorithm sig_hash_alg; 318 PRFHashAlgorithm prf_hash_alg; 319 opaque data<0..2^16-1>; 320 } lurk_request; 322 id A unique identifier to allow pipelining and match requests and 323 responses. 325 cert The identifier for the keypair to be used in this request. 326 This SHOULD be the SHA256 value of the public key. 328 client_version The TLS Version Number provided by the Client in the 329 clientHello message. Note that for RSALG requests, the value must 330 be verified (see RFC5264, section 7.4.7.1) 332 server_version The TLS Version Number provided by the Server in the 333 serverHello message. Note that for RSALG requests, the value must 334 be verified (see RFC5264, section 7.4.7.1) 336 client_random The TLS Client Random provided by the clientHello 337 message. 339 server_random The TLS Server Random provided by the serverHello 340 message. Note that for RSALG requests, this is actually the 341 digested value of N. 343 sig_hash_alg For server_kx requests, this is the signature hash 344 value that the Server will use (see RFC5246, section 7.4.1.4.1). 345 For rsalg requests, this field is ignored and SHOULD be NULL. 346 TODO - TLSv1.3 considerations. 348 prf_hash_alg For rsalg requests, this identifies the PRF function to 349 use. For server_kx requests, this field is ignored and SHOULD be 350 NULL. 352 TODO: this likely should follow the same format as the first byte of 353 sighashalgo above, also need md5/sha1 combo value here. 355 data For rsalg requests, this contains the encrypted PRF. For 356 server_kx signing requests, this contains the key parameters to 357 sign. 359 4.4. Session Ticket Request 361 A session ticket key input request message looks like this: 363 struct { 364 lurk_msg_header header; 365 uint64 id; 366 uint8 cert<32>; 367 uint8 server_salt<48>; 368 } lurk_session_ticket_request; 370 id A unique identifier to allow pipelining and match requests and 371 responses. 373 cert The identifier for the keypair to be used in this request. 374 This SHOULD be the SHA256 value of the public key. 376 server_salt A server supplied random salt. 378 4.5. Response Message 380 A response message, used by both request types, looks like this: 382 enum { 383 success(0), invalidParameters(1), certUnavailable(2), 384 permissionDenied(3), insufficentResources(4), (255) 385 } ResponseStatus 386 struct { 387 lurk_msg_header header; 388 ResponseStatus status; 389 uint64 id; 390 uint8 state<32>; 391 opaque data<0..2^16-1>; 392 } lurk_response; 394 id The request id for which this is the response. 396 state A 32 byte tag identifying the current state of the server. 397 This is expected to be the same value found in the setup_response 398 message. If this value is different the Server MUST send a 399 setup_request message. 401 data For any status other than success, the data is ignored and MUST 402 be NULL. For rsalg requests, the data contains the master secret. 403 For server_kx requests, the data contains the signed hash. For 404 session ticket key requests, the data contains the computed HMAC. 406 5. Open Issues 408 The KeyOwner could choose the TLS server random. This makes RSALG 409 even less likely to be useful as an oracle, but has turned out to be 410 difficult to integrate into existing TLS/SSL libraries. 412 Should the lurk_request and lurk_response messages be padded out to 413 eight-byte alignment? 415 Should we use variant for the different request/response payloads? 417 6. Acknowledgements 419 We acknowledge the cooperation of Charlie Gero and Phil Lisiecki of 420 Akamai Technologies, and their disclosure of US Patent Application 421 20150106624, "Providing forward secrecy in a terminating TLS 422 connection proxy." 424 7. Normative References 426 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 427 Requirement Levels", BCP 14, RFC 2119, 428 DOI 10.17487/RFC2119, March 1997, 429 . 431 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 432 (TLS) Protocol Version 1.2", RFC 5246, 433 DOI 10.17487/RFC5246, August 2008, 434 . 436 Authors' Addresses 438 Samuel Erb 439 Akamai Technologies 441 Email: serb@akamai.com 443 Rich Salz 444 Akamai Technologies 446 Email: rsalz@akamai.com