Subject: [Ietf-krb-wg] Information Model: aliases and keys

From: Sam Hartman <[email-masked]>
Date: Thu, 04 Dec 2008 09:22:26 -0500

One of my assumptions when looking at the information model is that
all aliases of a principal shared the same keys.  That's how I define
the difference between an alias and another name.

However I've realized that this model works for clients and it works
for services assuming that services are keyed with random keys.

It does not work well for services keyed with passwords.  It assumes
that either the service knows the canonical name of its principal--the
one used to salt the key, or that aliases use different keys because
they are salted with the alias name.

I think that we need to be clear in the information model what's going
on here and which model of aliasing is going on.

_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Ken Raeburn <[email-masked]>
Date: Thu, 4 Dec 2008 10:15:27 -0500

> they are salted with the alias name.

Or that the service knows the salt string to use, which lets it  
recreate the key without reference to a principal name.

Or that you're using a cryptosystem like RC4 where we don't use the  
salt string.

Ken

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 04 Dec 2008 11:20:07 -0500

> on here and which model of aliasing is going on.

[speaking without a hat]

I think your model of what constitutes an alias is to stringent.  I think 
it's reasonable to have a single principal with a potentially large number 
of names, where the specific key used may be derived from the name, but 
other attributes such as expiration date, supported enctypes, ticket 
lifetime, etc are all shared.

I think perhaps the problem with the model is the assumption that the 
Kerberos database stores individual keys with specific values for use with 
specific enctypes.  This is inconsistent with some existing implementations 
in which the database actually stores passwords which are used to 
dynamically generate keys for whatever enctype and salt string are needed.

I think if you update the model to recognize that the KDB may contain 
password(s) for a principal instead of or in addition to keys, then the 
problem you describe goes away.

-- Jeff

---

From: Tom Yu <[email-masked]>
Date: Thu, 04 Dec 2008 11:33:15 -0500

> problem you describe goes away.

I think the persistence of the assumption that the KDB contains keys
rather than passwords is due to some people (myself included)
believing that storing passwords in the KDB is a poor security
practice.  I might even feel strongly enough about it that I would
want the risks of storing passwords in the KDB called out in a
Security Considerations item.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Sam Hartman <[email-masked]>
Date: Thu, 04 Dec 2008 11:39:32 -0500

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

    Jeffrey> I think if you update the model to recognize that the KDB
    Jeffrey> may contain password(s) for a principal instead of or in
    Jeffrey> addition to keys, then the problem you describe goes
    Jeffrey> away.

Sort of.  I think the information model needs to carry enough
information so that I can figure out what's going on.

As we're discovering over in implementation land, the way you think
about this affects interoperability.  IN particular, I'm beginning to
come to the conclusion that if you want to support aliases and need to
deal with implementations that store passwords in the KDB, then
everyone needs to support password as key.  That has a huge impact on
the abstract model of how we think about Kerberos keying and on what
you need to do in order to implement an interoperable service.

To the extent that this working group takes up modeling aliases, I
want it to take up giving implementers enough information that we can
successfully implement interoperable services and clients.  I don't
think simply saying that "some kdbs may store passwords," does that.
It may be part of a solution though.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Sam Hartman <[email-masked]>
Date: Thu, 04 Dec 2008 11:41:08 -0500

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

    Ken> On Dec 4, 2008, at 09:22, Sam Hartman wrote:
    >> It does not work well for services keyed with passwords.  It
    >> assumes that either the service knows the canonical name of its
    >> principal--the one used to salt the key, or that aliases use
    >> different keys because they are salted with the alias name.

    Ken> Or that the service knows the salt string to use, which lets
    Ken> it recreate the key without reference to a principal name.
Right.  But my point is that the abstract information a service needs to know ends up changing in a universe with aliases.

    Ken> Or that you're using a cryptosystem like RC4 where we don't

Sadly that only works for rc4.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 4 Dec 2008 12:59:09 -0600

> on here and which model of aliasing is going on.

I'd like to divide aliases into two kinds: a) those resulting from
different Unicode normalization and case, or from applications of IDNA
toACE(), b) those where the alias name differs from the canonical name
in other ways that cannot be tested for programmatically by an
implementation.

Aliases of type (a) can share keys, and probably should, otherwise
searching for an appropriate key in a keytab gets slow (you have to do
up to N * 2 crypto operations, not just N, for N keytab entries, where
the ops are string2key and decryption).

Aliases of type (b) could share passwords.  The fact that one KDC
implementation uses this approach means that clients must be prepared
for it.

Of course, aliases of type (b) can be implemented as distinct principals
in a KDC that doesn't support associating a list of aliases with a
principal.  And servers can just maintain keytab entries for all their
aliases, whether they be genuinely treated as aliases by the KDC or not.

Which means that the Information Model:

 - should not concern itself with aliases of type (a), except in so far
   as to represent whether a KDC allows them or not;

 - needs to model aliases of type (b) with password sharing, and the
   cleanest model for that is:

    - aliases are distinct principals with a link to their canonical
      principal;

    - there needs to be a way to search for principals which are aliases
      of a given principal.

Nico
--

---

From: "Henry B. Hotz" <[email-masked]>
Date: Thu, 04 Dec 2008 11:28:31 -0800

> you need to do in order to implement an interoperable service.

I guess I need a bit of elaboration here.  Absent aliases, I don't see 
the password vice keys issue as externally significant.

Is it only the combination of the two that you're finding difficult?

I can see the issue of alias-name-salted keys for each and every alias 
as being needed if you have something that wants to authenticate to the 
alias directly with a password (vice TGS or keytab).  Also if you want 
to add aliases without updating the password at the same time.

Does it break too many interoperability scenarios if you prohibit direct 
use of the password with alias names?  Or only allow it in scenarios 
where the KDC can deliver the correct salt?

-- 
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
[email-masked], or [email-masked]
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 4 Dec 2008 13:21:33 -0600

> Security Considerations item.

When the password is long and randomly generated (as would be the case
for service principals), there's not much (any!) distinction between
"password" and "key" as far as the security of the KDB goes.

Of course, the KDC may not be able to tell the difference between a
password that a) is strong (long and randomly generated) and b) not
reused elsewhere.  Which gets us back to your concern.  The KDC could
use other clues to make that distinction, of course (e.g., the type of
the principal, the operation used to set its password, whether the KDC
generated the password, ...).

If we also assume that users will never have aliases other than those
which differ from the canonical name by case and normalization only,
then we're probably in good shape with respect to KDB security even if
the KDB stores passwords for non-user principals.

Nico

---

From: Sam Hartman <[email-masked]>
Date: Thu, 04 Dec 2008 15:57:48 -0500

Nico, I find myself in disagreement with most of your conclusions, and
don't think you explained your thinking enough that I can figure out
where things went wrong.

In particular:

* I don't see why aliases should be split into multiple types.  If we
  can avoid doing so it is desirable not to have to sync
  canonicalizations between the KDC and service.  So I don't see why
  one form of programmatic transformation should be special cased.

* I don't in general see why unicode makes the number of keys you need
  to try larger.

* I don't see why we should prefer password-based aliasing.  I'm
beginning to see an argument why we should support it, but I generally
agree with Tom on this issue.

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 4 Dec 2008 15:11:29 -0600

>   one form of programmatic transformation should be special cased.

Because the kind that differ in case or normalization need not
necessarily be covered by the information model.

> * I don't in general see why unicode makes the number of keys you need

Huh?

> agree with Tom on this issue.

My reply to Tom's security consideration issue was thoughrough.  Perhaps
you could answer it thoughroughly rather than dismiss it.  For example,
you might argue that there's no reliable way for the KDC to distinguish
between user passwords and randomly-generated-passwords-for-the-purpose-
of-generating-keys, and then explain why the mitigations I offered
aren't sufficient.

Nico

---

From: Sam Hartman <[email-masked]>
Date: Thu, 04 Dec 2008 16:26:11 -0500

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

    Nicolas> If we also assume that users will never have aliases
    Nicolas> other than those which differ from the canonical name by
    Nicolas> case and normalization only, then we're probably in good
    Nicolas> shape with respect to KDB security even if the KDB stores
    Nicolas> passwords for non-user principals.

Most implementations expect to routinely violate this assumption.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Sam Hartman <[email-masked]>
Date: Thu, 04 Dec 2008 16:31:44 -0500

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

    Nicolas> On Thu, Dec 04, 2008 at 03:57:48PM -0500, Sam Hartman
    Nicolas> wrote:
    >> Nico, I find myself in disagreement with most of your
    >> conclusions, and don't think you explained your thinking enough
    >> that I can figure out where things went wrong.
    >> 
    >> In particular:
    >> 
    >> * I don't see why aliases should be split into multiple types.
    >> If we can avoid doing so it is desirable not to have to sync
    >> canonicalizations between the KDC and service.  So I don't see
    >> why one form of programmatic transformation should be special
    >> cased.

    Nicolas> Because the kind that differ in case or normalization
    Nicolas> need not necessarily be covered by the information model.

Ah.  OK. I agree the information model shouldn't cover these by
enumerating them.  I don't think the rest of your conclusion--that
they should use the same keys-- follows.

    >> * I don't in general see why unicode makes the number of keys
    >> you need to try larger.

    Nicolas> Huh?

?:-)

    >> * I don't see why we should prefer password-based aliasing.
    >> I'm beginning to see an argument why we should support it, but
    >> I generally agree with Tom on this issue.

    Nicolas> My reply to Tom's security consideration issue was
    Nicolas> thoughrough.  Perhaps you could answer it thoughroughly
    Nicolas> rather than dismiss it.  

I had not received it when I wrote to you.
Yes, you bring up a good point  regarding security.

A couple of responses.

1) Storing user passwords seems like a reasonably bad idea.   It seems hard to distinguish storing user passwords from storing service passowrds.

2) This is a change to the kdb model; I don't agree that simply
   because another implementation has done something different is
   sufficient justification for me giving up a model of the KDB.  The
   model of the KDB that stores keys is in a lot of code.  (So is the
   one that stores passwords).  Note that storing passwords is not
   particular superior in any Kerberos context I can think of.

---

From: Sam Hartman <[email-masked]>
Date: Thu, 04 Dec 2008 16:36:00 -0500

>>>>> "Henry" == Henry B Hotz <[email-masked]> writes:

    Henry> I guess I need a bit of elaboration here.  Absent aliases,
    Henry> I don't see the password vice keys issue as externally
    Henry> significant.

    Henry> Is it only the combination of the two that you're finding
    Henry> difficult?

Correct.
And note I'm talking about the service side, not the client side.

I.E. I'm not trying to get tickets; I'm trying to decrypt them.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 4 Dec 2008 15:54:11 -0600

> they should use the same keys-- follows.

Mostly because it's just easier that way.  Servers can store keys for
all base pricnipals and go from there.

Here's a question: are there any KDCs and servers that support aliases
of type (a) (that differ from canon only in case/norm)?

> 1) Storing user passwords seems like a reasonably bad idea.   It seems
>    hard to distinguish storing user passwords from storing service
>    passowrds.

But is there any reason not to go with a convention, as I described?  (A
flag, or the op used to set the password, or the fact that the KDC
generated it...)

IMO the bigger problem is that it's difficult to ensure that such a
password is not reused for other purposes such that KDB compromise could
further compromise other systems.  But I don't think that's so likely in
practice that a security consideration wouldn't suffice.

>    particular superior in any Kerberos context I can think of.

I agree.  I did describe, in another reply, what I think is the correct
model, and which would allow you to: a) not share passwords, b) not
share keys, while c) keeping things simple.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Luke Howard <[email-masked]>
Date: Sat, 27 Dec 2008 00:40:59 +1100

Sam,

Sorry, just catching up on mailing list mail now.

> they are salted with the alias name.

Is it not reasonable for the service to know the canonical name of the  
principal?

In Windows land, the service and the KDC share a "well known"  
algorithm for determining the salt. (I use the expression loosely as  
it does not appear to be defined anywhere. For the record, the salting  
principal appears to be host/sAMAccountName-Without-Trailing- 
$.realm@REALM.)

If the absence of a shared salting algorithm, can't a service get the  
salt from ETYPE-INFO and store that with the password?

-- Luke

---

From: Sam Hartman <[email-masked]>
Date: Fri, 26 Dec 2008 11:02:25 -0500

>>>>> "Luke" == Luke Howard <[email-masked]> writes:

    Luke> Sam, Sorry, just catching up on mailing list mail now.

    >> different keys because they are salted with the alias name.

    Luke> Is it not reasonable for the service to know the canonical
    Luke> name of the principal?

    Luke> In Windows land, the service and the KDC share a "well
    Luke> known" algorithm for determining the salt. (I use the
    Luke> expression loosely as it does not appear to be defined
    Luke> anywhere. For the record, the salting principal appears to
    Luke> be host/sAMAccountName-Without-Trailing- $.realm@REALM.)

OK, so all windows aliases use the same salt?  If so, then I think my
concern goes away as there appear to be no instances of the "salt each
alias separately" principals.

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 26 Dec 2008 12:59:46 -0600

> alias separately" principals.

I asked Larry about this a few months ago and the answer was that this
was so for arcfour but not for AES.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Luke Howard <[email-masked]>
Date: Sat, 27 Dec 2008 09:17:31 +1100

> alias separately" principals.

Yes.

-- Luke

---

From: Luke Howard <[email-masked]>
Date: Sat, 27 Dec 2008 11:03:08 +1100

> was so for arcfour but not for AES.

Are you sure you made the distinction between "same salt" and "same  
salt algorithm"? Recall arcfour has no salt.

Also, the Active Directory attribute that stores keys only contains a  
single field for the salt. See [MS-SAMR] 2.2.10.4.

-- Luke