Password Authenticated Connection Establishment with the Internet Key Exchange Protocol version 2 (IKEv2)
Note: This ballot was opened for revision 08 and is now closed.
(Sean Turner) Yes
(Ron Bonica) No Objection
(Stewart Bryant) No Objection
(Gonzalo Camarillo) No Objection
(Wesley Eddy) No Objection
(Adrian Farrel) No Objection
(Stephen Farrell) No Objection
Comment (2012-03-15 for -08)
- 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).
(Russ Housley) No Objection
(Peter Saint-Andre) No Objection
Comment (2012-03-08 for -08)
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!).