Re: [IPsec] WG Last Call on "The NULL Authentication Method in IKEv2 Protocol"

[Yaron Sheffer <[e-mail]>]

Hi Valery, Paul,

I re-read the new draft and I must say it is much clearer than the previous version. Still, a few comments:

• Please spell-check the draft. There are numerous typos.
• The "privileged IKE operations" is obviously a bit thin. "Initial Contact" may be a good example of an operation that we'd be better off without. But if we don't have any specific examples, let's remove this section.
• Implementations MAY force... to single host-to-host IPsec SAs. If we cannot come up with a good way for an unauthenticated peer to prove ownership of SA ranges (whatever "ownership" might mean in this context), then I guess we should change the MAY into a SHOULD.
• We are still using IP addresses to identify peers: "if an IKE peer receives... from an IP address that matches a configured connection". I think an IKE peer that supports null auth should be able to distinguish peers depending on other characteristics, and should be able to handle mixed configurations/policies even for a single IP address.
• I suggest adding this short subsection to the Security Considerations:

Although this document discourages the use of non-null ID payloads to identify an unauthenticated peer, IKEv2 provides channel bindings capabilities and those may be used to authenticate this identity at a later time, while binding the authenticated identity with the original IKE exchange. This applies to a related but distinct use case, where peers cannot be authenticated at the time of the exchange but do not wish to remain anonymous. Please see [AutoVPN] for one way of after-the-fact authentication of an IKE peer.

[AutoVPN] draft-sheffer-autovpn, 2014.