Hi Valery, On Sep 9, 2014, at 2:08 PM, Valery Smyslov <[email protected]> wrote:
> Hi Les, > >> 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? > > 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. 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. >> 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. > Concur. >> 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? > > 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. 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. > > Regards, > Valery. > >> $0.02 >> >> On Sep 8, 2014, at 10:00 PM, [email protected] wrote: >> >>> Send IPsec mailing list submissions to >>> [email protected] >>> >>> 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 protected] >>> >>> You can reach the person managing the list at >>> [email protected] >>> >>> 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 protected]> >>> To: [email protected], [email protected] >>> Cc: [email protected] >>> Subject: Re: [IPsec] Call for adoption: The NULL Authentication Method >>> in IKEv2 Protocol >>> Message-ID: <[email protected]> >>> 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 protected] >>> https://www.ietf.org/mailman/listinfo/ipsec >>> >>> >>> ------------------------------ >>> >>> End of IPsec Digest, Vol 125, Issue 9 >>> ************************************* >> >> _______________________________________________ >> IPsec mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
