Hi Paul,
please, see my comments inline.
This is what we (libreswan) have started implementing as well, although we
called it AUTH_NONE instead of AUTH_NULL. We use private range number 201
for this exchange type. We also followed the PSK exchange method. But
we are still looking at some issues and therefor have not yet written
out our implementation as draft yet. For those interested, libreswan
developers are meeting up in San Francisco in the second and third week
of January to work on OE (both anonymous and authenticated). Ping me if
you would like to attend.
Valery's draft is a start, but we need to address a lot more than just
defining a new IKEv2 AUTH method:
1) Use of IDs
I don't think we should allow any IDs, as there could be conflicts with
other non-anonymous connections. Or possibly a way to detect which
non-anonymous IDs are accepted at the remote. I was leaning towards
mandating the ID to be "anonymous" to make it extremely clear that this
is an anonymous connection.
I think that using NULL Auth method clearly identifies
anonymous users and allows to distingush them from regular ones.
Adding special "anonymous" ID here seems to be superfluous.
First, in this case you need to specify what to do when
"anonymous" ID is used with regular auth method or
NULL auth method is used with non-"anonymous" ID.
More conditions to check - more branches - more possibilities
to make errors in code. Second, as Yaron pointed out, IDs
may still be useful for upper level and sometimes even
could be verified via out-of-band means.
So, I think that it's better to follow Occam's razor principle here
and not to add new ID type, as all that it could tell to the peer
is already told by using NULL Auth method.
2) Endpoints
Your draft does not state anything about the traffic selectors. I think
it is important to specify it for only a single host-to-host connection
only. Deployments who want to protect a whole subnet can use similar
tricks to load balancers and capture port (4)500 and use the NAT-T
capability of IPsec. Allowing subnet-to-subnet is just too dangerous
because there are no verifiable claims yet about who owns what IP range.
Aren't these restrictions too narrow? I can imagine situation with
anonymous user access to protected network (some kind of DMZ).
In this case we will have one-way authentication (server will be
authenticated, but user - not) and traffic selectors host-subnet.
I can agree with you that peer using NULL Auth must
represent single IP only, but it is not necessary that
both peers will use NULL Auth, one of them may
be fully authenticated,
3) Mode
I would like to only support tunnel mode and not transport mode, due to
the interaction with NATs - particularly multiple endpoints behind the
Why? Transport mode ESP has no issues with NAT, has it?
same NAT router. We would hope this happens a lot if everyone enables
OE (anonymous and non-anonymous). Obviously using AH also makes no sense
so we should note that this is only valid for ESP.
4) Mandatory PFS
It should be mandatory to do PFS with an appropriate DH group.
Why should it be mandatory? Why can't it be left to local security policy?
5) Priority
The priority of the SPDs of any anonymous IPsec connection should be
lower than the priority of any non-anonymous SPD. This ensures that
an anonymous IPsec connection can never steal traffic from an
authenticated IPsec connection.
Agree.
non-anonymous with anonymous IPsec
Now this only covers anonymous IPsec. While better than plaintext,
we do hope servers with stable hostnames will use IPSECKEY records to
provide their public key, and that the clients will mostly use this new
auth-none, while the server responds with its FQDN ID so the client can
verify the connection is not MITMed. In fact, I think it is better for
roaming devices to remain as anonymous as possible by not providing
the server with an identity (and why I also do not like your proposal
of allowing and ignoring the identity).
It doesn't contradict to my proposal - roaming devices can put
anything in their identity or even make it empty - all at their discretion,
so they have all means to keep their anonymity.
Most of your concerns are related to OE use case. I don't think
that NULL Auth is limited to OE case only. User may have all
credentials to authenticate himself, but still prefer to anonymously
access some protected network to prevent traceability of his actions.
On the other hand, I can imagine situation, when user must be authenticated,
but server - not. Consider example with remote garage door opener -
this device must authenticate user to ensure his access to garage,
but does user need to authenticate door opener? I don't think so -
user requests some simple action and can immediately see the result -
either door openes or remains closed. What additional value
user gains if he will know for sure via IKE that it is exactly the door
he is willing to open? Lacking device authentication may simplify setup.
And these cases are not related to OE, IMHO.
So, I think that it is worth to separate NULL Auth from OE stuff
and describe all OE related issues in a separate draft, that
will use NULL Auth as a mechanism to skip authentication.
Regards,
Valery.
I have not yet solved the issue of two servers and "return traffic". Say
host A on public IP initiates anonymously to host B on public IP. Let's
say both are mail servers. Host A has authenticated host B. Host A
can now send traffic to host B encrypted. Host B can respond to that
traffic. While the tunnel is up, host B needs to connect to host A
for unrelated traffic. It has an IPsec connection up, but it has not
authenticated this connection. It should not initiate traffic to host A.
BTNS tried to solve this problem with changing the kernel and doing
channel binding, but I don't think that solution has support anywhere.
I can think of some methods on Linux to "hack" detection and support,
but I'm not happy about it yet.
Evil ranges
Another unresolved problem of using tunnel mode is if a client uses
somebody elses IP range. eg my laptop behind NAT using 8.8.8.8 should
not be able to steal the remote's google DNS traffic. Again, I can
see linux hacks to implement this but I'm still not happy with this.
One way out is to use CP and assign IP addresses but since our clients
and servers will have thousands of these of connections there will be
clashes. Using IPv6 is possible but I'm not convinced the v6-in-v4 IPsec
has seen enough deployment and might not be implemented widely.
Other kinds of semi-anonymous connections
We are trying to limit the number of different kinds of OE connections
possible to make it as easy as possible to represent things back to the
user. So we have left things like "ssh style leap of faith" out of this.
Paul
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
