Hi Yaron,
sorry for late reply - I was on vacation.
I still think that the example is valid. The example describes the remote
opener which
opens the only door. If you want to open different doors using single opener
then you might
run into trouble you described. But this attack can be thwarted by using
more specific commands: not just "open" and "close", but "open garage door",
"close kitchen door" etc. In this case each door must know its name
and must act only if received command concerns it. Note, that mutual
authentication
is still not needed here.
Another example, where initiator must be authenticated while responder
is not needed to be authenticated is some sensor (e.g. temperature), that
sleeps most of the time, but periodically wakes up, measures something
(like temperature) and sends the result to some server. Clearly, the sensor
must
be authenticated, but the server it connects to may be left unauthenticated
(I presume that the measurement itself is not secret, so no harm
if attacker gets it, authentication is only needed for the server to
be sure it receives authorative data).
Regards,
Valery.
----- Original Message -----
From: Yaron Sheffer
To: ipsec
Sent: Friday, July 25, 2014 8:37 PM
Subject: [IPsec] Garage door - let's pick a different example
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.
Thanks,
Yaron
------------------------------------------------------------------------------
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
