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

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 22 Jun 2018 13:36:16 +0000

Hi Jim,

I would like to comment on this issue.

-----
> > 14.  I have real problems w/ the use of a KID for POP identification.  It
may
> identify the wrong key or, if used for granting access, may have problems
w/
> identity collisions.  These need to be spelt out someplace to help people
> tracking down questions of why can't I verify w/ this CWT, I know it's
right.
>
> The Key ID is a hint to help identify which PoP key to use.  Yes, if a Key
ID is
> sent that doesn't correspond to the right PoP key, failures may occur.  I
view
> that as usage bug - not a protocol problem.  If keys aren't consistently
known
> and identified by both parties, there are lots of things that can go
wrong, and
> this is only one such instance.  That said, I can try to say something
about the
> need for keys to be consistently and known by both parties, if you think
that
> would help.

> 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.
"

Ciao
Hannes

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.

---

From: Jim Schaad <[email-masked]>
Date: Fri, 22 Jun 2018 07:58:38 -0700

That language works if you assume that there is only one CWT that an RS will
look to.  If there are multiple CWTs then one needs coordination language
between them.

> -----Original Message-----
> From: Hannes Tschofenig <[email-masked]>
> Sent: Friday, June 22, 2018 6:36 AM
> To: Jim Schaad <[email-masked]>; 'Mike Jones'
> <[email-masked]>; draft-ietf-ace-cwt-proof-of-
> [email-masked]
> Cc: [email-masked]
> Subject: Key IDs ... RE: [Ace] WGLC on draft-ietf-ace-cwt-proof-of-
> possession-02
> 
> Hi Jim,
> 
> > identity collisions.  These need to be spelt out someplace to help
> > people tracking down questions of why can't I verify w/ this CWT, I
> > know it's
> right.
> >
the
> key may allow the other person to masquerade as the first person.  I am
> 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).
> 
> "
> 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.
> "
> 
> 
> Ciao
> Hannes
> 
> 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.

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 22 Jun 2018 15:43:44 -0500

> 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

---

From: Mike Jones <[email-masked]>
Date: Fri, 22 Jun 2018 20:44:20 +0000

I think you're looking for language something along these lines, right 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."

				-- Mike

-----Original Message-----
From: Jim Schaad <[email-masked]> 
Sent: Friday, June 22, 2018 7:59 AM
To: Hannes Tschofenig <[email-masked]>; Mike Jones <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: RE: Key IDs ... RE: [Ace] WGLC on draft-ietf-ace-cwt-proof-of-possession-02

That language works if you assume that there is only one CWT that an RS will look to.  If there are multiple CWTs then one needs coordination language between them.

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.
could
> go into a separate operational consideration section (or into the 
> security consideration section instead).
> 
> "
> 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
and
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,
privileges.
recipient,
any
any

---

From: Mike Jones <[email-masked]>
Date: Fri, 22 Jun 2018 20:48:35 +0000

See my note just now proposing this text to Jim:

As long as the PoP keys for different contexts are kept segregated, Key ID collisions or reuse cause no problems.

				-- Mike

-----Original Message-----
From: Benjamin Kaduk <[email-masked]> 
Sent: Friday, June 22, 2018 1:44 PM
To: Hannes Tschofenig <[email-masked]>
Cc: Jim Schaad <[email-masked]>; Mike Jones <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of-possession-02

On Fri, Jun 22, 2018 at 01:36:16PM +0000, Hannes Tschofenig wrote:
> 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.
> could go into a separate operational consideration section (or into the security consideration section instead).
> 
> "
> 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.
> and the recipient about the claims that need to be present and what degree of trust can be put into those.
> 
> 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

---

From: Jim Schaad <[email-masked]>
Date: Sat, 23 Jun 2018 18:03:40 +0200

> Sent: Friday, June 22, 2018 10:44 PM
> Cc: Jim Schaad <[email-masked]>; 'Mike Jones'
> [email-masked]; [email-masked]
> > person.  I am unworried about the instance of a failure to get a key
based
> on a key id.
> > 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.
> > 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.
> > "
> 

One case where this is desired is if you issue a second CWT with additional
permissions for a client and you want to tie it to the same key.  You could
either duplicate the key or just reference it by ID.

Jim

---

From: Jim Schaad <[email-masked]>
Date: Sat, 23 Jun 2018 18:05:27 +0200

No not really, Hannes's language is much closer to what I am looking for.  I
don't care if they are different kinds of CWTs.  I care about impersonation.

> From: Mike Jones <[email-masked]>
> To: Jim Schaad <[email-masked]>; Hannes Tschofenig
> <[email-masked]>; draft-ietf-ace-cwt-proof-of-
> [email-masked]
> Cc: [email-masked]
> "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."
> 
> 				-- Mike
> 
> To: Hannes Tschofenig <[email-masked]>; Mike Jones
> > identify

---

From: Mike Jones <[email-masked]>
Date: Sat, 23 Jun 2018 16:06:42 +0000

The sentence I sent was in addition to Hannes language to address the multiple CWT case discussed in the thread - not a replacement for it.

				-- Mike

-----Original Message-----
From: Jim Schaad <[email-masked]> 
Sent: Saturday, June 23, 2018 9:05 AM
To: Mike Jones <[email-masked]>; Hannes Tschofenig <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: RE: Key IDs ... RE: [Ace] WGLC on draft-ietf-ace-cwt-proof-of-possession-02

No not really, Hannes's language is much closer to what I am looking for.  I don't care if they are different kinds of CWTs.  I care about impersonation.

> Subject: RE: Key IDs ... RE: [Ace] WGLC on 
> draft-ietf-ace-cwt-proof-of-
> possession-02
> 
> "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
attacker
> cannot cause the wrong PoP key to be used by using a valid Key ID for 
> the wrong kind of CWT."
> 
> 				-- Mike
> 
> Subject: RE: Key IDs ... RE: [Ace] WGLC on 
> draft-ietf-ace-cwt-proof-of-
> possession-02
> 
> That language works if you assume that there is only one CWT that an 
> RS
will
> look to.  If there are multiple CWTs then one needs coordination 
> language between them.
> 
> > > people tracking down questions of why can't I verify w/ this CWT, 
> > > I know it's
> > right.
> > >
> > am unworried about the instance of a failure to get a key based on a 
> > key
id.
> > unless intentionally desired. Failure to do so may allow one party

---

From: Benjamin Kaduk <[email-masked]>
Date: Sat, 23 Jun 2018 16:29:57 -0500

> 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

---

From: Jim Schaad <[email-masked]>
Date: Sun, 24 Jun 2018 10:14:43 +0200

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

> Sent: Saturday, June 23, 2018 11:30 PM
> To: Mike Jones <[email-masked]>
> Cc: Hannes Tschofenig <[email-masked]>; Jim Schaad
> <[email-masked]>; [email-masked];
> [email-masked]
to
attacker
> > As long as the PoP keys for different contexts are kept segregated, Key
ID
> collisions or reuse cause no problems.
> 
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.

---

From: Ludwig Seitz <[email-masked]>
Date: Mon, 25 Jun 2018 09:24:24 +0200

>> tracking down questions of why can't I verify w/ this CWT, I know it's

I just wanted to note that we inherited that issue from RFC 7800, does 
someone recall what the security considerations were in that case?

Perhaps a variant of Hannes' text comes closer to what Jim is looking for:

"

...

When an issuer creates a CWT containing a key id claim, it is not 
acceptable to issue another CWT containing the same key id, unless they 
both are for the same subject and for the same audience (e.g. providing 
additional privileges for the subject).
"

/Ludwig

-- 
Ludwig Seitz, PhD
Security Lab, RISE SICS
Phone +46(0)70-349 92 51

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 26 Jun 2018 08:53:57 +0000

Ben,

I was wondering whether the situation is any different in Kerberos. If the KDC creates tickets with a session key included then it needs to make sure that it does not create the same symmetric key for different usages.
The key in the Kerberos ticket is similar to the PoP key in our discussion.

Are we aware of key collision in Kerberos?

Ciao
Hannes

-----Original Message-----
From: Benjamin Kaduk [mailto:[email-masked]]
Sent: 23 June 2018 23:30
To: Mike Jones
Cc: Hannes Tschofenig; Jim Schaad; [email-masked]; [email-masked]
Subject: Re: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of-possession-02

-Ben

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 26 Jun 2018 10:00:04 -0500

> Are we aware of key collision in Kerberos?

I don't believe key collision is an issue in Kerberos.  Long-term keys
(which are not what we're talking about here) are identified by a principal
name, encryption type, and version number.  Session keys that are contained
within tickets (and returned to the client in the KDC-REP) are random, so
even if we are only using the birthday bound we're still in pretty good
shape.  The modern enctypes tend to use subsession keys generated by the
client and/or server as well as the KDC-generated session key, which
provides further binding to the current session.

Does that answer your question?

-Ben

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 26 Jun 2018 15:12:52 +0000

It does answer my question, Ben.

This begs the question why the collision of session keys is suddenly a problem in the ACE context when it wasn't a problem so far. Something must have changed.

Ciao
Hannes

-----Original Message-----
From: Benjamin Kaduk [mailto:[email-masked]]
Sent: 26 June 2018 17:00
To: Hannes Tschofenig
Cc: Mike Jones; Jim Schaad; [email-masked]; [email-masked]
Subject: Re: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of-possession-02

-Ben

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 26 Jun 2018 10:14:16 -0500

I thought we were worried about collision of key *identifiers*, which were
not necessarily raw keys or hashes thereof.  But it's possible I was not
paying enough attention and got confused.

-Ben

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 26 Jun 2018 16:08:42 +0000

Hi Ben,

You are right. We were talking about the key identifiers.

Let me still stick with the Kerberos example. In that context this would mean that the KDC stores multiple accounts in the database that point to the same principal name. Have you seen that happening?
Re-using the same principle name over time as identifier get recycle when users get retired or otherwise leave the system might be an option. Is this a more likely?

As you see I am trying to find some examples of vulnerabilities in existing systems and I am having a hard time.

Ciao
Hannes

-----Original Message-----
From: Benjamin Kaduk [mailto:[email-masked]]
Sent: 26 June 2018 17:14
To: Hannes Tschofenig
Cc: Mike Jones; Jim Schaad; [email-masked]; [email-masked]
Subject: Re: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of-possession-02

-Ben

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 26 Jun 2018 16:08:43 +0000

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:[email-masked]]
Sent: 24 June 2018 10:15
To: 'Benjamin Kaduk'; 'Mike Jones'
Cc: Hannes Tschofenig; [email-masked]; [email-masked]
Subject: RE: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of-possession-02

jim

to
attacker
ID
privileges, and
may
as your

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 26 Jun 2018 11:46:06 -0500

In Kerberos, the full principal name includes a realm name as well as the
name of the principal itself; this realm would be roughly analogous to an
OAuth Issuer.  There are plenty of case where there are collisions between
the non-realm portion of the Kerberos principal; for example, I control all
of [email-masked], [email-masked], and [email-masked] 
but apply different levels of trust and privilege to them.   A more
poignant example would be the case of [email-masked] and
[email-masked], of which I control the former but not the latter.
There is some potential for actual issues when the GSSAPI is involved,
since the standard way to pick a server ("GSS acceptor") to talk to is to
generate a host-based principal name, e.g., service="host" and
hostname="ssh.dialup.example.com", which does not include Kerberos realm
information (since the GSSAPI does not have such a concept).  The Kerberos
library uses the hostname and some mapping rules/heuristics to pick a
Kerberos realm to use for ssh.dialup.example.com, but if the heuristic is
wrong for a particular case, an attacker could acquire that service
principal in the "wrong" realm, MITM, and appear to make the client connect
successfully.  (Non-MITM'd connections would fail, though, so this is
likely to be detected quickly as a configuration error.)

Within a single realm (and database), there is equivalence between account
and principal name, though there are some occurrences of re-use of the same
principal name when users or machines leave the system and reenter.  There
is usually a broad time separtation for that, though.

-Ben

---

From: Jim Schaad <[email-masked]>
Date: Tue, 26 Jun 2018 18:54:23 +0200

No Ben, you are 100% correct.  This is about identifiers and not session
keys.

> Sent: Tuesday, June 26, 2018 5:14 PM
> Cc: Mike Jones <[email-masked]>; Jim Schaad
paying
> enough attention and got confused.
> 
> -Ben
> 
> > This begs the question why the collision of session keys is suddenly a
> problem in the ACE context when it wasn't a problem so far. Something must
> have changed.
> >
> > Ciao
> > Hannes
> >
> >
> > Cc: Mike Jones; Jim Schaad;
> > [email-masked]; [email-masked]
> > Subject: Re: [Ace] Key IDs ... RE: WGLC on
> > draft-ietf-ace-cwt-proof-of-possession-02
> >
> > > I was wondering whether the situation is any different in Kerberos. If
the
> KDC creates tickets with a session key included then it needs to make sure
> that it does not create the same symmetric key for different usages.
> > (which are not what we're talking about here) are identified by a
> > principal name, encryption type, and version number.  Session keys
> > that are contained within tickets (and returned to the client in the
> > KDC-REP) are random, so even if we are only using the birthday bound
> > we're still in pretty good shape.  The modern enctypes tend to use
> > subsession keys generated by the client and/or server as well as the
> > KDC-generated session key, which provides further binding to the current
> session.
> >
recipient,
any
any

---

From: Jim Schaad <[email-masked]>
Date: Tue, 26 Jun 2018 18:57:19 +0200

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

> Sent: Tuesday, June 26, 2018 6:09 PM
> To: Jim Schaad <[email-masked]>; 'Benjamin Kaduk'
> <[email-masked]>; 'Mike Jones' <[email-masked]>
> Cc: [email-masked]; [email-masked]
> 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.
> 
the
> RS down to a reasonable set to enumerate (hopefully one).
> 
> 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
> 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
> 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.
> 
> CWT issued by the same entity and say "use the same conformation method
> as this CWT does".
> 
> jim
> 
> > <[email-masked]>;
> > > in
> an
> > 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
recipient,
any
any

---

From: Samuel Erdtman <[email-masked]>
Date: Wed, 27 Jun 2018 08:17:48 +0200

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.

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.

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

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.

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

Best regards
//Samuel

---

From: Jim Schaad <[email-masked]>
Date: Wed, 27 Jun 2018 09:19:41 +0200

From: Samuel Erdtman <[email-masked]> 
Sent: Wednesday, June 27, 2018 8:18 AM
To: Jim Schaad <[email-masked]>
Cc: Hannes Tschofenig <[email-masked]>; Benjamin Kaduk <[email-masked]>; Mike Jones <[email-masked]>; [email-masked]; [email-masked]
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.

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.

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

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.

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.

[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.

Best regards
//Samuel

On Tue, 26 Jun 2018 at 18:57, Jim Schaad <[email-masked] <mailto:[email-masked]> > wrote:

Hannes,

Jim

> From: Hannes Tschofenig <[email-masked] <mailto:[email-masked]> >
> To: Jim Schaad <[email-masked] <mailto:[email-masked]> >; 'Benjamin Kaduk'
> <[email-masked] <mailto:[email-masked]> >; 'Mike Jones' <[email-masked] <mailto:[email-masked]> >
> Cc: [email-masked] <mailto:[email-masked]> ; [email-masked] <mailto:[email-masked]> 
that
The
as
> From: Jim Schaad [mailto:[email-masked] <mailto:[email-masked]> ]
> Sent: 24 June 2018 10:15
> Cc: Hannes Tschofenig; [email-masked] <mailto:[email-masked]> ;
> [email-masked] <mailto:[email-masked]> 
the
have a
up a
and by
> > From: Benjamin Kaduk <[email-masked] <mailto:[email-masked]> >
> > To: Mike Jones <[email-masked] <mailto:[email-masked]> >
> > Cc: Hannes Tschofenig <[email-masked] <mailto:[email-masked]> >; Jim Schaad
> > <[email-masked] <mailto:[email-masked]> >;
> > [email-masked] <mailto:[email-masked]> ;
> > [email-masked] <mailto:[email-masked]> 
recipient,
any
any

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 27 Jun 2018 07:32:09 +0000

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:[email-masked]]
Sent: 26 June 2018 18:57
To: Hannes Tschofenig; 'Benjamin Kaduk'; 'Mike Jones'
Cc: [email-masked]; [email-masked]
Subject: RE: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of-possession-02

Hannes,

Jim

that
The
as
the
have a
up a
and by
recipient,
any
any

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 27 Jun 2018 07:32:08 +0000

Samuel, Jim,

We have two cases in ACE-OAuth:

1)      Client provides a key (or a reference to a key) to the AS. It wants the AS to include that key into the PoP token. The key is the long version of the key id*.

2)      Client asks the AS to get a token. In this case the AS creates a key and places that key or key id in the PoP token.

We seem to be worried that these keys / key ids are not unique over the lifetime of the tokens.
The ACE-OAuth document should say that the AS has to make sure that keys and key ids are not re-used over the lifetime of a PoP token, unless this is a desired behaviour.
I don’t think that the CWT PoP token is the right place to discuss this topic.

Ciao
Hannes

*: Here is what the draft says:

“
The proof-of-possession key can also be identified by the use of a
   Key ID instead of communicating the actual key, provided the
   recipient is able to obtain the identified key using the Key ID.
“

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

Best regards
//Samuel

On Tue, 26 Jun 2018 at 18:57, Jim Schaad <[email-masked]<mailto:[email-masked]>> wrote:
Hannes,

Jim

> From: Hannes Tschofenig <[email-masked]<mailto:[email-masked]>>
> To: Jim Schaad <[email-masked]<mailto:[email-masked]>>; 'Benjamin Kaduk'
> <[email-masked]<mailto:[email-masked]>>; 'Mike Jones' <[email-masked]<mailto:[email-masked]>>
> Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
that
The
as
> From: Jim Schaad [mailto:[email-masked]<mailto:[email-masked]>]
> Sent: 24 June 2018 10:15
> Cc: Hannes Tschofenig; [email-masked]<mailto:[email-masked]>;
> [email-masked]<mailto:[email-masked]>
the
have a
up a
and by
> > From: Benjamin Kaduk <[email-masked]<mailto:[email-masked]>>
> > To: Mike Jones <[email-masked]<mailto:[email-masked]>>
> > Cc: Hannes Tschofenig <[email-masked]<mailto:[email-masked]>>; Jim Schaad
> > <[email-masked]<mailto:[email-masked]>>;
> > [email-masked]<mailto:[email-masked]>;
> > [email-masked]<mailto:[email-masked]>
recipient,
any
any

---

From: Jim Schaad <[email-masked]>
Date: Wed, 27 Jun 2018 09:58:29 +0200

I agree that some F2F on this would be useful.

> Sent: Wednesday, June 27, 2018 9:32 AM
and
> then getting permissions associated with the initial key that they should
not
> be doing.
> > Subject: RE: [Ace] Key IDs ... RE: WGLC on
> > details of that key derivation function are specified outside the
> > CWT-POP document and most likely in the context of the various profiles.
> > 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.
> >
> > Cc: Hannes Tschofenig;
> > Subject: RE: [Ace] Key IDs ... RE: WGLC on
> > values:  What is the computation method?  What is the proof value?
> > You
> can
> > 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.
> >
> > 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
> >
> > 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.
> >
> > 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
> > decrypting the CWT the key value is proofed.  You then match computed
> > key ids in the same manner.
> >
> > 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
> >
> > > > "Likewise, if PoP keys are used for multiple different kinds of
> > > > CWTs in
> > an
> > > cannot cause the wrong PoP key to be used by using a valid Key ID
> > > for the wrong kind of CWT."
> > > >
> > > If we trust everyone to implement things properly.  We should
> > > probably
> > only
recipient,
any
any

---

From: Samuel Erdtman <[email-masked]>
Date: Thu, 28 Jun 2018 17:39:52 +0200

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 <[email-masked]> wrote:

>
>
>
>
> *From:* Samuel Erdtman <[email-masked]>
> *Sent:* Wednesday, June 27, 2018 8:18 AM
> *To:* Jim Schaad <[email-masked]>
> *Cc:* Hannes Tschofenig <[email-masked]>; Benjamin Kaduk <
> [email-masked]>; Mike Jones <[email-masked]>;
> *Subject:* Re: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of-
> possession-02
>
>
>
OK, see comments below on why I think the attacker would have to know the
subject too.

> [JLS] Unclear why this is relevant.  I am asking for this new token as
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] 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.

> 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] 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.

> > Subject: RE: [Ace] Key IDs .... RE: WGLC on draft-ietf-ace-cwt-proof-of-
> > possession-02
> >
> > Hi Jim,
> >
> > Subject: RE: [Ace] Key IDs .... RE: WGLC on draft-ietf-ace-cwt-proof-of-
> > possession-02
> >
> hash
> what
> _______________________________________________
> Ace mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ace
>
>

---

From: Jim Schaad <[email-masked]>
Date: Fri, 29 Jun 2018 07:57:00 +0200

From: Samuel Erdtman <[email-masked]> 
Sent: Thursday, June 28, 2018 5:40 PM
To: Jim Schaad <[email-masked]>
Cc: Samuel Erdtman <[email-masked]>; [email-masked]; Mike Jones <[email-masked]>; Hannes Tschofenig <[email-masked]>; Benjamin Kaduk <[email-masked]>; ace <[email-masked]>
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 <[email-masked] <mailto:[email-masked]> > wrote:

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

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

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.

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?

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

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.

Jim

Best regards
//Samuel

Hannes,

Jim

that
The
as

the
have a

up a
and by
recipient,
any
any

_______________________________________________
Ace mailing list
[email-masked] <mailto:[email-masked]> 
https://www.ietf.org/mailman/listinfo/ace

---

From: Samuel Erdtman <[email-masked]>
Date: Fri, 29 Jun 2018 08:09:59 +0200

see inline

On Fri, Jun 29, 2018 at 7:57 AM, Jim Schaad <[email-masked]> wrote:

>
>
>
>
> *From:* Samuel Erdtman <[email-masked]>
> *Sent:* Thursday, June 28, 2018 5:40 PM
> *Cc:* Samuel Erdtman <[email-masked]>; draft-ietf-ace-cwt-proof-of-
> [email-masked]; Mike Jones <[email-masked]>; Hannes
> Tschofenig <[email-masked]>; Benjamin Kaduk <[email-masked]>;
> ace <[email-masked]>
> [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.
>

I agree, but the number of such attackers are fewer and you could revoke
access to such users. It is not perfect but it is better than nothing.

> [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?
>

I would not send the key-id in the PSK identifier I would send the full
token as described in draft-ietf-ace-dtls-authorize (4.1. DTLS Channel
Setup Between C and RS).

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

I agree so the AS (issuer) MUST keep key-id unique for the lifetime of the
token.

> [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.
>
>
>
> Jim
>
>
>
>
>
> Best regards
> //Samuel
>