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:ka...@mit.edu]
Sent: 26 June 2018 17:14
To: Hannes Tschofenig
Cc: Mike Jones; Jim Schaad; draft-ietf-ace-cwt-proof-of-possess...@ietf.org; 
ace@ietf.org
Subject: Re: [Ace] Key IDs ... RE: WGLC on 
draft-ietf-ace-cwt-proof-of-possession-02

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 +0000, Hannes Tschofenig wrote:
> 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 2018 17:00
> To: Hannes Tschofenig
> Cc: Mike Jones; Jim Schaad; draft-ietf-ace-cwt-proof-of-possess...@ietf.org; 
> ace@ietf.org
> Subject: Re: [Ace] Key IDs ... RE: WGLC on 
> draft-ietf-ace-cwt-proof-of-possession-02
>
> On Tue, Jun 26, 2018 at 08:53:57AM +0000, 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 usages.
> > The key in the Kerberos ticket is similar to the PoP key in our discussion.
> >
> > 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
> 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.

_______________________________________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Reply via email to