Subject: Re: [IPsec] Fw: New Version Notification for draft-smyslov-ipsecme-ikev2-null-auth-00.txt

From: "Valery Smyslov" <[email-masked]>
Date: Fri, 10 Jan 2014 15:21:59 +0400

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

---

From: Paul Wouters <[email-masked]>
Date: Sat, 11 Jan 2014 12:45:46 -0500 (EST)

> Adding special "anonymous" ID here seems to be superfluous.

Than you should stick to that and not send any IDs whatsoever.

> could be verified via out-of-band means.

I am strongly against channel bindings, connection latching, or connection
reconfiguration-promotions. Nice good complicated ideas, but they have
failed with BTNS already. If you want access to a non-anonymously shared
resource, setup a proper authenticated IPsec connection.

> is already told by using NULL Auth method.

Ocam's razor would tell you not to send IDs if you don't plan to use
them or have the other end use them.

> anonymous user access to protected network (some kind of DMZ).

Again, you are promoting anonymous IPsec to "somewhat restricted could
possibly allow non-anoymous IPsec" upgrades. Don't.

> both peers will use NULL Auth, one of them may

The problem is a server vouching for any IP ranges. How do you find out?
What's the discovery mechanism? How can we prevent it from falsely
claiming to give it precious traffic (like 127.0.0.1 or 8.8.8.8). The
initiator knows what IP it was trying to connect to. So to me, it should
be limited to that IP only.

I'll agree we might be able to do this work in another draft. But at
least it should go into the security consideration section.

> Why? Transport mode ESP has no issues with NAT, has it?

Yes it does, when multiple clients behind the same NAT router try to
connect to the same remote IPsec gateway.

> Why should it be mandatory? Why can't it be left to local security policy?

Because null auth is already weak? Then again, I think PFS should be
made mandatory for all IPsec connections. I guess this could also move
into a separate OE draft.

> so they have all means to keep their anonymity.

But "at their discretion" means someone is going to make an
authentication decision based on it. It's dangerous. Instead of
sprinkling the draft with "SHOULD NOT use ID" and "MUST NOT use ID",
we should simply not give them the option for making such bad mistakes.

> access some protected network to prevent traceability of his actions.

So use NULL AUTH with no IDs? I don't see the problem?

> On the other hand, I can imagine situation, when user must be authenticated,

So don't use NULL AUTH, but a real AUTH with ID.

I don't think we disagree here? When you say "allow the ID to be used
for audit only" I think you are introducing a false sense of security.
That ID could be easilly forged making the audit log incorrect. The
audit log _should_ log no ID if presented with a forgable ID.

> will use NULL Auth as a mechanism to skip authentication.

Sure, but than I do really want the ID parts not sent for NULL AUTH.

Paul

---

From: Yaron Sheffer <[email-masked]>
Date: Sat, 11 Jan 2014 20:32:06 +0200

Hi Paul,

I regularly use SSH, which binds a public key fingerprint to a DNS name. 
It's usable, and not too complicated.

We can argue why BTNS failed but I don't want to waste our time on that. 
I believe some limited form of channel binding can work. Specifically, I 
am thinking of post facto authentication, e.g. by reading out the 
fingerprint on the phone.

Regarding audit, we can mandate that each record should say something 
like "Snow White (claimed but unauthenticated identity)".

Thanks,
	Yaron

---

From: Paul Wouters <[email-masked]>
Date: Sun, 12 Jan 2014 00:15:52 -0500 (EST)

On Sat, 11 Jan 2014, Yaron Sheffer wrote:

> I regularly use SSH, which binds a public key fingerprint to a DNS name. It's 
> usable, and not too complicated.

But always requires a human decision.

> I believe some limited form of channel binding can work. Specifically, I am 
> thinking of post facto authentication, e.g. by reading out the fingerprint on 
> the phone.

As I explained before, I don't see why we need to complicate the OE
cases with other cases that can be done perfectly fine with existing
authenticated IPsec. There is no issue setting up two IPsec connections,
one authenticated and one anonymous. Seeing how many prefer 1000's of
narrowed IKEv2 tunnels over a single net-net tunnel, I don't see why
your use case requires complicating the OE case.

> Regarding audit, we can mandate that each record should say something like 
> "Snow White (claimed but unauthenticated identity)".

You are suggesting client side security? I don't understand. If I would
write software where an ID is sent but completely unauthenticated and
falsifiable, I would probably just not log it to avoid confusion.

Paul

---

From: Yoav Nir <[email-masked]>
Date: Sun, 12 Jan 2014 07:48:17 +0000

On Jan 12, 2014, at 7:15 AM, Paul Wouters <[email-masked]>
 wrote:
>> Regarding audit, we can mandate that each record should say something like "Snow White (claimed but unauthenticated identity)".
> 

IDK. My mail client shows your message as coming from "Paul Wouters <[email-masked]>" even though that is just a text field that you could put anything in. We always trust claimed identities to a certain extent. The only time we don't is when someone claims an identity that is bound (in our policy) to some authorization. So if your machine contacts mine out of the blue and claims to be "Paul's VPN gateway" that's fine and I can log it. If it claims to be "ili-natasha-gw.checkpoint.com", then I'll need some more proof.

Yoav

---

From: "Valery Smyslov" <[email-masked]>
Date: Mon, 13 Jan 2014 17:57:10 +0400

> Than you should stick to that and not send any IDs whatsoever.

If we mandate ID to always be empty in case of NULL Auth,
then what to do if you still receive non-empty ID with NULL Auth?
Reject connection attempt or just ignore received ID?
For me the latter looks more appropriate (just follow
Postel's principle - be tolerant to what others do).
And I don't see any harm here if you just ignore received ID.
Act as if you receive no ID at all. You may even not to
log it, if you think it might give user false sense of security.

BTW, we have 3 possibility for inidicating "anonymous" ID.
1. Don't send ID Payload at all.
2. Send empty ID Payload (say, Type = 0, Len=0).
3. Send special ID Payload (say, Type=KeyId, Value="anonymous")

For me, case 3 looks the worst, I'd rather to avoid special values.
Case 1 looks the best from theoretical point of view, but
it will add complexity to already over-complicated IKE_AUTH
state machine (note, that currently ID Payload is mandatory).
For me case 2 looks like acceptible compromise.

What do others think?

> connect to the same remote IPsec gateway.

Can you, please, elaborate? Where the problem come from?

> Because null auth is already weak?

So what? How auth (or the lack of it) is related to PFS?

> Then again, I think PFS should be
> made mandatory for all IPsec connections.

I tend to agree with you in general, but I still think it is a policy issue.

> Sure, but than I do really want the ID parts not sent for NULL AUTH.

If draft says that in case of NULL Auth ID Payload SHOULD be sent empty
and MUST be ignored by receiver, will it satisfy you?

Regards,
Valery.

---

From: Paul Wouters <[email-masked]>
Date: Thu, 16 Jan 2014 21:41:30 -0500 (EST)

> Postel's principle - be tolerant to what others do).

Yes, I would ignore it.

> For me case 2 looks like acceptible compromise.

I don't think this complicates the state machine that much, as it's
clearly distinct by the auth type none payload. My preference is for #1.

> Can you, please, elaborate? Where the problem come from?

Multiple clients behind the same NAT router with transport mode would use
different NATed UDP ports. The IPsec server can differentiate incoming
packets this way.  But for outgoing UDP packet streams (not udp replies)
it would need to know which of the clients using the same IP this packet
would need to get encrypted to. You would need some kind of "mark"
asociating the SA with the socket. For *swan we did this with an "SAref"
marker. It would use ip_conntrack and put an SPI based iptables MARK
on the packt. For new connections originating from the IPsec gateway,
you could set a socket option (IP_IPSEC_BINDREF) if you know the SPI/MARK.

> I tend to agree with you in general, but I still think it is a policy issue.

Stepping back, I agree that we could leave these things out of the auth
none specification.

> and MUST be ignored by receiver, will it satisfy you?

Yes, that would be perfect.

By the way, I do prefer the name "auth none" over "auth null". To me,
'null' embodies more of an error condition.

Paul

---

From: "Valery Smyslov" <[email-masked]>
Date: Fri, 17 Jan 2014 17:23:39 +0400

> clearly distinct by the auth type none payload. My preference is for #1.

Thank you for sharing your opinion. I still think that empty
ID is preferrable, as IMHO it will add less complexity to
implementation. I'd still like to know more opinions on this.

> you could set a socket option (IP_IPSEC_BINDREF) if you know the SPI/MARK.

I got your point. But this problem is unrelated to NULL Auth and even
to OE, IMHO. So I don't think it must be addressed in this draft.

> Yes, that would be perfect.

Great.

> 'null' embodies more of an error condition.

My reasons for selecting this name were the folowing.
First, we define new Authentication Method in IANA. A method
is some essence, that defines how authentication has to be done.
For me "NONE authentication" implies that this essence doesn't
exist at all, while "NULL authentication" implies that this essence
(authentication) exists, but performs no real action (is dummy).
For me is sounds a bit better, as we define an essence in IANA.
And second, I had a similar example - NULL Encryption Algorithm
in ESP. For some reason it was named NULL, not NONE,
so I just decided to follow this tradition.

Disclaimer: english is not my native language, so my
arguments for the naming may look a bit silly.

Regards,
Valery.

---

From: Paul Wouters <[email-masked]>
Date: Fri, 17 Jan 2014 19:39:57 -0500 (EST)

> implementation. I'd still like to know more opinions on this.

Sure. Let's hear from others.

> to OE, IMHO. So I don't think it must be addressed in this draft.

Agreed.

> so I just decided to follow this tradition.

I figured that was the reason. Although I think in the ESP case
there is an NO-OP encryption with the name NULL. Here I think
we have "no authentication", not an "authentication with null"

> arguments for the naming may look a bit silly.

The same disclaimer applies to me. So I would also like to hear
from others on this issue. Regardless, it is not a big deal for
me.

Paul