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 ka...@athena.mit.edu, ka...@zone.mit.edu, and ka...@grand.central.org
but apply different levels of trust and privilege to them. A more
poignant example would be the case of b...@freebsd.org and
b...@athena.mit.edu, 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
On Tue, Jun 26, 2018 at 04:08:42PM +0000, Hannes Tschofenig wrote:
> 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
