draft-ietf-dhc-forcerenew-nonce-06.txt   draft-ietf-dhc-forcerenew-nonce-07.txt 
dhc D. Miles dhc D. Miles
Internet-Draft Google Internet-Draft Google
Updates: 3203 (if approved) W. Dec Updates: 3203 (if approved) W. Dec
Intended status: Standards Track Cisco Systems Intended status: Standards Track Cisco Systems
Expires: September 12, 2012 J. Bristow Expires: December 16, 2012 J. Bristow
Swisscom Schweiz AG Swisscom Schweiz AG
R. Maglione R. Maglione
Telecom Italia Telecom Italia
March 11, 2012 June 14, 2012
Forcerenew Nonce Authentication Forcerenew Nonce Authentication
draft-ietf-dhc-forcerenew-nonce-06 draft-ietf-dhc-forcerenew-nonce-07
Abstract Abstract
Dynamic Host Configuration Protocol (DHCP) FORCERENEW allows for the Dynamic Host Configuration Protocol (DHCP) FORCERENEW allows for the
reconfiguration of a single host by forcing the DHCP client into a reconfiguration of a single host by forcing the DHCP client into a
Renew state on a trigger from the DHCP server. In Forcerenew Nonce Renew state on a trigger from the DHCP server. In Forcerenew Nonce
Authentication the server sends a nonce to the client in the initial Authentication the server sends a nonce to the client in the initial
DHCP ACK that is used for subsequent validation of a FORCERENEW DHCP ACK that is used for subsequent validation of a FORCERENEW
message. This document updates RFC 3203. message. This document updates RFC 3203.
skipping to change at page 1, line 40 skipping to change at page 1, line 40
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 12, 2012. This Internet-Draft will expire on December 16, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 18 skipping to change at page 2, line 18
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
3. Message authentication . . . . . . . . . . . . . . . . . . . . 3 3. Message authentication . . . . . . . . . . . . . . . . . . . . 3
3.1. Forcerenew Nonce Authentication . . . . . . . . . . . . . 4 3.1. Forcerenew Nonce Authentication . . . . . . . . . . . . . 4
3.1.1. Forcerenew Nonce Protocol Capability Option . . . . . 4 3.1.1. Forcerenew Nonce Protocol Capability Option . . . . . 4
3.1.2. Forcerenew Nonce Protocol . . . . . . . . . . . . . . 6 3.1.2. Forcerenew Nonce Protocol . . . . . . . . . . . . . . 7
3.1.3. Server considerations for Forcerenew Nonce 3.1.3. Server considerations for Forcerenew Nonce
Authentication . . . . . . . . . . . . . . . . . . . . 8 Authentication . . . . . . . . . . . . . . . . . . . . 8
3.1.4. Client considerations for Forcerenew Nonce 3.1.4. Client considerations for Forcerenew Nonce
Authentication . . . . . . . . . . . . . . . . . . . . 9 Authentication . . . . . . . . . . . . . . . . . . . . 9
4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
6.1. Protocol vulnerabilities . . . . . . . . . . . . . . . . . 11 6.1. Protocol vulnerabilities . . . . . . . . . . . . . . . . . 11
7. Normative References . . . . . . . . . . . . . . . . . . . . . 11 7. Normative References . . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction 1. Introduction
The DHCP Reconfigure Extension defined in [RFC3203] is a useful The DHCP Reconfigure Extension defined in [RFC3203] is a useful
mechanism allowing dynamic reconfiguration of a single host triggered mechanism allowing dynamic reconfiguration of a single host triggered
by the DHCP server. Its application is currently limited by a by the DHCP server. Its application is currently limited by a
requirement that FORCERENEW message is always authenticated using requirement that FORCERENEW message is always authenticated using
procedures as described in [RFC3118]. Authentication for DHCP procedures as described in [RFC3118]. Authentication for DHCP
[RFC3118] is mandatory for FORCERENEW, however as it is currently [RFC3118] is mandatory for FORCERENEW, however as it is currently
defined [RFC3118] requires distribution of constant token or shared- defined [RFC3118] requires distribution of constant token or shared-
skipping to change at page 4, line 42 skipping to change at page 4, line 42
A DHCP server that does not support Forcerenew Nonce Protocol A DHCP server that does not support Forcerenew Nonce Protocol
authentication SHOULD ignore the FORCERENEW_NONCE_CAPABLE(<TBD>) authentication SHOULD ignore the FORCERENEW_NONCE_CAPABLE(<TBD>)
option. A DHCP server indicates DHCP Forcerenew Nonce Protocol option. A DHCP server indicates DHCP Forcerenew Nonce Protocol
preference by including a FORCERENEW_NONCE_CAPABLE(<TBD>) option in preference by including a FORCERENEW_NONCE_CAPABLE(<TBD>) option in
any DHCP Offer messages sent to the client. any DHCP Offer messages sent to the client.
A DHCP client MUST NOT send DHCP messages with authentication options A DHCP client MUST NOT send DHCP messages with authentication options
where the protocol value is Forcerenew Nonce Authentication(<TBD>). where the protocol value is Forcerenew Nonce Authentication(<TBD>).
The FORCERENEW_NONCE_CAPABLE option is a zero length option with code The FORCERENEW_NONCE_CAPABLE option contains code <TDB>, length n and
of <TDB> and format as follows: a sequence of algorithms the client supports:
Code Len Code Len Algorithms
+-----+-----+ +-----+-----+----+----+----+
| TBD | 0 | | TBD | n | A1 | A2 | A3 | ....
+-----+-----+ +-----+-----+----+----+----+
This document, in section Section 3.1.2, defines the Forcerenew Nonce
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 The client would indicate that it supports the functionality by
inserting the FORCERENEW_NONCE_CAPABLE option in the DHCP Discover inserting the FORCERENEW_NONCE_CAPABLE option in the DHCP Discover
and Request messages. If the server supports Forcerenew nonce and Request messages. If the server supports Forcerenew nonce
authentication and requires Forcerenew nonce authentication, it will authentication and requires Forcerenew nonce authentication, it will
insert the FORCERENEW_NONCE_CAPABLE option in the DHCP Offer message. insert the FORCERENEW_NONCE_CAPABLE option in the DHCP Offer message.
Server Client Server Server Client Server
(not selected) (selected) (not selected) (selected)
 End of changes. 9 change blocks. 
13 lines changed or deleted 19 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/