Password Authenticated Connection Establishment with the Internet Key Exchange Protocol version 2 (IKEv2)
RFC 6631
Yes
(Sean Turner)
No Objection
(Adrian Farrel)
(Gonzalo Camarillo)
(Robert Sparks)
(Ron Bonica)
(Russ Housley)
(Stewart Bryant)
(Wesley Eddy)
Note: This ballot was opened for revision 08 and is now closed.
Sean Turner Former IESG member
Yes
Yes
(for -08)
Unknown
Adrian Farrel Former IESG member
No Objection
No Objection
(for -08)
Unknown
Gonzalo Camarillo Former IESG member
No Objection
No Objection
(for -08)
Unknown
Peter Saint-Andre Former IESG member
No Objection
No Objection
(2012-03-08 for -08)
Unknown
Section 5.1 states: The input password string SHOULD be processed according to the rules of the [RFC4013] profile of [RFC3454]. Why or when would an implementation violate the SHOULD? That is, why is this not a MUST? Also, please be aware there there is work underway to obsolete RFC 3454 and RFC 4013, primarily because stringprep is limited to Unicode 3.2; see draft-melnikov-precis-saslprepbis. This is just a heads-up, and I'm not necessarily suggesting that you change the text to something like "use RFC 4013 or equivalent". However, when your experiment is done and you put this on the standards track, you'll probably be asked to update the internationalization to use saslprepbis (if the PRECIS WG finishes before your experiment does!).
Robert Sparks Former IESG member
No Objection
No Objection
(for -08)
Unknown
Ron Bonica Former IESG member
No Objection
No Objection
(for -08)
Unknown
Russ Housley Former IESG member
No Objection
No Objection
(for -08)
Unknown
Stephen Farrell Former IESG member
No Objection
No Objection
(2012-03-15 for -08)
Unknown
- I found the overall description of PACE hard to follow, it'd be better if you gave the MODP method for mapping s in the overview so that someone who just knows standard D-H can see why this is a ZKPP. - "free of patents" is not possible, and not really appropriate as a claim in an RFC - section 5.1 could badly do with some examples if that's possible. I'd expect interop problems in any case, but more without that. Those might be shared with the other scheme drafts. - [I-D.kivinen-ipsecme-secure-password-framework] is now an RFC - s2, point 1: don't just say that a value encrypted with the password (ENONCE) is sent to the responder, since that'd in general be vulnerable to off-line dictionary attacks. Maybe say that ENONCE is ok to send because it is specially constructed so as not to expose anything about the password. - "MUST be presisted to stable memory" might be too onerous, I'd say a SHOULD would be better there in case someone has to use an existing DB of shared secrets. - The LongTermSecret scheme seems to be independent of PACE so I wondered why its here and not in a document of its own. - 4.1 seems to call for a table of mappings from authenticated ciphers to the unauthenticated equivalents, otherwise interop is not likely. I think you need to provide those mappings (or at least some) and ideally ask IANA to create a registry for others (it'd be needed if this got onto the standards track later).
Stewart Bryant Former IESG member
No Objection
No Objection
(for -08)
Unknown
Wesley Eddy Former IESG member
No Objection
No Objection
(for -08)
Unknown