Hi Yaron, Paul,
* 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.
I agree that this section currently is vague. Paul has some examples
of "privileged IKE operations" in his mind, so I think he will fill this
section
with them.
* 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.
Well, host-to-host is too restrictive in any case. If anonymous client
wants to get access to a DMZ network, then what the reason
not to allow him/her to do it? The restriction should be applied only
to unauthenticated peer, while the authenticated server could
very well represent the subnet behind it.
And in case of unauthenticated client the server could (should?)
assign him/her an internal IP address, so the client won't
represent arbitrary IP address, only the address the
server gives him.
* 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 think that the presence or absence of authentication may
influence on the scope of services the client can reach.
For example, un-authenticated client may be restricted to
only one DMZ network, but if it re-enters and authenticates itself
(even from the same IP address), then it may get access to a full protected
network. I think Yaron is right here and we should not impose
such restrictions.
* 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.
I agree with Paul here, but I also think that this document
must not prohibit such use cases, if they exist.
How about the following (I took Yaron's text as the base)?
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.
The security of such scheems must be well analysed, as they
are easy to be compromised.
Regards,
Valery.
Paul
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
