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

Benjamin Kaduk <> Fri, 22 June 2018 20:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E8040130EF4; Fri, 22 Jun 2018 13:43:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.201
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id yewJGUVTFFxQ; Fri, 22 Jun 2018 13:43:51 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 11D8C130EFF; Fri, 22 Jun 2018 13:43:50 -0700 (PDT)
X-AuditID: 12074425-793ff700000042ec-28-5b2d5f86ba0b
Received: from ( []) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id 1C.78.17132.68F5D2B5; Fri, 22 Jun 2018 16:43:50 -0400 (EDT)
Received: from (OUTGOING-AUTH-1.MIT.EDU []) by (8.13.8/8.9.2) with ESMTP id w5MKhnbR003901; Fri, 22 Jun 2018 16:43:49 -0400
Received: from ( []) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by (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 <>
To: Hannes Tschofenig <>
Cc: Jim Schaad <>, "'Mike Jones'" <>, "" <>, "" <>
Message-ID: <>
References: <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
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: <>
Subject: Re: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of-possession-02
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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.