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

Hannes Tschofenig <hannes.tschofenig@gmx.net> Mon, 28 July 2014 15:48 UTC

Return-Path: <hannes.tschofenig@gmx.net>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E35761A02EB for <ipsec@ietfa.amsl.com>; Mon, 28 Jul 2014 08:48:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PsgqOYd8W9MJ for <ipsec@ietfa.amsl.com>; Mon, 28 Jul 2014 08:48:37 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 707461B28E0 for <ipsec@ietf.org>; Mon, 28 Jul 2014 08:48:19 -0700 (PDT)
Received: from [172.16.254.119] ([80.92.116.212]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0M8ehf-1WGNHu37aN-00wAWv; Mon, 28 Jul 2014 17:48:17 +0200
Message-ID: <53D670C2.1060203@gmx.net>
Date: Mon, 28 Jul 2014 17:48:18 +0200
From: Hannes Tschofenig <hannes.tschofenig@gmx.net>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0
MIME-Version: 1.0
To: Yoav Nir <ynir.ietf@gmail.com>
References: <53D287BA.2070104@gmail.com> <53D6125B.4030509@gmx.net> <782DD2E2-9691-42A3-8D7F-5EF6268D98EB@gmail.com>
In-Reply-To: <782DD2E2-9691-42A3-8D7F-5EF6268D98EB@gmail.com>
OpenPGP: id=4D776BC9
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="2whF3gH5BcE4D8KgOkjxilxf7LwQup7C5"
X-Provags-ID: V03:K0:NR6wZcTDQ8Ibg3MOoqQpM77nXJBLqBF8K0ralE07+PVhxslU33g D2mRFWuolMvhunDLnosjy8NPa9drbEJnwANtIiQDD78qx2Kw8GLlEuIk5YSYia03Knu96gE 4ot1cgGMvUlA7W/IbEqWPAyrOnRaaa/ZpVFBEqn+OryNxG6MBVYGyIWLowB0JoqDvTYpy5G JulhpNLsAG6fj2jheXN4g==
Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/KVFLA9XLwnu-xXXrwTd4lbGf6kw
Cc: ipsec <ipsec@ietf.org>
Subject: Re: [IPsec] Garage door - let's pick a different example
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 28 Jul 2014 15:48:47 -0000

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
> use case for NULL auth.

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.


> 
> On Jul 28, 2014, at 12:05 PM, Hannes Tschofenig
> <hannes.tschofenig@gmx.net> wrote:
> 
>> 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.
>>> 
>>> 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
>