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 IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec