IETF Logo Mail Archive

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

Hannes Tschofenig <Hannes.Tschofenig@arm.com> Tue, 18 December 2018 15:32 UTC

Return-Path: <Hannes.Tschofenig@arm.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 6AF64130E6B for <ace@ietfa.amsl.com>; Tue, 18 Dec 2018 07:32:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.002
X-Spam-Level:
X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com
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 i482R4zsvdef for <ace@ietfa.amsl.com>; Tue, 18 Dec 2018 07:32:46 -0800 (PST)
Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10060.outbound.protection.outlook.com [40.107.1.60]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49AC9130E6A for <ace@ietf.org>; Tue, 18 Dec 2018 07:32:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=sb4oWw1iD3PKJYGZn7OTvVLpbBhVIAgAtBiPZAUBmKg=; b=kmuJjPnQbcj9WUZc3rCj/YFU52fRubCk3MKaxfoR/Brk4uqrUUOnLpfxu0foxuse8NAdcDyET/7kECX7QX59Vc84YvoHQvnj35nP0ah86IXoZf+8IG0QqEEfhdq9IIjAVqKwvyn/9CVTaBtmX5RKPAWd/iX9Hw4dSLu8AvTs9Is=
Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com (10.173.75.16) by VI1PR0801MB1805.eurprd08.prod.outlook.com (10.168.67.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1446.17; Tue, 18 Dec 2018 15:32:42 +0000
Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::e8de:6a41:cbf4:89d8]) by VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::e8de:6a41:cbf4:89d8%3]) with mapi id 15.20.1425.023; Tue, 18 Dec 2018 15:32:42 +0000
From: Hannes Tschofenig <Hannes.Tschofenig@arm.com>
To: Stefanie Gerdes <gerdes@tzi.de>, Ludwig Seitz <ludwig.seitz@ri.se>, Jim Schaad <ietf@augustcellars.com>, "ace@ietf.org" <ace@ietf.org>
Thread-Topic: [Ace] Security of the Communication Between C and RS
Thread-Index: AQHUluCo2rYBZxPox06btKUYOKg3d6WEnlqQ
Date: Tue, 18 Dec 2018 15:32:42 +0000
Message-ID: <VI1PR0801MB2112B55F632604E1B385652CFABD0@VI1PR0801MB2112.eurprd08.prod.outlook.com>
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> <b3aa33a9-9a04-f741-35f1-9037b58bb636@tzi.de>
In-Reply-To: <b3aa33a9-9a04-f741-35f1-9037b58bb636@tzi.de>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [80.92.114.221]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; VI1PR0801MB1805; 6:rs7aklc73J7TQfkwGXxwLXnysyZN4tqzOhpH/0E+IOSdJwnPVwtrz6CPzSUMvFp4+M/MXUwMAmNbIEZUMRuVHD+h6pvZThgOyG/shKnCkYWrgifpvFrLY7ADzwyiLgRWIAhITjDWNgh1OJerkSLT7r24nZZtI4FpZis+9lOmjz75P7cUmtEgbgmn/s5jLqyLesvrncUWMr4QQ1uXxY8B6yy+Ol3Tg/Dv17nET/p1VPWbvFB07d1Zh3Vm4zJ/X95FzCfMPc+rJVGzJbO7hT9EDf+NoBfXHlYi4qTxtnsd+DeemoZxXelZB5WzgLocKKLhoUQIYX8CNUTSRMOtS5dM2RbuNwC9edlz3q4fdRt0E4LAMgxP5wCmW3yAMUE0VioRSimOOfbesgHJqFKAKVO7Y9dBRtQsUpFJEu+or6eONJlIPYcbjpHq5Sbsbtf+ZZCChdh8WsQhev5l7p3iYs0Mmg==; 5:n11qy7IL3kNYx7iv5pzIvwCBtQfD6PcjcCF0Sewmi4gHc8X7Uk4WzoLDrbIMOqudSOLmEgp+p++AAYvFuIfkvwyAPW8hbNWpp7OmJGbCFzJApv9gBTZ2bmnG2RLvaHS89bK37uNpH5agx+HA/kAuEbeT3pJhcHrdEBkyvRZkMX4=; 7:YWUvAkbzfyLxd3SCd4+h6ACTi9Emc2Qt3Rhh644ANs2f9cVJNj6OScOy0bmSqEIH9YeX6orBL+ZTo4o+UQhXrj1C4NnppcaWhe2++C1Y+8CAq6koz2FJh1eyXt3/2J6OLs6oFV0FIyemddvjWOdR7w==
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: 6c0561e5-9eba-480d-eed1-08d664fe0d13
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(4618075)(2017052603328)(7153060)(7193020); SRVR:VI1PR0801MB1805;
x-ms-traffictypediagnostic: VI1PR0801MB1805:
x-microsoft-antispam-prvs: <VI1PR0801MB1805F9ED9D405F9672C700ACFABD0@VI1PR0801MB1805.eurprd08.prod.outlook.com>
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(3230021)(999002)(5005020)(6040522)(2401047)(8121501046)(3231475)(944501520)(52105112)(93006095)(93001095)(10201501046)(3002001)(6055026)(148016)(149066)(150057)(6041310)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123562045)(20161123564045)(201708071742011)(7699051)(76991095); SRVR:VI1PR0801MB1805; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0801MB1805;
x-forefront-prvs: 08902E536D
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(346002)(136003)(39860400002)(396003)(376002)(199004)(189003)(40434004)(446003)(8936002)(8676002)(476003)(11346002)(14454004)(2501003)(81156014)(81166006)(26005)(7736002)(33656002)(2906002)(486006)(6436002)(106356001)(105586002)(7696005)(74316002)(25786009)(6506007)(5660300001)(72206003)(86362001)(76176011)(97736004)(478600001)(68736007)(6346003)(305945005)(186003)(15650500001)(71200400001)(102836004)(71190400001)(93886005)(3846002)(6116002)(55016002)(53936002)(9686003)(6246003)(66066001)(229853002)(5024004)(316002)(14444005)(110136005)(99286004)(256004); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0801MB1805; H:VI1PR0801MB2112.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com;
x-microsoft-antispam-message-info: yjqQcn+hD8II+J/JZ5OxV6otQetruk8864Qm80jDPfY3vdaDExROeZB7WShiu/xUmfaQ5yTzZUkpo7/aCuiWRkrPAT3zcr4qwo9+0qLStysOuxDwu32nBtl6+5tSeLpBdXJJTbsONS8c3X4zpFVmmvGvs22sAca/+dibGwUmCHPM+wThsgHA714qCNHvXAUx+ULsuhLXsD3EsgvzSQIQ2EtYmyEbH4IykiqvCTKJAQSub8UYQp8m0ijTe/4FfxyzLBLT3/8MHmxqcxHeokwS3KmXaa+EHErXVt/uj+paLJeFDoBZD8/Ex+60Z9A3TSE9
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 6c0561e5-9eba-480d-eed1-08d664fe0d13
X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Dec 2018 15:32:42.2134 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB1805
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/fG47YoVjF65Qt1CUTpovP3RBTd0>
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 15:32:48 -0000

Hi Steffi,

>> I also think that the client must be able to assume that RS' RPK that C receives from AS is also valid as long as the token, unless C has additional information.
>
> I would think that it is rather unlikely that the RS will change its public/private key pair so quickly. Right?

> I don't really know what you mean with "quickly". Access tokens may be valid for a long time, depending on the application scenario. Also, RS may already have its RPK for a while at the time when AS generates the access token. RPKs do not contain semantic information and C may not have additional information about the RPK. Therefore, C must be able to assume that the RS' RPK is valid as long as the access token.

>From an AS point of view it would make sense to make sure they hand out information to client that actually works. If the token is still valid while the information about the RPK of the RS isn't then there may indeed be a failure case.
This isn't too bad since the client will then (hopefully) contact the AS again to get a new access token.

We could nevertheless add a note saying that the operator of the AS needs to consider these cases and that the client should contact the AS again in an error situation.

Ciao
Hannes
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

v2.23.0 | Report a Bug | By Email