idnits 2.17.1 draft-nir-saag-star-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 : ---------------------------------------------------------------------------- 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 (March 5, 2018) is 2237 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC5246' is defined on line 767, but no explicit reference was found in the text == Unused Reference: 'RFC7296' is defined on line 802, but no explicit reference was found in the text == Outdated reference: A later version (-18) exists of draft-ietf-acme-acme-07 == Outdated reference: A later version (-18) exists of draft-ietf-acme-acme-07 -- Duplicate reference: draft-ietf-acme-acme, mentioned in 'I-D.ietf-acme-star', was also mentioned in 'I-D.ietf-acme-acme'. == Outdated reference: A later version (-30) exists of draft-ietf-anima-autonomic-control-plane-13 == Outdated reference: A later version (-45) exists of draft-ietf-anima-bootstrapping-keyinfra-11 == Outdated reference: A later version (-10) exists of draft-ietf-anima-reference-model-05 == Outdated reference: A later version (-29) exists of draft-ietf-netconf-zerotouch-20 -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 6961 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 6962 (Obsoleted by RFC 9162) Summary: 0 errors (**), 0 flaws (~~), 9 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SecDispatch Y. Nir 3 Internet-Draft Dell EMC 4 Intended status: Informational T. Fossati 5 Expires: September 6, 2018 Nokia 6 Y. Sheffer 7 Intuit 8 T. Eckert 9 Huawei 10 March 5, 2018 12 Considerations For Using Short Term Certificates 13 draft-nir-saag-star-01 15 Abstract 17 Recently there has been renewed interest in an old idea: Issue 18 certificates with short validity periods and forego revocation 19 processing, reasoning that expiration is a sufficient replacement for 20 revocation as long as that expiration is not too far off. 22 This document covers considerations, both security and operational, 23 for using such Short Term Auto Renewed (STAR) certificates for 24 various scenarios where Using a revocation protocol is considered 25 inappropriate. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on September 6, 2018. 44 Copyright Notice 46 Copyright (c) 2018 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (https://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 1.1. Conventions Used in This Document . . . . . . . . . . . . 3 63 2. Short Term Auto Renewed Certificates . . . . . . . . . . . . 4 64 2.1. Alternative Design: OCSP Stapling . . . . . . . . . . . . 5 65 2.2. The Case For Foregoing Revocation . . . . . . . . . . . . 5 66 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 6 67 3.1. Data Center Network Hosts . . . . . . . . . . . . . . . . 6 68 3.2. Distributed System Installed in One Or More Data Centers 6 69 3.2.1. Distributed Network Security Functions . . . . . . . 6 70 3.3. Certificate Delegation for Content Delivery Networks . . 6 71 3.4. Autonomic Networking Infrastructure . . . . . . . . . . . 6 72 4. Operational Considerations . . . . . . . . . . . . . . . . . 7 73 4.1. Certificate Lifetime and Renewal Schedule . . . . . . . . 7 74 4.2. Availability of the Certificate Authority . . . . . . . . 8 75 4.3. Clock Skew and the notBefore Field . . . . . . . . . . . 9 76 4.4. Automatic Renewal . . . . . . . . . . . . . . . . . . . . 10 77 4.5. Secure (Re-)Enrollments . . . . . . . . . . . . . . . . . 10 78 4.6. Future enhancements for renewal/re-enrollment . . . . . . 11 79 4.7. Certificate Transparency . . . . . . . . . . . . . . . . 12 80 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 81 5.1. Reasons for Revocation . . . . . . . . . . . . . . . . . 13 82 5.2. Longevity and Revocation . . . . . . . . . . . . . . . . 14 83 5.3. Clock Skew and Security . . . . . . . . . . . . . . . . . 14 84 5.4. CA availability . . . . . . . . . . . . . . . . . . . . . 15 85 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 86 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 87 7.1. Normative References . . . . . . . . . . . . . . . . . . 15 88 7.2. Informative References . . . . . . . . . . . . . . . . . 15 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 91 1. Introduction 93 Certificates ([RFC5280]) are used in multiple protocols such as the 94 Internet Key Exchange (IKEv2-[RFC7296]) and the Transport Layer 95 Security protocol (TLS-[RFC5246]). Certificates are used to 96 authenticate communicating parties to each other. Certificates are 97 issued by Certificate Authorities (CAs) to End Entities (EE) to be 98 used to authenticate them to Relying Parties (RPs) in security 99 protocols. Systems that use secure communications typically include 100 certificate authorities, end entities and relying parties, with some 101 nodes in the network having more than one of these roles. 103 When deploying a system involving secure communications, one of the 104 challenges is how to deal with compromise of an End Entity's private 105 key. The standard way of dealing with this is adding a protocol 106 layer for revocation such as CRLs ([RFC5280]) or OCSP ([RFC6960]). 108 Such revocation protocols have drawbacks. Although caching of CRLs 109 and OCSP responses is allowed, each setup of a secure channel may 110 require accessing the CRL distribution point (DP) or the OCSP 111 responder. This is both time consuming and provides the system with 112 a few more modes of failure. Assuring reliability of the revocation 113 service increases the cost, and overcoming the latency issue requires 114 changes to the security protocols. All other things being equal, a 115 system that includes revocation checking is more complex and less 116 reliable than a system that does not include it. 118 For these reasons it is attractive to forego revocation checking. 119 Some deployed systems do this by either eliminating the CRL DP and 120 OCSP extensions from the certificates, or ignoring network and 121 timeout errors in fetching revocation information. Both practices 122 reduce the security of the system. 124 An alternative solution to the revocation problem is to issue 125 certificates with a short validity period and forego revocation 126 checking. Normally certificates are issued with a validity period of 127 between a few months and a few years. With a shorter validity period 128 if the private key is compromised the potential for abuse is lower 129 because the certificate and its private key expire within a short 130 period of time - a few hours to a few days. 132 The rest of this document describes operational and security 133 considerations with using short term certificates. 135 1.1. Conventions Used in This Document 137 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 138 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 139 document are to be interpreted as described in [RFC2119]. 141 Throughout this document we will use the term DP to denote a server 142 for revocation information, either a CRL distribution point or an 143 OCSP Responder. For our purposes they are the same. 145 We use the term longevity for the period of time between certificate 146 issuance and the time of its expiration as indicated in the notAfter 147 field of the certificate. Note that issuance time may be different 148 from the notBefore field in the certificate. 150 The text describes end entities as renewing their certificates 151 because the usual operational model for certificates is one of 152 "pull": end entities create certificate requests and send them to CAs 153 for signature. Some systems are designed around a "push" operation 154 where either the CA or a management function generates a new 155 certificate and installs it on the end entity. The text in the 156 document uses pull terminology, but is equally relevant for a push 157 design. 159 2. Short Term Auto Renewed Certificates 161 Short term certificates are like any other [RFC5280] certificates 162 except that the period of time between their issuance and their 163 notAfter date is relatively short. Whereas normally certificates are 164 issued for a period of time between a few months and a few years, 165 short term certificates usually expire after a few hours, a few days, 166 or at a limit a couple of weeks. 168 The certificates discussed in this document have neither a CRL DP 169 extension nor an OCSP authorityInformationAccess extension. In other 170 words such certificates cannot be revoked. Instead, they are valid 171 until they expire. 173 Automatic certificate renewal is getting ever more popular with 174 enrollment protocols such as EST ([RFC7030]) or ACME 175 ([I-D.ietf-acme-acme]). For short term certificates automatic 176 renewal is essential as a human cannot be expected to flawlessly 177 perform a manual renewal every few days or hours. This document does 178 not recommend any particular automatic renewal method, but 179 Section 4.4 recommends that some such method be used. Automatic 180 renewal processing can roll over the keys from one certificate to its 181 successor, or it can generate new keys with each Certificate 182 generation. As revocation may not exist, multiple certificates for 183 the same EE may be valid at any given time. 185 The solution for revocation in this scheme is to stop the automatic 186 renewal. The existing compromised certificate will remain valid 187 until it expires. See the considerations in Section 5.1 about 188 revocation. 190 [Topalovic] describes the design of a system involving STAR 191 certificates for the web, and analyzes its security and efficacy. It 192 concludes that STAR certificates can be as secure as certificates 193 with OCSP revocation. 195 2.1. Alternative Design: OCSP Stapling 197 Relying parties can also avoid the need for contacting the DP at 198 connection setup by having the End Entities implement OCSP stapling. 199 This feature has the EEs rather than the RPs retrieve the OCSP 200 response and send it as part of the protocol. OCSP stapling is 201 described for TLS in [RFC6961] and [RFC6066], and for IKE in 202 [RFC4806]. 204 STAR has several advantages over OCSP stapling: 206 o A CA that only signs certificates is simpler than a CA that both 207 signs certificates and issues OCSP responses. In fact, a CA for 208 STAR does not need to keep any record of issued certificates. 210 o A system that does not use CRLs or OCSP need not have an always- 211 available DP for delivering those CRLs or OCSP responses. This 212 reduces both complexity and attack surface. 214 o OCSP stapling in TLS versions prior to 1.3 works only for the 215 server as end entity. There was no provision for sending the OCSP 216 response for a client certificate in the protocol. 218 2.2. The Case For Foregoing Revocation 220 When explaining PKI to people, it is hard to justify why the CA or a 221 delegate needs to both sign blob-1 (the certificate) and also sign 222 blob-2 (the CRL or OCSP response) to tell relying parties that blob-1 223 is still valid. Surely one signed blob should be enough. 225 The explanation that we come up with is that traditionally issuing a 226 certificate required human intervention, while the revocation 227 checking object could be issued automatically and at great frequency. 228 So blob-1 would have to be valid for long enough to not over-burden 229 the human charged with maintaining them, while blob-2 could be re- 230 issued frequently. 232 This explanation no longer holds up. While the initial certificate 233 enrollment may need to be initiated by a human, protocols exist today 234 that make certificate renewal just as automated as CRL issuance. 235 Certificates can be just as frequently issued as CRLs were in the 236 past. The added complexity is no longer needed. 238 In real systems such as the web relying parties or end entities cache 239 revocation objects as long as it's allowed. If a CRL has a 240 nextUpdate field that is 4 days in the future, a typical system will 241 not attempt to fetch a new one before those 4 days have elapsed. For 242 this reason, moving to STAR certificates provides a similar level of 243 security to what is generally practiced on the web. 245 3. Use Cases 247 This section lists some use cases where STAR certificates seem to be 248 more appropriate than long-lived certificates with revocation 249 checking. The purpose of this section is only motivational. None of 250 the following sections are intended to be a definition of the use 251 case or the standard by which future documents or implementations 252 will be measured for sufficiency. 254 3.1. Data Center Network Hosts 256 TBA 258 3.2. Distributed System Installed in One Or More Data Centers 260 This is a system installed in multiple hosts in one or more data 261 centers that fulfills some task and requires mutual authentication of 262 its components. An example of such a system is a Storage Area 263 Network (SAN). 265 3.2.1. Distributed Network Security Functions 267 This example of a distributed system is multiple network security 268 functions (NSF) [RFC8192] where the SDN controller needs to 269 authenticate the NSFs with which it communicates, and some NSFs need 270 to communicate with each other. 272 3.3. Certificate Delegation for Content Delivery Networks 274 TBA 276 3.4. Autonomic Networking Infrastructure 278 The Autonomic Network Infrastructure (see 279 [I-D.ietf-anima-reference-model]) is an IETF ANIMA Working Group 280 developed network system architecture to provide the foundation for 281 both future "autonomic networks" (AN), as well as the infrastructure 282 to enable zero-touch secure bootstrapping of domain-wide PKI 283 certificates for network equipment (BRSKI, see 284 [I-D.ietf-anima-bootstrapping-keyinfra]) as well as the set-up of a 285 zero-touch, secure communications fabric for management of existing 286 networks (ACP, see [I-D.ietf-anima-autonomic-control-plane], 287 especially in the context of evolving SDN control & management (see 289 [I-D.ietf-anima-stable-connectivity]) . These domain certificates 290 are furthermore meant to be reuseable across all network services 291 between network equipment in that domain, therefore allowing to 292 eliminate the need for per-service crypto management (IGP, multicast, 293 BGP, netconf/COPS/radius connections,...). 295 Overall, the PKI related functions of ANI intend to increase 296 proliferation of PKI security through simplification, achieved 297 through automation and making solutions more resilient by minimizing 298 managed component requirements. CRL or OCSP introduce another set of 299 servers/services that needs to be managed/automated/distributed. The 300 connectivity requirement to such servers and/or the grace periods 301 during which connectivity to them is not required introduce more 302 complex system/security design parameters. 304 With ANI/ACP/BRSKI, renewal of certificates is fully automated and 305 therefore shorter lifetimes of certificates can easily be used to 306 avoid the additional need for CRL/OCSP. The limitation on reducing 307 certificate lifetimes is only the desired maximum length of time 308 during which connectivity to a CA for renewal may not exist - and the 309 maximum renewal rate of certificates that can be supported by those 310 CA. 312 Because of the ACP, connectivity to the CA is also more resilient 313 against network/provisioning/configuration problems than network 314 without an ACP. Lastly, the whole ANI is built and maintained 315 autonomously without the need of any configurations except for one or 316 more seed-nodes that perform an expanded version of a PKI 317 Registration Authority. 319 4. Operational Considerations 321 The motivations for using short-term certificates are operational. 322 We don't want the latency introduced by fetching the CRL from the DP; 323 we don't want the cost of making the DP 99.999% reliable, and we 324 don't want the cost of making the network paths from all RPs to the 325 DP always available. 327 Deploying short term certificates comes with its own set of 328 operational considerations, and some of these are enumerated in the 329 following sub-sections. 331 4.1. Certificate Lifetime and Renewal Schedule 333 Since we do not assume the CA to be close to 100% available it makes 334 sense for End Entities to renew their certificates well in advance. 335 While the security considerations in Section 5.2 set an upper limit 336 on the longevity of a STAR certificate, operational necessity sets 337 the frequency of renewal. It is necessary to strike a balance 338 between renewing too often which leads to increased load on the CA 339 and renewing too seldom which increases the risk of having the 340 certificate expire while either the CA or the End Entity are down. 342 Individual system properties play a significant role here. Systems 343 where both the CA and the EEs are expected to be up all of the time 344 absent a fault may choose to renew a day or even an hour before 345 expiration, while systems with nodes that are only up infrequently 346 and for short periods of time may choose to renew the certificates 347 whenever the EEs happen to be up. 349 As a general rule of thumb for systems where the CA is mostly 350 available it makes sense for the EE to make the first attempt to 351 renew its certificate about half-way through its lifetime. If that 352 attempt fails because the CA is not available an EE SHOULD retry at 353 regular intervals until it succeeds. Shortly before expiration, the 354 EE SHOULD increase the frequency of retires. 356 For example, suppose a STAR certificate is issued for 8 days. The EE 357 will first attempt to renew the certificate 4 days before expiration. 358 If that fails it will retry every three hours until only six hours 359 are left before expiration. At that point it will increase the 360 frequency and retry every five minutes. If this is part of the 361 system design, at this point it should also alert the user that 362 something is wrong. 364 4.2. Availability of the Certificate Authority 366 While the STAR design does not require 99.999% availability, the CA 367 does need to be available for renewing certificates. Downtimes of 368 more than a quarter of the certificate longevity SHOULD NOT happen. 369 For most modern hardware this is entirely possible even without 370 exotic clustering solutions, but when configuring the system 371 administrators should consider that the longevity of the certificates 372 constrains the required availability of the CA. 374 When setting the longevity for certificates administrators SHOULD 375 consider how long it takes to recover from a failure of the CA. That 376 length of time can be seconds with a good clustering solution, but 377 can span hours or days without one, especially if the fault happens 378 at a bad time. A failure of a CA should be considered a conceivable 379 occurrence, and longevity should be set so that such a failure does 380 not lead to expiration and outage. 382 Conversely, if short longevity is required by security targets, the 383 CA should be made more reliable with clustering solutions. 385 4.3. Clock Skew and the notBefore Field 387 Despite NTP ([RFC5905]) being over thirty years old and implemented 388 in every major operating system clock skew is a fact of life and many 389 deployed systems don't have the right time. It is also not possible 390 to just mandate the use of NTP because the systems that use STAR 391 certificates are often installed on hosts and networks where NTP is 392 either not configured or blocked. We cannot assume that these 393 systems can enable NTP at will. 395 Skewed clocks have always been a problem for certificates. Because 396 STAR certificates are always just a few days or hours from expiration 397 they are more sensitive to clock skew. A sufficiently skewed clock 398 can cause three different disfunctions and for STAR certificate such 399 disfunction happens with considerably less skew than with long term 400 certificates: 402 o A valid certificate may be rejected as not yet valid if the 403 current system time is earlier than its notBefore time. 404 Fortunately this issue can be safely mitigated by setting the 405 notBefore field to a time earlier than the time of issuance. 407 o A valid certificate may be rejected as expired if the current 408 system time is later than its notAfter time. As long as the clock 409 skew is not too great this is solved by a sensible renewal policy. 410 If as in the example in Section 4.1 the certificate is renewed 4 411 days before expiration or within a few hours after that, a clock 412 skew of up to 3 days will not be a problem. 414 o An expired certificate may be accepted if the current system time 415 is earlier than its notAfter time. This is a security issue that 416 is discussed in Section 5.3. 418 There are several common modes of clock skew: 420 o The system that doesn't have its clock set at all. These systems 421 might be set to January 1st, 1970 or to some date that was 422 interesting for the hardware vendor. Such systems are 423 incompatible with certificates and MUST NOT be used for STAR 424 certificates. 426 o The system has its timezone set wrong, and the system time was set 427 so that local time looks good. This limits the clock skew to 24 428 hours and is generally workable. 430 o A system that has the time set right but the date set wrong. 431 These are also not usable with certificates. 433 o A system that was set to the correct time once but has since 434 drifted away. Computer hardware varies wildly between systems 435 with quartz clocks that drift only a few seconds a month and 436 systems that can lose or gain minutes a day. The former are quite 437 usable, the latter are not. 439 Because of the prevalence of systems with a relatively small skew it 440 is RECOMMENDED to set the notBefore field to a time 72 hours before 441 the actual issuance date. 443 End Entities MUST NOT use expired certificates and Relying Parties 444 SHOULD alert whenever an expired certificate is presented. This will 445 help the users keep their host clocks set or encourage them to enable 446 NTP. 448 4.4. Automatic Renewal 450 Automatic enrollment and renewal is recommended for any system using 451 certificates. While it is possible to renew certificates manually on 452 time, even organizations with the best of IT departments occasionally 453 miss this: [cert-expires] 455 With short term certificates, this becomes even more important. 456 Renewing a certificate manually every few days or hours is extremely 457 labor intensive, especially when the system contains hundreds, 458 thousands or more end entities, and the risk of outages becomes a 459 certainty. 461 This document does not mandate any particular enrollment or renewal 462 mechanism. Any of a myriad of standard and proprietary methods can 463 be used and systems with proprietary methods have been shipping for 464 years. The IETF is in the process of standardizing the ACME protocol 465 for enrollment and renewal ([I-D.ietf-acme-acme]) and an extension is 466 proposed to make it more suitable for STAR certificates 467 ([I-D.ietf-acme-star]). The ANI as described in Section 3.4 is a 468 complete zero touch system design providing and relying on automatic 469 certificate renewal. 471 4.5. Secure (Re-)Enrollments 473 When short lived certificates expire, automatic re-enrollment can 474 further help to provide survivable, resilient PKI security. 475 Traditionally, initial enrollments, even with otherwise automated 476 solutions such as EST ([RFC7030]) required a manual interaction, or 477 else the device had to perform TOFU (Trust On First Use) to be 478 automatically enrolled. TOFU is even more problematic for re- 479 enrollments and becomes more problematic, the shorter lived 480 certificates and/or trust anchors are. Consider the risk where 481 during re-enrollment, the device may already be fully configured and 482 could be taken over by an attacker just having to wait for a short 483 lived certificate device certificate or trust anchor to expire. Or 484 consider devices auto-resetting themselves to factory conditions to 485 avoid this problem and then not having to be re-enrolled, but also be 486 re-configured - in the absence of fully zero-touch provisioning 487 solutions. 489 ANIs BRSKI protocol ([I-D.ietf-anima-bootstrapping-keyinfra], which 490 introduces extensions to EST), and NetConf Zero Touch 491 ([I-D.ietf-netconf-zerotouch] allow fully automated enrollment and 492 re-enrollment of device certificate and trust anchors through the use 493 of "vouchers" ([I-D.ietf-anima-voucher]). These are new digital 494 artifacts that allow enrolling devices to securely trust domains to 495 (re-)enroll them. They work by providing a signed statement by a 496 representative of the manufacturer of the device, that the device 497 with a specified identity (e.g: IDevID) should trust a particular 498 domain - identified by an initial trust anchor. This allows to 499 overcome the biggest challenge of expired short lived certificates/ 500 trust-anchors. 502 Furthermore, if the certificate and/or trust anchors are required for 503 security of network connectivity - such as routing protocol security 504 or network layer encryption - to even reach a re-enrollment server, 505 then there is yet another challenge with short lived certificates/ 506 trust-anchors and their higher likelyhood of expiring. 508 In the case of ANI, network layer security (e.g.: IPsec) is used for 509 protecting network connectivity including to reach the EST renewal 510 server. When certificate/TA are expired, renewal can not be used. 511 Instead though, automatic re-enrollment can be used, which does not 512 rely on generic network layer security, but instead relies on its own 513 proxy service to provide connectivity for such devices that need to 514 re-enroll. Nevertheless, re-enrollment may be a complex operation 515 due to the potential need to involve the above mentioned 516 representative entity of the manufacturer to generate vouchers. 518 4.6. Future enhancements for renewal/re-enrollment 520 One easy improvement that is specifically of interest with the use of 521 short-lived device certificates/trust-anchors is a new interpretation 522 of the lifetime of certificates. Today, there is no clear 523 distinction when or how to apply the lifetime, and in result, it is 524 usually assumed to be applicable to all operations relying on those 525 certificates. 527 In the case of short-lived certificates, the elements performing 528 certificate renewal/re-enrollment can easily have a different 529 interpretation of the lifetime and may not rely on what the 530 certificate itself says. This allows to turn re-enrollments into 531 renewals and avoid possible complexities or manual steps potentially 532 required for re-enrollment (depending on the system used). 534 In the case of BRSKI/EST, there is only one TLS connection used for 535 renewal and/or re-enrollment and expiry affects the certificates used 536 on this TLS connection. The server uses EST for renewal or the 537 extended signaling of BRSKI for re-enrollment. When a device with 538 expired, short-lived certificate connects to the BRSKI/EST server, 539 this server could allow to perform only simple EST renewal instead of 540 re-enrollment with a voucher by simply considering the lifetime of 541 the presented (and expired) device certificate to be extended. 543 This type of re-interpretation requires primarily some generic work 544 to allow this type of interpretation - and then per-solution work to 545 leverage this interpretation. In the case of BRSKI/EST for example, 546 devices would simply use their expired domain certificate to 547 authenticate themselves and perform certificate renewal - instead of 548 using their IDevID and trying to re-enroll (which is a more complex 549 operation with potentially external dependenices against the 550 manufacturer component). 552 4.7. Certificate Transparency 554 Certificate Transparency (CT), [RFC6962] is about keeping a log of 555 all issued certificates. 557 A system that issues a certificate every few days to thousands or end 558 entities will create more records for a CT log than a web host that 559 gets one certificate every year. 561 TBA: Discussion about this. 563 5. Security Considerations 565 STAR certificates eliminate an important security feature of PKI 566 which is the ability to revoke certificates. Revocation allows the 567 administrator to limit the damage done by a rogue node or an 568 adversary who has control of the private key. With STAR certificates 569 expiration replaces revocation so there is a timeliness issue. 571 It should be noted that revocation also has timeliness issues, 572 because both CRLs and OCSP responses have nextUpdate fields that tell 573 RPs how long they should trust this revocation data. These fields 574 are typically set to hours, days, or even weeks in the future. Any 575 revocation that happens before the time in nextUpdate goes unnoticed 576 by the RP. 578 Section 5.1 discusses the reasons why a certificate would be revoked 579 if revocation was available and how STAR certificates do the same. 580 Section 5.2 discusses considerations for setting the longevity of a 581 certificate, and Section 5.3 discusses how longevity should be 582 adjusted to deal with clock skew. 584 More discussion of the security of STAR certificates is available in 585 [Topalovic]. 587 5.1. Reasons for Revocation 589 There are two types of compromise that require administrators to 590 revoke a certificate: 592 o A host has lost control of the private key. There are many ways 593 that this can happen: a host can be hacked and a file containing 594 the private key may or may not have been copied; a disk may be 595 replaced and the old one has not been securely disposed of; a 596 fault causes the private key to be erased. In all these cases we 597 would like to revoke the certificate to make sure an adversary 598 cannot use the private key for nefarious purposes. For STAR 599 certificates the only solution is to wait for the certificate to 600 expire and the system is vulnerable until that happens. Longevity 601 should be set so that this risk is acceptable. 603 o A host may begin doing unintended things, either due to a software 604 fault or due to a malicious takeover. Again without revocation 605 RPs will continue to trust this node until its certificate 606 expires. 608 When a node "goes rogue" or an adversary gets control of the private 609 key it is important to block renewal or these certificates or else 610 the attack can persist forever. No matter how short-term these short 611 term certificates are, there is a certain window of time when the 612 attacker can use the certificate. This can often be mitigated with 613 application-level measures. 615 With most systems relying parties are configured with the names of 616 nodes with which they are allowed to communicate. When revocation is 617 not available changing the configuration so that the rogue node 618 cannot connect is RECOMMENDED. This is useful even when revocation 619 is available because timeliness issues are common to both revocation 620 and expiration. 622 5.2. Longevity and Revocation 624 There is always a period of time between when a compromise is 625 discovered and when RPs stop trusting the certificate. With 626 revocation this has to do with the time it takes to process the 627 revocation and the span of time between the thisUpdate and nextUpdate 628 fields. With STAR certificates this is controlled by the time it 629 takes to inhibit renewals and the longevity of the certificates. 631 For this reason it makes sense to set the longevity to a period of 632 time similar to the span of time that we would set for the CRL or 633 OCSP updates. Typically a few days is an appropriate time. For some 634 cases this can be as low as a few hours. Setting the renewal time 635 too short may cause operational problems as discussed in Section 4.3 636 and Section 4.2. In general longevity should not be set shorter than 637 the availability of the CA allows. 639 Fortunately modern hardware is powerful enough and reliable enough 640 that even a system with tens of thousands of end entities with 641 longevity of 1-2 days should not suffer an outage because of expired 642 certificates. 644 5.3. Clock Skew and Security 646 As discussed in Section 4.3 clock skew can lead to expired 647 certificates being treated as valid. While even the use of NTP may 648 leave clocks with a few seconds of inaccuracy, all installations MUST 649 take steps to limit the clock skew on their hosts. 651 An upper bound for the amount of skew allowed for hosts in a 652 particular system is one of the parameters for such a system. For 653 systems using NTP this can be 2 seconds. For systems where the 654 clocks are set manually, this tends to be far greater, but without an 655 upper bound no guarantees can be made about the security of 656 certificate use. 658 This upper bound is also a limit on the target certificate longevity. 659 For example, if hosts and CAs can each have a clock skew of 24 hours 660 then it is impossible to achieve a longevity of under 48 hours. With 661 a reasonable skew and a reasonable target longevity we can achieve 662 our security targets by reducing the certificate longevity by twice 663 the upper bound for skew. So if skew is bounded by 24 hours (the bad 664 timezone case) and target longevity is 7 days, it makes sense to set 665 the longevity on the CA to 5 days. 667 5.4. CA availability 669 A successful Denial of Service (DoS) attack against a CA prevents it 670 from issuing certificates. With short-term certificates this could 671 quickly lead to outages as certificates expire. 673 The important period of time here is the time between when the EE 674 first attempts to renew the certificate and the time that the 675 certificate expires. For example, if the EE attempts to renew the 676 certificates a mere five minutes before expiration, then a five- 677 minute CA outage can lead to an invalid certificate and failed 678 connections. 680 This issue is no different from DoS attacks against the DP for 681 certificates with revocation. The methods of protection are also 682 similar: 684 o Certificate renewal should first be attempted plenty of time in 685 advance as recommended in Section 4.1. This will leave enough 686 time for administrators to deal with the attack. 688 o As for all important infrastructure, network defenses SHOULD be 689 deployed to mitigate DoS attacks. 691 6. IANA Considerations 693 There are no requests to IANA in this document. 695 7. References 697 7.1. Normative References 699 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 700 Requirement Levels", BCP 14, RFC 2119, 701 DOI 10.17487/RFC2119, March 1997, 702 . 704 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 705 Housley, R., and W. Polk, "Internet X.509 Public Key 706 Infrastructure Certificate and Certificate Revocation List 707 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 708 . 710 7.2. Informative References 712 [cert-expires] 713 Lennon, M., "Google Lets SMTP Certificate Expire", April 714 2015, . 717 [I-D.ietf-acme-acme] 718 Barnes, R., Hoffman-Andrews, J., and J. Kasten, "Automatic 719 Certificate Management Environment (ACME)", draft-ietf- 720 acme-acme-07 (work in progress), June 2017. 722 [I-D.ietf-acme-star] 723 Sheffer, Y., Lopez, D., Gonzalez de Dios, O., Pastor 724 Perales, A., and T. Fossati, "Use of Short-Term, 725 Automatically-Renewed (STAR) Certificates to Delegate 726 Authority over Web Sites", draft-ietf-acme-acme-07 (work 727 in progress), June 2017. 729 [I-D.ietf-anima-autonomic-control-plane] 730 Eckert, T., Behringer, M., and S. Bjarnason, "An Autonomic 731 Control Plane (ACP)", draft-ietf-anima-autonomic-control- 732 plane-13 (work in progress), December 2017. 734 [I-D.ietf-anima-bootstrapping-keyinfra] 735 Pritikin, M., Richardson, M., Behringer, M., Bjarnason, 736 S., and K. Watsen, "Bootstrapping Remote Secure Key 737 Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- 738 keyinfra-11 (work in progress), February 2018. 740 [I-D.ietf-anima-reference-model] 741 Behringer, M., Carpenter, B., Eckert, T., Ciavaglia, L., 742 Pierre, P., Liu, B., Nobre, J., and J. Strassner, "A 743 Reference Model for Autonomic Networking", draft-ietf- 744 anima-reference-model-05 (work in progress), October 2017. 746 [I-D.ietf-anima-stable-connectivity] 747 Eckert, T. and M. Behringer, "Using Autonomic Control 748 Plane for Stable Connectivity of Network OAM", draft-ietf- 749 anima-stable-connectivity-10 (work in progress), February 750 2018. 752 [I-D.ietf-anima-voucher] 753 Watsen, K., Richardson, M., Pritikin, M., and T. Eckert, 754 "Voucher Profile for Bootstrapping Protocols", draft-ietf- 755 anima-voucher-07 (work in progress), January 2018. 757 [I-D.ietf-netconf-zerotouch] 758 Watsen, K., Abrahamsson, M., and I. Farrer, "Zero Touch 759 Provisioning for Networking Devices", draft-ietf-netconf- 760 zerotouch-20 (work in progress), February 2018. 762 [RFC4806] Myers, M. and H. Tschofenig, "Online Certificate Status 763 Protocol (OCSP) Extensions to IKEv2", RFC 4806, 764 DOI 10.17487/RFC4806, February 2007, 765 . 767 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 768 (TLS) Protocol Version 1.2", RFC 5246, 769 DOI 10.17487/RFC5246, August 2008, 770 . 772 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 773 "Network Time Protocol Version 4: Protocol and Algorithms 774 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 775 . 777 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) 778 Extensions: Extension Definitions", RFC 6066, 779 DOI 10.17487/RFC6066, January 2011, 780 . 782 [RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A., 783 Galperin, S., and C. Adams, "X.509 Internet Public Key 784 Infrastructure Online Certificate Status Protocol - OCSP", 785 RFC 6960, DOI 10.17487/RFC6960, June 2013, 786 . 788 [RFC6961] Pettersen, Y., "The Transport Layer Security (TLS) 789 Multiple Certificate Status Request Extension", RFC 6961, 790 DOI 10.17487/RFC6961, June 2013, 791 . 793 [RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate 794 Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013, 795 . 797 [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., 798 "Enrollment over Secure Transport", RFC 7030, 799 DOI 10.17487/RFC7030, October 2013, 800 . 802 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 803 Kivinen, "Internet Key Exchange Protocol Version 2 804 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 805 2014, . 807 [RFC8192] Hares, S., Lopez, D., Zarny, M., Jacquenet, C., Kumar, R., 808 and J. Jeong, "Interface to Network Security Functions 809 (I2NSF): Problem Statement and Use Cases", RFC 8192, 810 DOI 10.17487/RFC8192, July 2017, 811 . 813 [Topalovic] 814 Topalovic, E., Saeta, B., Huang, L., Jackson, C., and D. 815 Boneh, "Towards Short-Lived Certificates", 2012, 816 . 818 Authors' Addresses 820 Yoav Nir 821 Dell EMC 822 9 Andrei Sakharov St 823 Haifa 3190500 824 Israel 826 EMail: ynir.ietf@gmail.com 828 Thomas Fossati 829 Nokia 831 EMail: thomas.fossati@nokia.com 833 Yaron Sheffer 834 Intuit 836 EMail: yaronf.ietf@gmail.com 838 Toerless Eckert 839 Huawei USA - Futurewei Technologies Inc. 840 2330 Central Expy 841 Santa Clara 95050 842 USA 844 EMail: tte+ietf@cs.fau.de