--- 1/draft-ietf-dhc-forcerenew-nonce-02.txt 2011-12-21 18:13:59.126671077 +0100 +++ 2/draft-ietf-dhc-forcerenew-nonce-03.txt 2011-12-21 18:13:59.154671063 +0100 @@ -1,96 +1,84 @@ softwire D. Miles Internet-Draft Alcatel-Lucent Intended status: Standards Track W. Dec -Expires: March 9, 2012 Cisco Systems +Expires: June 23, 2012 Cisco Systems J. Bristow Swisscom Schweiz AG R. Maglione Telecom Italia - September 6, 2011 + December 21, 2011 Forcerenew Nonce Authentication - draft-ietf-dhc-forcerenew-nonce-02 + draft-ietf-dhc-forcerenew-nonce-03 Abstract 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 Forcerenew Nonce Authentication the server exchanges a - nonce with the client on the initial DHCP ACK that is used for - subsequent validation of a Forcerenew message. + server. In Forcerenew Nonce Authentication the server sends a nonce + with the client on the initial DHCP ACK that is used for subsequent + validation of a Forcerenew message. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on March 9, 2012. + This Internet-Draft will expire on June 23, 2012. Copyright Notice Copyright (c) 2011 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. - This document may contain material from IETF Documents or IETF - Contributions published or made publicly available before November - 10, 2008. The person(s) controlling the copyright in some of this - material may not have granted the IETF Trust the right to allow - modifications of such material outside the IETF Standards Process. - Without obtaining an adequate license from the person(s) controlling - the copyright in such materials, this document may not be modified - outside the IETF Standards Process, and derivative works of it may - not be created outside the IETF Standards Process, except to format - it for publication as an RFC or to translate it into languages other - than English. - Table of Contents - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 - 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 - 3. Message authentication . . . . . . . . . . . . . . . . . . . . 4 - 3.1. Forcerenew Nonce Authentication . . . . . . . . . . . . . 4 - 3.1.1. Forcerenew Nonce Protocol Capability Option . . . . . 5 - 3.1.2. Forcerenew Nonce Protocol . . . . . . . . . . . . . . 7 + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 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 Protocol . . . . . . . . . . . . . . 6 3.1.3. Server considerations for Forcerenew Nonce - Authentication . . . . . . . . . . . . . . . . . . . . 8 + Authentication . . . . . . . . . . . . . . . . . . . . 7 3.1.4. Client considerations for Forcerenew Nonce - Authentication . . . . . . . . . . . . . . . . . . . . 9 - 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 - 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 - 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 - 6.1. Protocol vulnerabilities . . . . . . . . . . . . . . . . . 10 - 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 - 7.1. Normative References . . . . . . . . . . . . . . . . . . . 11 - 7.2. Informative References . . . . . . . . . . . . . . . . . . 11 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 + Authentication . . . . . . . . . . . . . . . . . . . . 8 + 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 + 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 + 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 + 6.1. Protocol vulnerabilities . . . . . . . . . . . . . . . . . 9 + 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 + 7.1. Normative References . . . . . . . . . . . . . . . . . . . 10 + 7.2. Informative References . . . . . . . . . . . . . . . . . . 10 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 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 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- @@ -253,50 +241,50 @@ | | | | |\ ____________ | | | DHCPRELEASE \| | | | | | Discards lease | | | v v v 3.1.2. Forcerenew Nonce Protocol - [RFC3118] defined an extensible DHCPv4 authentication option which - supports multiple protocols. The Forcerenew Nonce Protocol makes use - of the DHCP authentication option defined in [RFC3118] re-using the - option format. + The Forcerenew Nonce Protocol makes use of both the DHCP + authentication option defined in [RFC3118] re-using the option format + and of the Reconfigure Key Authentication Protocol defined in + [RFC3315]. The following fields are set in an DHCP authentication option for the Forcerenew Nonce Authentication Protocol: - protocol + protocol 3 algorithm 1 RDM 0 The format of the Authentication information for the Forcerenew Nonce Authentication Protocol is: 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) | +-+-+-+-+-+-+-+-+ | . . . . . +-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type Type of data in Value field carried in this option: - 1 Forcerenew Nonce value (used in ACK message) + 1 Reconfigure Key value (used in ACK message) 2 HMAC-MD5 digest of the message (FORCERENEW message) Value Data as defined by field 3.1.3. Server considerations for Forcerenew Nonce Authentication The use of Forcerenew Nonce Protocol is dependent on the client indicating its capability through the FORCERENEW_NONCE_CAPABLE() DHCP option in any DHCP Discover or Request messages. The DHCP @@ -371,31 +359,25 @@ 4. Acknowledgements Comments are solicited and should be addressed to the DHC WG mailing list (dhcwg@ietf.org) and/or the authors. This contribution is based on work by Vitali Vinokour. Major sections of this draft use modified text from [RFC3315]. The authors wish to thank Ted Lemon and Bernie Volz for their support. 5. IANA Considerations - This document requests IANA to allocate an option code for the newly - defined DHCP option FORCERENEW_NONCE_CAPABALE as described in the - text. - - This document requests IANA to allocate a DHCP Authentication - Option(90) protocol number be assigned for Forcerenew Nonce - Authentication, per [RFC3118]. + This document requests IANA to assign 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: - This document requests IANA to create a new namespace associated with - the Forcerenew Nonce Authentication protocol: algorithm, per - [RFC3118]. + an option code of TBD1 for FORCERENEW_NONCE_CAPABALE 6. 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 this proposal. In this proposal any party able intercept the nonce exchange could impersonate a server and thus offers no protection from man-in-the- middle attacks. FORCERENEW messages failing the authentication should be silently discarded by the client. @@ -420,26 +401,26 @@ [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. -7.2. Informative References - [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. +7.2. Informative References + [TR-101i2] Anschutz, T., "Migration to Ethernet-Based Broadband Aggregation Broadband Forum TR-101 Issue 2", July 2011. Authors' Addresses David Miles Alcatel-Lucent L3 / 215 Spring St Melbourne, Victoria 3000,