On 07/26/2014 02:07 AM, Tero Kivinen wrote:
Yaron Sheffer writes:
This might sound like a nit, but we have this text in the draft, as
a use case for null auth:
"User wants to get some simple action from the remote device. Consider garage
door opener: it must authenticate user to open the door, but it is not
necessary for the user to authenticate the door opener. In this case one-way
authentication is sufficient."
The problem is, this is an incorrect protocol. Specifically, a MITM (who might
be physically located by the kitchen door), could redirect the protocol
exchange to a door different from the one I intended to open. Seeing that
nothing happens, I will simply press the remote again and open the garage
door, too.
This is of course a generic problem, where unauthenticated protocols have
unforeseen consequences.
No, that is not caused by the unauthenticated protocol, but caused by
the same device to be used with two different doors. Even if the
device would do full authentication and would verify that the door is
in his list of doors which can be opened, attacker could still do the
same thing.
Only way to get rid of that, would be to either put display on the
device telling which door responded, or put multiple buttons to the
device and you would have to bind each button to exactly one door
(i.e. each button using separate key or shared secret).
And, not you do not even need man in the middle in cryptographic
sense, just rerouting the packets from the air to the other
destination would be enough.
So for that kind of uses the device would need to be tied to exactly
one door...
What you're saying is that to secure this system, we need authentication
of the device, either at the IKE level or at the application level (plus
UI improvements). I agree, and suggest again that this is not a good use
case for null or one-way authentication.
Thanks,
Yaron
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
