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

Jim Schaad <> Fri, 29 June 2018 05:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 83F12130E36; Thu, 28 Jun 2018 22:57:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 0jl2E-AQTjkA; Thu, 28 Jun 2018 22:57:34 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3391A129C6A; Thu, 28 Jun 2018 22:57:33 -0700 (PDT)
Received: from Jude ( by ( with Microsoft SMTP Server (TLS) id 15.0.1347.2; Thu, 28 Jun 2018 22:54:00 -0700
From: Jim Schaad <>
To: 'Samuel Erdtman' <>
CC: 'Samuel Erdtman' <>, <>, 'Mike Jones' <>, 'Hannes Tschofenig' <>, 'Benjamin Kaduk' <>, 'ace' <>
References: <> <> <> <> <027401d40b93$6b73b470$425b1d50$> <> <00e701d40d6e$c09b3db0$41d1b910$> <> <013301d40de7$39660220$ac320660$> <>
In-Reply-To: <>
Date: Fri, 29 Jun 2018 07:57:00 +0200
Message-ID: <027e01d40f6e$01e326b0$05a97410$>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_027F_01D40F7E.C56DF280"
X-Mailer: Microsoft Outlook 16.0
Content-Language: en-us
Thread-Index: AQJmkbQj82tMYvZUbCUZIMhlVFE4oQHH3wOzAp0N2z4AwuijgAIaIIxmAaqrEKcBY2dBsQHPZ3YMAaTEJ9wBbSlX/qLXY+sw
X-Originating-IP: []
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, 29 Jun 2018 05:57:38 -0000



From: Samuel Erdtman <> 
Sent: Thursday, June 28, 2018 5:40 PM
To: Jim Schaad <>
Cc: Samuel Erdtman <>om>;; Mike Jones <>om>; Hannes Tschofenig <>om>; Benjamin Kaduk <>du>; ace <>
Subject: Re: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of-possession-02


Thanks for the clarifying comments here comes a few replies since I will not be able to join the IETF meeting :-(


see inline


On Wed, Jun 27, 2018 at 9:19 AM, Jim Schaad < <> > wrote:



From: Samuel Erdtman < <> > 
Sent: Wednesday, June 27, 2018 8:18 AM
To: Jim Schaad < <> >
Cc: Hannes Tschofenig < <> >; Benjamin Kaduk < <> >; Mike Jones < <> >; <> ; <> 
Subject: Re: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of-possession-02


Jim, are you saying that if the client can pick the key identifier and if it has seen a key identifier of another client it could request a PoP token with the observed key-id and the observed subject but with an new key. 
I guess this is a potential scenario that could be worth mentioning in security considerations.

[JLS] No I am not assuming that the observed subject is also chosen by the attacker, just the observed key-id.

OK, see comments below on why I think the attacker would have to know the subject too.


If we look at ACE-OAuth there are as far as I can tell a few things that makes this a hard attack to do.

When the client makes the token request it is authenticated.

[JLS] Unclear why this is relevant.  I am asking for this new token as myself.

In my opinion authentication of the client will significantly lessen the number of attackers since they need to have some initial access. i.e. no absolute protection but one layer.


[JLS] I am already in the system and have full credentials.  I am trying to get the same permissions that you have.  Not all attackers are external to the system.


And with the subject being the authenticated client cannot control what goes into the cwt as subject

[JLS] You are making an assumption that a) the subject is actually going to be populated rather than be left empty and thus be anonymous and 2) that the resource server is going to make any enforcement based on the subject.  I expect it to be done based on audience and scope only.

My assumption is that RS will uniquely identify the key with Issuer, Subject and Key-ID. If subject is omitted for an anonymous token I assume that the AS (Issuer) makes sure the key-id is unique during the lifetime of the token. If issuer is left out I assume it is identified by the CWT signing key or that the RS only accept tokens from one AS.

When the key is found and has been used to authenticate the user of the token I too expect that the RS does the authorization based on audience and scope.


[JLS] I am not sure how this is going to work.  As the CS I do a DTLS connect to the RS and put the Key-ID into the PSK identifier field.  The RS now has the Key-ID, but does not have the Issuer or Subject information.  Are you using this triple value binding someplace else?


Since the cwt with the PoP key is signed there is no way for the attacking client to retro-fit the token to suit its needs e.g. change subject or key-id.

[JLS] I am asking for a new token not trying to modify an existing token so this is not especially relevant.

Based on my previous statement you should not be able to impersonate the observed key with a token issued for you.


[JLS] Given two anonymous subject fields, the subject would not be a differentiator

Finally I think it is preferable if the server selects key identifier. 

[JLS] I would agree, however if you have two AS that are operating in the same authorization range and are not tightly linked then this is not easy for doing an additional privilege token where the POP is identified by the KID.  This is even harder if an RS is going to allow two different AS from different scopes to be authoritative as they would never coordinate together.

In the case of RS accepting tokens from multiple ASs I think the RS must use the issuer (in the CWT) to do key lookup.


[JLS] That may be true, however I have still not seen how to do the processing of getting a supplementary CWT and thus don’t know how it works.  I was assuming that the Client would send a KID as part of it’s request to the AS so one now has interesting questions of how the server does the assignment.  Also having a KID as part of an asymmetric key is probably going to be normal operating procedure so this is another case where the Client is providing one.




Best regards

On Tue, 26 Jun 2018 at 18:57, Jim Schaad < <> > wrote:


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.


> -----Original Message-----
> From: Hannes Tschofenig < <> >
> Sent: Tuesday, June 26, 2018 6:09 PM
> To: Jim Schaad < <> >; 'Benjamin Kaduk'
> < <> >; 'Mike Jones' < <> >
> Cc: <> ; <> 

> 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
> is in the CWT-PoP but rather use it as input in a key derivation function.
> 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
> 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 [ <> ]
> Sent: 24 June 2018 10:15
> To: 'Benjamin Kaduk'; 'Mike Jones'
> Cc: Hannes Tschofenig; <> ;
> <> 

> 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
> optionally have an unprotected KID value used to filter the set of keys on
> 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
> 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
> reference the same secret are going to be used for permissions even if
> 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
> 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 < <> >
> > Sent: Saturday, June 23, 2018 11:30 PM
> > To: Mike Jones < <> >
> > Cc: Hannes Tschofenig < <> >; Jim Schaad
> > < <> >;
> > <> ;
> > <> 
> > 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
> please notify the sender immediately and do not disclose the contents to
> other person, use it for any purpose, or store or copy the information in
> medium. Thank you.

Ace mailing list <>