idnits 2.17.1 draft-sheffer-dhc-initial-random-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 (December 5, 2013) is 3795 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 3315 (Obsoleted by RFC 8415) 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 Y. Sheffer 3 Internet-Draft Porticor 4 Intended status: Standards Track P. Hoffman 5 Expires: June 8, 2014 VPNC 6 December 5, 2013 8 A DHCP Extension To Provide Initial Random Material 9 draft-sheffer-dhc-initial-random-00 11 Abstract 13 Some network devices get little or no entropy from their underlying 14 operating systems when they are first started. As a result, 15 cryptographic applications started before there is sufficient entropy 16 in the operating system's pool can be initialized into a state that 17 can be exploited by an attacker. This document defines a DHCP 18 extension that can provide the operating system of a network device 19 with some initial randomness that can only be known by an attacker 20 who is on the same network segment as the device and its DHCP server. 21 The operating system can mix this random input into its random pool 22 early in the boot procedure and thus have more entropy available when 23 cryptographic applications start. 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on June 8, 2014. 42 Copyright Notice 44 Copyright (c) 2013 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.1. Conventions used in this document . . . . . . . . . . . . . 3 61 2. The Initial Randomness Extension . . . . . . . . . . . . . 3 62 2.1. Extension Format . . . . . . . . . . . . . . . . . . . . . 4 63 2.1.1. DHCPv4 . . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 2.1.2. DHCPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 2.2. Client and Server Behavior . . . . . . . . . . . . . . . . 5 66 3. Alternatives and Applicability . . . . . . . . . . . . . . 5 67 3.1. Alternatives to This Proposal . . . . . . . . . . . . . . . 5 68 4. Security Considerations . . . . . . . . . . . . . . . . . . 6 69 4.1. RNG Properties . . . . . . . . . . . . . . . . . . . . . . 6 70 4.2. Resistance Against Network Attacks . . . . . . . . . . . . 6 71 4.3. Denial of Service . . . . . . . . . . . . . . . . . . . . . 6 72 4.4. Saving RNG State . . . . . . . . . . . . . . . . . . . . . 6 73 4.5. Protocol Signaling . . . . . . . . . . . . . . . . . . . . 7 74 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . 7 75 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 7 76 7. References . . . . . . . . . . . . . . . . . . . . . . . . 7 77 7.1. Normative References . . . . . . . . . . . . . . . . . . . 7 78 7.2. Informative References . . . . . . . . . . . . . . . . . . 8 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 8 81 1. Introduction 83 Security protocols require random bits for secure use. Ideally, such 84 randomness should be provided to the operating system (OS) by a 85 physical source of entropy, a "True Random Number Generator" (TRNG). 86 Unfortunately, such sources of entropy are not generally available. 87 All common OSs use random bits from other sources such as clock 88 variations, event timing, network traffic, and so on, to create a 89 pool of random bits available to applications. Further, some OSs do 90 not retain randomness pools across reboots, leading to the need for 91 fresh random bits each time a system is started. 93 Recently it was discovered [Mining] that a relatively large number of 94 TLS and SSH public keys in the wild share a factor. The reason for 95 that is presumed to be lack of much initial randomness when devices 96 are first started and the keys are created. Security protocols, in 97 particular SSH [RFC4253], that generate secret parameters before 98 there is sufficient randomness end up with long-lived private keys 99 that are vulnerable to guessing. 101 This document proposes that network devices use DHCP to request 102 additional random material to be mixed in with the recipient's 103 operating system's own random pool early in the boot process. The 104 DHCP server can provide such material from its own "Pseudo-Random 105 Number Generator" (PRNG). The requesting network device's OS can 106 then mix the obtained material into its own PRNG. 108 The proposal does not mandate any particular use by the client, but 109 Section 3 describes various ways of applying it in different 110 settings. 112 1.1. Conventions used in this document 114 All the DHCP related terms used in this document are to be 115 interpreted as defined in the Dynamic Host Configuration Protocol v4 116 (DHCPv4) [RFC2131] and Dynamic Host Configuration Protocol v6 117 (DHCPv6) [RFC3315] specifications. DHCP refers to both DHCPv4 and 118 DHCPv6 messages and entities throughout this document. 120 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 121 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 122 document are to be interpreted as described in [RFC2119]. 124 2. The Initial Randomness Extension 125 2.1. Extension Format 127 The extension consists of a variable-length Random Material field of 128 arbitrary (random) octets. The field's length MUST be either 0, or 129 between 16 and 64 octets. If the length is 0, it means that the 130 sender is requesting randomness from the server and does not include 131 any random material of its own. 133 The design of the extension allows the DHCP client to request the 134 server to send random material, and for both client and server to 135 each offer its own random material to the other party. If the 136 receiving party cryptographically mixes the offered random material 137 into its random pool, even if that material is completely predictable 138 (such as all zeros), it will not have a negative effect on the pool. 140 2.1.1. DHCPv4 142 Code Random Octets 143 +-----+-----+-----+-----+-----+-----+-----+-----+-----+ 144 |TBD1 | Len | X | X | r0 | r1 | r2 | r3 | r4 | ... 145 +-----+-----+-----+-----+-----+-----+-----+-----+-----+ 147 Figure 1: DHCPv4 Extension 149 The Code field is TBD by IANA. 151 The Len field is the length of the random octets, and excludes the 152 Code field and the Length field itself. 154 The X octets are used for padding, they MUST be sent as zero and MUST 155 be ignored by the receiver. 157 2.1.2. DHCPv6 159 0 1 2 3 160 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 162 | Option Code (TBD2) | OptLen | 163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 164 | Random Octets... + 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 167 Figure 2: DHCPv6 Extension 169 The Option Code is TBD by IANA. 171 The OptLen field is the length of the random octets, and excludes the 172 Option Code field and the OptLen field itself. 174 2.2. Client and Server Behavior 176 A client MAY use this extension in a DHCPREQUEST or a DHCPINFORM 177 message. The client SHOULD include random material in its request if 178 it believes it has seen more than n bits of physical entropy, where n 179 is defined by local policy. If the client does not include any 180 random material, it MAY still use this extension, with an empty 181 Random Octets field, to signal that it requests random material from 182 the server. 184 A server MAY use this extension in a DHCPACK message. A server using 185 this extension that is unable to provide random material SHOULD 186 include an empty Random Octets field. 188 If a server is also a DHCP client to some other DHCP server on a 189 different interface, it is RECOMMENDED that the server obtain random 190 material from its upstream server before it serves randomness to its 191 clients. 193 3. Alternatives and Applicability 195 This section lists several viable alternatives to the current 196 proposal. Then we discuss several use cases, and for each one, 197 whether and how this extension can be used. 199 3.1. Alternatives to This Proposal 201 In general, there are three good alternatives to the current 202 solution: 204 1. Use of an on-board hardware based TRNG, such as the Intel RdRand 205 instruction [IntelArch]. 206 2. Pre-provisioning, with the manufacturer of the device creating a 207 unique and secret value on each new device, and seeding the RNG 208 with this value. 209 3. In virtual systems, use of randomness obtained from the host. 211 It is noted that option #2 can be implemented by the current 212 extension, when used in a secure network. 214 While all alternatives are technically feasible today, there are 215 still many platforms that do not use any of them. 217 As discussed in Section 4.1, a good random number generator must be 218 able to mix randomness from multiple sources, in a manner than 219 accumulates entropy even if some of the sources are highly non-random 220 and/or observable to an attacker. So as a best practice, 221 implementors that have multiple sources available to them should mix 222 them together, to avoid known and unknown issues with any of the 223 sources. 225 4. Security Considerations 227 In addition to those listed here, please refer to [RFC4086] for 228 further considerations. 230 4.1. RNG Properties 232 This document assumes a modern crypto-grade RNG on both client and 233 server, which should have at least the following properties: 235 o The output stream cannot be distinguished from a truly random one 236 without knowing the secret state. 237 o The RNG can be fed by any external material, even material known 238 by an attacker, at any time. Such material will normally 239 increase, and will never decrease the generator's entropy. 240 o The generator's internal state can never be revealed to an 241 attacker, even if the attacker can feed any amount of known data 242 into the RNG. 244 4.2. Resistance Against Network Attacks 246 The current extension is not resistant to either passive or active 247 attackers. Specifically, if an attacker knows the complete state of 248 the RNG, and is able to listen in on the local network, they will be 249 able to compute the state of the RNG after it has been fed with the 250 random material. 252 4.3. Denial of Service 254 An active attacker can use this extension to overload the server's 255 CPU and possibly to exhaust the server's entropy pool. To avoid such 256 attacks, the server SHOULD rate-limit responses to this particular 257 extension. 259 4.4. Saving RNG State 261 The current extension is targeted at the initial bootstrap of a host 262 or device. Different devices choose whether or not to save random 263 state across reboots based on their particular design considerations. 264 In short, saving state causes the booting machine to have some random 265 material already; saving state also allows someone who can view the 266 quiescent state (such as reading from the drive) to know the initial 267 state of the OS's random pool. 269 4.5. Protocol Signaling 271 This protocol does not allow the client or the server to signal what 272 type of random material is being requested or offered. Specifically, 273 they are unable to signal whether randomness is being backed by 274 measured physical entropy. This was done to simplify the protocol, 275 and also because the protocol is vulnerable to active attackers that 276 may be present on the network and could alter any such signals. 278 5. IANA Considerations 280 This document defines the DHCP Initial Randomness option which 281 requires assignment of DHCPv4 option code TBD1 assigned from the 282 "Bootp and DHCP options" registry (), as specified in 284 [RFC2939]. 286 This document defines the DHCP Initial Randomness option which 287 requires assignment of DHCPv6 option code TBD2 assigned from the 288 "DHCP option Codes" registry (). 291 6. Acknowledgements 293 This proposal was inspired by a discussion on the Cryptography 294 mailing list, and we would like to thank John Gilmore for triggering 295 the idea of "BOOTP for RNG". 297 7. References 299 7.1. Normative References 301 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 302 Requirement Levels", BCP 14, RFC 2119, March 1997. 304 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 305 RFC 2131, March 1997. 307 [RFC2939] Droms, R., "Procedures and IANA Guidelines for Definition 308 of New DHCP Options and Message Types", BCP 43, RFC 2939, 309 September 2000. 311 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 312 and M. Carney, "Dynamic Host Configuration Protocol for 313 IPv6 (DHCPv6)", RFC 3315, July 2003. 315 7.2. Informative References 317 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 318 Requirements for Security", BCP 106, RFC 4086, June 2005. 320 [RFC4253] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 321 Transport Layer Protocol", RFC 4253, January 2006. 323 [Mining] Heninger, N., Durumeric, Z., Wustrow, E., and J. 324 Halderman, "Mining Your Ps and Qs: Detection of Widespread 325 Weak Keys in Network Devices", Proceedings of the 21st 326 USENIX Security Symposium , August 2012, 327 . 329 [IntelArch] 330 "Intel 64 and IA-32 Architectures Software Developer's 331 Manual Combined Volumes 2A, 2B, and 2C: Instruction Set 332 Reference, A-Z", December 2012. 334 Authors' Addresses 336 Yaron Sheffer 337 Porticor 338 29 HaHarash St. 339 Hod HaSharon 4501303 340 Israel 342 Email: yaronf.ietf@gmail.com 344 Paul Hoffman 345 VPN Consortium 346 127 Segre Place 347 Santa Cruz, CA 95060 348 US 350 Email: paul.hoffman@vpnc.org