<?xml version="1.0" encoding="UTF-8"?>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc tocindent="no"?>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc tocindent="no"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY rfc2131 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2131.xml">
<!ENTITY rfc2939 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2939.xml">
<!ENTITY rfc3315 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3315.xml">
<!ENTITY rfc4086 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4086.xml">
<!ENTITY rfc4253 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4253.xml">
]>
<rfc docName="draft-sheffer-dhc-initial-random-00" ipr="trust200902" category="std">
  <front>
    <title abbrev="Initial Randomness">A DHCP Extension To Provide Initial Random Material</title>
    <author initials="Y." surname="Sheffer" fullname="Yaron Sheffer">
      <organization abbrev="Porticor">Porticor</organization>
      <address>
        <postal>
          <street>29 HaHarash St.</street>
          <city>Hod HaSharon</city>
          <code>4501303</code>
          <country>Israel</country>
        </postal>
        <email>yaronf.ietf@gmail.com</email>
      </address>
    </author>
    <author initials="P." surname="Hoffman" fullname="Paul Hoffman">
      <organization abbrev="VPNC">VPN Consortium</organization>
      <address>
        <postal>
          <street>127 Segre Place</street>
          <city>Santa Cruz, CA</city>
          <code>95060</code>
          <country>US</country>
        </postal>
        <email>paul.hoffman@vpnc.org</email>
      </address>
    </author>
    <date month="December" year="2013"/>
    <area>
Internet Area
</area>
    <keyword>Internet-Draft</keyword>
    <abstract>
      <t>
Some network devices get little or no entropy from their underlying operating systems when they are first started. As a result, cryptographic applications started before there is sufficient entropy in the operating system's pool can be initialized into a state that can be exploited by an attacker. This document defines a DHCP extension that can provide the operating system of a network device with some initial randomness that can only be known by an attacker who is on the same network segment as the device and its DHCP server. The operating system can mix this random input into its random pool early in the boot procedure and thus have more entropy available when cryptographic applications start.</t>
    </abstract>
  </front>
  <middle>
    <section title="Introduction" anchor="d1e338">
      <t>
Security protocols require random bits for secure use. Ideally, such randomness should be provided to the operating system (OS) by a physical source of entropy, a “True Random Number Generator” (TRNG). Unfortunately, such sources of entropy are not generally available. All common OSs use random bits from other sources such as clock variations, event timing, network traffic, and so on, to create a pool of random bits available to applications. Further, some OSs do not retain randomness pools across reboots, leading to the need for fresh random bits each time a system is started.</t>
      <t>
Recently it was discovered <xref target="Mining"/> that a relatively large number of TLS and SSH public keys in the wild share a factor. The reason for that is presumed to be lack of much initial randomness when devices are first started and the keys are created. Security protocols, in particular SSH <xref target="RFC4253"/>, that generate secret parameters before there is sufficient randomness end up with long-lived private keys that are vulnerable to guessing.</t>
      <t>
This document proposes that network devices use DHCP to request additional random material to be mixed in with the recipient's operating system's own random pool early in the boot process. The DHCP server can provide such material from its own “Pseudo-Random Number Generator” (PRNG). The requesting network device's OS can then mix the obtained material into its own PRNG.</t>
      <t>
The proposal does not mandate any particular use by the client, but  <xref target="sec_Applicability"/> describes various ways of applying it in different settings.</t>
      <section title="Conventions used in this document" anchor="d1e372">
        <t>
All the DHCP related terms used in this document are to be interpreted as defined in the Dynamic Host Configuration Protocol v4 (DHCPv4) <xref target="RFC2131"/> and Dynamic Host Configuration Protocol v6 (DHCPv6) <xref target="RFC3315"/> specifications. DHCP refers to both DHCPv4 and DHCPv6 messages and entities throughout this document.</t>
        <t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in <xref target="RFC2119"/>.</t>
      </section>
    </section>
    <section title="The Initial Randomness Extension" anchor="d1e402">
      <section title="Extension Format" anchor="d1e408">
        <t>
The extension consists of a variable-length Random Material field of arbitrary (random) octets. The field's length MUST be either 0, or between 16 and 64 octets. If the length is 0, it means that the sender is requesting randomness from the server and does not include any random material of its own.</t>
        <t>
The design of the extension allows the DHCP client to request the server to send random material, and for both client and server to each offer its own random material to the other party. If the receiving party cryptographically mixes the offered random material into its random pool, even if that material is completely predictable (such as all zeros), it will not have a negative effect on the pool.</t>
        <section title="DHCPv4" anchor="d1e420">
          <t>
</t>
          <t>
            <figure anchor="magicparlabel-177" title="DHCPv4 Extension">
              <artwork> Code               Random Octets
+-----+-----+-----+-----+-----+-----+-----+-----+-----+
|TBD1 | Len |  X  |  X  | r0  |  r1 |  r2 |  r3 |  r4 | ...
+-----+-----+-----+-----+-----+-----+-----+-----+-----+</artwork>
            </figure>
          </t>
          <t>
The Code field is TBD by IANA.</t>
          <t>
The Len field is the length of the random octets, and excludes the Code field and the Length field itself.</t>
          <t>
The X octets are used for padding, they MUST be sent as zero and MUST be ignored by the receiver.</t>
        </section>
        <section title="DHCPv6" anchor="d1e458">
          <t>
</t>
          <t>
            <figure anchor="magicparlabel-201" title="DHCPv6 Extension">
              <artwork>     0                   1                   2                   3 
     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |       Option Code (TBD2)      |            OptLen             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                       Random Octets...                        +
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ </artwork>
            </figure>
          </t>
          <t>
The Option Code is TBD by IANA.</t>
          <t>
The OptLen field is the length of the random octets, and excludes the Option Code field and the OptLen field itself.</t>
        </section>
      </section>
      <section title="Client and Server Behavior" anchor="d1e492">
        <t>
A client MAY use this extension in a DHCPREQUEST or a DHCPINFORM message. The client SHOULD include random material in its request if it believes it has seen more than n bits of physical entropy, where n is defined by local policy. If the client does not include any random material, it MAY still use this extension, with an empty Random Octets field, to signal that it requests random material from the server.</t>
        <t>
A server MAY use this extension in a DHCPACK message. A server using this extension that is unable to provide random material SHOULD include an empty Random Octets field.</t>
        <t>
If a server is also a DHCP client to some other DHCP server on a different interface, it is RECOMMENDED that the server obtain random material from its upstream server before it serves randomness to its clients.</t>
      </section>
    </section>
    <section title="Alternatives and Applicability" anchor="sec_Applicability">
      <t>
This section lists several viable alternatives to the current proposal. Then we discuss several use cases, and for each one, whether and how this extension can be used.</t>
      <section title="Alternatives to This Proposal" anchor="d1e519">
        <t>
In general, there are three good alternatives to the current solution:</t>
        <t>
          <list style="numbers">
            <t>
Use of an on-board hardware based TRNG, such as the Intel RdRand instruction <xref target="IntelArch"/>.</t>
            <t>
Pre-provisioning, with the manufacturer of the device creating a unique and secret value on each new device, and seeding the RNG with this value.</t>
            <t>
In virtual systems, use of randomness obtained from the host.</t>
          </list>
        </t>
        <t>
It is noted that option #2 can be implemented by the current extension, when used in a secure network.</t>
        <t>
While all alternatives are technically feasible today, there are still many platforms that do not use any of them.</t>
        <t>
As discussed in  <xref target="sub_RNG_Properties"/>, a good random number generator must be able to mix randomness from multiple sources, in a manner than accumulates entropy even if some of the sources are highly non-random and/or observable to an attacker. So as a best practice, implementors that have multiple sources available to them should mix them together, to avoid known and unknown issues with any of the sources.</t>
      </section>
    </section>
    <section title="Security Considerations" anchor="d1e556">
      <t>
In addition to those listed here, please refer to <xref target="RFC4086"/> for further considerations.</t>
      <section title="RNG Properties" anchor="sub_RNG_Properties">
        <t>
This document assumes a modern crypto-grade RNG on both client and server, which should have at least the following properties:</t>
        <t>
          <list style="symbols">
            <t>
The output stream cannot be distinguished from a truly random one without knowing the secret state.</t>
            <t>
The RNG can be fed by any external material, even material known by an attacker, at any time. Such material will normally increase, and will never decrease the generator's entropy.</t>
            <t>
The generator's internal state can never be revealed to an attacker, even if the attacker can feed any amount of known data into the RNG.</t>
          </list>
        </t>
      </section>
      <section title="Resistance Against Network Attacks" anchor="d1e593">
        <t>
The current extension is not resistant to either passive or active attackers. Specifically, if an attacker knows the complete state of the RNG, and is able to listen in on the local network, they will be able to compute the state of the RNG after it has been fed with the random material.</t>
      </section>
      <section title="Denial of Service" anchor="d1e602">
        <t>
An active attacker can use this extension to overload the server's CPU and possibly to exhaust the server's entropy pool. To avoid such attacks, the server SHOULD rate-limit responses to this particular extension.</t>
      </section>
      <section title="Saving RNG State" anchor="d1e611">
        <t>
The current extension is targeted at the initial bootstrap of a host or device. Different devices choose whether or not to save random state across reboots based on their particular design considerations. In short, saving state causes the booting machine to have some random material already; saving state also allows someone who can view the quiescent state (such as reading from the drive) to know the initial state of the OS's random pool.</t>
      </section>
      <section title="Protocol Signaling" anchor="d1e620">
        <t>
This protocol does not allow the client or the server to signal what type of random material is being requested or offered. Specifically, they are unable to signal whether randomness is being backed by measured physical entropy. This was done to simplify the protocol, and also because the protocol is vulnerable to active attackers that may be present on the network and could alter any such signals.</t>
      </section>
    </section>
    <section title="IANA Considerations" anchor="d1e630">
      <t>
This document defines the DHCP Initial Randomness option which requires assignment of DHCPv4 option code TBD1 assigned from the "Bootp and DHCP options" registry (<eref target="http://www.iana.org/assignments/ bootp-dhcp-parameters/bootp-dhcp-parameters.xml"/>), as specified in <xref target="RFC2939"/>.</t>
      <t>
This document defines the DHCP Initial Randomness option which requires assignment of DHCPv6 option code TBD2 assigned from the "DHCP option Codes" registry (<eref target="http://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xml"/>).</t>
    </section>
    <section title="Acknowledgements" anchor="d1e654">
      <t>
This proposal was inspired by a discussion on the Cryptography mailing list, and we would like to thank John Gilmore for triggering the idea of “BOOTP for RNG”.</t>
    </section>
  </middle>
  <back>
    <references title="Normative References">&rfc2119;
&rfc2131;
&rfc2939;
&rfc3315;
</references>
    <references title="Informative References">&rfc4086;
&rfc4253;

<reference anchor="Mining" target="https://factorable.net/"><front><title>Mining Your Ps and Qs: Detection of Widespread Weak Keys in Network Devices</title><author initials="N." surname="Heninger" fullname="Nadia Heninger"><organization/></author><author initials="Z." surname="Durumeric" fullname="Zakir Durumeric"><organization/></author><author initials="E." surname="Wustrow" fullname="Eric Wustrow"><organization/></author><author initials="J. A." surname="Halderman" fullname="J. Alex Halderman"><organization/></author><date year="2012" month="August"/></front><seriesInfo name="Proceedings of the 21st USENIX Security Symposium" value=""/></reference> 
<reference anchor="IntelArch"><front><title>Intel 64 and IA-32 Architectures Software Developer's Manual Combined Volumes 2A, 2B, and 2C: Instruction Set Reference, A-Z</title><author fullname="Intel Corp."><organization/></author><date year="2012" month="December"/></front></reference> </references>
  </back>
</rfc>
