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