IETF Logo Mail Archive

[Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of-possession-02

Hannes Tschofenig <Hannes.Tschofenig@arm.com> Fri, 22 June 2018 13:36 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 35255130E58; Fri, 22 Jun 2018 06:36:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level:
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] 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 dv8Pz7sR_PQM; Fri, 22 Jun 2018 06:36:21 -0700 (PDT)
Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0057.outbound.protection.outlook.com [104.47.1.57]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A6DB130E5F; Fri, 22 Jun 2018 06:36:19 -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=5yc7S95bgUcu3POmbdsd/SpyM/M/2dxQ3/ahOkw1/dU=; b=kSyU+hjMx3+HQkash1N6GdlMbcMNUcvGo9lQ7c8MQXHCa5CE/GhdWdX/vxjfEnrD8XJpZA6VTPn3JHWPb8gUbNutYCuY7KHZCleG6aLmSGpsROCb5EqK4D52hAWGOOzQb22o3lBMAv/QdRSxWyq+/e6Hdo0AERMm+PeyBXHp64I=
Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com (10.173.75.16) by VI1PR0801MB1616.eurprd08.prod.outlook.com (10.167.211.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.863.19; Fri, 22 Jun 2018 13:36:17 +0000
Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::d1df:1498:96ec:6b35]) by VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::d1df:1498:96ec:6b35%4]) with mapi id 15.20.0863.021; Fri, 22 Jun 2018 13:36:17 +0000
From: Hannes Tschofenig <Hannes.Tschofenig@arm.com>
To: Jim Schaad <ietf@augustcellars.com>, 'Mike Jones' <Michael.Jones@microsoft.com>, "draft-ietf-ace-cwt-proof-of-possession@ietf.org" <draft-ietf-ace-cwt-proof-of-possession@ietf.org>
CC: "ace@ietf.org" <ace@ietf.org>
Thread-Topic: Key IDs ... RE: [Ace] WGLC on draft-ietf-ace-cwt-proof-of-possession-02
Thread-Index: AdQKFSUx11D9ChnERGKUCytum2t16A==
Date: Fri, 22 Jun 2018 13:36:16 +0000
Message-ID: <VI1PR0801MB2112C4D6D3CED7C15D9AE886FA750@VI1PR0801MB2112.eurprd08.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com;
x-originating-ip: [80.92.115.225]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; VI1PR0801MB1616; 7:BHHQqOuSSYYaSGzsqGKqtUBNhZ8pJ40Id75rTfa43J6Hdg/kLamiTnDJvKWhk3u7xrvMTXkMo1q6fR8C7WD3y92IRKnoj73sGHi99NKzJwH4uBdh0+bhNf+ZZ/d+Zm7J6jRslMgseeistENO6SpHYtEayAwBCUIvsiVLU7VCyxHVs107NqUpmpK8Zv/Xa3aPLIVTC2VRqm2X8TbYd9bJAZw1xv4FpOYJiVoD3l9r1Oven3P+zseevroaD2OQgUfE
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: d4e97ebd-ce90-4dca-476a-08d5d8452192
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:(223705240517415); BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(711020)(48565401081)(2017052603328)(7153060)(7193020); SRVR:VI1PR0801MB1616;
x-ms-traffictypediagnostic: VI1PR0801MB1616:
x-microsoft-antispam-prvs: <VI1PR0801MB1616D7A6E0F48C7BD2FFA43DFA750@VI1PR0801MB1616.eurprd08.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(192374486261705)(223705240517415);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3002001)(93006095)(93001095)(10201501046)(3231254)(944501410)(52105095)(6055026)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123564045)(20161123562045)(20161123560045)(6072148)(201708071742011)(7699016); SRVR:VI1PR0801MB1616; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0801MB1616;
x-forefront-prvs: 071156160B
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(366004)(39860400002)(39380400002)(396003)(346002)(40434004)(189003)(199004)(5660300001)(59450400001)(68736007)(86362001)(14454004)(2900100001)(102836004)(186003)(316002)(106356001)(105586002)(476003)(74316002)(6436002)(26005)(478600001)(72206003)(6506007)(7696005)(2906002)(561944003)(99286004)(25786009)(305945005)(110136005)(3846002)(4326008)(8936002)(3280700002)(1511001)(9686003)(486006)(5890100001)(55016002)(5250100002)(6116002)(8666007)(2501003)(66066001)(8676002)(53936002)(3660700001)(97736004)(7736002)(33656002)(81166006)(81156014); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0801MB1616; H:VI1PR0801MB2112.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: qVjtSNA7cLzB/EK1I3dUjQtj5AJN4J4BD0t8j7EWUdiAuD6hNk61iUCWsTurbfDJdVHfs1tfDCwQ0RRuMGviFTAIixV6TlgwW42saXMqifY7eaGVBRXmw73qXzR01nqlA57sbzXzQPjXISzKWTvtf18RABWu2PqnR8BHjAUDdlmLNAth+fpKYerX/6SUDZdcpcSkSbmMyjx62yH/lNF6J6kBo4QLW7wiQeysEzPVD7mzo74QDoK2t5cIQXOZM+dKescgbTeyfrsTwr8yXpnrO2LrBDgOHUUIu6CjZL4rGE3jPxWErOjUa86ZeHlFJU80QdRFjMnVTXArdejHyT29cw==
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: d4e97ebd-ce90-4dca-476a-08d5d8452192
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Jun 2018 13:36:16.9680 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB1616
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/J_ml0AX0UtgEcZB0DKUMe469zNE>
Subject: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of-possession-02
X-BeenThere: ace@ietf.org
X-Mailman-Version: 2.1.26
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: Fri, 22 Jun 2018 13:36:23 -0000

Hi Jim,

I would like to comment on this issue.

-----
> > 14.  I have real problems w/ the use of a KID for POP identification.  It
may
> identify the wrong key or, if used for granting access, may have problems
w/
> identity collisions.  These need to be spelt out someplace to help people
> tracking down questions of why can't I verify w/ this CWT, I know it's
right.
>
> The Key ID is a hint to help identify which PoP key to use.  Yes, if a Key
ID is
> sent that doesn't correspond to the right PoP key, failures may occur.  I
view
> that as usage bug - not a protocol problem.  If keys aren't consistently
known
> and identified by both parties, there are lots of things that can go
wrong, and
> this is only one such instance.  That said, I can try to say something
about the
> need for keys to be consistently and known by both parties, if you think
that
> would help.

> My problem is that if there are two different people with the same Key ID,
either intentionally or unintentionally, then using the key ID to identify
the key may allow the other person to masquerade as the first person.  I am
unworried about the instance of a failure to get a key based on a key id.
That is not the problem you are proposing to address.

-----

I think we should document this issue. Here is some text proposal that could go into a
separate operational consideration section (or into the security consideration section instead).

"
- Operational Considerations

The use of CWTs with proof-of-possession keys requires additional information to be shared
between the involved parties in order to ensure correct processing. The recipient needs to be
able to use credentials to verify the authenticity, integrity and potentially the confidentiality of
the CWT and its content. This requires the recipient to know information about the issuer.
Like-wise there needs to be an upfront agreement between the issuer and the recipient about
the claims that need to be present and what degree of trust can be put into those.

When an issuer creates a CWT containing a key id claim, it needs to make sure that it does not
issue another CWT containing the same key id with a different content, or for a different subject,
within the lifetime of the CWTs, unless intentionally desired. Failure to do so may allow one party
to impersonate another party with the potential to gain additional privileges.
"


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