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

Benjamin Kaduk <kaduk@mit.edu> Fri, 22 June 2018 20:43 UTC

Return-Path: <kaduk@mit.edu>
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 E8040130EF4; Fri, 22 Jun 2018 13:43:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] 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 yewJGUVTFFxQ; Fri, 22 Jun 2018 13:43:51 -0700 (PDT)
Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) (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 11D8C130EFF; Fri, 22 Jun 2018 13:43:50 -0700 (PDT)
X-AuditID: 12074425-793ff700000042ec-28-5b2d5f86ba0b
Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id 1C.78.17132.68F5D2B5; Fri, 22 Jun 2018 16:43:50 -0400 (EDT)
Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id w5MKhnbR003901; Fri, 22 Jun 2018 16:43:49 -0400
Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id w5MKhi6U008647 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 22 Jun 2018 16:43:47 -0400
Date: Fri, 22 Jun 2018 15:43:44 -0500
From: Benjamin Kaduk <kaduk@mit.edu>
To: Hannes Tschofenig <Hannes.Tschofenig@arm.com>
Cc: 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>, "ace@ietf.org" <ace@ietf.org>
Message-ID: <20180622204344.GP64617@kduck.kaduk.org>
References: <VI1PR0801MB2112C4D6D3CED7C15D9AE886FA750@VI1PR0801MB2112.eurprd08.prod.outlook.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <VI1PR0801MB2112C4D6D3CED7C15D9AE886FA750@VI1PR0801MB2112.eurprd08.prod.outlook.com>
User-Agent: Mutt/1.9.1 (2017-09-22)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmphleLIzCtJLcpLzFFi42IRYrdT0W2L1402WLeI3eL7tx5mi5//rjNb 3Jxxisli9fTvbBZ7p31icWD1WDNvDaPHxjnT2TyWLPnJ5NG64y97AEsUl01Kak5mWWqRvl0C V0bj6j/sBdv5Knp2PGBsYDzC3cXIySEhYCJx5tcfxi5GLg4hgcVMEpen/2aGcDYySmyaP4MN wrnKJPFyZQc7SAuLgKrEnmvTWEBsNgEViYbuy8wgtoiAocTe5kOsIA3MAl8YJT48OMAKkhAW CJN48mAt0A4ODl6gfdM/lICEhQQSJI5Mmw02k1dAUOLkzCdgM5kFtCRu/HvJBFLOLCAtsfwf B0iYUyBR4sG+L0wgtqiAssTevkPsExgFZiHpnoWkexZC9wJG5lWMsim5Vbq5iZk5xanJusXJ iXl5qUW6Fnq5mSV6qSmlmxjBge2iuoNxzl+vQ4wCHIxKPLwaX3WihVgTy4orcw8xSnIwKYny 3qwACvEl5adUZiQWZ8QXleakFh9ilOBgVhLhdXsKlONNSaysSi3Kh0lJc7AoifPmLGKMFhJI TyxJzU5NLUgtgsnKcHAoSfAaxulGCwkWpaanVqRl5pQgpJk4OEGG8wAN3xMLVMNbXJCYW5yZ DpE/xagoJc57ASQhAJLIKM2D6wUlHons/TWvGMWBXhHmbQZZwQNMWnDdr4AGMwENrm7WAhlc koiQkmpgnDVvreYrG9+sCzH/+l194i+fstGbvKXb0clus3ryrddl8wzWiezxOqirvUdDPuND x+t7cb8Cdb6x/ErdJO123+mDGPOf+PD8dvYJ5ge9fil2txyQjGwQ4fK+6f3jx9OSE+uv98d2 NfWmFx68/P+3K7Oh+V+2xgd3DlU+m+CZcjBY6/L9uMn/lFiKMxINtZiLihMB8Hps8hcDAAA=
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/OqDmCSYL9BHI38-6-KiFU1_DWOM>
Subject: Re: [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 20:43:53 -0000

On Fri, Jun 22, 2018 at 01:36:16PM +0000, Hannes Tschofenig wrote:
> Hi Jim,
> 
> 
> > 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.
> "

When would this be "intentionally desired"?  It seems like there would be
better ways to share authorization between parties than to issue such
duplicate CWTs.

-Ben