Ballot for draft-ietf-ipsecme-ikev2-null-auth
Yes
No Objection
Note: This ballot was opened for revision 06 and is now closed.
- 2.1: just wanted to check as I didn't have time to go through it all myself - are we confident that using SK_pi/SK_pr in this way has no cryptographic downsides? The reference to the EAP methods convinces me this is no worse than an existing thing, but not (by itself) that it is cryptographically sound, so I just wanted to check as I think prf(SK_pr,IDr') has until now been calculated but not transmitted, so there's a tiny change here maybe, but as I said I didn't have time to fully check. If someone just tells me that yes, the authors/wg did consider this, that'll be fine, no need to fully explain to me why using SK_pr like this is safe (though if you want to, that'd be fine too). - 2.5: "hand out" is an odd phrase here - would be better to expand on that I think and say more precisely what should never be done.
First: Thanks, Paul, for a very informative and useful shepherd writeup. Editorial comment in Section 2: If a peer that requires authentication receives an AUTH payload containing the NULL Authentication method type, it MUST return an AUTHENTICATION_FAILED notification. We're referring to NULL authentication as "authentication", so maybe this should say something like "If a peer that requires positive identification receives [...]", or "If a peer that requires authenticated identity receives [...]" ?