Subject: Re: [IPsec] IPsec Digest, Vol 125, Issue 9

From: Les Leposo <[email-masked]>
Date: Tue, 9 Sep 2014 12:40:31 +0300

imho, this would be useful for bring-up work i.e. for both developers and deployers.

However, as folks already pointed out, there are significant security tradeoffs (and mitigations) that SHOULD/MUST to be explicated (i.e.more verbiage).
Points to consider:
1) allowing unauthenticated IKE-SAs (and in turn CHILD-SAs) to be established, would open up opportunities for ikev2 "exhaustion attacks" that previously weren't there (on the server side), no?

2) this feature could also tempt network admins to fallback to 'null authentication' as a work-around/short-cut in cases where they are unable to properly configure a deployment.

It would help if better use cases are highlighted:
A) the anonymity use case is subjective because, one could simply use a psk/cert that identifies an "access group" as opposed to an "individual" psk/cert, no?

B) the "low power" sensor use case is also subjective because, if the sensor data is truly confidential, would you want to make sure the sensor wont be redirected to a rogue/fake server?

$0.02

On Sep 8, 2014, at 10:00 PM, [email-masked] wrote:

> Send IPsec mailing list submissions to
> 	[email-masked]
> 
> To subscribe or unsubscribe via the World Wide Web, visit
> 	https://www.ietf.org/mailman/listinfo/ipsec
> or, via email, send a message with subject or body 'help' to
> 	[email-masked]
> 
> You can reach the person managing the list at
> 	[email-masked]
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of IPsec digest..."
> 
> 
> Today's Topics:
> 
>   1. Re: Call for adoption: The NULL Authentication Method in
>      IKEv2 Protocol (Yaron Sheffer)
> 
> 
> ----------------------------------------------------------------------
> 
> Message: 1
> Date: Mon, 08 Sep 2014 21:52:55 +0300
> From: Yaron Sheffer <[email-masked]>
> To: [email-masked], [email-masked]
> Cc: [email-masked]
> Subject: Re: [IPsec] Call for adoption: The NULL Authentication Method
> 	in IKEv2 Protocol
> Message-ID: <[email-masked]>
> Content-Type: text/plain; charset=windows-1255; format=flowed
> 
> Paul and Paul (and yet another Paul),
> 
> Just a process comment: this is a call for adoption, a "first call" not 
> a last call. There may still be many issues with the document, which we 
> will fix as a group *if* the document is adopted. So is the document 
> dealing with an important problem, and is it good enough as a starting 
> point of a solution?
> 
> Thanks,
> 	Yaron
> 
> 
> 
> ------------------------------
> 
> Subject: Digest Footer
> 
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec
> 
> 
> ------------------------------
> 
> End of IPsec Digest, Vol 125, Issue 9
> *************************************

---

From: "Valery Smyslov" <[email-masked]>
Date: Tue, 9 Sep 2014 15:08:21 +0400

Hi Les,

> However, as folks already pointed out, there are significant security 
> tradeoffs (and mitigations) that SHOULD/MUST to be explicated (i.e.more 
> verbiage).
> Points to consider:
> 1) allowing unauthenticated IKE-SAs (and in turn CHILD-SAs) to be 
> established, would open up opportunities for ikev2 "exhaustion attacks" 
> that previously weren't there (on the server side), no?

Not really more than now. Currently an attacker could
perform IKE_SA_INIT, and then send bogus signature
in IKE_AUTH. The server will need to do DH and to
perform signature verification before rejecting the connection.
With NULL Authentication the server will not do
signature verification, that saves some CPU resources,
and will only sign itself.

And the server could always limit the number of unauthenticated connections

> 2) this feature could also tempt network admins to fallback to 'null 
> authentication' as a work-around/short-cut in cases where they are unable 
> to properly configure a deployment.

The Security Considerations must strongly discourage to do it.

> A) the anonymity use case is subjective because, one could simply use a 
> psk/cert that identifies an "access group" as opposed to an "individual" 
> psk/cert, no?

Yes, it is possible. But there are some disadvantages comparing to special 
mode.
For example, with "group cert" one will need to perform an expensive
public cryptography operations, that are unnecessary in this case.

> B) the "low power" sensor use case is also subjective because, if the 
> sensor data is truly confidential, would you want to make sure the sensor 
> wont be redirected to a rogue/fake server?

It is presumed in this example, that the measurment itself is not secret
(for example, the temperature of the air). If the sensor is redirected,
the attacker won't get any new information. It propably should
be spelled out more explicitely in the draft.

Regards,
Valery.

---

From: Paul <[email-masked]>
Date: Tue, 9 Sep 2014 08:40:26 -0400

> On Sep 9, 2014, at 5:40, Les Leposo <[email-masked]> wrote:
> 

Yes it could use up some more CPU and ram. But it's a trade of the admin makes.

> 2) this feature could also tempt network admins to fallback to 'null authentication' as a work-around/short-cut in cases where they are unable to properly configure a deployment.

Or they just configure a psk "test". No difference.

> A) the anonymity use case is subjective because, one could simply use a psk/cert that identifies an "access group" as opposed to an "individual" psk/cert, no?

Not sure what you mean with subjective in this context. But one sided anonymity isn't the same as both ends authenticating with psk "test". The server can still use a strong rsa key that the client authenticates. It is just that the server doesn't authenticate the client because it accepts crypto from anyone.

> B) the "low power" sensor use case is also subjective because, if the sensor data is truly confidential, would you want to make sure the sensor wont be redirected to a rogue/fake server?

Same here. The iot device can have a firmware rsa key of the server used to authenticate the server, while the client is not authenticated.

Paul

---

From: Les Leposo <[email-masked]>
Date: Tue, 9 Sep 2014 16:19:22 +0300

Hi Valery,

> and will only sign itself.
Sure, CPU and RAM are not as expensive as "fast-path" or SA "tables" typical found in servers with hardware acceleration - prior to this proposal, these expensive resources were (typically) reserved only after authentication (and child SA nego succeeded).
However, with this proposal, the server will be allocating these resources anyhow because it can't judge between a good vs. bad client.

> And the server could always limit the number of unauthenticated connections
absolutely, it would help the server implementors, if this proposal required such safe guards- others would be rate-limiting and perhaps shorter Child-SA lifetimes.

> The Security Considerations must strongly discourage to do it.
Concur.

> Yes, it is possible. But there are some disadvantages comparing to special mode.
Concur, the sensor data would have to be inconsequential.

Because even when the measurement is not secret, a rogue "sensor" could easily pollute the central data which could be bad especially if the data is consequently used to control e.g. the cooling plant.

---

From: Les Leposo <[email-masked]>
Date: Tue, 9 Sep 2014 16:25:55 +0300

Hi Paul,

> Yes it could use up some more CPU and ram. But it's a trade of the admin makes.
Concur, but the admin would need to be given sufficient warning, through this document.

> Not sure what you mean with subjective in this context. But one sided anonymity isn't the same as both ends authenticating with psk "test". The server can still use a strong rsa key that the client…
But accepting crypto from anyone is like a big "Kick Me" sign on the server's spec sheet.

> Same here. The iot device can have a firmware rsa key of the server used to authenticate the server, while the client is not authenticated.
Great.

---

From: Paul Wouters <[email-masked]>
Date: Tue, 9 Sep 2014 09:27:13 -0400 (EDT)

On Tue, 9 Sep 2014, Les Leposo wrote:

> Sure, CPU and RAM are not as expensive as "fast-path" or SA "tables" typical found in servers with hardware acceleration - prior to this proposal,
> these expensive resources were (typically) reserved only after authentication (and child SA nego succeeded).

No one is telling you to enable this by default.

> However, with this proposal, the server will be allocating these resources anyhow because it can't judge between a good vs. bad client.

In the same way as you cannot judge between different half-open IKE
connections. Nothing really changes, and a few (tens of thousands) of
lines in the SADB shouldn't be that hard on a kernel. Clearly you won't
enable this on your embedded $20 router.

> absolutely, it would help the server implementors, if this proposal required such safe guards- others would be rate-limiting and perhaps shorter

Resource management depends on local resources. Therefor these are
typically left for local policy to decide. Is there any reason to
do that differently here?

>             2) this feature could also tempt network admins to fallback to 'null authentication' as a work-around/short-cut in cases
>             where they are unable to properly configure a deployment.
>

Do our security considerations state not to use "secret" as a PSK? Sure,
we should give some sane security advise, but we shouldn't talk about
obviously stupid things to do like purposefully degrading your security.

> Because even when the measurement is not secret, a rogue "sensor" could easily pollute the central data which could be bad especially if the data
> is consequently used to control e.g. the cooling plant.

That still assumes neither party authenticates. There is a big
difference between one-sided authentication (like most ssh and tls)
and no authentication (like most port 80)

Paul