idnits 2.17.00 (12 Aug 2021) /tmp/idnits36393/draft-mglt-lurk-tls-use-cases-02.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 (June 28, 2016) is 2146 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 5246 (Obsoleted by RFC 8446) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Migault 3 Internet-Draft K. Ma 4 Intended status: Standards Track Ericsson 5 Expires: December 30, 2016 R. Rich 6 Akamai 7 S. Mishra 8 Verizon Communications 9 O. Gonzales de Dios 10 Telefonica 11 June 28, 2016 13 LURK TLS/DTLS Use Cases 14 draft-mglt-lurk-tls-use-cases-02 16 Abstract 18 TLS as been designed to setup and authenticate transport layer 19 between a TLS Client and a TLS Server. In most cases, the TLS Server 20 both terminates the TLS Connection and owns the authentication 21 credentials necessary to authenticate the TLS Connection. 23 This document provides use cases where these two functions are split 24 into different entities, i.e. the TLS Connection is terminated on an 25 Edge Server, while authentication credentials are generated by a Key 26 Server, that owns the Private Key. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on December 30, 2016. 45 Copyright Notice 47 Copyright (c) 2016 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 63 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 64 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 4. Architecture Overview . . . . . . . . . . . . . . . . . . . . 4 66 5. Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5 67 5.1. Containers and Virtual Machines Use Cases . . . . . . . . 5 68 5.1.1. Description . . . . . . . . . . . . . . . . . . . . . 5 69 5.1.2. LURK Expectations . . . . . . . . . . . . . . . . . . 6 70 5.2. Content Provider Use Case . . . . . . . . . . . . . . . . 7 71 5.2.1. Description . . . . . . . . . . . . . . . . . . . . . 7 72 5.2.2. LURK Expectations . . . . . . . . . . . . . . . . . . 7 73 5.3. Content Owner / Content Provider Use Case . . . . . . . . 8 74 5.3.1. Description . . . . . . . . . . . . . . . . . . . . . 8 75 5.3.2. LURK Expectations . . . . . . . . . . . . . . . . . . 8 76 5.4. Content Distribution Network Interconnection Use Case . 9 77 5.4.1. Description . . . . . . . . . . . . . . . . . . . . . 9 78 5.4.2. LURK Expectations . . . . . . . . . . . . . . . . . . 9 79 6. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 10 80 6.1. LURK Requirements . . . . . . . . . . . . . . . . . . . . 10 81 6.2. Key Server Requirements . . . . . . . . . . . . . . . . . 10 82 6.3. Edge Server Requirements . . . . . . . . . . . . . . . . 11 83 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 84 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 85 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 86 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 87 10.1. Normative References . . . . . . . . . . . . . . . . . . 11 88 10.2. Informative References . . . . . . . . . . . . . . . . . 12 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 91 1. Requirements notation 93 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 94 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 95 document are to be interpreted as described in [RFC2119]. 97 2. Introduction 99 TLS has been designed for end-to-end security between a TLS Server 100 and a TLS Client. As TLS is widely used to provide an authenticated 101 channel between applications, the following models assumes that 102 applications end points and connectivity end point are combined. In 103 that case, authentication of the connection end point and 104 authentication of the application end point could be combined and 105 assimilated as a single authentication. 107 Such assumption for the TLS model may not be true especially in the 108 current web architecture where application content is not necessarily 109 associated with the connection end point. For example, Content 110 Delivery Network are in charge of delivering content that they may or 111 may are not own. 113 This document provide use case where authentication of the TLS Server 114 involves multiple parties or entities as opposed to a single entity 115 in the standard TLS model. 117 3. Terminology 119 TLS Client: The TLS Client designates the initiator of the TLS 120 session. The terminology is the one of [RFC5246]. The current 121 document considers that the TLS Client and the application 122 initiating the session are hosted on the same host. If not 123 they are hosted on the same administrative domain with a trust 124 relation between the TLS Client and the application. In other 125 words, the client endpoint is considered to be a single entity 126 as described initially in [RFC5246]. 128 TLS Server: The TLS Server designates the endpoint of a TLS session 129 initiated by the TLS Client. In the standard TLS, the TLS 130 Server, is both the terminating point of the TLS Connection and 131 the entity authenticated by the TLS Client. This document 132 considers that the TLS Server be split into the Edge Server 133 terminating the TLS Connection and the Key Server providing the 134 necessary capabilities to the TLS Client to proceed with the 135 authentication. 137 Private Key: is the cryptographic credential used by the TLD client 138 to authenticate the TLS Server. The purpose of this document 139 is to enable the Private Key to be hosted in the Key Server, 140 that is, outside of the TLS Connection terminating point. 142 TLS Connection: The authenticated TLS Connection between the TLS 143 Client and the TLS Server. In this document, the TLS 144 connection terminates on the Edge Server and enables 145 authenticating the Private Key hosted on the Key Server. 147 Key Server: The server hosting the Private Key. The Key Server 148 provides an interface that enable cryptographic operations to 149 be performed remotely by the Edge Servers. 151 Edge Server: The Edge Server designates a node that handles traffic 152 for a Content Provider. A TLS client initiates a TLS session 153 to authenticate a Content provider, but may in fact be served 154 by an Edge Server likely belonging to a different 155 administrative domain. 157 Content Owner: The owner of the content. This is the entity 158 requested by the application of the TLS Client. 160 Content Provider: The entity responsible to deliver the content. 161 In some cases, the Content Provider also own its own Content 162 Delivery Network. 164 Content Delivery Network (CDN): designates a organization in charge 165 of managing delivery of a content on behalf of a Content 166 Provider. In most cases, the CDN is a different organization 167 than the Content Provider. 169 4. Architecture Overview 171 Figure 1 provides an overview of the architecture considered by the 172 different uses cases exposed in this document. 174 The TLS Client initiates a TLS connection with the Edge Server (1) 175 which is expected to be authenticated by its Private Key. The Edge 176 Server terminates the TLS connection of the TLS Client, but does not 177 own the Private Key. Instead, the Private Key is owned by the Key 178 Server, which performs all cryptographic operations on behalf of the 179 Edge Server. Upon request from the Edge Server, the Key Server 180 provides the authentication credentials to the Edge Server (2). 181 These authentication credentials depend on the authentication methods 182 agreed between the TLS Client and the Edge Server as well as the 183 capabilities of the Key Server. The Authentication Credentials 184 returned by the Key Server enables the Edge Server to complete the 185 TLS Handshake and the TLS Client to authenticate the Edge Server as a 186 key owner of the Private Key (3). 188 The above described architecture to split the standard TLS Server 189 into two functions: the Edge Server that terminates the TLS 190 Connection and the Key Server to host the Private Key and perform all 191 necessary cryptographic operations for the authentication. 193 <----------- TLS Server ------------> 194 +------------+ +-------------+ +-------------+ 195 | TLS Client | <---------> | Edge Server | <-------> | Key Server | 196 +------------+ +-------------+ +-------------+ 197 | Private Key | 198 +-------------+ 199 1. TLS Connection Initialization 200 ---------------------------> 201 2. Authentication Credentials 202 (Private Key based 203 cryptographic operations) 204 <--------------------------> 205 3. Finalization of the TLS 206 Connection Handshake 207 <--------------------------> 209 TLS Connection Established 210 <==========================> 212 Figure 1: TLS Session Key Interface Architecture 214 5. Use cases 216 5.1. Containers and Virtual Machines Use Cases 218 5.1.1. Description 220 In virtual environment application servers may run within virtual 221 machines or containers. When TLS is used to provide an authenticated 222 and encrypted communication channel to the application, it is 223 currently common that the container or the virtual machine hosts the 224 Private Key used for the authentication. Hosting multiple copies of 225 the Private Key through the cloud increases the risk of leaking the 226 Private Key. 228 For example, virtualization and persistent storage of virtual 229 machines or containers image over different places in the cloud may 230 result in multiple copies of the Private Key through the cloud. In 231 addition, operating system level virtualization is a virtualization 232 method with a very low overhead. Isolation is performed at the 233 process and kernel level, which may provide a smaller isolation 234 compared to the one provided by the traditional hypervisors. With 235 lighter isolation, containers avoid storing private and highly 236 sensitive data such as a Private Key. 238 5.1.2. LURK Expectations 240 In this scenario, LURK enables the cloud provider to store the 241 Private Key in a centralized Key Server that is remotely accessed by 242 the different instances of the virtual machines or containers. As 243 containers or virtual machines are not hosting the Private Key, the 244 risks of leakage due to a lake of strong isolation or due to a 245 replication of the image is reduced. On the other hand, each 246 container or virtual machine is likely to interact with the Key 247 Server in an authenticated way, in which case, credentials used for 248 the authentication is exposed to risks of leakage that are similar to 249 those the Private Key were exposed without LURK. As a result, LURK 250 does not reduces the risk of leakage itself, but transfers the risk 251 from the Private Key to the containers or virtual machines' 252 authentication credentials. In fact, the consequence of a leakage of 253 authentication credentials is reduced compared to those of the 254 leakage of the Private Key. First the authentication credential 255 restricts the attacker to the operations enabled by the Key Server 256 whereas with the Private Key, the attacker is likely to perform any 257 cryptographic operations without any restrictions. Second, by 258 nature, the authentication credentials have internal cloud scope and 259 can be specific for each container or each virtual machine, whereas 260 the Private Key is used for the authentication outside the cloud and 261 is shared by all containers or virtual machines. As a result, a 262 revocation of the Private Key would impact all containers or virtual 263 machines as well as TLS Client outside the cloud. On the other hand, 264 the impact of revoking an authentication credential could be limited 265 to a single container or virtual machine and without any impact for 266 any TLS Clients outside the cloud. In a nutshell, this makes 267 management of the authentication credentials much easier than 268 management of the Private Key, and so much easier to mitigate a 269 leakage. 271 In this scenario, the Key Server as well as the containers or virtual 272 machine are expected to be hosted on the same Cloud. As a result, 273 the latency between the Key Server and the containers or the virtual 274 machine and the Key Server remains limited and acceptable for the TLS 275 Client. In addition, the containers or virtual machines 276 communicating with the Key Server may be different applications 277 running on different operating systems. 279 5.2. Content Provider Use Case 281 5.2.1. Description 283 A Content Provider may use multiple Edge Servers that are directly 284 exposed on the Internet. Edge Servers present a high risk of 285 exposure as they are subject to, for example, misconfigurations as 286 well as OS and web applications vulnerabilities at the Edge Server. 287 For example, as illustrated by the Heartbleed attack [HEART]. 288 Specifically, the Heartbleed attack uses a weakness of a software 289 implementation that allowed retrieval of the private key used by the 290 TLS server. Such attack would not have been successful if the 291 private key was not stored on the Edge Server. In addition, a Cloud 292 Provider may run different implementations of web servers, or OS in 293 order to make its infrastructure or service less vulnerable to a 294 single point of failure. On the other hand, the diversity of 295 implementations increases the risk of a leakage of the Private Key. 297 5.2.2. LURK Expectations 299 In this scenario, LURK enables a Content Provider to store the 300 critical information in a more secured place such as, the Key Server, 301 accessed only by all the authenticated Edge Servers. 303 Note that if the Private Key is shared between multiple Edge Servers, 304 a leakage occurring at one Edge Server compromises all servers and 305 the services. Section 5.1 describes more in depth the difference 306 between a leakage of the authentication credentials of the Edge 307 Server versus the Private Key. 309 In this scenario, the Key Server is accessed by a limited number of 310 Edge Servers which are authenticated. An Edge Server may present a 311 vulnerability, it will not have access to the Private Key. It 312 eventually may use the identity of the Edge Server to perform 313 cryptographic operations with that Private Key, and means should be 314 provided to limit the usability of such use. 316 In this scenario, the latency between the Edge Server and the Key 317 Server depends on the distribution of the Edge Servers. When Edge 318 Servers are far away from the Key Server, the time to set TLS 319 Connection may be impacted by this architecture. In the event, such 320 overhead impacts the quality of service of the TLS Client, the 321 Content Provider may use multiple Key Servers to reduce the latency 322 of the communication between the Edge Server and the Key Server. 323 This scenario assumes that we are within a single administrative 324 domain, so the Private Key remains inside the boundaries of such 325 domain. In addition, the use of the Key Server prevents a direct 326 access to the Private Key. 328 5.3. Content Owner / Content Provider Use Case 330 5.3.1. Description 332 It is common that applications - like a web browser for example - use 333 TLS to authenticate a Content Owner designated by a web URL and build 334 a secure channel with that Content Owner. 336 When the Content Owner is not able to support all the TLS Client 337 requests or would like to optimize the delivery of its content, it 338 may decide to take advantage of a third party delivery service 339 designated a Content Delivery Network (CDN) also designated as the 340 Content Provider. This third party is able to locate the Edge 341 Servers closer to the TLS Clients in various different geographical 342 locations. 344 The Content Owner may still want to be authenticated by TLS Client 345 while not terminating the TLS Connection of the TLS Client. In 346 addition, while the Content Owner provides the Content Provider the 347 content to deliver it may not agree or want to provide its Private 348 Key to the Content Provider. In fact, the Private Key used to 349 authenticate the Content Provider may present more value than the 350 content itself. For example, the content may be accessed by devices 351 or clients configured with the public authentication credential. In 352 such cases, the leak of the Private Key and the renewal of the 353 Private Key would require to configure all these devices. Such 354 additional configuration are likely to affect the image of the 355 Content Provider as well as result in some interruption of the 356 service. The content, on the other hand may have only an ephemeral 357 value and the Content Owner, may accept the risks of leakage and 358 provide the Content Provider the content in cleartext. 359 Alternatively, the content may also be encrypted with DRM, so its 360 access remains restricted to authorized users only. 362 5.3.2. LURK Expectations 364 In this scenario, LURK enables a Content Owner to delegate the 365 delivery aspects while still controlling the authentication of the 366 Content Owner. Similarly it enables the Content Provider to remain 367 focused only on the delivery aspects of the content, without 368 supporting the risks associated to the leakage of the Private Key. 369 The Content Provider and the Content Owner are different 370 administrative entities. As a result, the Key Server and the Edge 371 Servers may be located in different networks and the communication 372 between the Edge Server and the Key Server may introduce some delays. 373 Such delay may be acceptable for the TLS Client, especially for long 374 term TLS connections. Otherwise, the Content Owner, may provide the 375 Key Server to the Content Provider. This use case is then very 376 similar to the one described in Section 5.2. Note that providing the 377 Key Server to the Content Provider in a hardware security module for 378 example, still prevents the Content Provider to access the Private 379 Key while it is able to serve content. 381 In this scenario, the Content Owner is likely to involve multiple 382 Content Providers. In addition, the agreement between the Content 383 Provider and the Content Owner may take various forms. The Content 384 provider for example, may provide an infrastructure, or a delivery 385 service. As a result, the Content Owner may not control the 386 application or TLS library interacting with the Key Server. 388 5.4. Content Distribution Network Interconnection Use Case 390 5.4.1. Description 392 In the case of Content Distribution Network Interconnection (CDNI) 393 [RFC6707], it may also that the company with which the Content Owner 394 has contracted may further delegate delivery to another CDN with 395 which the Content Owner has no official business relationship. Even 396 if the Content Provider trusts the upstream CDN, and perhaps has 397 strong legal contracts in place, it has no control over, and possibly 398 no legal recourse against, the further downstream CDNs. 400 5.4.2. LURK Expectations 402 In this scenario, LURK enables a delegation between CDNs of the 403 delivery without providing the Private Key which would require 404 additional agreement. As a result, LURK provides more agility in the 405 delivery of content. Similarly to Section 5.3 the delegating CDN may 406 provide the content but not the Private Key. If the delegating CDN 407 hosts the Key Server it needs to to provide an access to the Key 408 Server. On the other hand, the delegating CDN may not even host the 409 Key Server, in which case, it may proxy the communications to the 410 upstream CDN or the Content Owner. Other architecture may also 411 enable a direct access to the Key Server by the delegated CDN. 413 In this scenario, different CDN are interacting, and the access to 414 the Key Server may result in substantial additional latencies. This 415 additional latency should not affect the quality of service of the 416 delivery service. In addition, the motivations for providing content 417 to the delegated CDN without providing the Private Key are similar to 418 those of Section 5.3. 420 6. Requirements 422 The requirements listed in this section are limited to the LURK 423 protocol, that is, the exchanges between the Edge Server and the Key 424 Server. 426 6.1. LURK Requirements 428 This section provides the requirements associated to the protocol 429 used by the Edge Server and the Key Server. In the remaining 430 section, this protocol is designated as LURK. 432 Multiple implementations of Edge Server, located in different 433 administrative domains must be able to interact with multiple 434 implementations of Key Servers also located in multiple 435 administrative domains. In addition, the scope of LURK is closely 436 related to TLS standardized at the IETF. 438 R1: LURK MUST be standardized at the IETF 440 LURK is limited to the Edge Server and the Key Server, so it is 441 expected to be transparent to the TLS Client. In addition, in order 442 to be deployed in the short term, any modification on the TLS Client 443 should be avoided. 445 R2: LURK MUST NOT impact the TLS Client. 447 6.2. Key Server Requirements 449 The Key Server holds the Private Key, and interacts with the Edge 450 Servers. 452 R3: The Key Server MUST be able to provide the necessary 453 authentication credential so the TLS Client and the Edge Server 454 set an authenticate TLS Connection with the Private Key. 456 R4: The Key Server MUST NOT leak any information associated to the 457 Private Key. In particular the Key Server MUST NOT provide a 458 generic singing/encryption oracle. 460 R5: The Key Server SHOULD NOT perform any operation outside the 461 authentication of a TLS Connection. 463 R6: The Key Server MUST provide confidential information to the Edge 464 Sever over an authenticated and encrypted channel. 466 6.3. Edge Server Requirements 468 R7: The Edge Server SHOULD be provisioned with the public 469 authentication credentials. Note: Public certificate 470 provisioning is outside of LURK. 472 7. Security Considerations 474 LURK provides a centralized control of the Private Key. This 475 centralized control was highly motivated by security to limit the 476 risk of leakage of the Private Key while providing some flexibility 477 and ability for different parties to interact together. On the other 478 hand, centralizing the authentication at the Key Server provides the 479 ability to control the access of content. More specifically, an 480 entity that controls the Key Server is able to prevent an 481 authenticated access to the content, by either not responding, or 482 providing corrupted authentication credentials such as for example 483 corrupted premasters to the Edge Server, or signatures that could not 484 be checked by the TLS Client. Such global control of the access to 485 content was not that easy when the content was distributed by a 486 distributed network of Edge Servers. As a result such facility may 487 be used by some governments agencies or make the Key Server an 488 interesting target for attackers to control the access of the 489 content. Note that even though the Key Server may remain inside an 490 domain, as it is being accessed by Edge Servers, attackers may 491 perpetrate attacks on the Key Server through these Edge Servers. 493 8. IANA Considerations 495 There are no IANA considerations in this document. 497 9. Acknowledgements 499 Thanks are due for insightful feedback on this document to Robert 500 Skog, Hans Spaak, Salvatore Loreto, John Mattsson, Alexei Tumarkin, 501 Yaron Sheffer, Eric Burger, Stephen Farrell, Richard Brunner, 502 Stephane Dault, Dan Kahn Gillmor, Joe Hildebrand, Thomas Fossati, 503 Kelsey Cairns. 505 10. References 507 10.1. Normative References 509 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 510 Requirement Levels", BCP 14, RFC 2119, 511 DOI 10.17487/RFC2119, March 1997, 512 . 514 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 515 (TLS) Protocol Version 1.2", RFC 5246, 516 DOI 10.17487/RFC5246, August 2008, 517 . 519 10.2. Informative References 521 [HEART] Codenomicon, "The Heartbleed Bug", 522 . 524 [RFC6707] Niven-Jenkins, B., Le Faucheur, F., and N. Bitar, "Content 525 Distribution Network Interconnection (CDNI) Problem 526 Statement", RFC 6707, DOI 10.17487/RFC6707, September 527 2012, . 529 Authors' Addresses 531 Daniel Migault 532 Ericsson 533 8400 boulevard Decarie 534 Montreal, QC H4P 2N2 535 Canada 537 Phone: +1 514-452-2160 538 Email: daniel.migault@ericsson.com 540 Kevin Ma J 541 Ericsson 542 43 Nagog Park 543 Acton, MA 01720 544 USA 546 Phone: +1 978-844-5100 547 Email: kevin.j.ma@ericsson.com 549 Rich Salz 550 Akamai 552 Email: rsalz@akamai.com 554 Sanjay Mishra 555 Verizon Communications 557 Email: sanjay.mishra@verizon.com 558 Oscar Gonzales de Dios 559 Telefonica 561 Email: oscar.gonzalezdedios@telefonica.com