Subject: Section 4 Kerberos Revisions for comment

From: Clifford Neuman <[email-masked]>
Date: Fri, 8 Sep 2000 17:46:44 -0700 (PDT)

Attached is the draft text for section 4 of the Kerberos revisions,
with the list of changes at the end.  This section is descriptive of
specific implementations.  I think it makes the description of
Kerberos more complete, but other implementations of Kerberos may
choose to do things differently and still be inter-operable.  If anyone
has ideas for some introductory text to this section that makes this
clear, but which still imposes some constraints where we feel
constraints are appropriate, I would be interested in hearing such
input.

Clifford Neuman
---

<H3>4.  The Kerberos Database</H3>

The Kerberos server must have access to a database containing the
principal identifiers and secret keys of any principals to be
authenticated<A HREF="#fn21">[21]</A> using such secret keys.  The
keying material in the database must be protected so that they are
only accessible to the Kerberos server and administrative functions
specifically authorized to access such material.

<H3>4.1.  Database contents</H3>

A database entry  should  contain  at  least  the  following
fields:

<PRE>
Field                Value

name                 Principal's identifier
key                  Principal's secret key
p_kvno               Principal's key version
max_life             Maximum lifetime for Tickets
max_renewable_life   Maximum total lifetime for renewable Tickets
</PRE>

The name field is an encoding of the principal's identifier.  The key
field contains an encryption key.  This key is the principal's secret
key.  (The key can be encrypted before storage under a Kerberos
"master key" to protect it in case the database is compromised but the
master key is not.  In that case, an extra field must be added to
indicate the master key version used, see below.) The p_kvno field is
the key version number of the principal's secret key.  The max_life
field contains the maximum allowable lifetime (endtime - starttime)
for any Ticket issued for this principal.  The max_renewable_life
field contains the maximum allowable total lifetime for any renewable
Ticket issued for this principal.  (See section 3.1 for a description
of how these lifetimes are used in determining the lifetime of a given
Ticket.)

<P>

A server may provide KDC service to several realms, as long as the
database representation provides a mechanism to distinguish between
principal records with identifiers which differ only in the realm
name.

<P>

When an application server's key changes, if the change is routine
(i.e.  not the result of disclosure of the old key), the old key
should be retained by the server until all tickets that had been
issued using that key have expired.  Because of this, it is possible
for several keys to be active for a single principal.  Ciphertext
encrypted in a principal's key is always tagged with the version of
the key that was used for encryption, to help the recipient find the
proper key for decryption.

<P>

When more than one key is active for a particular principal, the
principal will have more than one record in the Kerberos database.
The keys and key version numbers will differ between the records (the
rest of the fields may or may not be the same). Whenever Kerberos
issues a ticket, or responds to a request for initial authentication,
the most recent key (known by the Kerberos server) will be used for
encryption.  This is the key with the highest key version number.

<H3>4.2.  Additional fields</H3>

Project Athena's KDC implementation uses additional fields in its
database:

<PRE>
Field        Value

K_kvno       Kerberos' key version
expiration   Expiration date for entry
attributes   Bit field of attributes
mod_date     Timestamp of last modification
mod_name     Modifying principal's identifier
</PRE>

The K_kvno field indicates the key version of the Kerberos master key
under which the principal's secret key is encrypted.

<P>

After an entry's expiration date has passed, the KDC will return an
error to any client attempting to gain tickets as or for the
principal.  (A database may want to maintain two expiration dates: one
for the principal, and one for the principal's current key.  This
allows password aging to work independently of the principal's
expiration date.  However, due to the limited space in the responses,
the KDC combines the key expiration and principal expiration date
into a single value called 'key_exp', which is used as a hint to the
user to take administrative action.)

<P>

The attributes field is a bitfield used to govern the operations
involving the principal.  This field might be useful in conjunction
with user registration procedures, for site-specific policy
implementations (Project Athena currently uses it for their user
registration process controlled by the system-wide database service,
Moira [LGDSR87]), to identify whether a principal can play the role of a
client or server or both, to note whether a server is appropriately
trusted to receive credentials delegated by a client, or to identify
the 'string to key' conversion algorithm used for a principal's
key[22].  Other bits are used to indicate that certain ticket options
should not be allowed in tickets encrypted under a principal's key
(one bit each): Disallow issuing postdated tickets, disallow issuing
forwardable tickets, disallow issuing tickets based on TGT
authentication, disallow issuing renewable tickets, disallow issuing
proxiable tickets, and disallow issuing tickets for which the
principal is the server.

<P>

The mod_date field contains the time of last modification of the
entry, and the mod_name field contains the name of the principal which
last modified the entry.

<H3>4.3.  Frequently Changing Fields</H3>

Some KDC implementations may wish to maintain the last time that a
request was made by a particular principal.  Information that might be
maintained includes the time of the last request, the time of the last
request for a ticket-granting ticket, the time of the last use of a
ticket-granting ticket, or other times.  This information can then be
returned to the user in the last-req field (see section 5.2).

<P>

Other frequently changing information that can be maintained is the
latest expiration time for any tickets that have been issued using
each key.  This field would be used to indicate how long old keys must
remain valid to allow the continued use of outstanding tickets.

<H3>4.4.  Site Constants</H3>

The KDC implementation should have the following configurable
constants or options, to allow an administrator to make and enforce
policy decisions:

<UL>
<LI>The minimum supported lifetime (used to determine whether the
KDC_ERR_NEVER_VALID error should be returned).  This constant should
reflect reasonable expectations of round-trip time to the KDC,
encryption/decryption time, and processing time by the client and
target server, and it should allow for a minimum 'useful' lifetime.

<LI>The maximum allowable total (renewable) lifetime of a ticket
(renew_till - starttime).

<LI>The maximum allowable lifetime of a ticket (endtime - starttime).

<LI>Whether to allow the issue of tickets with empty address fields
(including the ability to specify that such tickets may only be issued
if the request specifies some authorization_data).

<LI>Whether proxiable, forwardable, renewable or post-datable tickets
are to be issued.
</UL>

--- 

Changes: Added language about who has access to the keys in the
Kerberos database.

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 11 Sep 2000 09:54:23 -0400

Section 4 must only be a guideline. The language seems to assume only
secret keys. There should be an admonition not to have any protocols
which allow or require secret keys to be retrieved from the KDC.

Are you still accepting comments about the name canonicalisation stuff
from sections 2 and 3? I have seen it in action and would like to warn
you of its ill effects.

Nico
--

---

From: "Booker C. Bense" <[email-masked]>
Date: Wed, 13 Sep 2000 12:51:20 -0700 (PDT)

> which allow or require secret keys to be retrieved from the KDC.

- That's silly, there are at least two justifiable requirements to 
transfer secret keys. 

1. Server replication. ( You do want a backup KDC ?) 

2. Service keys which exist on multiple machines and
must be kept in sync. 

- Two is perhaps more controversial, but 1 is a requirement
for production. 

- Booker C. Bense 

BTW, if you aren't using secret keys there isn't much point 
in using kerberos. Public keys belong in a directory, not a 
KDC.

---

From: "Booker C. Bense" <[email-masked]>
Date: Wed, 13 Sep 2000 12:51:20 -0700 (PDT)

- Booker C. Bense

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 13 Sep 2000 16:23:05 -0400

> - That's silly, there are at least two justifiable requirements to 

I meant principals' secret keys. I don't think there's any way to
extract such keys from a Kerberos database now through the standard KDC
and kadmin protocols (well, kadmin isn't stadanrd anyways).

> 1. Server replication. ( You do want a backup KDC ?) 

Yes. It can be done without having the cleartext of the principals'
keys.

> 2. Service keys which exist on multiple machines and

Yes, and you should know those keys to begin with. If a key is lost then
the administrator should create a new one. When you setup a keytab you
increment the kvno of the principal and stuff the *new* key, not a
pre-existing key, into the keytab, which you can then copy around, if
you wish.

Do people now setup services with SPNs and keys that are shared to
multiple machines for any reason other than High Availability?

> - Two is perhaps more controversial, but 1 is a requirement

What I was getting at is this: if you use a tamper-proof co-processor to
handle all KDC crypto operations so that neither database keys nor
principal's keys are ever present in cleartext on the KDC beyond the
co-processor, then recovery from KDC compromises is fairly easy as
attackers cannot retrieve the keys from the database.

See Naomaru Itoi's paper on using the IBM 4758 to secure a Kerberos
database.

If there were a protocol to extract existing principals' keys from the
Kerberos DB, then Naomaru's work on this would be worthless. But there
isn't such a protocol now, so let's just not introduce any new such
protocols.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 13 Sep 2000 16:23:05 -0400

Nico
--

---

From: "Booker C. Bense" <[email-masked]>
Date: Wed, 13 Sep 2000 14:03:34 -0700 (PDT)

> Yes. It can be done without having the cleartext of the principals'

- Yes, but how do you do it without the cleartext key being available
to the backup KDC somehow? 

> pre-existing key, into the keytab, which you can then copy around, if

- In practice this does not work very well, and it makes it pretty
much impossible to regularly change these kinds of keys which is 
something that you'd really like to do. 

> multiple machines for any reason other than High Availability?

- This is the primary use, but I have seen other uses. They primarily
have to do with the lack of a good authorization model, but there
are other uses.

> isn't such a protocol now, so let's just not introduce any new such

- How would this make the work worthless? Service keys are ALREADY in 
CLEARTEXT on the the service machine. How does the ablity to download
these keys comprise the database encrytion? Every user can trivially
recreate the cleartext version of their key. Why does this make the
secure coprocessor work worthless ? 

- Booker C. Bense

---

From: "Booker C. Bense" <[email-masked]>
Date: Wed, 13 Sep 2000 14:03:34 -0700 (PDT)

- Booker C. Bense

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 13 Sep 2000 17:21:37 -0400

> to the backup KDC somehow? 

You backup the database, with keys encrypted. The database master key
can also be backed up, though if you're using a tamper-proof crypto
co-processor then you'd never backup the master key.

> something that you'd really like to do. 

Why/how does it not work? Is it a matter of having better utilities to
manipulate keytab files and their contents?

> have to do with the lack of a good authorization model, but there

With respect to HA, why not update one keytab file and copy it to the
other systems in the cluster?

> secure coprocessor work worthless ? 

Yes, the service keys are stored in cleartext on the servers, but an
attacker would have to attack all those servers to get at all the
service keys. Users also know their keys and type them in cleartext when
they are prompted for them.

The problem is that if an attacker compromises a KDC he/she can steal
the keys and impersonate any users, particularly if the attacker steals
the TGS keys. Recovery from the loss of the TGS keys is not trivial.
Losing all the principal keys is nearly equivalent to losing the TGS
keys.

If you secure your KDC with a tamper-proof crypto co-processor you can
limit any attacker that breaks into your KDC to abusing the
co-processor's services and impersonating any user, for some time. Once
the attacker is off the KDC he or she can no longer abuse the KDC. But
if the attacker makes off with the unencrypted database, then the gig is
up.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 13 Sep 2000 17:21:37 -0400

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 13 Sep 2000 17:27:49 -0400

> secure coprocessor work worthless ? 

I forgot to answer this. The answer is that if there's a way to get the
cleartext keys out of the database, then any attacker that breaks into
your KDC will be able to steal ALL the keys. Regardless of wether you're
using tamper-proof crypto co-processors.

It's worth using tamper-proof crypto co-processors only if it prevents
extraction of cleartext keys from the database (or if it improves KDC
performance, but that's not the issue Noamaru Itoi was trying to deal
with).

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 13 Sep 2000 17:27:49 -0400

Nico
--

---

From: "Booker C. Bense" <[email-masked]>
Date: Wed, 13 Sep 2000 16:04:31 -0700 (PDT)

> co-processor then you'd never backup the master key.

- I get this. How are you ever going to write a recommendation that
allows this but doesn't allow writing a protocol that sends an
encrypted version of a keytab? I guess you could say something 
like

"The secret key should never be transferred out of the KDC encrypted
with a key that is in the KDC." 

> manipulate keytab files and their contents?

- Try it and see. It's not a problem of manipulating the keytabs, it's
a problem of "securely" copying around the key in a timely fashion.
You need at least one more key.... It's not impossible, it's just
painful. Now think about what can go wrong if you want to automate 
this process. 

> other systems in the cluster?

- There is a race condition here. If for some reason, the machine
that updates the keytab dies before transfers the keytab to the other
machines, the whole cluster is useless. It can't be recovered
without admin intervention. You can update the keytabs, but it
requires a body to watch the process. Given the high risk of
automating this and the low reward, most sites just set the keytab
once and forget about it. 

- The other part of many home-brew HA systems is an image machine
from which you can quickly build new machines to add to the cluster. 
Using a keytab across all machines in the cluster pretty much requires
that this keytab live on the image machine. Or in a "image" area on
a shared filesystem. 

- Also, for machines that are really being pounded (ie. webservers),
there will be a period in which the users have valid service keys, but
the server doesn't have the necessary key. While false negatives are
okay from a security perspective, they are absolutely terrible for
users.

- Perhaps the KDC is the wrong place to solve this problem, but if
you are going to have HA and use kerberos, you really need to have
some way for the process to update it's shared keytab when it gets
a service ticket it can't decrypt. Or else you never update keytabs.

- Among the people that have to admin these kinds of machines, the
number one request I get is a way to download keytabs directly from
the KDC. Perhaps there's no way to do this securely, but the inablity
to do this compromises security in other ways. 

- Booker C. Bense

---

From: "Booker C. Bense" <[email-masked]>
Date: Wed, 13 Sep 2000 16:04:31 -0700 (PDT)

- Booker C. Bense

---

From: Ken Hornstein <[email-masked]>
Date: Wed, 13 Sep 2000 21:58:55 -0400

>painful. Now think about what can go wrong if you want to automate 

FWIW, I've done this plenty of times (transferred a key to a keytab
and copied the keytab around securely).  It really isn't a problem.

--Ken

---

From: Ken Hornstein <[email-masked]>
Date: Wed, 13 Sep 2000 21:58:55 -0400

--Ken

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 13 Sep 2000 22:07:14 -0400

[Should I just address the lists? or reply all?]

> encrypted version of a keytab? I guess you could say something 

Huh?

I asked that no protocols be added which allow keys to be extracted from
the Kerberos database, that keys be settable only, not gettable. Though,
with respect to the password/key change protocol, I do think it's ok
for the server to create a random key and return that to the
principal.

> with a key that is in the KDC." 

Huh?

> painful. Now think about what can go wrong if you want to automate 

Ok, so you want to share a key amongst several servers. You can do this,
just update the key on one server, then copy the keytab (or just the one
key in the keytab) to the others. How does one do that securely?
Kerberized (well, GSS-APIized) FTP, or SSH. But you must have a valid
key on the target servers you say? Sure, so? You can have multiple valid
kvnos for a given principal.

I'm not asking for anything new here. There is no protocol now where
you can extract keys from Kerberos databases, well, MIT Kerberos
databases anyhow.

> once and forget about it. 

I've seen HA setups fail in ways that require admin intervention. Big
deal. There's always some boundary condition you can't handle
automatically. And again, you can have multiple valid kvnos for one
principal, thus fixing the boundary condition.

> that this keytab live on the image machine. Or in a "image" area on

Ok, I see no problem here. Use FTP/SSH to maintain your keytabs.

> okay from a security perspective, they are absolutely terrible for

Change your keys on weekends. It might be nice to add a new key for a
principal with a new kvno but have it placed "on hold" until all
necessary keytabs are updated.

Anyways, sharing SPNs over multiple hosts sounds like a bad idea.

> a service ticket it can't decrypt. Or else you never update keytabs.

The KDC is a bad place to solve that problem.

> to do this compromises security in other ways. 

This really argues for a feature whereby you can add a key to a
principal but put the key "on hold", then release it when you're ready.

In fact, I see no other way to avoid the race you describe when you have
multiple hosts sharing one SPN.

This feature could be added in the password/key change protocol spec,
without having to modify the Kerberos AS/TGS/AP protocols. How about
it? This is the time to consider such a feature.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 13 Sep 2000 22:07:14 -0400

Huh?

Huh?

Nico
--

---

From: Ken Raeburn <[email-masked]>
Date: 14 Sep 2000 14:44:45 -0400

> once and forget about it. 

Regarding the password/key changing protocol proposal, there was some
discussion of having the "client" service make sure its new key was
safely stored on disk before sending a message to the KDC to actually
cause that key to become active.  (Whether that message is a "set-key"
or "activate-(kdc-generated-)key" doesn't really matter in this
context.)  Just extend that to "safely distributed to a sufficient
number of machines in the cluster".

> okay from a security perspective, they are absolutely terrible for

Don't get rid of old keys until all issued tickets have expired.
I.e., activation time of new key, plus max lifetime for tickets under
old key, plus clock-skew allowance.

> to do this compromises security in other ways. 

I think a "rekey cluster" operation would be close, but if not all
machines are up at any one time, copying keys around (either manually
or through some automated mutual-updating scheme) seems like the only
alternative to being able to extract the data from the Kerberos
database.  And copying keys manually provides one more opportunity for
the sysadmin to do something stupid, like forget the encryption
option, so perhaps we should give her the tools to do it right....

On the other hand, how do maintainers of machine clusters provide for
synchronization of other data, when machines might be down, any chosen
"master" machine might go down before propagating its data, etc?  How
different is the keytab really, aside from needing to be encrypted in
transit?

---

From: Ken Raeburn <[email-masked]>
Date: 14 Sep 2000 14:44:45 -0400

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 14 Sep 2000 16:52:23 -0400

> number of machines in the cluster".

How about:

 - an option to set a new key "on hold"
 - a command to release a key that was "on hold"
 - a command to retrieve a key that is "on hold"

The last two would require that the client authenticate with the
previous valid key for the same SPN.

I wonder how well this would work in a multi-master system and
especially if multiple hosts try to use these features for the same SPN.
Which makes me think that SPN sharing is not a good idea, though it's
necessary in HA situations.

The protocol can't specify that only one key may exist "on hold" and
that the process of setting/releasing "on hold" keys be atomic as that
won't work well with multi-master systems like MS's ActiveDirectory.

...

> option, so perhaps we should give her the tools to do it right....

Tools would be nice. But then, our HA systems all have private heartbeat
interconnects, so we have no need to encrypt keytabs as we transfer them
from one system to the other. One HA cluster member should be the
primary keytab updator.

> different is the keytab really, aside from needing to be encrypted in

If your system supports sharing disks between the members of the
cluster, even if only one member can mount any filesystem at any given
time, then you can recover easily from the loss of a cluster member.
Things get hairy again if you lose a filesystem with useful data on it,
such as, say, a keytab file. But if you have private interconnects then
keytab distribution is easy.

HA clusters spread over too large a distance for private interconnects
need a better plan. But then, incidents involving HA cluster member
failures while keys are being updated should be few and far between;
infrequent administrative intervention is acceptable (you can never get
100% uptime, much less without manual intervention).

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 14 Sep 2000 16:52:23 -0400

How about:

...

Nico
--

---

From: "Booker C. Bense" <[email-masked]>
Date: Fri, 15 Sep 2000 15:52:38 -0700 (PDT)

> number of machines in the cluster".

- I think this would address most of my problems. I'd really prefer
to be able to pull the key down directly, but I could live with this
solution. 

> Don't get rid of old keys until all issued tickets have expired.

- This is not the problem, the problem is the KDC handing out service
tickets with the new key before the new key is distributed to all the
members of the cluster. Also, these keys are often clients as often
as they are servers.  

> option, so perhaps we should give her the tools to do it right....

- In "theory" this is no problem. In practice it just isn't that
simple. It's not easy to write secure systems, one-off hacks sound
good in a email discussion, but they never get peer review. You don't
know if what you've cobbled together is really secure or not. Even
worse is accidently updating the keytab one member of the cluster
without realizing it. Like doing a ktadd without realizing that it
changes the password.

- I would really like a system robust enough to automate changing
these keys on the order of at least 3 times a day. I'd prefer once
an hour. 

> different is the keytab really, aside from needing to be encrypted in

- Perhaps if I list a concrete example, I can make my point clearer.

- The kind of keys I'm concerned with are typically used in the middle
tier of a 3 tier database access model ( client -> middleware ->
database ). Generally the middleware lives behind a web page and we
use a kind of DNS round-robin to provide HA for these web pages.
These keys have way more power in the source systems than I'm really
comfortable to have lying around for monthes. The big reason these
keys have to be in sync is that cookies are encrypted with them
and you have no guarantee that the cookie you got from machine A
in the pool will be returned to back to machine A. 

- Yes, sharing a service principal across machines is a bad idea,
that's why I'd like to change it as often as possible. 

- Booker C. Bense

---

From: "Booker C. Bense" <[email-masked]>
Date: Fri, 15 Sep 2000 15:52:38 -0700 (PDT)

- Booker C. Bense

---

From: Ken Raeburn <[email-masked]>
Date: 22 Sep 2000 14:09:29 -0400

> using tamper-proof crypto co-processors.

The point was never to get the KDC to send out the keys with no
encryption, it was to get them out in a way readable to an
appropriately authorized party.  If the only means for extracting a
"cleartext" key is as part of an encrypted message after proving that
you're one of the principals on the magic admin acl, then the attacker
won't be able to do squat by herself, except maybe come after you with
a baseball bat and demand your admin password.

IIRC, part of the reason for not permitting extraction of current keys
was so that some unscrupulous or compromised administrator (see
baseball bat above) couldn't simply pull keys out and forge tickets
unnoticed, but would instead have to actually change the keys, which
would be a noticable disruption to other parties, and wouldn't help
the attacker much in the case of new service keys that aren't getting
installed on the servers anyways.  Whether this is worth the
inconvenience of having to pass keys around manually in your HA setup
depends on your threat model, I suppose.  Perhaps it should be left up
to the realm administrator to set policy?

> extraction of cleartext keys from the database (or if it improves KDC

I thought he was trying to prevent *unauthorized* parties with
physical access from getting data out.  You still need to support some
flavor of administrator access that involves a key potentially known
to parties other than the "owner" of the principal -- certainly to
change forgotten passwords and add new principals, perhaps to extract
keys (or not).

Ken

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 22 Sep 2000 14:53:23 -0400

> a baseball bat and demand your admin password.

NOTE: What I meant by cleartext is: not encrypted in the database
      master key, or, in other words, available to the client in
      cleartext.  Obviously, sessions over which keys are exchanged
      would be encrypted with a session key.

If the attacker breaks into the KDC (i.e., gets root), the attacker can
get the keys, which he or she can be counted on doing and then you have
to re-key your realm.

Naomaru Itoi's solution is to use a tamper-proof crypto co-processor
such that the principals' keys are NEVER available in the KDC processes'
virtual memory space (or files or anything) unless they are encrypted in
the database master key.

So with Naomaru Itoi's solution if someone breaks into your KDC they can
abuse it (i.e., get all the tickets they want as any user in the realms
served by that KDC), but they can't extract keys from the database. So
if you catch them, you don't have to re-key, you can just kick them out
and get their tickets back.

I consider the password changing services to be outside the KDC proper
for the purpose of this discussion. This is because the principals' keys
obviously must be available not encrypted in the database master key
when:

 - users remember them and type them in at password prompts
 - they are set via a password changing service
 - a password changing service generates a random key and returns it to
   the client [for storage in a keytab, say]
 - they are stored in keytabs, say

But once a key is in the KDC's database there should be no way to
extract it. Yes, you can dump the database and transfer and so on, but
in those cases the keys may be encrypted in a database master key or in
a session key and only KDC processes are involved.

And my request is that the Kerberos 5.1 spec state that no protocols
should allow the extraction of active keys from the KDC in cleartext,
regardless of session encryption. This request doesn't change the
current state of things. And it doesn't impact any of what's been
discussed in the password changing service protocol discussion.

Why is my request a problem then?

Note also that what I'm calling the "database master" key here is an MIT
Kerberos concept and is not referenced in the RFC as it has nothing to
do with the Kerberos protocol itself.

> to the realm administrator to set policy?

Wrt your 'IIRC', I wasn't around when what remember happened :)

> change forgotten passwords and add new principals, perhaps to extract

Of course. And an attacker can use this to DoS you if they get access to
the KDC, but you can then just restore that database. Whereas if the
attacker can get at the keys, in cleartext, then you have to re-key your
realm as the attacker can now continue forge tickets long after losing
access to the KDC until you re-key your realms.

Nico
--

---

From: "Booker C. Bense" <[email-masked]>
Date: Fri, 22 Sep 2000 18:01:57 -0700 (PDT)

On Fri, 22 Sep 2000, Nicolas Williams wrote:

[ Lotsa stuff about secure coprocessors deleted]
> discussed in the password changing service protocol discussion.

- It does from my point of view. Until you've precisely defined
  all your terms, it's just open too way to much interpretation. 
  Just what is and isn't the "KDC"?

> Why is my request a problem then?

- For one, it would establish a precedent about RFC's prohibiting 
  the future development of something totally outside the scope of
  the given RFC. At best I think you can only make a BCP style
  recommendation. 

- For two, all the wording choices you've used so far don't
  really address the issue very well. You can't be fuzzy or vague
  in an RFC, as we have already seen vendors will look for the
  smallest loophole. It isn't a matter of just adding a few
  sentences. 

> do with the Kerberos protocol itself.

- If it's not defined in the RFC or some other RFC then you can't
  reference it in a document. You'll need to come up with a
  precise definition of all of the terms you've used above to add
  the prohibition that you want. Until you have some precise
  language about what can and can't be accessed, this is all just
  so much handwaving. From my perspective that should really
  be left to another RFC altogether. 

> Wrt your 'IIRC', I wasn't around when what remember happened :)

- That's why he's recalling it for you. 

> access to the KDC until you re-key your realms.

- I don't think there is any disagreement on the benefits of the
secure co-processor work ( modulo my initial thick-headness.)  It
does greatly improve the security of the KDC, however that is not
the only security threat to the kerberos system. Root level
breakins to the KDC's are a very bad thing, but how often do they
happen in real life? Bad admins are a much more realistic
threat. And if you don't have a secure co-processor machine, this
prohibition doesn't improve your security at all.

- To my mind there is a much more serious threat to kerberos
systems, if you have a principal in the system you can mount an
offline dictionary attack on any service ticket that you
get. Once you have this service key, you have carte-blanche to any
resources that service can access. After all, this is what anyone
cracking your system is really after, the resources protected by
kerberos.  The keys in the KDC are just a step to getting that,
they aren't the crown jewels.

- The only way to combat this is to regularly update your service keys
and to have the best random data you can get in those keys[1].  Any
prohibition that would limit the means of doing this is should be
avoided in my opinion. Ideally, I would like to have the option to
have the KDC push out new keys to the servers every 8 hours. I think
you could do this and still have the advantages of the secure
co-processor work, but I can't see how you can write language that
can't be twisted back to prohibit such kinds of systems. Writing RFC's
is nearly as bad as writing laws, you can have the best intentions,
but if you aren't really precise about the language you can generate
the exact opposite of your intended goals[2]. After all the goal of
the first RFC was to allow any conforming KDC to be interchangeably be
used with any other conforming KDC and we've all had our noses rubbed
in how bad that went wrong.....

- Booker C. Bense 

[1] - Generating crypto quality random data is hard. From what 
    I've seen most current implementations could stand some 
    work in this area. 

[2] - For a really good example of this look into the "work-in"
    loft tax exemption in San Francisco. It was intended to keep
    artists in the city, but now is driving them out at a record
    pace.

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 25 Sep 2000 11:53:08 -0400

>   Just what is and isn't the "KDC"?

"Protocol designers and implementors should beware that designing any
protocol which makes it possible to extract principals' active secret
keys, unencrypted (not including session encryption) from a KDC may
prevent the use of tamper-proof hardware for securing KDCs."

>   the given RFC. At best I think you can only make a BCP style

Originally I asked for an admonition. A prohibition would be stronger,
sure, but we're talking about wether an implementation can be said to be
compliant with the Kerberos 5 Specification 2 standard. There's plenty
of MUST and MUST NOT language in the draft already.

>   smallest loophole. It isn't a matter of just adding a few

See the language I propose above. The fuzzy bit there is "active secret
keys, unencrypted." Is that too fuzzy?

>   be left to another RFC altogether. 

I did not mean to add mention of database master keys to the RFC. I
never said the RFC should mention database master keys. Of course, the
"unencrypted (not including session encryption)" bit in the language I
propose above is an indirect reference to database master keys. I think
this is acceptable.

...
> - That's why he's recalling it for you. 

Come now. I had a smiley there. "IIRC" stands for "if I remember
correctly", which I took as an invitation to confirm the memory that
followed.

...
> prohibition doesn't improve your security at all.

It's not "how often are KDCs breached?" it's "how bad is it if a KDC is
breached?" And the answer is "pretty bad: you must re-key your
realm(s)."

If you don't now use tamper-proof hardware to secure the keys stored in
your KDC you might still desire to do it later.

> they aren't the crown jewels.

If you get one service principal's key you get access to the services
and resources represented by that principal. If you get access to all
the principals in a realm then you get access to all the services and
resources normally protected by Kerberos authentication. That's a pretty
big difference, one of scale, yes, but huge scale.

> in how bad that went wrong.....

Why doesn't the "on hold" keys proposal satisfy your keytab
synchronisation issues?

Why, if you can't extract active keys from your KDC now, do you think
that you'll need to later?

Here's where the meaning of "active" in the language I propose at the
top of this message comes into play. "Active" means that the key has
been distributed and is now being used. Thus distribution of keys from
the KDC to the clients is NOT precluded.

>     I've seen most current implementations could stand some 

Again. I maintain that the language I've proposed does NOT preclude the
genration of random keys on the KDCs for distribution from there.

>     artists in the city, but now is driving them out at a record

The law of unintended consequences. Absolutely. The law (read 'RFC') can
be changed. :)

Anyways, a warning, as opposed to a prohibition should do.

Nico
--

---

From: Ken Raeburn <[email-masked]>
Date: 25 Sep 2000 16:53:18 -0400

Nicolas Williams <[email-masked]> writes:
>[...]

Actually, I don't disagree with the recommendation you suggest adding
to the draft.  I do disagree with your assessment of the situation
regarding Itoi's work with tamper-proof coprocessors, and the damage
control needed after an attack.

The tamper-proof cards could still be used as slave KDCs in insecure
locations even if key extraction is permitted (implemented on the
card, including ACL checks, of course, and probably requiring use of a
secure networked logging facility before returning any data).  If you
trust your administrators' accounts not to be compromised, at least.
Or if the extraction is only permitted from *other* KDCs, perhaps only
the master KDC in the MIT model.  (As I recall, his work didn't really
touch on administrative functions or other changes to the database,
and for that and other reasons is IMHO incomplete for use as a KDC in
an insecure environment.)

As far as re-keying after a compromise of an administrator's account:
If you've got secure logging of the operations performed by the
administrator, you've got a list of principals that need re-keying.
If you don't, you need to re-key any principals with interesting
privileges anyways (and all users, if you want to be paranoid), unless
key extraction is not allowed *and* the old key is confirmed to still
be the active one by the owner of the account.  Even if key extraction
isn't permitted, a compromised administrative account might be used to
set the password on *another* administrator's account, perhaps one who
is on vacation and won't be able to notice and report a problem with
her account for another month after the first compromised account is
detected; or perhaps a less directly privileged account that has write
access to some files used by an administrator, etc.

And yes, the privileges to changes passwords for administrators might
be restricted to one or two super-administrators, but the privilege to
extract keys of various sorts should also be restricted, and that
should be factored into any analysis of such attacks.  (E.g., your
average user-account administrator doesn't need the ability to extract
or change the keys for your primary file servers.  And probably no one
should be allowed to extract the current key for the secure logging
facility used to track key extractions, or the master key, or a few
others.)

The only thing fixed by disallowing extraction of current, active keys
is the ability for the intruder to break into an account without the
account owner noticing.  Damage can still be done until the breakin is
noticed (or a routine password change is done), and secure logging
from the KDC will still indicate a set of changes made.

Being able to extract only not-yet-active keys significantly reduces
the window of attack, but it's still there.  If the attacker can get
that key, then wait until it's activated....

> obviously must be available not encrypted in the database master key

This strikes me as circular.  If you say it's okay to break with the
constraint of keys outside the coprocessor always being encrypted in
the master key because obviously there's this list of cases where it
can't be, and then complain because another situation breaks with the
constraint, well, maybe that situation should be on your list of
exceptions too.

Pardon the rhetoric, please.  As I said, I agree with your
recommendation, I just don't agree with your arguments in support of
it or your descriptions of the damage potential.

> Wrt your 'IIRC', I wasn't around when what remember happened :)

Actually, I'm not sure if that was the original reasoning -- all the
initial work was done at OV and I wasn't part of it -- but it's the
main argument I've heard put forth in favor of keeping it this way.

Ken

P.S.  Regarding Booker's comments on the appropriateness of such
recommendations for this RFC, perhaps much or all of section 4 should
be made a separate RFC?

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 25 Sep 2000 22:12:49 -0400

...
> it or your descriptions of the damage potential.

Hey, I just got it anyways. I've been missing a silly point. That is: of
course key extraction would require proper authentication to the KDC and
if you're using tamper-proof hw you're talking about moving large parts
of the KDC into the tamper-proof hw, including authentication of KDC
clients. Thus, even if you can extract keys from the KDC, as long as you
must authenticate to the crypto co-processor and it is safe then your
keys are as safe as they can be (you still have to mind your password
quality, enc-types, key distribution, host security, etc...). Doh.

It was something you wrote above and which I have deleted (doh) which
made me realize this.

So, strike my request on this issue; I hereby withdraw it.

> main argument I've heard put forth in favor of keeping it this way.

Yeah, probably. Thanks anyways :)

> recommendations for this RFC, perhaps much or all of section 4 should

Well, I'd asked that a statement be made that Section 4 is purely
informational, a guideline, not a standard.

Nico
--

---

From: "Booker C. Bense" <[email-masked]>
Date: Tue, 26 Sep 2000 11:25:45 -0700 (PDT)

> informational, a guideline, not a standard.

- There are a few things in there that need to be something like a
standard. At a minimum you need to define the semantics of things like
key version numbers, if you ever hope to have any kind of
interoperablity. RFC's have traditionally ignored the implementation
details and only been concerned with what goes over the wire, thus
they don't have a good vocabulary for making application design
decisions. This is really what Section 4 talks about, I think it's 
a useful addition to the RFC. 

- Booker C. Bense

---

From: "Douglas E. Engert" <[email-masked]>
Date: Fri, 29 Sep 2000 13:44:08 -0500

So are you two now in agreement?  

Can both of you summarize for the list any changes to the document 
you are proposing after this discussion on section 4?

-- 

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

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 29 Sep 2000 14:49:45 -0400

I withdraw my comments on Section 4.

Nico

--