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

Note: This ballot was opened for revision 04 and is now closed.

(Jari Arkko; former steering group member) Yes

Yes (2012-02-16 for -04)
No email
send info
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 ...?

(Ralph Droms; former steering group member) Yes

Yes ( for -)
No email
send info

(Adrian Farrel; former steering group member) No Objection

No Objection (2012-02-14 for -)
No email
send info
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".

(Gonzalo Camarillo; former steering group member) No Objection

No Objection ( for -04)
No email
send info

(Pete Resnick; former steering group member) No Objection

No Objection (2012-02-14 for -)
No email
send info
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.

(Peter Saint-Andre; former steering group member) No Objection

No Objection (2012-02-15 for -)
No email
send info
I concur with the DISCUSS that Russ lodged (based on the Gen-ART review).

(Robert Sparks; former steering group member) (was Discuss) No Objection

No Objection ( for -06)
No email
send info

(Ron Bonica; former steering group member) No Objection

No Objection ( for -)
No email
send info

(Russ Housley; former steering group member) (was Discuss) No Objection

No Objection ( for -06)
No email
send info

(Sean Turner; former steering group member) (was Discuss) No Objection

No Objection (2012-06-14)
No email
send info

(Stephen Farrell; former steering group member) No Objection

No Objection (2012-02-13 for -)
No email
send info
- 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?

(Stewart Bryant; former steering group member) No Objection

No Objection ( for -)
No email
send info

(Wesley Eddy; former steering group member) No Objection

No Objection ( for -)
No email
send info