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

Yaron Sheffer <yaronf.ietf@gmail.com> Sat, 23 August 2014 09:13 UTC

Return-Path: <yaronf.ietf@gmail.com>
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 387761A8738 for <ipsec@ietfa.amsl.com>; Sat, 23 Aug 2014 02:13:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 L36BhqDSQum4 for <ipsec@ietfa.amsl.com>; Sat, 23 Aug 2014 02:13:08 -0700 (PDT)
Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA24A1A8736 for <ipsec@ietf.org>; Sat, 23 Aug 2014 02:13:07 -0700 (PDT)
Received: by mail-wi0-f180.google.com with SMTP id n3so602462wiv.13 for <ipsec@ietf.org>; Sat, 23 Aug 2014 02:13:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=7ZsQq2S23C+iRX8Swnkz98JtmMNTmot1ciwcZGuY6sg=; b=0R4jOm5iogvxQgX4SdBBYTtdeRwhwWhENbNh6S1v6H7rURgzqT/4zQZT1klVR/+EPL 5VuOfNf69NmsOnexnGXRTxj0ZvsEbDUwqh3hh6SiP2u6zq1b2xfNv6vYwRv3bh7ZoKLa 20AyQCW059vtnZkKScR/JJ+QnnSivncPvNvlWGUkidd1ryngjLXx8cFD0SYcalwcxJ0V WLWJ+mNX8YMBcWeRqofPGoU2v/uAElL9uBszx3UAnN8dZxh1NNLyGliqs4NKT9fJt6gJ B7wky0CXmwW3703VDiUgf680z/B43SF/+iQy4KQaliWVefSwndXUkSRSdshANQArJAkW pPoQ==
X-Received: by 10.180.75.49 with SMTP id z17mr3152759wiv.80.1408785186363; Sat, 23 Aug 2014 02:13:06 -0700 (PDT)
Received: from [10.0.0.3] (bzq-79-177-106-104.red.bezeqint.net. [79.177.106.104]) by mx.google.com with ESMTPSA id ne14sm1149975wic.14.2014.08.23.02.13.05 for <multiple recipients> (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 23 Aug 2014 02:13:05 -0700 (PDT)
Message-ID: <53F85B1F.6000007@gmail.com>
Date: Sat, 23 Aug 2014 12:13:03 +0300
From: Yaron Sheffer <yaronf.ietf@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0
MIME-Version: 1.0
To: Valery Smyslov <svanru@gmail.com>, ipsec <ipsec@ietf.org>
References: <53D287BA.2070104@gmail.com> <7C3DE8C9078E4ECC86A3CB77B9449616@buildpc>
In-Reply-To: <7C3DE8C9078E4ECC86A3CB77B9449616@buildpc>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/DGJdmWAJ6q2n5QM-FjwD7JbO7x8
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: Sat, 23 Aug 2014 09:13:10 -0000

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:
> 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 <mailto:yaronf.ietf@gmail.com>
>     *To:* ipsec <mailto:ipsec@ietf.org>
>     *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
>