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

Stefanie Gerdes <gerdes@tzi.de> Tue, 18 December 2018 14:46 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 B613E127AC2 for <ace@ietfa.amsl.com>; Tue, 18 Dec 2018 06:46:56 -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 aAABZnUdO-_x for <ace@ietfa.amsl.com>; Tue, 18 Dec 2018 06:46:54 -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 41B7F126CC7 for <ace@ietf.org>; Tue, 18 Dec 2018 06:46:54 -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 2149B209F0; Tue, 18 Dec 2018 15:46:52 +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>
From: Stefanie Gerdes <gerdes@tzi.de>
Message-ID: <dff54c41-9598-8f77-83ec-f4494703d923@tzi.de>
Date: Tue, 18 Dec 2018 15:46:39 +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: <VI1PR0801MB21126DDCCA251EEB8DB21DAAFABD0@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/kKfdK2409n8oqZ4J-ON5vY2_Rw8>
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: Tue, 18 Dec 2018 14:46:57 -0000

Hi Hannes,

On 12/18/2018 02:51 PM, Hannes Tschofenig wrote:

> ~snip~
> 
> 
> Now that I got a response from the OAuth working group (in the sense that I was thinking about the claims in the access token rather than the parameters in the response from the AS) I think checking the expires_in field has to be optional since
> * the expires_in parameter is optional, and
> * it only has an advisory nature.
> 
> It is useful to send the parameter so that the client can determine when to request a new access token (for example, via the refresh token) but it is not absolutely necessary for the protocol operation.

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.

Viele Grüße
Steffi