Re: [Ace] Security of the Communication Between C and RS

Jim Schaad <ietf@augustcellars.com> Wed, 19 December 2018 20:22 UTC

Return-Path: <ietf@augustcellars.com>
X-Original-To: ace@ietfa.amsl.com
Delivered-To: ace@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5EEF130ED7 for <ace@ietfa.amsl.com>; Wed, 19 Dec 2018 12:22:47 -0800 (PST)
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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 iCOMUts4IXgS for <ace@ietfa.amsl.com>; Wed, 19 Dec 2018 12:22:45 -0800 (PST)
Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14C07130EC9 for <ace@ietf.org>; Wed, 19 Dec 2018 12:22:45 -0800 (PST)
Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 19 Dec 2018 12:17:32 -0800
From: Jim Schaad <ietf@augustcellars.com>
To: 'Ludwig Seitz' <ludwig.seitz@ri.se>, 'Hannes Tschofenig' <Hannes.Tschofenig@arm.com>, 'Stefanie Gerdes' <gerdes@tzi.de>, <ace@ietf.org>
References: <154322421294.8323.8505315870685563404.idtracker@ietfa.amsl.com> <945fbebe-659f-ac72-3ab6-8e05447e7c92@ri.se> <1c5b81f3-50ce-be68-bec3-68ce2ff15b43@tzi.de> <4ae4eccd-68bf-18ef-f909-142f8172eca1@ri.se> <81ba3ab4-a9ce-a6fd-fbe6-c36a6fbbd9a5@tzi.de> <VI1PR0801MB2112E04F9FD7412350995417FAA20@VI1PR0801MB2112.eurprd08.prod.outlook.com> <b994af16-9bb8-4386-e7d2-321e453417fc@ri.se> <VI1PR0801MB21124D7C11F3A1F49DCA9A2CFABD0@VI1PR0801MB2112.eurprd08.prod.outlook.com> <VI1PR0801MB21126DDCCA251EEB8DB21DAAFABD0@VI1PR0801MB2112.eurprd08.prod.outlook.com> <dff54c41-9598-8f77-83ec-f4494703d923@tzi.de> <VI1PR0801MB21125D384A3DE6BD90AEDB74FABD0@VI1PR0801MB2112.eurprd08.prod.outlook.com> <b79ea204-0d7d-3968-6ea5-cd33d5502380@tzi.de> <VI1PR0801MB2112F215E8DF2E8AC34F217FFABE0@VI1PR0801MB2112.eurprd08.prod.outlook.com> <e42032d6-ad15-26d2-cdbb-aaa34900d1ad@tzi.de> <9f35177f-30d4-817e-dfc3-9a54903ab023@ri.se> <VI1PR0801MB2112BA2A400D660DC32B7293FABE0@VI1PR0801MB2112.eurprd08.prod.outlook.com> <f441528a-aba4- 8556-0493-2e12a38e4133@ri.se>
In-Reply-To: <f441528a-aba4-8556-0493-2e12a38e4133@ri.se>
Date: Wed, 19 Dec 2018 12:22:32 -0800
Message-ID: <035a01d497d8$941fa920$bc5efb60$@augustcellars.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQK3+H3pFttPP+s38ebErlDfr5TlzwHGtbndAWWZiHUBoal9GAG606RNAr6sEpUBdBg41wIoMkRRAVy26uEBni/SMwLhh1vKAXfJk28ClIb+HQJIod4qAfJwDVsCR+KGWAKnCEv4osAIQ8A=
Content-Language: en-us
X-Originating-IP: [73.180.8.170]
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/Chapdba1LDbM1UEti-S-GSqrOLQ>
Subject: Re: [Ace] Security of the Communication Between C and RS
X-BeenThere: ace@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" <ace.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ace>, <mailto:ace-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ace/>
List-Post: <mailto:ace@ietf.org>
List-Help: <mailto:ace-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ace>, <mailto:ace-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 19 Dec 2018 20:22:48 -0000


> -----Original Message-----
> From: Ludwig Seitz <ludwig.seitz@ri.se>
> Sent: Wednesday, December 19, 2018 5:24 AM
> To: Hannes Tschofenig <Hannes.Tschofenig@arm.com>om>; Stefanie Gerdes
> <gerdes@tzi.de>de>; Jim Schaad <ietf@augustcellars.com>om>; ace@ietf.org
> Subject: Re: [Ace] Security of the Communication Between C and RS
> 
> On 19/12/2018 14:04, Hannes Tschofenig wrote:
> > Thanks, Ludwig. The list of steps below help me to understand the concern.
> >
> > ----
> >
> >
> > 1.) C obtains token and pop-key from AS
> > 2.) C transmits token to RS and sets up secure communication (e.g.
> > DTLS-PSK) using the pop-key
> > 3.) C sends secure requests to the RS
> > 4.) token expires, an attacker manages to get hold of the pop-key
> > 5.) C continues to send requests containing sensitive information to the RS ,
> attacker can now read the messages and spoof positive responses from the RS.
> C never notices that the token is invalid and that it is actually talking to the
> attacker.
> >
> 
> > ----
> >
> > In step (4) you tie the expiry of the token to the attacker getting
> > hold of the key. What happens if the attacker gets hold of the pop key
> > before the token expires?
> 
> If it is detected the AS would revoke the token. Then the client _could_ use
> client introspection to get that information. Note that this is what the CMU
> people are looking at.

I am having a real problem with the idea that we are going to start adding the idea of revocation to the entire system.   I would much rather make sure that both sides are given an idea of when things are going to expire and just make things expire relatively quickly.

> 
> > Additionally, if you use DTLS/TLS just having the PoP key still
> > requires the attacker to run a new DTLS/TLS handshake with the RS.
> 
> If the pop-key was used as a basis for doing a DTLS-PSK handshake, the attacker
> should be able to hijack the connection and impersonate either party.

This depends on the version of PSK that you are doing.  If you use PSK+ECDH then the attacker cannot hijack the connection.

> 
> 
> > It would also be useful to know where the attacker got the PoP key
> > from and how you can even detect the compromise.
> 
> That is a different story entirely. You could imagine the case of an RS
> improperly deleting an expired token and the associated pop-key, and then
> being subject to a physical attack that recovers that information.

It would be more reasonable to say that if you are doing a physical attack, then it would be easy to get an RPK and then you are the RS until such a time as the AS is told that the key is no longer trusted.  In this case you will just continue getting tokens as a client which are still valid and none of this is helpful in any event.

Jim


> 
> >
> > Additionally, there is the question why the RS wouldn't stop
> > communicating if the token expired since it has that information.
> 
> The RS would indeed stop, but since the token is opaque to the client, it has no
> way of knowing that the token has expired, and our clever attacker is using the
> pop-key to impersonate the RS and maintain the illusion that the connection is
> still alive an running.
> 
> > Normally, the idea is that the RS has a protected resource and the
> > client wants to access it. That's why the RS is asking the client to
> > send a token that gives it access.
> >
> 
> Yes but say e.g. that the RS is a message broker and the client is a publisher,
> writing sensitive data to the RS.
> 
> 
> I think Steffi's point definitely warrants text in the security
> considerations, outlining how a client could detect that a token has
> expired.
> 
> /Ludwig
> 
> --
> Ludwig Seitz, PhD
> Security Lab, RISE
> Phone +46(0)70-349 92 51