On Tue, Jun 26, 2018 at 08:53:57AM +, Hannes Tschofenig wrote:
> 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
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
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
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:ka...@mit.edu]
Sent: 26 June
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
No Ben, you are 100% correct. This is about identifiers and not session
keys.
> -Original Message-
> From: Benjamin Kaduk
> Sent: Tuesday, June 26, 2018 5:14 PM
> To: Hannes Tschofenig
> Cc: Mike Jones ; Jim Schaad
> ; draft-ietf-ace-cwt-proof-of-possess...@ietf.org;
> ace@ietf.org
>
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
On Tue, Jun 26, 2018 at 03:12:52PM +, Hannes Tschofenig wrote:
> It does answer my question, Ben.
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
