Re: [IPsec] Garage door - let's pick a different example

["Valery Smyslov" <[e-mail]>]

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
  [e-mail]
  https://www.ietf.org/mailman/listinfo/ipsec