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

Reply via email to