Forcerenew Nonce Authentication
draft-ietf-dhc-forcerenew-nonce-07

[Ballot discuss]
I guess I'm the last guy standing - I've not seen responses to these.  It is possible I missed them though.

Updated based on -06

Seems the DHCP option needs to indicate the algorithm(s) supported by the server/client?  If HMAC-CoolNewAlg gets registered for use with DHCP won't you need to indicate whether HMAC-CoolNewAlg and/or HMAC-MD5 is supported?

Assuming we always use HMAC-MD5 then you'll have an output of 128 bits, but what happens if DHCP starts to use HMAC-SHA-256 - i.e., are we always going to use HMAC-CoolNewAlg-128?

[Ballot comment]
Update based on -06

s3.1.2: Maybe for the algorithm you should point to the IANA registry for DHCP Algorithm Name Space Values (http://www.iana.org/assignments/auth-namespaces/auth-namespaces.xml) but say that currently only HMAC-MD5 is supported?  The alg used in this wouldn't ever differ right?

[Ballot discuss]
(Updated for -05)

Cleared:

This is still unaddressed:
Doesn't the client's computation confirming the same HMAC-MD5 over the message need to be performed the same way the server computes the value (as described in the last paragraph of 3.1.3)? Should the instructions for zeroing the HMAC-MD5 field in the message fed into the computation be repeated here?

[Ballot comment]
Thanks for writing this document. I believe it is ready to move forward, despite the unsubstantiated worries about weakening RFC 3118 security :-)

One small comment:

>  The server SHOULD NOT include the nonce in an ACK when responding to
>  a renew unless a nonce was generated.

... unless a *new* nonce was generated ...?

[Ballot comment]
A couple 2119 issues maybe:

s3: r/The FORCERENEW message must be authenticated/The FORCERENEW message MUST be authenticated ?

s3.1.1: r/authentication should ignore/authentication SHOULD ignore ?

And for the algs supported:

s3.1.2: Maybe for the algorithm you should point to the IANA registry for DHCP Algorithm Name Space Values (http://www.iana.org/assignments/auth-namespaces/auth-namespaces.xml) but say that currently only HMAC-MD5 is supported?  The alg used in this wouldn't ever differ right?

[Ballot discuss]
Seems the DHCP option needs to indicate the algorithm(s) supported by the server/client?  If HMAC-CoolNewAlg gets registered for use with DHCP won't you need to indicate whether HMAC-CoolNewAlg and/or HMAC-MD5 is supported?

Assuming we always use HMAC-MD5 then you'll have an output of 128 bits, but what happens if DHCP starts to use HMAC-SHA-256 - i.e., are we always going to use HMAC-CoolNewAlg-128?

[Ballot comment]
The portion of 3.1.2 which starts "The following fields are set in an DHCP authentication option for the Forcerenew Nonce Authentication Protocol:" is poorly written. The fields are not listed in order, the explanation for length is incorrect. This needs to be rewritten.

[Ballot comment]
Should you describe a mechanism whereby the nonce can be changed?

---

Section 6
Please don;t refer to this as a "proposal". It is just about to become
an RFC. Use "document".

[Ballot discuss]
The introduction motivates this extension by claiming there are specialized environments in which the mandatory coupling between FORCERENEW and 3118 DHCP Authentication could be relaxed, but doesn't restrict the mechanism discussed in this document to those environments. There is some discussion already taking place in response to the genart review touching on this topic indicating there should be a restriction, but it's not clear yet what that the intended restriction is.

Doesn't the client's computation confirming the same HMAC-MD5 over the message need to be performed the same way the server computes the value (as described in the last paragraph of 3.1.3)? Should the instructions for zeroing the HMAC-MD5 field in the message fed into the computation be repeated here?

[Ballot comment]
- I agree with Russ' discuss based on the gen-art review.

- I like the idea as explained in the response to the gen-art
review, but didn't get that from the abstract or writeup so I
think fixing those to make the purpose of this clear (make
off-path attacks hard) would be good.

- What is an RDM? (3.1.3) Better to spell that out rather
than force the reader off to rfc 3115.

- Shouldn't there be a requirement to use a different "reconfigure
key value" every single time? If those are re-used, then a client
could pretend to be the server.

- I guess I wondered if you can do this, why can't the server just
sign the response with a private key?

- Should there be an IANA registry for the type field here in
case you ever want more than hmac-md5?

[Ballot discuss]
The Gen-ART Review by Ben Campbell on 6-Feb-2012 raised some
  significant concerns, and the authors agree that some updates to the
  document are needed.  The review can be found at this URL:
  http://www.ietf.org/mail-archive/web/gen-art/current/msg07161.html

IANA has a question about the action requested by the authors in
draft-ietf-dhc-forcerenew-nonce-03.txt.

IANA understands that, upon approval of this document, there is a single
action which IANA must complete.

In the BOOTP Vendor Extensions and DHCP Options subregistry of the
Dynamic Host Configuration Protocol (DHCP) and Bootstrap Protocol
(BOOTP) Parameters located at:

http://www.iana.org/assignments/bootp-dhcp-parameters/bootp-dhcp-parameters.xml

a new DNCPv4 option code will be added to the registry as follows:

Tag: [ tbd ]
Name: FORCERENEW_NONCE_CAPABALE
Data length:
Description:
Reference: [ RFC-to-be ]

QUESTION: registrations in this registry often have Data length and
Description properties supplied. Would the authors like to supply Data
length and Description properties for this new option code?

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (Forcerenew Nonce Authentication) to Proposed Standard


The IESG has received a request from the Dynamic Host Configuration WG
(dhc) to consider the following document:
- 'Forcerenew Nonce Authentication'
  as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2012-02-06. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

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 sends a nonce
  with the client on the initial DHCP ACK that is used for subsequent
  validation of a Forcerenew message.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-dhc-forcerenew-nonce/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-dhc-forcerenew-nonce/


No IPR declarations have been submitted directly on this I-D.

  (1.a) Who is the Document Shepherd for this document? Has the
        Document Shepherd personally reviewed this version of the
        document and, in particular, does he or she believe this
        version is ready for forwarding to the IESG for publication?
       
I (Ted Lemon) am the document shepherd. I have reviewed the document, and believe it is ready for publication.

  (1.b) Has the document had adequate review both from key WG members
        and from key non-WG members? Does the Document Shepherd have
        any concerns about the depth or breadth of the reviews that

       
The document has been reviewed by quite a few members of the working group, and is reasonably mature. The document has not been reviewed by other working groups--it is very specific to DHCP.

  (1.c) Does the Document Shepherd have concerns that the document
        needs more review from a particular or broader perspective,
        e.g., security, operational complexity, someone familiar with
        AAA, internationalization or XML?
       
The document mirrors functionality present in DHCPv6, which was specificaly reviewed for appropriateness at the time that RFC3315 is published, so in that sense it has been reviewed and reflects the current state of the art.  This is not to say that further review would be unwelcome.

  (1.d) Does the Document Shepherd have any specific concerns or
        issues with this document that the Responsible Area Director
        and/or the IESG should be aware of? For example, perhaps he
        or she is uncomfortable with certain parts of the document, or
        has concerns whether there really is a need for it. In any
        event, if the WG has discussed those issues and has indicated
        that it still wishes to advance the document, detail those
        concerns here. Has an IPR disclosure related to this document
        been filed? If so, please include a reference to the
        disclosure and summarize the WG discussion and conclusion on
        this issue.
       
I don't have any concerns about the document.  No IPR disclosures have been made.

  (1.e) How solid is the WG consensus behind this document? Does it
        represent the strong concurrence of a few individuals, with
        others being silent, or does the WG as a whole understand and
        agree with it? 

The document got strong support in response to a second WGLC, although for whatever reason the first WGLC was ignored.

  (1.f) Has anyone threatened an appeal or otherwise indicated extreme
        discontent? If so, please summarise the areas of conflict in
        separate email messages to the Responsible Area Director. (It
        should be in a separate email because this questionnaire is
        entered into the ID Tracker.)
       
No objections were raised on the mailing list.

  (1.g) Has the Document Shepherd personally verified that the
        document satisfies all ID nits? (See the Internet-Drafts Checklist
        and http://tools.ietf.org/tools/idnits/). Boilerplate checks are
        not enough; this check needs to be thorough. Has the document
        met all formal review criteria it needs to, such as the MIB
        Doctor, media type and URI type reviews?
       
The draft passes idnits with no warnings or errors.

  (1.h) Has the document split its references into normative and
        informative? Are there normative references to documents that
        are not ready for advancement or are otherwise in an unclear
        state? If such normative references exist, what is the
        strategy for their completion? Are there normative references
        that are downward references, as described in [RFC3967]? If
        so, list these downward references to support the Area
        Director in the Last Call procedure for them [RFC3967].
       
The doc has been split. All references are to published documents.

  (1.i) Has the Document Shepherd verified that the document IANA
        consideration section exists and is consistent with the body
        of the document? If the document specifies protocol
        extensions, are reservations requested in appropriate IANA
        registries? Are the IANA registries clearly identified? If
        the document creates a new registry, does it define the
        proposed initial contents of the registry and an allocation
        procedure for future registrations? Does it suggest a
        reasonable name for the new registry? See [RFC5226]. If the
        document describes an Expert Review process has Shepherd
        conferred with the Responsible Area Director so that the IESG
        can appoint the needed Expert during the IESG Evaluation?
I've reviewed the IANA section; it defines a new code, which is documented properly, and defines no new tables that need to be documented.

  (1.j) Has the Document Shepherd verified that sections of the
        document that are written in a formal language, such as XML
        code, BNF rules, MIB definitions, etc., validate correctly in
        an automated checker?
       
No such language exists in the text.

  (1.k) The IESG approval announcement includes a Document
        Announcement Write-Up. Please provide such a Document
        Announcement Write-Up? Recent examples can be found in the
        "Action" announcements for approved documents. The approval
        announcement contains the following sections:
    Technical Summary

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.

    Working Group Summary

This document received a thorough review by the WG, and had broad support.

    Document Quality
        Are there existing implementations of the protocol? Have a
        significant number of vendors indicated their plan to
        implement the specification? Are there any reviewers that
        merit special mention as having done a thorough review,
        e.g., one that resulted in important changes or a
        conclusion that the document had no substantive issues? If
        there was a MIB Doctor, Media Type or other expert review,
        what was its course (briefly)? In the case of a Media Type
        review, on what date was the request posted?

I am not aware of any implementations.