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

From: Yaron Sheffer <[email-masked]>
Date: Fri, 25 Jul 2014 19:37:14 +0300

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

---

From: Tero Kivinen <[email-masked]>
Date: Sat, 26 Jul 2014 02:07:41 +0300

Yaron Sheffer writes:
> "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.

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 devive would need to be tied to exactly
one door... 
-- 
[email-masked]

---

From: Yaron Sheffer <[email-masked]>
Date: Sat, 26 Jul 2014 20:34:34 +0300

On 07/26/2014 02:07 AM, Tero Kivinen wrote:
> 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.

Thanks,
	Yaron

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 28 Jul 2014 11:05:31 +0200

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.

On 07/25/2014 06:37 PM, Yaron Sheffer wrote:
> 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.
> 
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec
>

---

From: Yoav Nir <[email-masked]>
Date: Mon, 28 Jul 2014 13:46:30 +0300

Hi Hannes

I tend to agree. The beauty of IP (with or without “sec”) is that I can open a connection in one place to a server that is located in another location half-way around the world. The garage door opener is used from a short distance, so you don’t really need routing. You still might want to use IP, if only because IP-supporting equipment is so ubiquitous. I would have liked it if we could use some zeroconf protocol for discovering the garage door, but just because the opener is physically close to the garage door does not mean that it is topologically close on the Internet. So the best IP-based way is to register the garage door in DNS (garagedoor.yaronshouse.org), and then HTTPS works at least as well as HTTP over IPsec.

All this underlines Yaron’s claim that we need a better example for a use case for NULL auth.

Yoav

BTW: my local police station has an electrically-operated gate to the parking lot where the patrol cars are parked. It’s opened remotely by calling a particular phone number. The gate answers, immediately hangs up, and opens. This is pretty bad, because a phone number is a terribly short shared secret.

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 28 Jul 2014 17:48:18 +0200

Hi Yoav,

On 07/28/2014 12:46 PM, Yoav Nir wrote:
> Hi Hannes
> 
> I tend to agree. The beauty of IP (with or without “sec”) is that I
> can open a connection in one place to a server that is located in
> another location half-way around the world. The garage door opener is
> used from a short distance, so you don’t really need routing.

Good observation!

> You
> still might want to use IP, if only because IP-supporting equipment
> is so ubiquitous.

For the use cases we are talking about it is not ubiquitous at all.
We only just see the first products offering IP-based services in that
area and they are using IP for an entirely different purpose, namely to
connect the garage door to some cloud-based service to allow a owner of
the garage to check (via his smart phone) whether it is open (or
potentially to open it from remote).

> I would have liked it if we could use some zeroconf
> protocol for discovering the garage door, but just because the opener
> is physically close to the garage door does not mean that it is
> topologically close on the Internet.

It turns out that there are various ways to discover the garage door and
to control it using all sorts of application layer protocols but all
this adds is delay and complexity with no additional value in this case.

> So the best IP-based way is to
> register the garage door in DNS (garagedoor.yaronshouse.org), and
> then HTTPS works at least as well as HTTP over IPsec.

HTTPS works pretty well.

> All this underlines Yaron’s claim that we need a better example for a

All we are doing here is to add new options, don't explain enough to
allow others (like developers) to figure out how this stuff is supposed
to work.

What I am trying to do is to look at design patterns and try to help
developers make their life easier. It is already difficult enough
because we often leave half-baked building blocks around that do not
help to build interoperable solutions. This work on IPsec for
constrained devices does not help me at all to get anywhere closer to
that goal.

Ciao
Hannes

> 
> Yoav
> 
> BTW: my local police station has an electrically-operated gate to the
> parking lot where the patrol cars are parked. It’s opened remotely by
> calling a particular phone number. The gate answers, immediately
> hangs up, and opens. This is pretty bad, because a phone number is a
> terribly short shared secret.

The use of cellular radio technology might have impacted their design
decisions. I don't know what other design decisions they had to deal
with. It is hard to say whether the use of IPsec would be any better or
whether they should just use CoAP over DTLS based on the profiles we
have been working on in DICE.

>> 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
>> 
>>> This might sound like a nit, but we have this text in the draft,
>>> as a use case for null auth:
>>> 
>>> 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
>>> 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
>>> 
>> 
>> _______________________________________________ IPsec mailing list 
>> [email-masked] https://www.ietf.org/mailman/listinfo/ipsec
>