Subject: Issues with draft-ietf-cat-kerberos-set-password-03

From: Sam Hartman <[email-masked]>
Date: 08 Aug 2000 01:16:38 -0400

I wanted to bring up the issues I brought up at the meeting on the
list as well as to  bring up one additional issue.

* The draft now makes explicit use of ASN.1.  One anti-requirement of
   Marc's original protocol was to avoid complex encodings like ASN.1.
   The protocol should be implementable without access to a genal
   ASN.1 parser/generator.  The Kerberos library may not expose this.
   This change should have been mentioned and should be discussed by
   the WG.

* I requested  that a method be added to randomize the principal's
  key, or to randomize a specific principal's key.   The requests
  taking specific principals rather than the authenticated principal
  are administrative in nature.  The server should return the random
  keys in the specified enctypes.

* I asked that text be added strongly recommending that rather than
  setting a key at the client, the client request a random key.    The
  client might be able to contribute to the random key.
  Implementations should be encouraged to allow setting a specific key
  to require more privilege than randomizing a key.

* A suggestion  at the WG meeting was  that the server be allowed  to
  return a different key (randomizing it) even when the client
  requested a set key or change key.  This is a bad idea, because for
  example when you are trying to synchronize two servers, you want to
  force the key to a certain value or  have a clean failure.

* I asked whether we really wanted the set key and set password
  functions  in this rather than having it specified in some admin
  protocol.  I have become convinced that we do want these functions.

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 8 Aug 2000 02:59:56 -0400 (EDT)

>   keys in the specified enctypes.

This is definitely desirable.  Such a feature would be used to set random
keys for services, and to allow service keys to be changed to new random
values (equivalent of 'ksrvutil change').

When this feature was suggested, I spoke up and requested that this not
take the place of being able to set/change the key to a specific value. 
As Sam notes, the latter ability can be important when trying to keep keys
for two services in sync, such as when setting up a cross-realm trust
relationship.

Still, I agree that clients should set specific keys only in rare
circumstances, such as when a specific key value is required.  If a random
key is required, it should come primarily from the server/KDC, which is
presumed to have a good source of random keys and to be easy to update if
a problem is found.  If a password is to be used, the client should not
perform its own string-to-key operations, since it may not know all of the
relevant algorithms. 

Further, implementations may want to restrict set/change key operations to
privileged users or prohibit them altogether.  In fact, as Sam suggests,
they should be strongly encouraged to do so.

>   protocol.  I have become convinced that we do want these functions.

I do believe that we should eventually consider developing a standardized
admin protocol.  At the WG meeting, I was willing to accept that some of
the proposed functionality in the set-password protocol might more
properly belong in an admin protocol.  However, I now believe that these
features are important enought to deserve more timely and widespread
implementation than a full admin protocol is likely to enjoy.

The obvious issue is that the change-password operation should be possible
to implement in virtually anything that does initial authentication using
user passwords.  For example, a terminal server may want to provide this
ability.  Such devices are likely to be deployed independent of the KDC
implementation in use in any given realm and are likely to have relatively
limited capabilities; thus, a simple standard protocol is desirable.

In addition, I see another class of users who are likely to benefit from a
standard set/change protocol.  Those are accounts administrators, help
desk staff, and the like -- users who are privileged to deal with password
change requests, keying new hosts, and so on, but are not general kerberos
adminstrators.  It may be desirable for these users to use clients other
than the normal adminstrative utilities provided with the particular KDC
in use.

-- Jeffrey T. Hutzelman (N3NHS) <[email-masked]>
   Sr. Research Systems Programmer
   School of Computer Science - Research Computing Facility
   Carnegie Mellon University - Pittsburgh, PA

---

From: [email-masked] (Johan Danielsson)
Date: 08 Aug 2000 15:53:51 +0200

Jeffrey Hutzelman <[email-masked]> writes:

I also strongly feel that we should *not* use ASN.1. Marc's original
draft was very simple, and I'd hate to see that turn into a monster of
complexity.

> If a password is to be used, the client should not perform its own
> string-to-key operations, since it may not know all of the relevant
> algorithms.

There are situations where you actually want to set a specific key (be
it from a password or not), and I don't think it's necessary to forbid
this functionality. It should be enough to explain the consequences,
and make it configurable.

A real standardised administrative protocol would be a good thing.

/Johan

---

From: Ken Hornstein <[email-masked]>
Date: Tue, 08 Aug 2000 12:45:57 -0400

>and make it configurable.

I agree.

>A real standardised administrative protocol would be a good thing.

I'm not sure.  That dives into things like "principal attributes", which
I think would be a GIANT can of worms.  I think standardizing on password
changes is good enough.

Or, hey, we could just store our KDC in LDAP and use LDAP tools to do
administration :-) (ok, ok, I'm kidding).

--Ken

---

From: [email-masked] (Johan Danielsson)
Date: 08 Aug 2000 19:13:46 +0200

Ken Hornstein <[email-masked]> writes:

> I'm not sure.  That dives into things like "principal attributes",
> which I think would be a GIANT can of worms.  I think standardizing
> on password changes is good enough.

Never said it would be easy, did I? :-)

> Or, hey, we could just store our KDC in LDAP and use LDAP tools to
> do administration :-) (ok, ok, I'm kidding).

No kidding, people are doing that. There's an OpenLDAP backend for
Heimdal.

/Johan

---

From: Sam Hartman <[email-masked]>
Date: 08 Aug 2000 13:27:38 -0400

>>>>> "Johan" == Johan Danielsson <[email-masked]> writes:

    Johan> There are situations where you actually want to set a

I argue that you should never use change key/set key if you are
setting a key based on a password.  This prevents the server from
doing password quality checks.  However, as you point out, there are
times when you want to set a key or change to a key that is not based
on a password.  Thus the protocol needs to support this functionality.

I believe the standard configuration (as a matter of policy, possibly
recommended by the document) should allow any principal to change its
key to a password or to a random key.  Certain principals should be
allowed to change to a client-specified key--for example cross-realm
principals.  Certain administrative users should be able to force
change the key or password of other principals.  Obviously
implementations may have more flexible configuration but should
support this basic setup.

---

From: "Booker C. Bense" <[email-masked]>
Date: Tue, 8 Aug 2000 11:34:12 -0700 (PDT)

> administration :-) (ok, ok, I'm kidding).

- I'm not kidding[1]. I think that's generally a really good idea,
however if you are going to follow that approach, you really want
a seperate passwd changing protocol.

- I noticed that there was a proposal for this on the agenda. 
Was it discussed seriously?

- Is there a URL for the hiemdal openldap backend ?  

- Booker C. Bense 

[1] http://www.stanford.edu/~bbense/ldapK5admin/

---

From: Love <[email-masked]>
Date: 08 Aug 2000 20:49:06 +0200

> - Is there a URL for the hiemdal openldap backend ?  

http://www.padl.com/~lukeh/heimdal/

Love

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 8 Aug 2000 17:39:24 -0400 (EDT)

> Was it discussed seriously?

Actually, it was presented more as a description of something someone was
doing than as a proposal on which the WG was expected to take any action.
There were some comments, mostly to the effect that this was a bad idea.
The description presented at the meeting included storing Kerberos
principals' keys in the LDAP server, which has serious security
implications.  Even storing non-key data in LDAP has the potential for
problems if the implementation is not careful to ensure that such data
is always stored and transferred in an integrity-protected manner
(including for the purpose of backups).  There are also some performance
implications in storing KDC data somewhere other than on the KDC.

---

From: "Booker C. Bense" <[email-masked]>
Date: Tue, 8 Aug 2000 15:10:08 -0700 (PDT)

> implications in storing KDC data somewhere other than on the KDC.

- Well, it sounds like that's not what I'm envisioning at all. 
What I was considering would be much more like a version of 
kadmind that spoke ldap, rather than integrating the KDC and 
a general purpose LDAP server al a Microsoft. This is
a bad idea for many reasons. 

- I don't want to keep keys in anything other than the 
"standard" kdc database. I just want an ldap protocol 
interface into that database. This seems to me quite
different from what I've seen discussed so far. 

- There are two big reasons that I think this would
be useful. 

1. It's one less set of protocols tools needed for automatic
   account creation. 

2. There is some chance that you could also admin the ACL's
   for a given key via this fashion. For user principals
   this is not that much of an issue, but for service principals
   you really need a scaleable way to address the problem of "who can
   download keytab foo/host ?" 

-Lastly, it gives you a large body of already done work on 
replication. This might or might not be useful, but it's 
certainly a place to start. 

- Booker C. Bense

---

From: [email-masked] (Johan Danielsson)
Date: 09 Aug 2000 15:20:31 +0200

Sam Hartman <[email-masked]> writes:

> setting a key based on a password.

Cross-realm keys where you can't control how the keys are generated
will never work.

/Johan

---

From: Ken Hornstein <[email-masked]>
Date: Wed, 09 Aug 2000 10:45:07 -0400

>Cross-realm keys where you can't control how the keys are generated

I'm not sure I understand your objection; if you're doing cross-realm,
then you either set the key or the password, depending on which one
you were given.  I think Sam's only saying that you shouldn't use
set key if you were given a password originally (which I agree with)
and thus, set key should be restricted to administrators.

--Ken

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 9 Aug 2000 13:00:57 -0400 (EDT)

> Cross-realm keys where you can't control how the keys are generated

To be strong, cross-realm keys should be randomly-generated by one KDC,
and then setkey'd into the other KDC.  Ideally, each KDC should generate
the key for one direction.  This process insures strong, random keys
(something that cannot be done with a randomly-generated password), and
does not violate Sam's assertion above.

Sam is right -- setkey/changekey should not be used on keys that were
derived from a password.  Instead, the changepw service should be given
the password, so that it can implement password policy checks and (if such
checks pass) generate keys for all the enctypes and salts that it knows
about.  Cross-realm keys would not be set using this method, because they
should not be derived from passwords.

---

From: Sam Hartman <[email-masked]>
Date: 09 Aug 2000 15:53:08 -0400

>> setting a key based on a password.

    Johan> Cross-realm keys where you can't control how the keys are
    Johan> generated will never work.

And cross-realm keys should not be generated from passwords.  We do
this because it is convenient, not because it is secure.  

But we digress from the purpose of this WG.  Both of us agree that the
protocol should have a function allowing a client to set a specific
key and that there should be some access controls on this function.

---

From: Ken Raeburn <[email-masked]>
Date: 10 Aug 2000 01:23:33 -0400

Jeffrey Hutzelman <[email-masked]> writes:
> (including for the purpose of backups).

I might've mentioned this before, but this issue bears some
resemblance to a project that someone at UMich(?) was looking into,
though I haven't heard anything about it lately.

His idea was to put the critical parts of the KDC (those dealing with
key data, checksums and encryption, primarily) on a tamper-proof card,
and the rest (including the network i/o and the database) on an
ordinary PC class system, which wouldn't need to be protected much.
Assuming the card really is tamper-proof, all you would be able to get
out of it is standard KDC functionality; trying to get other info out
or alter the software would result in the destruction of the keys
needed to decode the database.

The key to both problems is verifying the integrity of the entire
database, when it might be under some degree of outside control, and
ensuring that the database without the critical keys is sufficiently
useless to an attacker.  It's an interesting challenge....

---

From: Ken Raeburn <[email-masked]>
Date: 10 Aug 2000 02:20:50 -0400

Jeffrey Hutzelman <[email-masked]> writes:
> a problem is found.

If we don't make the use of KDC-supplied data a requirement to be
enforced by the KDC -- and given that the client could simply divulge
its key to the world if it wanted, I don't see why we should -- it
actually seems like an easy problem to solve, using the set-key
message.  If the client doesn't need to set the key to a specific
value, it's already got some KDC-supplied data it "SHOULD" use in
client-side key generation.

It's called a session key.

Ken

---

From: Sam Hartman <[email-masked]>
Date: 10 Aug 2000 15:40:47 -0400

>>>>> "Ken" == Ken Raeburn <[email-masked]> writes:

    Ken> Jeffrey Hutzelman <[email-masked]> writes:
    >> Still, I agree that clients should set specific keys only in
    >> rare circumstances, such as when a specific key value is
    >> required.  If a random key is required, it should come
    >> primarily from the server/KDC, which is presumed to have a good
    >> source of random keys and to be easy to update if a problem is
    >> found.

    Ken> If we don't make the use of KDC-supplied data a requirement
    Ken> to be enforced by the KDC -- and given that the client could
    Ken> simply divulge its key to the world if it wanted, I don't see
    Ken> why we should -- it actually seems like an easy problem to
    Ken> solve, using the set-key message.  If the client doesn't need
    Ken> to set the key to a specific value, it's already got some
    Ken> KDC-supplied data it "SHOULD" use in client-side key
    Ken> generation.

    Ken> It's called a session key.

First, this breaks in cases wher you don't have a dense key space; you
cannot extract the random bits.  This may be a problem if yo,you are
setting a key for an enctype different than your session key.

Secondly, I want the ACL on change-key to be different than
randomize-key.

---

From: Ken Hornstein <[email-masked]>
Date: Thu, 10 Aug 2000 15:45:54 -0400

>setting a key for an enctype different than your session key.

Ow.  I keep forgetting about that one.  My first thought is to feed the
key through something like MD5 or SHA-1, but I suspect crypto people
will run screaming from that.

>Secondly, I want the ACL on change-key to be different than

Definately.

--Ken

---

From: Ken Raeburn <[email-masked]>
Date: 10 Aug 2000 18:41:07 -0400

> will run screaming from that.

Actually, that's exactly what I'd do in that case.  (Or just do it
always, so you don't have to think about the specific cryptosystem.)
With a good key generation function (for which sha1 might be a first
step), it wouldn't be the randomness of individual bits, but the large
number of possible inputs.

However, if the input key space is not dense, it may not give a
desirable degree of randomness you want for generating new keys of a
different type.  But a second AS_REQ/TGS_REQ to the KDC may help with
that... :-)

Hm, another reason for KDC-generated keys comes to mind.  In small
devices, you may not want to add the key-generation code for some
cryptosystems that may be big and/or time-consuming.  I don't want my
TV remote or cell phone to lock up for 15sec when I hit the "rekey"
button.  And depending on the desired key types, you may not want to
simply re-use the session key as the new key, so you would need real
key generation somewhere.

> >Secondly, I want the ACL on change-key to be different than

Why?
I'm curious ... right now, I'm just failing to come up with any cases
where the difference is important.  There probably are cases, I'm just
blanking on them.

---

From: Ken Hornstein <[email-masked]>
Date: Fri, 11 Aug 2000 00:51:43 -0400

>Hm, another reason for KDC-generated keys comes to mind.

Oh, I think there are _plenty_ of reasons for KDC-generated keys.
No argument there.

>where the difference is important.  There probably are cases, I'm just

I want principals to be able to re-randomize themselves (think automatic
host principal rekey every month).  Like you can do now with "ktadd"
inside of kadmin.

--Ken

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 11 Aug 2000 03:02:15 -0400

> host principal rekey every month).  Like you can do now with "ktadd"

Actually, doing that with randomize-key could be dangerous.  What happens 
if a host re-randomizes its host key, and then crashes before writing the 
new key to disk?  For that application, I think it is probably better to 
generate a new random key (or get the KDC to do so), add it to the keytab 
on disk, and then change it in the KDC.

-- Jeff

---

From: Sam Hartman <[email-masked]>
Date: 11 Aug 2000 14:00:22 -0400

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

    Jeffrey> On 08/11/00 00:51:43 -0400 Ken Hornstein
    Jeffrey> <[email-masked]> wrote:

    Jeffrey> Actually, doing that with randomize-key could be
    Jeffrey> dangerous.  What happens if a host re-randomizes its host
    Jeffrey> key, and then crashes before writing the new key to disk?
    Jeffrey> For that application, I think it is probably better to
    Jeffrey> generate a new random key (or get the KDC to do so), add
    Jeffrey> it to the keytab on disk, and then change it in the KDC.

No, I don't want hosts to have access to generate their own keys
because they might generate weaker keys and they don't need the
access.

You do have a ticket valid for a bit of time to rekey the host.  If
you run into problems during that time, you can re-use the ticket.

---

From: Ken Hornstein <[email-masked]>
Date: Fri, 11 Aug 2000 14:48:23 -0400

>you run into problems during that time, you can re-use the ticket.

I'm not sure that alleviates Jeff's concern; if the host crashes after
the point at which it got a new ticket from the KDC but before you've
written it to disk, you're still going to lose.  Okay, you could run
something at boot time that notices that a rekey failed and could reuse
an existing ticket, but that sounds dicey.

Personally, I'm willing to live with that small window of vulnerability.
I think the only way of solving it properly would be to do some sort
of 2-phase commit protocol.  e.g.

- Start transaction
- get new random key
- write/flush to disk
- Commit transaction

If the connection to the admin server times out before you get a commit,
then rollback the transaction.

--Ken

---

From: Ken Raeburn <[email-masked]>
Date: 14 Aug 2000 05:06:36 -0400

> host principal rekey every month).  Like you can do now with "ktadd"

Sure, and that's completely doable with keys created and set by the
client, if the client-side key generation (with input from the KDC) is
good enough.

> because they might generate weaker keys and they don't need the

I wouldn't suggest putting set-key into the protocol without also
putting forth a recommendation for a *good* key generation scheme.  At
least for dense-keyspace algorithms, it shouldn't be that hard.  (I
don't know much about key generation for other types of algorithms,
but as Sam pointed out to me, at the very worst, you can map a dense
space of generated bytes to the /dev/random values used in the
generation of keys for arbitrary algorithms.)

Of course, those of us producing Kerberos distributions can just
provide the software...

---

From: Ken Raeburn <[email-masked]>
Date: 14 Aug 2000 05:14:51 -0400

> an existing ticket, but that sounds dicey.

It also doesn't work if the password-changing server goes off the air
at the wrong time, e.g., for planned maintenance that'll take longer
than the window the ticket's valid for.

Or if the sysadmins (on either end) are performing stupid firewall
tricks, like blocking the reply from the password-changing service but
not the request to it.

> of 2-phase commit protocol.  e.g.

This sounds like a far better solution to me, if we need to get the
random key from the KDC as a separate exchange.

---

From: Ken Raeburn <[email-masked]>
Date: 14 Aug 2000 05:26:47 -0400

> putting forth a recommendation for a *good* key generation scheme.  At

It occurs to me, this is still more complicated than it needs to be.
It could be as easy as requesting a session key of the appropriate
type, and using it as the new key.

Ken

---

From: Ken Hornstein <[email-masked]>
Date: Mon, 14 Aug 2000 14:58:53 -0400

>client, if the client-side key generation (with input from the KDC) is

This is implementation specific, buuuttt ....

Right now in the MIT code, principals can rekey themselves without any
problem (because "randomize key" and "change password" have the same
access control, and there is no "set key").  That's fine.

I think everyone agrees allowing arbitrary clients to use "set key"
is bad (because it gets around password policy restrictions).  But I want
to allow arbitrary clients to use "randomize key" at will (well, okay,
it's not completely arbitrary, but it's varied enough that I don't
want to have to mark those explicitly with ACLs).

And if we continue to allow clients to do "randomize key", this means I
can get better-quality random keys for services without having to upgrade
client software.

--Ken

---

From: Derek Atkins <[email-masked]>
Date: 14 Aug 2000 17:32:09 -0400

Perhaps this requires three functions:
	change/set password
	randomize key
	set key

It is clearly "safe" to allow any principal to use the first two
functions (although a user that randomizes their own key will probably
lock themselves out of the system ;) Clearly, you do want to limit the
third option, and I would propose that this third option should be
limited to administrators of the kerberos realm, or have its own acl.

Setkey seems only relevant (if you split off randomize key) for
syncronizing two different authentication systems (e.g., cross-realm).

Does this separation solve your problem?

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/      PP-ASEL      N1NWH
       [email-masked]                        PGP key available

---

From: Ken Hornstein <[email-masked]>
Date: Tue, 15 Aug 2000 00:34:10 -0400

>limited to administrators of the kerberos realm, or have its own acl.

Agreed.

>Does this separation solve your problem?

Yes.  You've said exactly what I've been trying to say, just more
clearly :-)

--Ken

---

From: Ken Raeburn <[email-masked]>
Date: 16 Aug 2000 02:22:35 -0400

Derek Atkins <[email-masked]> writes:
> lock themselves out of the system ;)

I was originally thinking that no single principal would be a good
logical candidate for both set-password and randomize-key, but it
occurred to me that we could let someone put her key into a keytab
(perhaps on a smartcard) and then randomize it.  Which leads to the
next question, can such a person get back to having a known password?
If the service allows a set-password request from a user whose current
key is not password-derived, she can.

This isn't really a protocol issue, but something for implementors to
think about.

> > is bad (because it gets around password policy restrictions).  But I want

Yes, this definitely convinces me, and was the thing I was missing.