IETF Logo Mail Archive

[OAUTH-WG] Formal analysis of draft-ietf-oauth-pop-key-distribution

Luca Arnaboldi <Luca.Arnaboldi@arm.com> Fri, 26 April 2019 10:51 UTC

Return-Path: <Luca.Arnaboldi@arm.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8F711200A4 for <oauth@ietfa.amsl.com>; Fri, 26 Apr 2019 03:51:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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 9blmrzzt-oJp for <oauth@ietfa.amsl.com>; Fri, 26 Apr 2019 03:51:57 -0700 (PDT)
Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40055.outbound.protection.outlook.com [40.107.4.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC9B9120033 for <oauth@ietf.org>; Fri, 26 Apr 2019 03:51:56 -0700 (PDT)
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=/SkvzENdQPU+2a8e3WQdQ6ndrLAyaM4giJGONx3GfTc=; b=f09C2Ii7V/KNOKg79yFLdBA8L2JWDFVvo8zBayXARlul5eiC4sJDK8DHPCP/AXFr/cYYCI414tx9pe6s6+PzGcV/nZUyHQngde9e1aD8BrjupmT9MAky7nnL6WyujYl4yfxWge1g+85sOVJyWfrElCkCep+g7sengya/fH709Zs=
Received: from DB8PR08MB3980.eurprd08.prod.outlook.com (20.179.12.87) by DB8PR08MB5003.eurprd08.prod.outlook.com (10.255.16.204) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1835.12; Fri, 26 Apr 2019 10:51:54 +0000
Received: from DB8PR08MB3980.eurprd08.prod.outlook.com ([fe80::8958:ef04:f5d4:837d]) by DB8PR08MB3980.eurprd08.prod.outlook.com ([fe80::8958:ef04:f5d4:837d%3]) with mapi id 15.20.1835.010; Fri, 26 Apr 2019 10:51:54 +0000
From: Luca Arnaboldi <Luca.Arnaboldi@arm.com>
To: "oauth@ietf.org" <oauth@ietf.org>
Thread-Topic: Formal analysis of draft-ietf-oauth-pop-key-distribution
Thread-Index: AQHU/BpqKPkcnHWaK0OaLJqnsHk3QA==
Date: Fri, 26 Apr 2019 10:51:53 +0000
Message-ID: <DB8PR08MB39801EF8D75849CE0BC571678E3E0@DB8PR08MB3980.eurprd08.prod.outlook.com>
Accept-Language: en-GB, en-US
Content-Language: en-GB
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Luca.Arnaboldi@arm.com;
x-originating-ip: [128.240.225.113]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 9e8fae1a-7c7b-47f3-0d35-08d6ca353203
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600141)(711020)(4605104)(4618075)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:DB8PR08MB5003;
x-ms-traffictypediagnostic: DB8PR08MB5003:
x-microsoft-antispam-prvs: <DB8PR08MB50031E5E43C50128BB4668FE8E3E0@DB8PR08MB5003.eurprd08.prod.outlook.com>
x-forefront-prvs: 001968DD50
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(346002)(396003)(136003)(39860400002)(366004)(40434004)(78124002)(199004)(189003)(5640700003)(7696005)(6436002)(2351001)(53936002)(71200400001)(71190400001)(99286004)(64756008)(66556008)(66476007)(66446008)(66066001)(55016002)(14454004)(33656002)(74316002)(6916009)(25786009)(6606003)(316002)(7736002)(966005)(76116006)(72206003)(66946007)(73956011)(54896002)(102836004)(6506007)(2501003)(52536014)(97736004)(186003)(26005)(81156014)(86362001)(1730700003)(5660300002)(81166006)(508600001)(8676002)(6306002)(19627405001)(256004)(476003)(14444005)(5024004)(68736007)(9686003)(486006)(2906002)(3846002)(6116002)(8936002); DIR:OUT; SFP:1101; SCL:1; SRVR:DB8PR08MB5003; H:DB8PR08MB3980.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)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: hUm+ohVdctI0SbA2jRY3zj7Y5ThUgZCsYsAAJJCELSv3NEsjGkWk7OTMov5tcsvwNrJbr+JNSF7TAU1FJqKCkf9Raaev+uRSni93HiJWjSPreWCORwlnRhHNbRV3IHKzJjPVnlsGZdd9jf/vsihfGCn4GzA1J+WAYesz1i54FQpzZE4CMtaWyQHviOeSW14Kfd+Gcxpm/Pu+H2008HHbEAL1YrWltKNpMOaOuqb7ogAgstn6JOvfEXNET2Esxlg0jSMYj9Qye4DEb1aqQAjksqyx4WLuRkNISAY4+O6TY6wxexexo4ucfAAXRdmYbZGaMbp+fTb9goyZP6c7FBfz37J2/jZ24ztErpctIqzmK5/VU327phwkS3JLaODM5+1kc/Ir3S82ESwlGn1AIfltvmwoPJ78tfoBzPz9ANam2Tc=
Content-Type: multipart/alternative; boundary="_000_DB8PR08MB39801EF8D75849CE0BC571678E3E0DB8PR08MB3980eurp_"
MIME-Version: 1.0
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 9e8fae1a-7c7b-47f3-0d35-08d6ca353203
X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Apr 2019 10:51:53.8810 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB8PR08MB5003
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/9UekP9qStrSS1_J_5a4p7XVamtc>
Subject: [OAUTH-WG] Formal analysis of draft-ietf-oauth-pop-key-distribution
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 26 Apr 2019 10:52:00 -0000

* I spoke with Hannes after the IETF meeting in Prague and he expressed the need to enhance our formal analysis (as presented at the OAuth Security Workshop) to verify whether it is necessary to demonstrate possession of the private key by the client to the authorization server.


* The analysis checked whether it was necessary for a proof of possession to be performed between the client and AS to ensure security. The result was that even without verification by the AS the client would not be able to access the resource from the RS without possessing the secret key associated to the token (assuming the check is done correctly by the RS).

Tamarin model for specific example with proofs available at : https://github.com/Yiergot/ACE-OAuth-FormalModel


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