summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc6704.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc6704.txt')
-rw-r--r--doc/rfc/rfc6704.txt675
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]
+