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

Stefanie Gerdes <gerdes@tzi.de> Wed, 19 December 2018 11:26 UTC

Return-Path: <gerdes@tzi.de>
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 2304E1277D2 for <ace@ietfa.amsl.com>; Wed, 19 Dec 2018 03:26:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 LNtm7loAGGzT for <ace@ietfa.amsl.com>; Wed, 19 Dec 2018 03:26:25 -0800 (PST)
Received: from smtp.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED097124BAA for <ace@ietf.org>; Wed, 19 Dec 2018 03:26:24 -0800 (PST)
Received: from [192.168.1.109] (p508A4EFC.dip0.t-ipconnect.de [80.138.78.252]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.uni-bremen.de (Postfix) with ESMTPSA id 9D29F20552; Wed, 19 Dec 2018 12:26:22 +0100 (CET)
To: Hannes Tschofenig <Hannes.Tschofenig@arm.com>, Ludwig Seitz <ludwig.seitz@ri.se>, Jim Schaad <ietf@augustcellars.com>, "ace@ietf.org" <ace@ietf.org>
References: <154322421294.8323.8505315870685563404.idtracker@ietfa.amsl.com> <cbd083d1-cb95-0732-aa8b-7c7de3f480d1@ri.se> <a0cdd836-7fe3-339e-0c48-961503857447@tzi.de> <03b601d49191$7d1bb400$77531c00$@augustcellars.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>
From: Stefanie Gerdes <gerdes@tzi.de>
Message-ID: <b79ea204-0d7d-3968-6ea5-cd33d5502380@tzi.de>
Date: Wed, 19 Dec 2018 12:26:13 +0100
User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <VI1PR0801MB21125D384A3DE6BD90AEDB74FABD0@VI1PR0801MB2112.eurprd08.prod.outlook.com>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/-uYXAy_-Li8HE4fDuQGd811LS1U>
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 11:26:27 -0000

Hi Hannes,

On 12/18/2018 04:26 PM, Hannes Tschofenig wrote:
> Hi Steffi,
> 
>> In OAuth, the expires_in field is usually used to inform the client how long the access token is valid. If the client uses the access token in a request after the token expired, the RS will reject the request, which usually is not a big problem for the client.
> 
>> In ACE, AS provides the client with keying material for the RS, which is a completely different situation. If the client does not know how long the keying material is valid, it may use outdated keying material to communicate with RS. The expires_in field can be used to inform the client how long the keying material for RS is valid, if the keying material is valid as long as the access token.
> 
>> The main reason to change keying material from time to time is to avoid that it is compromised. I therefore think that it is necessary for the security of the solution that C knows how long the keying material is supposed to be valid.
> 
> If a client uses either an old key or an old token then the request will fail. I don't see much difference here between OAuth and ACE.

The difference is that C cannot authenticate RS with an outdated key.
And even if the correct RS rejects the request, the confidentiality of
the request may already have been breached, i.e., the damage is already
done. C therefore must know how long the keying material is valid.

Viele Grüße
Steffi