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

[Jim Schaad <[e-mail]>]

I agree that some F2F on this would be useful.

> -----Original Message-----
> From: Hannes Tschofenig <[e-mail]>
> Sent: Wednesday, June 27, 2018 9:32 AM
> To: Jim Schaad <[e-mail]>; 'Benjamin Kaduk'
> <[e-mail]>; 'Mike Jones' <[e-mail]>
> Cc: [e-mail]; [e-mail]
> 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:[e-mail]]
> Sent: 26 June 2018 18:57
> To: Hannes Tschofenig; 'Benjamin Kaduk'; 'Mike Jones'
> Cc: [e-mail]; [e-mail]
> 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 <[e-mail]>
> > Sent: Tuesday, June 26, 2018 6:09 PM
> > To: Jim Schaad <[e-mail]>; 'Benjamin Kaduk'
> > <[e-mail]>; 'Mike Jones' <[e-mail]>
> > Cc: [e-mail]; [e-mail]
> > 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:[e-mail]]
> > Sent: 24 June 2018 10:15
> > To: 'Benjamin Kaduk'; 'Mike Jones'
> > Cc: Hannes Tschofenig;
> > [e-mail];
> > [e-mail]
> > 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 <[e-mail]>
> > > Sent: Saturday, June 23, 2018 11:30 PM
> > > To: Mike Jones <[e-mail]>
> > > Cc: Hannes Tschofenig <[e-mail]>; Jim Schaad
> > > <[e-mail]>;
> > > [e-mail];
> > > [e-mail]
> > > 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.