doc: Add RFC documents

1 files changed, 675 insertions, 0 deletions

diff --git a/doc/rfc/rfc6704.txt b/doc/rfc/rfc6704.txt
new file mode 100644
index 0000000..5b20d5d
--- /dev/null
+++ b/doc/rfc/rfc6704.txt
@@ -0,0 +1,675 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                          D. Miles
+Request for Comments: 6704                                        Google
+Updates: 3203                                                     W. Dec
+Category: Standards Track                                  Cisco Systems
+ISSN: 2070-1721                                               J. Bristow
+                                                     Swisscom Schweiz AG
+                                                             R. Maglione
+                                                          Telecom Italia
+                                                             August 2012
+
+
+                    Forcerenew Nonce Authentication
+
+Abstract
+
+   Dynamic Host Configuration Protocol (DHCP) FORCERENEW allows for the
+   reconfiguration of a single host by forcing the DHCP client into a
+   Renew state on a trigger from the DHCP server.  In the Forcerenew
+   Nonce Authentication protocol, the server sends a nonce to the client
+   in the initial DHCP ACK that is used for subsequent validation of a
+   FORCERENEW message.  This document updates RFC 3203.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc6704.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Miles, et al.                Standards Track                    [Page 1]
+
+RFC 6704                    Forcerenew Nonce                 August 2012
+
+
+Copyright Notice
+
+   Copyright (c) 2012 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+Table of Contents
+
+   1. Introduction ....................................................2
+   2. Requirements Language ...........................................3
+   3. Message Authentication ..........................................3
+      3.1. Forcerenew Nonce Authentication ............................3
+           3.1.1. Forcerenew Nonce Protocol Capability Option .........4
+           3.1.2. Forcerenew Nonce Authentication Protocol ............6
+           3.1.3. Server Considerations for Forcerenew Nonce
+                  Authentication ......................................8
+           3.1.4. Client Considerations for Forcerenew Nonce
+                  Authentication ......................................9
+   4. IANA Considerations ............................................10
+   5. Security Considerations ........................................10
+      5.1. Protocol Vulnerabilities ..................................11
+   6. Acknowledgements ...............................................11
+   7. Normative References ...........................................11
+
+1.  Introduction
+
+   The DHCP reconfigure extension defined in [RFC3203] is a useful
+   mechanism allowing dynamic reconfiguration of a single host triggered
+   by the DHCP server.  Its application is currently limited by a
+   requirement that a Forcerenew message is always authenticated using
+   procedures as described in [RFC3118].  Authentication for DHCP
+   [RFC3118] is mandatory for FORCERENEW; however, as it is currently
+   defined, [RFC3118] requires distribution of constant token or shared-
+   secret out-of-band to DHCP clients.
+
+   The motivation for making authentication mandatory in DHCP FORCERENEW
+   was to prevent an off-network attacker from taking advantage of DHCP
+   FORCERENEW to accurately predict the timing of a DHCP renewal.
+   Without DHCP FORCERENEW, DHCP renewal timing is under the control of
+
+
+
+Miles, et al.                Standards Track                    [Page 2]
+
+RFC 6704                    Forcerenew Nonce                 August 2012
+
+
+   the client, and an off-network attacker has no way of predicting when
+   it will happen, since it doesn't have access to the exchange between
+   the DHCP client and DHCP server.
+
+   However, the requirement to use the DHCP authentication described in
+   [RFC3118] is more stringent than is required for this use case and
+   has limited adoption of DHCP FORCERENEW.  [RFC3315] defines an
+   authentication protocol using a nonce to prevent off-network
+   attackers from successfully causing clients to renew.  Since the off-
+   network attacker doesn't have access to the nonce, it can't trick the
+   client into renewing at a time of its choosing.
+
+   This document defines extensions to Authentication for DHCPv4
+   Messages [RFC3118] to create a new authentication protocol for DHCPv4
+   FORCERENEW [RFC3203] messages; this method does not require out-of-
+   band key distribution to DHCP clients.  The Forcerenew Nonce is
+   exchanged between server and client on initial DHCP ACK and is used
+   for verification of any subsequent FORCERENEW message.  This document
+   updates [RFC3203].
+
+2.  Requirements Language
+
+   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 [RFC2119].
+
+3.  Message Authentication
+
+   The Forcerenew message MUST be authenticated using either [RFC3118]
+   or the proposed Forcerenew Nonce Authentication protocol.
+
+3.1.  Forcerenew Nonce Authentication
+
+   The Forcerenew Nonce Authentication protocol provides protection
+   against misconfiguration of a client caused by a Forcerenew message
+   sent by a malicious DHCP server.  In this protocol, a DHCP server
+   sends a Forcerenew Nonce to the client in the initial exchange of
+   DHCP messages.  The client records the Forcerenew Nonce for use in
+   authenticating subsequent Forcerenew messages from that server.  The
+   server then includes a Hashed Message Authentication Code (HMAC)
+   computed from the Forcerenew nonce in subsequent Forcerenew messages.
+
+   Both the Forcerenew Nonce sent from the server to the client and the
+   HMAC in subsequent Forcerenew messages are carried as the
+   Authentication information in a DHCP Authentication option.  The
+   format of the Authentication information is defined in the following
+   section.
+
+
+
+
+Miles, et al.                Standards Track                    [Page 3]
+
+RFC 6704                    Forcerenew Nonce                 August 2012
+
+
+   The Forcerenew Nonce Authentication protocol is used (initiated by
+   the server) only if the client and server are not using the
+   authentication mechanism specified in [RFC3118] and the client and
+   server have negotiated to use the Forcerenew Nonce Authentication
+   protocol.
+
+3.1.1.  Forcerenew Nonce Protocol Capability Option
+
+   A DHCP client indicates DHCP Forcerenew Nonce Protocol capability by
+   including a FORCERENEW_NONCE_CAPABLE (145) option in DHCP Discover
+   and Request messages sent to the server.
+
+   A DHCP server that does not support Forcerenew Nonce Authentication
+   protocol authentication SHOULD ignore the FORCERENEW_NONCE_CAPABLE
+   (145) option.  A DHCP server indicates DHCP Forcerenew Nonce Protocol
+   preference by including a FORCERENEW_NONCE_CAPABLE (145) option in
+   any DHCP Offer messages sent to the client.
+
+   A DHCP client MUST NOT send DHCP messages with authentication options
+   where the protocol value is Forcerenew Nonce Authentication.
+
+   The FORCERENEW_NONCE_CAPABLE option contains code 145, length n, and
+   a sequence of algorithms the client supports:
+
+             Code   Len   Algorithms
+            +-----+-----+----+----+----+
+            | 145 |  n  | A1 | A2 | A3 | ....
+            +-----+-----+----+----+----+
+
+                 Figure 1: FORCERENEW_NONCE_CAPABLE Option
+
+   In this document, Section 3.1.2 defines the Forcerenew Nonce
+   Authentication protocol for algorithm equal to 1 and type equal to 2;
+   future documents will specify the other values for algorithm !=1 and
+   type !=2, allowing a different algorithm to be used with shorter/
+   longer values.
+
+   The client would indicate that it supports the functionality by
+   inserting the FORCERENEW_NONCE_CAPABLE option in the DHCP Discover
+   and Request messages.  If the server supports Forcerenew nonce
+   authentication and requires Forcerenew nonce authentication, it will
+   insert the FORCERENEW_NONCE_CAPABLE option in the DHCPOFFER.
+
+
+
+
+
+
+
+
+
+Miles, et al.                Standards Track                    [Page 4]
+
+RFC 6704                    Forcerenew Nonce                 August 2012
+
+
+                     Server          Client          Server
+                 (not selected)                    (selected)
+
+                       v               v               v
+                       |               |               |
+                       |     Begins initialization     |
+                       |               |               |
+                       | _____________/|\____________  |
+                       |/DHCPDISCOVER  | DHCPDISCOVER \|
+                       | w/FORCERENEW- | w/FORCERENEW- |
+                       | NONCE-CAPABLE | NONCE-CAPABLE |
+                       |               |               |
+                   Determines          |          Determines
+                  configuration        |         configuration
+                       |               |               |
+                       |\              |              /|
+                       | \__________   |    _________/ |
+                       |  DHCPOFFER \  |   /DHCPOFFER  |
+                       |w/FORCERENEW \ |  /w/FORCERENEW|
+                       |NONCE-CAPABLE \| /NONCE-CAPABLE|
+                       |               |               |
+                       |       Collects replies        |
+                       |               |               |
+                       |     Selects configuration     |
+                       |               |               |
+                       | _____________/|\____________  |
+                       |/ DHCPREQUEST  |  DHCPREQUEST\ |
+                       | w/Forcerenew- | w/Forcerenew- |
+                       | Nonce-Capable | Nonce-Capable |
+                       |               |               |
+                       |               |     Commits configuration
+                       |               |               |
+                       |               |Creates 128-bit Forcerenew Nonce
+                       |               |               |
+                       |               | _____________/|
+                       |               |/ DHCPACK      |
+                       |               | w/Auth-Proto= |
+                       |               | Forcerenew-   |
+                       |               |        Nonce  |
+                       |               |               |
+                       |Client stores Forcerenew Nonce |
+                       |               |               |
+                       |    Initialization complete    |
+                       |               |               |
+                       .               .               .
+                       .               .               .
+                       |               |               |
+                       |          Forcerenew           |
+
+
+
+Miles, et al.                Standards Track                    [Page 5]
+
+RFC 6704                    Forcerenew Nonce                 August 2012
+
+
+                       |               | _____________/|
+                       |               |/ DHCPFORCE    |
+                       |               | w/Auth-Proto= |
+                       |               | Forcerenew-   |
+                       |               |   Digest(HMAC)|
+                       |               |               |
+                       | Client checks HMAC digest     |
+                       | using stored Forcerenew Nonce |
+                       |               |               |
+                       |               |\____________  |
+                       |               |  DHCPREQUEST\ |
+                       |               | w/FORCERENEW- |
+                       |               | NONCE-CAPABLE |
+                       |               |               |
+                       |               |     Commits configuration
+                       |               |               |
+                       |               |Creates 128-bit Forcerenew Nonce
+                       |               |               |
+                       |               | _____________/|
+                       |               |/ DHCPACK      |
+                       |               | w/Auth-Proto= |
+                       |               |   Forcerenew- |
+                       |               |         Nonce |
+                       |               |               |
+                       |               |               |
+                       |               |               |
+                       .               .               .
+                       .               .               .
+                       |               |               |
+                       |      Graceful shutdown        |
+                       |               |               |
+                       |               |\ ____________ |
+                       |               | DHCPRELEASE  \|
+                       |               |               |
+                       |               |        Discards lease
+                       |               |               |
+                       v               v               v
+
+   Figure 2: Timeline Diagram of Messages Exchanged between DHCP Client
+      and Servers Using the Forcerenew Nonce Authentication Protocol
+
+3.1.2.  Forcerenew Nonce Authentication Protocol
+
+   The Forcerenew Nonce Authentication protocol makes use of both the
+   DHCP authentication option defined in [RFC3118] reusing the option
+   format and of the Reconfigure Key Authentication Protocol defined in
+   [RFC3315].
+
+
+
+
+Miles, et al.                Standards Track                    [Page 6]
+
+RFC 6704                    Forcerenew Nonce                 August 2012
+
+
+   The following diagram defines the format of the DHCP authentication
+   option:
+
+       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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |     Code      |    Length     |  Protocol     |   Algorithm   |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |     RDM       | Replay Detection (64 bits)                    |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |  Replay cont.                                                 |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |  Replay cont. |                                               |
+      +-+-+-+-+-+-+-+-+                                               |
+      |                                                               |
+      |           Authentication Information                          |
+      |                                                               |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+            Figure 3: Format of the DHCP Authentication Option
+
+   The following fields are set in an DHCP authentication option for the
+   Forcerenew Nonce Authentication protocol.
+
+      Code: 90 (Authentication) per [RFC3118]
+
+      Length: contains the length of the protocol
+
+      Protocol: 3 (Reconfigure Key) per [RFC3118]
+
+      Algorithm: 1 (HMAC-MD5) per [RFC3118] and [RFC3315]
+
+      Replay Detection: per the Replay Detection Method (RDM)
+
+      Replay Detection Method (RDM): 0
+
+      Authentication Information: specified below
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Miles, et al.                Standards Track                    [Page 7]
+
+RFC 6704                    Forcerenew Nonce                 August 2012
+
+
+   The format of the Authentication Information for the Forcerenew Nonce
+   Authentication Protocol is as follows:
+
+       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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |     Type      |                 Value (128 bits)              |
+      +-+-+-+-+-+-+-+-+                                               |
+      .                                                               .
+      .                                                               .
+      .                                               +-+-+-+-+-+-+-+-+
+      |                                               |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+            Figure 4: Format of the Authentication Information
+
+      Type: The type of data in Value field carried in this option:
+
+         1 Forcerenew nonce Value (used in ACK message)
+
+         2 HMAC-MD5 digest of the message (Forcerenew message)
+
+      Value: The message authentication code generated by applying MD5
+      to the DHCP message
+
+3.1.3.  Server Considerations for Forcerenew Nonce Authentication
+
+   The use of Forcerenew Nonce Authentication protocol is dependent on
+   the client indicating its capability through the
+   FORCERENEW_NONCE_CAPABLE (145) DHCP option in any DHCP Discover or
+   Request messages.  The DHCP Discovery or Request message from the
+   client MUST contain the FORCERENEW_NONCE_CAPABLE (145) option if the
+   Forcerenew Nonce Protocol is to be used by the server.  The absence
+   of the FORCERENEW_NONCE_CAPABLE (145) option indicates to the server
+   that the Forcerenew Nonce Authentication protocol is not supported;
+   thus, the server MUST NOT include a Forcerenew Nonce Protocol
+   Authentication option in the DHCP ACK.
+
+   The server indicates its support of the Forcerenew Nonce
+   Authentication protocol by including the DHCP
+   FORCERENEW_NONCE_CAPABLE (145) option in the DHCPOFFER.  The server
+   SHOULD NOT include this option unless the client has indicated its
+   capability in a DHCP Discovery message.  The presence of the
+   FORCERENEW_NONCE_CAPABLE (145) option in the DHCP offer may be used
+   by clients to prefer DHCP servers that are Forcerenew Nonce
+   Authentication protocol capable over those servers that do not
+   support such capability.
+
+
+
+
+Miles, et al.                Standards Track                    [Page 8]
+
+RFC 6704                    Forcerenew Nonce                 August 2012
+
+
+   If a capable server receives a DISCOVER or REQUEST (any type) that
+   indicates the client is capable, and the server has no previous nonce
+   recorded, it MUST generate a nonce and include it in the ACK.
+
+   The server selects a Forcerenew Nonce for a client only during
+   Request/ACK message exchange.  The server records the Forcerenew
+   nonce and transmits that nonce to the client in an Authentication
+   option in the DHCP ACK message.
+
+   The server SHOULD NOT include the nonce in an ACK when responding to
+   a renew unless a new nonce was generated.  This minimizes the number
+   of times the nonce is sent over the wire.
+
+   If the server to which the DHCP Request message was sent at time T1
+   has not responded, the client enters the REBINDING state and attempts
+   to contact any server.  The new Server receiving the DHCP message
+   MUST generate a new nonce.
+
+   The Forcerenew nonce is 128 bits long, and it MUST be a
+   cryptographically strong random or pseudo-random number that cannot
+   easily be predicted.  The nonce is embedded as a 128-bit value of the
+   Authentication information where type is set to 1 (Forcerenew nonce
+   Value).
+
+   To provide authentication for a Forcerenew message, the server
+   selects a replay detection value according to the RDM selected by the
+   server and computes an HMAC-MD5 of the Forcerenew message, based on
+   the procedure specified in Section 21.5 of [RFC3315], using the
+   Forcerenew Nonce for the client.  The server computes the HMAC-MD5
+   over the entire DHCP Forcerenew message, including the Authentication
+   option; the HMAC-MD5 field in the Authentication option is set to
+   zero for the HMAC-MD5 computation
+
+3.1.4.  Client Considerations for Forcerenew Nonce Authentication
+
+   A client that supports this mechanism MUST indicate Forcerenew nonce
+   Capability by including the FORCERENEW_NONCE_CAPABLE (145) DHCP
+   option defined in Section 3.1.1 in all DHCP Discover and Request
+   messages.  DHCP servers that support Forcerenew nonce Protocol
+   authentication MUST include the FORCERENEW_NONCE_CAPABLE (145) DHCP
+   option in all DHCP Offers, allowing the client to use this capability
+   in selecting DHCP servers should multiple Offers arrive.
+
+   The client MUST validate the DHCP ACK message contains a Forcerenew
+   Nonce in a DHCP authentication option.  If the server has indicated
+   capability for Forcerenew Nonce Authentication protocol in the DHCP
+   OFFER and the subsequent ACK received by the client while in the
+   selecting state omits a valid DHCP authentication option for the
+
+
+
+Miles, et al.                Standards Track                    [Page 9]
+
+RFC 6704                    Forcerenew Nonce                 August 2012
+
+
+   Forcerenew Nonce Authentication protocol, the client MUST discard the
+   message and return to the INIT state.
+
+   The client MUST record the Forcerenew Nonce from any valid ACK it
+   receives, if the ACK contains one.
+
+   To authenticate a Forcerenew message, the client computes an HMAC-
+   MD5, based on the procedure specified in Section 21.5 of [RFC3315],
+   over the DHCP Forcerenew message (after setting the HMAC-MD5 field in
+   the Authentication option to zero), using the Forcerenew Nonce
+   received from the server.  If this computed HMAC-MD5 matches the
+   value in the Authentication option, the client accepts the FORCERENEW
+   message.
+
+4.  IANA Considerations
+
+   IANA has assigned the following new DHCPv4 option code from the
+   registry "BOOTP Vendor Extensions and DHCP Options" maintained at
+   http://www.iana.org/assignments/bootp-dhcp-parameters:
+
+   Tag: 145
+
+   Name: FORCERENEW_NONCE_CAPABLE
+
+   Data length: 1
+
+   Description: Forcerenew Nonce Capable
+
+   Reference: this document
+
+5.  Security Considerations
+
+   As in some network environments FORCERENEW can be used to snoop and
+   spoof traffic, the FORCERENEW message MUST be authenticated using the
+   procedures as described in [RFC3118] or the mechanism described in
+   this document.
+
+   The mechanism in [RFC3315] for DHCPv6, which this document mirrors
+   for DHCPv4, uses a nonce to prevent an off-link attacker from
+   successfully triggering a renewal on a client by sending
+   DHCPFORCERENEW; since the attacker is off-link, it doesn't have the
+   nonce, and can't force a renewal.
+
+   An on-link attacker can always simply watch the DHCP renewal message
+   go out and respond to it, so this mechanism is useless for preventing
+   on-link attacks; hence, the security of the nonce in the case of on-
+   link attacks isn't relevant.  Therefore, HMAC-MD5 is, by definition,
+   adequate for the purpose, and there is no need for an extensible HMAC
+
+
+
+Miles, et al.                Standards Track                   [Page 10]
+
+RFC 6704                    Forcerenew Nonce                 August 2012
+
+
+   mechanism.  FORCERENEW messages failing the authentication should be
+   silently discarded by the client.
+
+5.1.  Protocol Vulnerabilities
+
+   The mechanism described in this document is vulnerable to a denial-
+   of-service (DoS) attack through flooding a client with bogus
+   FORCERENEW messages.  The calculations involved in authenticating the
+   bogus FORECERENEW messages may overwhelm the device on which the
+   client is running.
+
+   The mechanism described provides protection against the use of a
+   FORCERENEW message by a malicious DHCP server to mount a DoS or man-
+   in-the-middle attack on a client.  This protocol can be compromised
+   by an attacker that can intercept the initial message in which the
+   DHCP server sends the nonce to the client.
+
+6.  Acknowledgements
+
+   This contribution is based on work by Vitali Vinokour.  Major
+   sections of this document use modified text from [RFC3315].  The
+   authors wish to thank Ted Lemon, Matthew Ryan, and Bernie Volz for
+   their support.
+
+7.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC3118]  Droms, R. and W. Arbaugh, "Authentication for DHCP
+              Messages", RFC 3118, June 2001.
+
+   [RFC3203]  T'Joens, Y., Hublet, C., and P. De Schrijver, "DHCP
+              reconfigure extension", RFC 3203, December 2001.
+
+   [RFC3315]  Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
+              and M. Carney, "Dynamic Host Configuration Protocol for
+              IPv6 (DHCPv6)", RFC 3315, July 2003.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Miles, et al.                Standards Track                   [Page 11]
+
+RFC 6704                    Forcerenew Nonce                 August 2012
+
+
+Authors' Addresses
+
+   David Miles
+   Google
+
+   EMail: davidmiles@google.com
+
+
+   Wojciech Dec
+   Cisco Systems
+   Haarlerbergpark Haarlerbergweg 13-19
+   Amsterdam, NOORD-HOLLAND  1101 CH
+   Netherlands
+
+   EMail: wdec@cisco.com
+
+
+   James Bristow
+   Swisscom Schweiz AG
+   Zentweg 9
+   Bern, 3050,
+   Switzerland
+
+   EMail: James.Bristow@swisscom.com
+
+
+   Roberta Maglione
+   Telecom Italia
+   Via Reiss Romoli 274
+   Torino  10148
+   Italy
+
+   EMail: roberta.maglione@telecomitalia.it
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Miles, et al.                Standards Track                   [Page 12]
+