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