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

[Paul Wouters <[e-mail]>]

On Sun, 18 Jan 2015, Yaron Sheffer wrote:

> 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.

Will do.

>  *  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.

That was partially because Valery and I didn't fully agree. Which means
it might not belong in this document. Initial Contact is addressed in
the document already in its own section. The question for example is
about CREATE_CHILD_SA. Which comes back to your point below about
making claims of owning an IP range that cannot be verified without
an identity. I'm thinking with my OE hat on, so I am perfectly fine
with restricting things to a single ip-ip connection (with natt support)
and so in such a case the initial exchange is all that is needed and
CREATE_CHILD_SA is never a valid exchange.

>  *  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.

I even wanted a MUST, for the exact same reason. Any claim of IP address
ownership other than the apparent source ip is dangerous. If the party
does not authenticate, we cannot trust any claim. And two clients could
attempt to claim the same ranges to get each other traffic.

>  *  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.

You might be able to distinguish, but there is (per definition with auth_null)
no proof, so any decisions based on apparent distinction would be very
insecure. I'm not sure how you would support mixing auth and auth_null.
If I setup a PSK between 1.2.3.4 and 5.6.7.8, and my 1.2.3.4 server
suddenly gets AUTH_NULL, it has to reject it based on the wrong type of
AUTH TYPE payload. If it would not reject it, would it mean this
un-authenticated client mayb setup an IPsec SA that was supposed to
be protected and limited to a machine that knows the PSK?

>  *  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.

If there is to be "authentication later", say through an Informational
Exchange, then the time to present your ID (and your ID TYPE) is during
that later authentication step. There is no good reason to throw in an
untrustable identifier. It will only lead to implementation errors and
security issues.

I find channel binding extremely dangerous. It adds a lot of complexity
for something that can simple be done with seperate or new IKE SAs. That
is, an IKE peer could start with AUTH_NONE and later if it would need
access to some non-public IP range, decide to start another IKE SA
that is authenticated to the same peer. Mixing that all into a single
IKE SA for complicated handovers seems unneccesary and prone to errors.

Additionally, I have no idea how this channel binding is supposed to
affect applications. If the remote peer gives me an AUTH_NULL based IPsec
SA to 1.2.3.4, and later bumps that up to PSK authenticated, what does
that mean for an application? What does it mean for the existing TCP
connection to 1.2.3.4 going through ESP?

You might have valid use cases with auto-vpn, but then, like for
opportunustic IPsec, those use cases and their security considerations
probably belong in their respective documents. I think this document
should only put out a warning, especially to implementors, to think
about what it means to have unauthenticated IKE and IPsec SAs.

Paul