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

From: Yaron Sheffer <[email-masked]>
Date: Sun, 18 Jan 2015 09:58:13 +0200

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.

---

From: Paul Wouters <[email-masked]>
Date: Mon, 19 Jan 2015 00:30:52 -0500 (EST)

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

---

From: "Valery Smyslov" <[email-masked]>
Date: Mon, 19 Jan 2015 16:01:10 +0300

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

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

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

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.

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

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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 19 Jan 2015 16:37:35 +0200

> CREATE_CHILD_SA is never a valid exchange.

Rekeys are not valid? I would expect null authentication method to be
used in cases where they might still want to do rekey, both for Child
SAs and the IKE SA.

Also even in IP-IP connections there might be per protocol+port
connections, i.e. it could be possible to do per tcp-flow Child SAs,
and that is still possible even if you restrict it to single IP-IP
connection.

> > * 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.
> 
> ownership other than the apparent source ip is dangerous.

Not true. For example if the RFC5739 is used and the client receives
full /64 IPv6 network from the server, that makes it clear what
addresses the client owns. Or actually any addresses the server gives
to client. 

> If the party

They can do that even if they authenticate, and you should still
provide protection against such attacks even then. 
-- 
[email-masked]

---

From: "Valery Smyslov" <[email-masked]>
Date: Mon, 19 Jan 2015 17:58:07 +0300

> used in cases where they might still want to do rekey, both for Child

Paul's idea was to limit unauthenticated peer to have a single IPsec SA.
I don't think he has rekey in mind, when suggested to prohibit 
CREATE_CHILD_SA.
However, since we disageed on that, this prohibition was not inserted
into the document.

> and that is still possible even if you restrict it to single IP-IP

I agree. This must be a policy issue, not a protocol issue -
whether per-flow SAs are allowed and how many SAs server
is willing to maintain. And the protocol has already
all the means to control it - NO_ADDITIONAL_SAS,
SINGLE_PAIR_REQUIRED, TS_UNACCETPABLE,
ADDITIONAL_TS_POSSIBLE notifications.

Regards,
Valery.

---

From: Paul Wouters <[email-masked]>
Date: Mon, 19 Jan 2015 11:07:48 -0500 (EST)

> used in cases where they might still want to do rekey, both for Child

You are right, I meant any new non-replacement IPsec SA's. I did not
mean to limit rekeying.

> and that is still possible even if you restrict it to single IP-IP

What is the purpose of installing a zillion unauthenticated protoport
specific IPsec SA's over a single one? The abuse case here for
unauthenticated clients is clear, thousands of SA's per IP in the
botnet.

It's a better DDOS than sending ESP because this takes CPU power to
decrypt the IKE message_and_ takes up kernel memory. And I think with
PFS on the CREATE_CHILD_SA you might runn the server out of
entropy too?

> addresses the client owns.

But who says the server owns that IPv6 range? Unless you have PKIX
validated that server (IPSECKEY in random DNS zone is not good enough!)
you cannot trust that.

> Or actually any addresses the server gives to client.

This is dangerous! the server could tell the client to give ALL of the
IPv6 network to it and become your ipv6 default router! A sane client
will never let a server dictate the ranges just like a sane server will

> provide protection against such attacks even then.

I'll come up with some text that limits traffic selectors and
CREATE_CHILD_SA to those authentication methods that convey trust by
configuration (eg PKIX) and not by authentication (NULL or random
IPSECKEY records in DNS)

Paul

---

From: Stephen Kent <[email-masked]>
Date: Mon, 19 Jan 2015 15:42:05 -0500

Yaron,

>  *
because NULL auth alters a fundamental security aspect of IPsec, I think 
we need to describe
in this document how this new capability interacts with the SPD and the 
PAD. The doc should
reference 4301 an describe any changes to that RFC that are needed to 
security accommodate Null auth.

A quick scan of this I-D does not indicate any references to either 
database or to 4301.

Steve

---

From: Paul Wouters <[email-masked]>
Date: Mon, 19 Jan 2015 15:55:20 -0500 (EST)

On Mon, 19 Jan 2015, Stephen Kent wrote:

> because NULL auth alters a fundamental security aspect of IPsec, I think we need to describe
> in this document how this new capability interacts with the SPD and the PAD. The doc should
> reference 4301 an describe any changes to that RFC that are needed to security accommodate
> Null auth.

There are no changes to the SPD or the PAD. This document merely defines
a new way of authentication at the IKE level. It is not different from
other documenst that added an authentication method, such as RFC-7427
which also does not mention the SPD or the PAD. 7427 does have the
following text:

   IKEv2 peers have a series of policy databases (see Section 4.4 of
    [RFC4301]) that define which security algorithms and methods should
    be used during establishment of security associations.  To help end
    users select the desired security levels for communications protected
    by IPsec, implementers may wish to provide a mechanism in the IKE
    policy databases to limit the mixing of security levels or to
    restrict combinations of protocols.

Would using this text in the security considerations resolve your issue?
We could change "mixing of security levels" to "mixing authenticated and
un-authenticated security levels".

Paul

---

From: <[email-masked]>
Date: Mon, 19 Jan 2015 21:18:51 +0000

> On Jan 19, 2015, at 3:55 PM, Paul Wouters <[email-masked]> wrote:
> 
> un-authenticated security levels”.

I think null authentication is a bit more drastic than a new algorithm to do what IPSec/IKE has always done: two way authentication of essentially all communication.  

For example, what would a PAD entry look like that expresses “NULL authentication permitted”?  Where would I find the spec for the algorithm that rejects unauthenticated communication when it is supposed to be rejected, and accepts it when it it is wanted?  I would expect this to be in RFC 4301 section 4.4.3.1, so it would seem that the new draft has to amend that section to cover these new rules.

	paul

---

From: Stephen Kent <[email-masked]>
Date: Mon, 19 Jan 2015 17:50:43 -0500

Paul,

Other authentication methods defined for IKE perform authentication, so 
there was
no need to express anything special in the SPD or PAD. NULL is obviously 
very
different.

The text you cited from 4727, with the edit you proposed would be a big 
improvement.

Steve

---

From: Yaron Sheffer <[email-masked]>
Date: Mon, 19 Jan 2015 20:25:24 -0800

> For example, what would a PAD entry look like that expresses “NULL authentication permitted”?  Where would I find the spec for the algorithm that rejects unauthenticated communication when it is su…

And then on the SPD side, I'm not sure we even know what this policy 
would look like. Even if we only allow a single IP, the address 
presented by the peer, the policy would not in general be secure. 
Because a "true" MITM, one that gets hold of the access router, would be 
able to assume any IP, including for example 8.8.8.8. So should we 
exclude certain services? Certain IP ranges? This could get very messy.

Paul W. is right that IKE gateways had always needed to protect against 
malicious peers, but IMHO the unauthenticated case is qualitatively more 
risky.

Thanks,
	Yaron

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 20 Jan 2015 16:59:39 +0200

> unauthenticated clients is clear, thousands of SA's per IP in the

I do not think anybody wants to install or allow zillion
unauthenticated SAs, but I can see people wanting to have per flow
Child SAs, which might be several Child SAs, depending how many flows
you are going to allow. Note, that TCP session requires MUCH more
memory than the Child SA used to protect it. TCP session has
receive/transmit windows and those are usually several kilobytes in
size etc...

Anyways all this is policy decisions which should be left to the
policy, not hardcoded in the protocol or in the RFC. 

> PFS on the CREATE_CHILD_SA you might runn the server out of

Whether you want to allow PFS for per flow SAs is again policy
decision. Currently people who what protection against prevasive
monitoring do want to have PFS, as that means attacks need to break
Diffie-Hellman for each flow they want to break, compared to just
breaking Diffie-Hellman once, and then being able to break all Child
SAs created using it.

Also there is no such thing as running out of entropy. Entropy is not
consumed when it is used. If you have 256 bits of randomess in the
system, if you use it once, the attacker still needs to know all 256
bits of randomess to break the system (we are assuming this is secure
crypto system). If you use it 2^256 times, the attacker still needs to
know all 256 bits to be able to break any one of them. On the other
hand if we gets those 256 bits, he can break all 2^256 flows at the
same time, so the cost of breaking one connection goes down, but the
initial cost of breaking any of them stays same. So the entropy in the
system is not going away even if you use it. Also the total cost to
break the system does not go down, but the value you gain if you break
the system goes up the more you use the same entropy..

> validated that server (IPSECKEY in random DNS zone is not good enough!)

This is good question. For IPv4 there is no point of giving any other
address than private use address, but for IPv6 there actually might
be. On the other if client is given prefix to public addresses where
it tries to talk to (for example google dns-servers ipv6 address
block), the server can only cause DoS for the client, it cannot get
the client to send any packets to server, as client will know that all
those addresses are his addresses, so he should take care of them
(they are assigned to him).

> will never let a server dictate the ranges just like a sane server will

How can server do that in configuration payload? Configuration
payloads assigning address give the addresses which are given to user.

There is INTERNAL_IP*_SUBNET stuff that can be used as hints by the
client what subnets might be served by the server, but clients should
most likely ignore those anyways. Also the traffic selectors are the
ones that really tell what traffic is sent to server, not
anything in configuration payloads.

Client will know why it created the connection to the server, and
should create the traffic selectors accordingly. I.e. if it only wants
to talk to the one specific address (opportunistic ipsec), then it
should include that address in TSr. It can leave TSi out and use the
server assigned IP-address, and when it gets TSi in, it might check
that it is properly narrowed to only include that one assigned
IP-address, but those checks are already there in the code, they are
nothing new to the unauthenticated connections.

If client is connecting to the server as there is some network behind
it wants to connect, that will require configuration in the client, so
that configuration needs to tell which networks there are behind the
gateway, and normal policy rules will check that server does not steal
more data than what is allowed by policy. 
-- 
[email-masked]

---

From: <[email-masked]>
Date: Tue, 20 Jan 2015 15:34:31 +0000

> On Jan 20, 2015, at 9:59 AM, Tero Kivinen <[email-masked]> wrote:
> ...
> know all 256 bits to be able to break any one of them. ...

Yes, “entropy used up” is an unfortunate misconception created by the authors of early /dev/random implementations.

I would put it not quite as strongly as you did.  If you have an RNG that uses a strong bit stream extender to extend the entropy pool content, your statement is valid since the strong extender hides the content of the entropy pool.  But if the RNG uses a weak extender, then your RNG security basically comes from the entropy in its entropy pool, and knowledge of that pool’s content is leaked by the RNG output.  I think some early /dev/random implementations were indeed of that second form, so the “entropy used up” notion was perhaps valid back then.  But it isn’t any longer.

The Yarrow paper by Scheier et al. makes this analysis quite clear (and they come to the same conclusion as you did as a result).

	paul