Skip to main content

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

Yes

(Ralph Droms)

No Objection

(Gonzalo Camarillo)
(Robert Sparks)
(Ron Bonica)
(Russ Housley)
(Sean Turner)
(Stewart Bryant)
(Wesley Eddy)

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

Jari Arkko Former IESG member
Yes
Yes (2012-02-16 for -04) Unknown
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 IESG member
Yes
Yes () Unknown

                            
Adrian Farrel Former IESG member
No Objection
No Objection (2012-02-14) Unknown
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 IESG member
No Objection
No Objection (for -04) Unknown

                            
Pete Resnick Former IESG member
No Objection
No Objection (2012-02-14) Unknown
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 IESG member
No Objection
No Objection (2012-02-15) Unknown
I concur with the DISCUSS that Russ lodged (based on the Gen-ART review).
Robert Sparks Former IESG member
(was Discuss) No Objection
No Objection (for -06) Unknown

                            
Ron Bonica Former IESG member
No Objection
No Objection () Unknown

                            
Russ Housley Former IESG member
(was Discuss) No Objection
No Objection (for -06) Unknown

                            
Sean Turner Former IESG member
(was Discuss) No Objection
No Objection (2012-06-14) Unknown

                            
Stephen Farrell Former IESG member
No Objection
No Objection (2012-02-13) Unknown
- 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 IESG member
No Objection
No Objection () Unknown

                            
Wesley Eddy Former IESG member
No Objection
No Objection () Unknown