Subject: Self-authenticating non-domain realms

From: Sam Hartman <[email-masked]>
Date: Wed, 16 Aug 2006 16:49:48 -0400

Hi.

I need to come up with a new type of kerberos realm under fairly tight
time pressure.  If we are able to come to consensus on a standard
solution, then we'll go with that.  Otherwise, something will be
implemented.  If we go with a standard solution, I definitely expect
it to ship in MIT Kerberos; I'm not sure whether it would be a good
idea for MIT to ship a non-standard solution in our main product.
We'd rather avoid having to think about that.

I don't entirely know what the time line is; definitely we'd need to
have most of the details worked out by November--probably sooner.

So, we want to be able to have realms in cases where there is no DNS
name to use and any DNS names will be unstable.  We want to be able to
confirm that the realm name cannot be spoofed using some cryptographic
technology.  We don't want to specify a specific discovery mechanism
for finding the KDCs in such a realm; that can be configured or can be
specified by a higher level.

The use case is to be able to provide ssh-style leap-of-faith
authentication for Kerberos.

We're assuming that realms are identified by some public key.

In general I'm imagining that responses from such a realm will include
a padata item that proves the identity of the realm.  Reusing parts of
pkinit may be useful here, although we do not want to assume that all
client principals have certs--some of them will have passwords.  It's
not entirely clear that you need any sort of public key if you have no
pkinit principals.  You could depend on your shared key for
authentication; I think that PK will be valuable for preventing
spoofing but am less sure of that than I was previously.  The rest of
this mail assumes you always do want a public key.

I see two basic approaches.

The first is to name realms based on UUIDs.  You would have a realm
name like uuid:548e17f1-6b0b-0410-998a-ba9209702869 .  In this case,
the realm would need to sign an assertion claiming that the realm name
maps to a particular public key.  You would then remember the mapping
from the realm name to public key.  This approach is somewhat simpler
than the next approach when dealing with changing the public key for a
realm.  You would just provide an authenticated list of old public
keys for the realm with the new key.

The other approach is to base the realm name on the hash of a public
key I was thinking something like
pkfp:SHA-1:4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB
.  The advantage of this approach is all you need keep track of is the
realm name.  The disadvantage of this approach is that you need to
rename your realm when you change your public key.  I'm not actually
sure that's a huge disadvantage.  Again, you would want to provide a
mechanism for the signature blob associated with a request to include
the old keys that used to belong to this realm.

I'm interested in thoughts.  I'm particularly interested in whether we
want to do this work in the IETF, whether public keys add anything to
the password case, and on what form of realm name we want.  I'm also
interested in comments about what we want in the binding of the
response to the realm key if we use public keys.

--Sam

---

From: Paul Nelson <[email-masked]>
Date: Wed, 16 Aug 2006 17:23:22 -0500

All certs have an issuer name.  Why not just use the kdc certificate's
issuer name as the domain name:
    cn=mydomain ca-1,cn=mydomain root, dc=mydomain,dc=org
This should be unique worldwide.

It's kind of long, but matches well with a certificate authority hierarchy.
Also, it doesn't HAVE to be that long.  The space might mess some parsing
up.

I assume a client must have the public certificate for the root of the
domain.  From your proposals using a UUID, it looks like the domain name
isn't something a user needs to type in?  If not, then using a distinguished
name wouldn't be any more difficult.

Also, you can easily locate the trust relationship by going from the
Kerberos domain name back to the certificate authority, and vice versa.

I think you need a trust model too.  The obvious thing would be to have a
list of certs that the client trusts, and require any KDC to have that cert
in its certificate chain.  Or only have the cert for the issuer (that
represents the domain name) of certs for KDCs you trust.

As far as padata, you only need that to come back from the KDC in the
AS-REP.  Just use the standard preauthentication protocol when using
passwords.  The padata needs to contain the certificate chain, and a
signature of the interesting parts of the AS-REP.

Now all you need is a way to locate KDCs that match the domain name, but
since the client knows the certificate, you could use just about any item in
the certificate to do the lookup.  It wouldn't be unusual to have each KDC
have it's own cert (like Active Directory).  One way to match would be to
use the Authority Key Identifier extension.  You could also add an extension
to the KDC certificate that lists all the suggested methods of locating KDC
in order of preference.

You need to specify what the minimum key usage is for a KDC cert (like
digital signature).

Paul Nelson
Thursby Software Systems, Inc.

---

From: Ken Raeburn <[email-masked]>
Date: Wed, 16 Aug 2006 19:49:40 -0400

I don't think we should rely on some shared (global or  
organizational) authority hierarchy to keep the names unique.
And as Sam said, we can't rely on stable DNS either.

---

From: Jeffrey Altman <[email-masked]>
Date: Wed, 16 Aug 2006 20:48:35 -0400

Paul:

Try to imagine a world in which all of the local computer account
databases were in fact Kerberos databases and all logins took place
using Kerberos.  My laptop for which I gave the GALATEA would in
fact be a self enclosed realm.  If there was a certificate authority
on the machine it would be the GALATEA CA and the best it could do
would be to generate a root certificate for itself and sign per-service
certificates using the automatically generated self-signed cert.

Now as I move the laptop around various networks the DNS name associated
with the machine is going to change.   So there is nothing I can do
from a DNS domain perspective to obtain a persistent name for the machine.

Microsoft Vista is already doing something similar for Certificate
Authorities.  A Vista workstation does generate a self-signed
certificate for itself and it will use that certificate in conjunction
with TLS to protect Remote Desktop and even IIS connections.  They
may also be using it to protect other certificate based services
although I am unaware of any.

Since there is nothing that prevents someone else from naming their
machine GALATEA I really don't want to use that as a unique identifier
for my local CA or Kerberos Realm.  I want something that can be
provably unique.  That is where the UUID comes in.  I can associate
the name GALATEA as a display name but I want my GALATEA realm to be
different from other's GALATEA realm.

I definitely want this work to be a standard's track work item.  I also
would like to see Microsoft try to squeeze this work into Vista since
they already have a standalone machine CA and they also have all of the
other pieces written.  It would just take a bit a spit and polish to
pull them all together.

The approach I would like to see is that the realm be given a display
name, a UUID and a KDC certificate.  The certificate would bind the
display name, the UUID and a public key pair together.  I would like to
see the KDC certificate be required to contain the EKU KeyPurposeId
id-pkinit-KPKdc [RFC3280].

This would allow the certificate for the KDC to be re-issued with new
display names as the machine name changes, with new public key pairs,
but with the same UUID.  What would not change is the CA root
certificate for the realm.  This would allow machines that provide
a local machine CA or users who obtain a certificate from a commercial
CA to use one in this model.

The KDC certificate can then be used with a future TLS mechanism for
the AS exchange or in conjunction with a HTTPS AS exchange.

I agree that how the realm is determined for services on the local
machine is best left up to some as yet unspecified discovery mechanism.
I can see using these realms within peer to peer networks such as JXTA,
local area discovery systems such as UPNP, Jini or Bonjour.

I would be very interested in helping to edit this document.

Jeffrey Altman

---

From: "RL 'Bob' Morgan" <[email-masked]>
Date: Wed, 16 Aug 2006 20:41:40 -0700 (PDT)

On Wed, 16 Aug 2006, Jeffrey Altman wrote:

> with TLS to protect Remote Desktop and even IIS connections.  They may 
> also be using it to protect other certificate based services although I 
> am unaware of any.

I believe they're also using a self-signed cert to sign the SAML 
assertions that are used as the default authentication mechanism in 
Cardspace (formerly known as InfoCard).  Dunno if it's the same cert as 
those other ones or not.

> CA to use one in this model.

And when 1000 of your closest friends decide to issue certs with that 
UUID, what is the guarantee of uniqueness, and what is the function of the 
UUID exactly?

  - RL "Bob" (thumbing through his old SPKI manuals ...)

---

From: Jeffrey Altman <[email-masked]>
Date: Wed, 16 Aug 2006 23:56:21 -0400

RL 'Bob' Morgan wrote:
> UUID, what is the guarantee of uniqueness, and what is the function of
> the UUID exactly?

The purpose of the UUID is equivalent to the purpose of the hostname
in SSH.  It is simply a relatively unique preferably long term
identifier that can be associated with a public key that your keep a
local cache of.   The reason we track the UUID instead of the public
key itself is so that it is possible for the KDC to generate a new
public key pair if necessary.  In that case for some period of time
the KDC we assert both the new and old public keys and the clients
would be able to upgrade without the SSH style warnings.

If your 1000th friend tried to assert the same UUID, oh well, the
public key won't match and the authentication will fail.    There isn't
a hell of lot different here than the situation in which an attacker
creates a KDC with the same name as a well known realm and then
convinces you to attempt an AS_REQ to it.

Jeffrey Altman

---

From: Saber Zrelli <[email-masked]>
Date: Thu, 17 Aug 2006 15:57:43 +0900

Hi,

* On Wed, 16 Aug 06 at 16:49, Sam Hartman wrote:
> technology.

I dont see how the realm name can be spoofed.

AFAIK, In the KDC reply, the EncKDCRepPart contanis the realm name
as welll as a nonce that authenticates the message. Isn't that
enough ?

Regards,
Saber.

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 17 Aug 2006 12:08:35 -0400

> convinces you to attempt an AS_REQ to it.

Right.  This is exactly like ssh leap-of-faith - the first time you talk to 
a realm, you record the association between the realm UUID and the public 
key of the root CA for that realm.  Once you've done that, future 
communication with entities using that UUID is considered authentic only if 
the same root CA is used.  The advantage of UUID's over simple names here 
is that names collide fairly easily, whereas UUID's don't collide unless 
you go out of your way to make them.

-- Jeff

---

From: Sam Hartman <[email-masked]>
Date: Thu, 17 Aug 2006 14:10:02 -0400

>>>>> "Jeffrey" == Jeffrey Altman <[email-masked]> writes:

    Jeffrey> The approach I would like to see is that the realm be
    Jeffrey> given a display name, a UUID and a KDC certificate.  The
    Jeffrey> certificate would bind the display name, the UUID and a
    Jeffrey> public key pair together.  I would like to see the KDC
    Jeffrey> certificate be required to contain the EKU KeyPurposeId
    Jeffrey> id-pkinit-KPKdc [RFC3280].

    Jeffrey> This would allow the certificate for the KDC to be
    Jeffrey> re-issued with new display names as the machine name
    Jeffrey> changes, with new public key pairs, but with the same
    Jeffrey> UUID.  What would not change is the CA root certificate
    Jeffrey> for the realm.  This would allow machines that provide a
    Jeffrey> local machine CA or users who obtain a certificate from a
    Jeffrey> commercial CA to use one in this model.

I don't think I would be interested in a model where the display name
is part of the certificate.  I expect that to change often enough that
I think it would be inappropriate to include in the cert.

Also, I really am under tight time pressure here and don't want to
depend on future TLS extensions etc.

Do you have any thoughts on whether a public key actually adds value
or on the uuid vs public-key named issue?

---

From: Jeffrey Altman <[email-masked]>
Date: Thu, 17 Aug 2006 14:16:58 -0400

> I think it would be inappropriate to include in the cert.

The display name could be optional but I suspect that organizations
will want it.  I don't believe that people change the base name of
their machines all that often.  The name I'm expecting to be there
is the equivalent of the Windows NETBIOS name.

> depend on future TLS extensions etc.

I am not suggesting that this work depend on TLS extensions.  I am
suggesting that if we define a certificate for this work that future
TLS extensions can make use of it.

> or on the uuid vs public-key named issue?

I believe the public key is required and I want to see the UUID for
long term name stability.

Jeffrey Altman

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 17 Aug 2006 14:26:42 -0400

> is the equivalent of the Windows NETBIOS name.

This is pretty straightforward, really.  Any certificate can have a subject 
DN, which can include a CN.  If there is a CN in the certificate, then 
software that wants to use that as a display name can do so.  If not, it 
can use something else.

> long term name stability.

Is there a SAN type for UUID's ?

---

From: Sam Hartman <[email-masked]>
Date: Thu, 17 Aug 2006 14:37:53 -0400

>>>>> "Jeffrey" == Jeffrey Altman <[email-masked]> writes:

    Jeffrey> The display name could be optional but I suspect that
    Jeffrey> organizations will want it.  I don't believe that people
    Jeffrey> change the base name of their machines all that often.
    Jeffrey> The name I'm expecting to be there is the equivalent of
    Jeffrey> the Windows NETBIOS name.

For my application I expect to handle the display name separately.

    >> Also, I really am under tight time pressure here and don't want
    >> to depend on future TLS extensions etc.

    Jeffrey> I am not suggesting that this work depend on TLS
    Jeffrey> extensions.  I am suggesting that if we define a
    Jeffrey> certificate for this work that future TLS extensions can
    Jeffrey> make use of it.

    >> Do you have any thoughts on whether a public key actually adds
    >> value or on the uuid vs public-key named issue?

    Jeffrey> I believe the public key is required and I want to see
    Jeffrey> the UUID for long term name stability.

Why do you believe the public key is required?  If you don't know,
that's fine, but if you do, that is interesting as well.  Why do you
believe the longer name stability is important?

---

From: "Douglas E. Engert" <[email-masked]>
Date: Thu, 17 Aug 2006 15:23:44 -0500

Are there any cross-realm issues that need to be addressed, while
using some non-hierarchal realm name?

Would anything of these issues have been brought up before with PKCROSS?

-- 

  Douglas E. Engert  <[email-masked]>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444

---

From: Martin Rex <[email-masked]>
Date: Thu, 17 Aug 2006 21:38:15 +0200 (MET DST)

> you go out of your way to make them.

Also names may collide more often, they're also the ones that remain
most constant (for same-use), because they can easily be memorized
by humans when they re-install / re-image the machine.

We have a many machines that get re-imaged frequently (sometimes
with the same version of the OS, sometimes with a newer version),
and the only thing that remains constant for the box is the hostname,
i.e. with betas, release candidates and finals of an OS/distribution,
and usually less than a year later the cycle resumes.

If they're some kind of Unix box, I notice it because my SSH
aborts the login with a furious alert whenever they do it.
Requiring them to carry over SSH-credentials, UUIDs and what-not
would be a burden they're very unlikely to bear.

-Martin

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 17 Aug 2006 15:41:20 -0500

> id-pkinit-KPKdc [RFC3280].

I second this.

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 17 Aug 2006 15:45:14 -0500

On Wed, Aug 16, 2006 at 11:56:21PM -0400, Jeffrey Altman wrote:
> in SSH.

Well, then we might as well use names, with UUIDs being an option for
generating unique names.

Just as some SSHv2 clients can make {hostname, port, host public key}
associations then so could Kerberos V clients make {realm, peer, public
key} associations where "peer" is some context-specific information that
allows one to disambiguate conflicting realm names.

Since users won't use UUIDs you do need UI-friendly names.  So, maybe
scratch UUIDs as separate from names.

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 17 Aug 2006 15:46:29 -0500

> depend on future TLS extensions etc.

What about using TLS would blow your time constraints?  I'd think it'd
be easier to spec and implement...

---

From: Sam Hartman <[email-masked]>
Date: Thu, 17 Aug 2006 17:24:38 -0400

>>>>> "Nicolas" == Nicolas Williams <[email-masked]> writes:

    Nicolas> On Thu, Aug 17, 2006 at 02:10:02PM -0400, Sam Hartman
    >> to depend on future TLS extensions etc.

    Nicolas> What about using TLS would blow your time constraints?
    Nicolas> I'd think it'd be easier to spec and implement...

It seems harder to spec than just a realm name and padata item.  It is
much harder to deal with in terms of code for us.

Also, I'm really trying to solve one problem here; coupling that
problem with other problems has led in my experience to longer design
and implementation times.

--Sam

---

From: Paul Leach <[email-masked]>
Date: Fri, 18 Aug 2006 10:06:56 -0700

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

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

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

Also, what accounts would the realm hold, for what kind of principals?

W.R.T. Vista, the use of self-signed certs in the TLS protocol is
primarily for cases where there is a local account with a password, and
we use NTLM inside the TLS connection, which proves that the server is
authentic regardless of its name -- the server has to prove it knows the
users password.

For CardSpace, the name in the self-signed cert is irrelevant -- the
server is expected to map the key to attributes of the holder of the
key.

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 18 Aug 2006 15:15:41 -0400

> authentic regardless of its name -- the server has to prove it knows the

And this is bound to the cryptographic properties of the TLS channel how?
If the answer is "it isn't", and clients accept self-signed server certs 
without validation, then you have a MITM attack waiting to happen.

-- Jeff

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 18 Aug 2006 15:35:47 -0500

> purposes), and it doesn't matter if it gets spoofed.

Unless you can create ssh-style leap-of-faith bindings.  Then realm
names could be as meaningful to Kerberos V users as hostnames are to ssh
users.

Ssh clients create {host, [port,] host public key} bindings on user
faith and then recall these bindings to prevent subsequent MITM attacks.

What kind of bindings would a Kerberos V client create?

{realm name, realm public key}?

or would there be other, optional context-specific information (like
port numbers in the ssh case)?  I'm not sure what other context
information could be used, so I suspect that the bindings really will be

{realm name, realm public key}

Users will generally tend to pick unique realm names and conflicts will
be rare and unintended.  When they occur one might create realm name
aliases.  So, I'm not sure that UUIDs really fit in.  Just realm names
and realm public keys.

Which makes me wonder why certificates wouldn't suffice (self-signed
ones in the common case, no doubt).  And so why PKINIT wouldn't suffice.

Cheers,

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 18 Aug 2006 16:01:15 -0500

On Fri, Aug 18, 2006 at 01:57:35PM -0700, Paul Leach wrote:
> Suppose you wanted to use PKINIT with self-signed certs and use
> leap-of-faith.
> 
> Compared to today, the processing required to properly handle them would
> change. When a KDC returns a cert that the client currently doesn't
> trust, then the client would prompt the user to ask them if they want to
> trust it. If there already is a realm name to key binding, and the KDC
> returns a different cert, then it loses -- it's first-come first-served.

Yup.

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

Key rollover could be built into PKINIT.  Key compromise -> you lose;
that's always the case in LoF systems.

Nico
--

---

From: Paul Leach <[email-masked]>
Date: Fri, 18 Aug 2006 13:57:35 -0700

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

---

From: Andrew Bartlett <[email-masked]>
Date: Wed, 30 Aug 2006 08:11:33 +1000

> authentic regardless of its name -- the server has to prove it knows the

So TLS is more about protecting the weak NTLM exchange from passive
snooping with something stronger, rather than binding real TLS
properties into the mix?

(And yes, I think it's a very good idea.  Unfortunately, the most
widespread use use of TLS and NTLM, being HTTP, doesn't rely on the NTLM
credentials at all, so we are back to zero server-provided proof :-)

Andrew Bartlett

-- 
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Red Hat Inc.                  http://redhat.com