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

From: "Valery Smyslov" <[email-masked]>
Date: Wed, 20 Aug 2014 15:36:41 +0400

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

---

From: "Valery Smyslov" <[email-masked]>
Date: Wed, 20 Aug 2014 15:44:14 +0400

>> 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.

Not really authentication of the devices, but at least indication
in the protocol which device the sending command is concerned.
And an ability for the device to understand who it is (garage or kitchen).
That is cheaper than mutual authentication.

Regards,
Valery.

---

From: "Valery Smyslov" <[email-masked]>
Date: Wed, 20 Aug 2014 15:55:34 +0400

Hi Hannes, 

I agree that the example is a bit artificial and in real life
one would not use IKE/IPsec to control garage door.
At least now. But if IoT becomes ubiquitous then
who knows, probably such setup will be default
"off shelf" solution...

Regards,
Valery.

P.S. What about mutual authentication in this case - 
please see my reply to original Yaron's message.

> Hi Yaron,
> 
> if you further try to implement a prototype for a door opener then you
> might run into a number of issues, such as
> 
> * how does the garage opener discover the garage door?
> * what radio technology are you going to use?
> * how does the garage door authorize the garage opener?
> 
> When you then answer all these questions you might realize (as I did)
> that you neither want to use IPsec there nor even IP.
> 
> Ciao
> Hannes
> 
> PS: I agree with your statement about mutual authentication.

---

From: Yaron Sheffer <[email-masked]>
Date: Sat, 23 Aug 2014 12:13:03 +0300

Hi Valery,

I agree the garage system can be made secure, if engineered correctly. 
But garage engineering is out of scope for this draft :-)

IMO the sensor example is much simpler and therefore much better. I 
would suggest that you replace the garage in the draft by a thermometer.

Thanks,
	Yaron

On 08/20/2014 02:36 PM, Valery Smyslov wrote:
>     *From:* Yaron Sheffer <mailto:[email-masked]>
>     *To:* ipsec <mailto:[email-masked]>
>     *Sent:* Friday, July 25, 2014 8:37 PM
>     *Subject:* [IPsec] Garage door - let's pick a different example
>
>     "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.
>
>     ------------------------------------------------------------------------
>