Subject: Re: Self-authenticating non-domain realms

From: Sam Hartman <[email-masked]>
Date: Fri, 01 Sep 2006 16:14:20 -0400

>>>>> "Paul" == Paul Leach <[email-masked]> writes:

    Paul> However, if the KDC returns a cert with a realm name for
    Paul> which a mapping currently exists, but the key is wrong, then
    Paul> there's a big problem. How can you tell if the key has been
    Paul> rolled for (for good crypto hygiene), or if an attacker is
    Paul> trying to spoof you? Proving knowledge of the old key is not
    Paul> useful -- the key may have been rolled precisely because it
    Paul> was possible it had been disclosed or that enough time had
    Paul> passed that it might have been cracked.

    Paul> In general, I think this is a fundamental problem with any
    Paul> simple leap-of-faith protocol: either it doesn't permit key
    Paul> rollover, or, if it does, every connection is potentially a
    Paul> leap-of-faith, not just the first one.

It's certainly a fundamental difference between TTP security and LOF
security, but I'm not sure it is a flaw so much as a lower level of security.

To me, it seems like you always accept key updates if the server knows
the current key.  One of two things is happening: you are receiving an
update from the correct server or you are receiving it from an
attacker.  If you are receiving it from the server it is clearly good
to accept.  If you are receiving from the attacker, well, the key you
are currently using is compromised so you should stop using it.
Ideally you'd stop using any key and flag a security problem but you
don't have enough information to do that.  At least by accepting an
attacker key you ncrease the probability that a future connection will
hit the real server, and get the user's attention.

The option of discouraging key updates seems far worse and is my
biggest complaint about ssh.

--Sam

---

From: Sam Hartman <[email-masked]>
Date: Fri, 01 Sep 2006 16:20:09 -0400

>>>>> "Paul" == Paul Leach <[email-masked]> writes:

    Paul> If the realm name isn't used by and meaningful to humans,
    Paul> then I would argue it lacks many of the characteristics of a
    Paul> name (for security purposes), and it doesn't matter if it
    Paul> gets spoofed.

Well, I view the realm name as an internal identifier that binds a
display name to a set of principals and KDCs.  because I may have
conflicts in display names I want realm names that are guaranteed to
be unique.  The Kerberos implementations don't deal well if you have
conflicts in realm names. My goal is that users never see the realm
name, only the display name, and that you deal with the leap of faith
issues at that level.

    Paul> Could you say a little more about scenarios where you expect
    Paul> this to be used?

    Paul> E.g., if this is for a peer-to-peer scenario, then maybe the
    Paul> realm name is "hartmans.at.mit.edu" -- i.e., the name I look
    Paul> for in a cert is derived from your email name if I'm trying
    Paul> to connect to your machine.

Email addresses are not human friendly names either.  A human friendly
name is something like "Sam's Laptop" or "Sam hartman Computer" or the
like.  Some people will use display names that look like email
addresses.