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

Jim Schaad <ietf@augustcellars.com> Wed, 27 June 2018 07:59 UTC

Return-Path: <ietf@augustcellars.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 9D645130E87; Wed, 27 Jun 2018 00:59:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 r0_fXAThNZBI; Wed, 27 Jun 2018 00:59:02 -0700 (PDT)
Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7AEA31277D2; Wed, 27 Jun 2018 00:59:01 -0700 (PDT)
Received: from Jude (128.93.88.230) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Wed, 27 Jun 2018 00:55:29 -0700
From: Jim Schaad <ietf@augustcellars.com>
To: 'Hannes Tschofenig' <Hannes.Tschofenig@arm.com>, 'Benjamin Kaduk' <kaduk@mit.edu>, 'Mike Jones' <Michael.Jones@microsoft.com>
CC: <draft-ietf-ace-cwt-proof-of-possession@ietf.org>, <ace@ietf.org>
References: <VI1PR0801MB2112C4D6D3CED7C15D9AE886FA750@VI1PR0801MB2112.eurprd08.prod.outlook.com> <20180622204344.GP64617@kduck.kaduk.org> <MW2PR00MB02986BC1E87754046C8CDC6AF5750@MW2PR00MB0298.namprd00.prod.outlook.com> <20180623212956.GE99689@kduck.kaduk.org> <027401d40b93$6b73b470$425b1d50$@augustcellars.com> <VI1PR0801MB2112611C298A9E68AC9B2402FA490@VI1PR0801MB2112.eurprd08.prod.outlook.com> <00e701d40d6e$c09b3db0$41d1b910$@augustcellars.com> <VI1PR0801MB21127A270BDC3D28363ACEDDFA480@VI1PR0801MB2112.eurprd08.prod.outlook.com>
In-Reply-To: <VI1PR0801MB21127A270BDC3D28363ACEDDFA480@VI1PR0801MB2112.eurprd08.prod.outlook.com>
Date: Wed, 27 Jun 2018 09:58:29 +0200
Message-ID: <013c01d40dec$a4c6c540$ee544fc0$@augustcellars.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Content-Language: en-us
Thread-Index: AQJmkbQj82tMYvZUbCUZIMhlVFE4oQHH3wOzAp0N2z4AwuijgAIaIIxmAaqrEKcBY2dBsQIhpQR+ousoYRA=
X-Originating-IP: [128.93.88.230]
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/ouTxM3xlx_JFLICDqZsBMSvlESk>
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: Wed, 27 Jun 2018 07:59:04 -0000

I agree that some F2F on this would be useful.

> -----Original Message-----
> From: Hannes Tschofenig <Hannes.Tschofenig@arm.com>;
> Sent: Wednesday, June 27, 2018 9:32 AM
> To: Jim Schaad <ietf@augustcellars.com>;; 'Benjamin Kaduk'
> <kaduk@mit.edu>;; 'Mike Jones' <Michael.Jones@microsoft.com>;
> Cc: draft-ietf-ace-cwt-proof-of-possession@ietf.org; ace@ietf.org
> Subject: RE: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of-
> possession-02
> 
> Hi Jim,
> 
> It sounds like we need some high bandwidth face-to-face time on this issue
> in Montreal.
> This is an interesting issue and IMHO reaches outside the CWT PoP
> document.
> 
> Ciao
> Hannes
> 
> -----Original Message-----
> From: Jim Schaad [mailto:ietf@augustcellars.com]
> Sent: 26 June 2018 18:57
> To: Hannes Tschofenig; 'Benjamin Kaduk'; 'Mike Jones'
> Cc: draft-ietf-ace-cwt-proof-of-possession@ietf.org; ace@ietf.org
> Subject: RE: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of-
> possession-02
> 
> Hannes,
> 
> My worry is not about implementers getting this correct and picking random
> key ids.  My worry is about an attacker seeing the key id of somebody and
> trying to use it either with the same or a different AS and getting a key
and
> then getting permissions associated with the initial key that they should
not
> be doing.
> 
> This is about an attack not about getting things to generally work right.
> 
> Jim
> 
> 
> > -----Original Message-----
> > From: Hannes Tschofenig <Hannes.Tschofenig@arm.com>;
> > Sent: Tuesday, June 26, 2018 6:09 PM
> > To: Jim Schaad <ietf@augustcellars.com>;; 'Benjamin Kaduk'
> > <kaduk@mit.edu>;; 'Mike Jones' <Michael.Jones@microsoft.com>;
> > Cc: draft-ietf-ace-cwt-proof-of-possession@ietf.org; ace@ietf.org
> > Subject: RE: [Ace] Key IDs ... RE: WGLC on
> > draft-ietf-ace-cwt-proof-of-
> > possession-02
> >
> > Hi Jim,
> >
> > you are essentially proposing that we should not directly use the key
> > id
> that
> > is in the CWT-PoP but rather use it as input in a key derivation
function.
> The
> > details of that key derivation function are specified outside the
> > CWT-POP document and most likely in the context of the various profiles.
> > Your proposals below suggest to use, among other things, the session
> > key
> as
> > input to that function. That sounds pretty straight forward but raises
> > the question why we fail to trust the implementer to create random key
> > ids but then still trust them to create random keys.
> >
> > That's fine for me nevertheless.
> >
> > Ciao
> > Hannes
> >
> > -----Original Message-----
> > From: Jim Schaad [mailto:ietf@augustcellars.com]
> > Sent: 24 June 2018 10:15
> > To: 'Benjamin Kaduk'; 'Mike Jones'
> > Cc: Hannes Tschofenig;
> > draft-ietf-ace-cwt-proof-of-possession@ietf.org;
> > ace@ietf.org
> > Subject: RE: [Ace] Key IDs ... RE: WGLC on
> > draft-ietf-ace-cwt-proof-of-
> > possession-02
> >
> > Thinking things through, I would be more comfortable with something
> > like the
> > following:
> >
> > 1.  Create a confirmation called 'computed key id'.  This has two
> > basic
> > values:  What is the computation method?  What is the proof value?
> > You
> can
> > optionally have an unprotected KID value used to filter the set of
> > keys on
> the
> > RS down to a reasonable set to enumerate (hopefully one).
> >
> > 2.  For RPK and TLS:  Define a method called hash of SPKI which has a
> > hash method as a parameter.  Given that this can be computed
> > independently by all entities based on a Public Key value and it will
> > be unique then you
> have a
> > key identifier that will not have collisions independent of who issues
> > the CWT.
> >
> > 3.  For PSK and TLS:  Define a method which takes some parameters
> including
> > the key value, the CWT issuer identity and perhaps some random string
> > and compute a proof of possession value on the PSK.
> >
> > 4.  For PSK and OSCORE: Define a similar method the question would be
> > what the key value is to be used but that can be defined as part of
> > OSCORE
> >
> > When using the keys for TLS
> >
> > For RPK the key is carried in the handshake and the server/client can
> > generate the computed key id and compare it to what the AS distributed.
> > The server can identify which CWTs are applicable by either comparison
> > of the RPKs or the computed key id.  This means you have a high
> > probability that you will not make a mistake and match to the wrong key.
> >
> > For PSK the identifier is carried in the handshake which is used to
> > look
> up a
> > key value and the handshake is performed.  By matching computed key
> > ids with the secret value one can ensure to a high probably that only
> > CWTs
> that
> > reference the same secret are going to be used for permissions even if
> they
> > come from different AS entities.
> >
> > For OSCORE it is similar, the identifier is used to look up a key
> > value
> and by
> > decrypting the CWT the key value is proofed.  You then match computed
> > key ids in the same manner.
> >
> > If you really want to have something that is not cryptographically
> computed
> > and point to something else, then it makes more sense to me to
> > reference a CWT issued by the same entity and say "use the same
> > conformation method as this CWT does".
> >
> > jim
> >
> > > -----Original Message-----
> > > From: Benjamin Kaduk <kaduk@mit.edu>;
> > > Sent: Saturday, June 23, 2018 11:30 PM
> > > To: Mike Jones <Michael.Jones@microsoft.com>;
> > > Cc: Hannes Tschofenig <Hannes.Tschofenig@arm.com>;; Jim Schaad
> > > <ietf@augustcellars.com>;;
> > > draft-ietf-ace-cwt-proof-of-possession@ietf.org;
> > > ace@ietf.org
> > > Subject: Re: [Ace] Key IDs ... RE: WGLC on
> > > draft-ietf-ace-cwt-proof-of-
> > > possession-02
> > >
> > > On Fri, Jun 22, 2018 at 08:48:35PM +0000, Mike Jones wrote:
> > > > See my note just now proposing this text to Jim:
> > > >
> > > > "Likewise, if PoP keys are used for multiple different kinds of
> > > > CWTs in
> > an
> > > application and the PoP keys are identified by Key IDs, care must be
> > > taken
> > to
> > > keep the keys for the different kinds of CWTs segregated so that an
> > attacker
> > > cannot cause the wrong PoP key to be used by using a valid Key ID
> > > for the wrong kind of CWT."
> > > >
> > > > As long as the PoP keys for different contexts are kept
> > > > segregated, Key
> > ID
> > > collisions or reuse cause no problems.
> > >
> > > If we trust everyone to implement things properly.  We should
> > > probably
> > only
> > > take that risk if we get some other benefit from it, though.  Jim
> > mentioned
> > > (off-list?) a scenario involving giving the same client additional
> > privileges, and
> > > of course we can gain some simplicity savings if we don't need to
> > > enforce global key-id uniqueness (for appropriate values of "global").
> > > So this
> > may
> > > well be the right thing to do; I just don't think it's without
> > > tradeoffs
> > as your
> > > text seems to imply.
> > >
> > > -Ben
> >
> > 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.
> 
> 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.