Subject: [Ietf-krb-wg] kdc-model: Separation of KeySets

From: [email-masked]
Date: Wed, 24 Mar 2010 17:18:11 -0400 (EDT)

This is a follow-up from the krb-wg meeting.  Section 6.2.3 of the
current model draft says:

   The reason for separating the KeySet from the Principal is security.
   The security of Kerberos 5 depends absolutely on the security of the
   keys stored in the KDC.  The KeySet type is provided to make this
   clear and to make separation of keys from other parts of the model
   clear.

   Implementations of this standard (eg an LDAP schema) MUST make a
   clear separation between the representation of KeySet from other
   information objects.

I wrote earlier:

  6.2.3 talks about separating the KeySet from the principal "for
  security," but doesn't explain why the separation introduces any
  security.  Perhaps because it means keys won't necessarily be
  transmitted if a principal is retrieved, in an implementation where
  objects are retrieved in blobs?

There seemed to be some misinterpretation of this comment in the
meeting.  Let me clarify:

* I am fine with treating KeySets as a separate object from the
  Principal, if only because a Principal can contain multiple KeySets
  (in key rollover situations).

* I don't think the document needs to justify this separation inline,
  but if it chooses to do so, the justification should be clear and
  make sense.

* It is not clear to me how putting KeySets into a separate object
  improves the security of the keys.  From the meeting, the only
  clarification I got was Sam suggesting (I think) that perhaps the
  key objects would have stricter access controls from principal data.
  I don't think that justification is obvious from the text, and
  whether that is facilicated by separating keysets depends very much
  on the protocol used to implement the model.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Leif Johansson <[email-masked]>
Date: Wed, 24 Mar 2010 23:51:15 +0100

>    on the protocol used to implement the model.

Can you provide concrete suggestions for modifications to the text? I
ask because at the meeting today and in the jabber room I got the sense
that most people didn't think this point was important enough to spend
lots of time on.

	Cheers Leif

---

From: Greg Hudson <[email-masked]>
Date: Wed, 24 Mar 2010 19:22:54 -0400

> that most people didn't think this point was important enough to spend

As I said in the meeting, I cannot propose text because no one has
explained the security reasoning.  All I can suggest is removing both
paragraphs as there is no need to justify the separation inline, or to
impose constraints upon schemas.

---

From: Love Hörnquist Åstrand <[email-masked]>
Date: Thu, 25 Mar 2010 10:10:33 -0700

> impose constraints upon schemas.

The the schema doesn't make keys optional then there is no way to express legacy key structures, this will make deployment much harder.

Love

---

From: Simo Sorce <[email-masked]>
Date: Thu, 25 Mar 2010 14:47:21 -0400

On Thu, 25 Mar 2010 10:10:33 -0700
Love Hörnquist Åstrand <[email-masked]> wrote:

> >> Can you provide concrete suggestions for modifications to the
> >> text? I ask because at the meeting today and in the jabber room I
> >> got the sense that most people didn't think this point was
> >> important enough to spend lots of time on.
> > 
> > explained the security reasoning.  All I can suggest is removing
> > both paragraphs as there is no need to justify the separation
> > inline, or to impose constraints upon schemas.
> 
> The the schema doesn't make keys optional then there is no way to
> express legacy key structures, this will make deployment much harder.

But this document explains the information model not some specific
schema. I think Greg is asking if there is any need to prescribe
something like this in the information model. Correct me if I am wrong
Greg.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Leif Johansson <[email-masked]>
Date: Fri, 26 Mar 2010 00:08:45 +0100

> something like this in the information model. Correct me if I am wrong

Yes I think everyone understands that and I claim that having a
schema that doesn't separate key management from the management
of other data does have security implications.

I want to keep text about this in the model but I am happy to
receive clarifying or updated language.

Lets get past this so we don't bikeshed too much on this point!

	Cheers Leif

---

From: Greg Hudson <[email-masked]>
Date: Fri, 26 Mar 2010 15:54:14 -0400

> of other data does have security implications.

What security implications?

All I am hearing is:

Step 1: It's important to protect the keys.
Step 2: ???
Step 3: Therefore keys must be kept separate from other principal data.

What goes wrong if they aren't separated?  What are the security
considerations?

---

From: "Henry B. Hotz" <[email-masked]>
Date: Mon, 29 Mar 2010 11:32:45 -0700

> What goes wrong if they aren't separated?  What are the security

Maybe it would be better said the other way 'round:  Outside of the actual key material, there isn't much (any?) data that's really sensitive in a KDC.  If someone gets a list of your usernames, their flag settings, and password expiration times, how much do you care?

------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
[email-masked], or [email-masked]

---

From: Leif Johansson <[email-masked]>
Date: Wed, 31 Mar 2010 15:16:02 +0200

> What goes wrong if they aren't separated?  What are the security

Can you suggest a concrete change to reflect what you don't like about 
the text?

	Cheers Leif

---

From: Sam Hartman <[email-masked]>
Date: Wed, 31 Mar 2010 12:17:34 -0400

In general, you want the schema to permit separation so that keys can be
segregated for backup, or for privilege control.

What it means to separate depends on what data model language you're
talking about.  For LDAP, I think it is important that it be possible to
store keys in a separate object so that those objects can be segregated
for backup.  I think that most LDAP implementations have per-attribute
access control.

I don't think people should be required to deploy that way; I simply
think the schema should support it.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Sam Hartman <[email-masked]>
Date: Wed, 31 Mar 2010 12:29:35 -0400

>>>>> "Sam" == Sam Hartman <[email-masked]> writes:

    Sam> In general, you want the schema to permit separation so that
    Sam> keys can be segregated for backup, or for privilege control.

    Sam> What it means to separate depends on what data model language
    Sam> you're talking about.  For LDAP, I think it is important that
    Sam> it be possible to store keys in a separate object so that those
    Sam> objects can be segregated for backup.  I think that most LDAP
    Sam> implementations have per-attribute access control.

    Sam> I don't think people should be required to deploy that way; I
    Sam> simply think the schema should support it.
    Sam> _______________________________________________ ietf-krb-wg
    Sam> mailing list [email-masked]
    Sam> https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

The other separation you might want is to use different data models for
key store updates and for the rest.  For example my preferred admin
strategy is to use LDAP for non-key-store operations and change/set
password for key store ops.  So, you want someone to be able to
implement only key store or not key store in a particular data model.
For most data models you want an implementation of that data model to be
able to leave out/include key store.  For deployments you also often
want that flexibility.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Greg Hudson <[email-masked]>
Date: Wed, 31 Mar 2010 12:43:42 -0400

> segregated for backup, or for privilege control.

Thank you, Sam.  Now that this has been explained, I can suggest the
following change:

REPLACE:

WITH:

  The security of Kerberos 5 depends absolutely on the confidentiality
  and integrity of the keys stored in the KDC.  Implementations of this
  standard MUST facilitate, to the extent possible, an administrator's
  ability to place more restrictive access controls on KeySets than on
  other principal data, and to arrange for more secure backup for
  KeySets.

I feel a little weird saying "MUST facilitate," but the concept being
expressed here is a little vague.  What we want is to make something
possible for a party three layers away from this standard:

  Data model --> Schema (e.g. for LDAP) --> Implementation --> Admin

The model implementation may be built on an object-based substrate (like
LDAP) or it may not.  If it's an object-based substrate, then placing
KeySets in separate objects will make it more likely to treat KeySets
separately for privilege and backup, but that is still dependent on the
server implementation.  For example, you could imagine an embedded LDAP
server which keeps all data in a single file and has no backup
facilities beyond backing up the single file--in such a server, it would
be very hard to do separate backup of key data regardless of how the
LDAP schema is written.

If the model implementation is instead built on an RPC-like substrate
(like Web Services), then that standard has very little influence on the
ability to do separate backup, but does have some influence on the
ability to do separate privilege.  For instance, the MIT kadmind's
get_principal query would probably be expressed differently, or divided
up into two queries, if it were designed to meet this constraint.

---

From: Greg Hudson <[email-masked]>
Date: Wed, 31 Mar 2010 12:46:06 -0400

On Wed, 2010-03-31 at 12:29 -0400, Sam Hartman wrote:
> password for key store ops.

There is already other language in the document about this, in sections
6.2 and 6.3.  I am not proposing to change that language.

---

From: "Henry B. Hotz" <[email-masked]>
Date: Wed, 31 Mar 2010 11:04:42 -0700

On Mar 31, 2010, at 9:43 AM, Greg Hudson wrote:

> expressed here is a little vague.

MUST restrict (protect?) access to KeySet data.

MAY allow less restrictive access to other data.

---

From: Simo Sorce <[email-masked]>
Date: Wed, 31 Mar 2010 15:53:59 -0400

On Wed, 31 Mar 2010 12:43:42 -0400
Greg Hudson <[email-masked]> wrote:

> > In general, you want the schema to permit separation so that keys
> > can be segregated for backup, or for privilege control.
> 
>    The reason for separating the KeySet from the Principal is
> security. The security of Kerberos 5 depends absolutely on the
> security of the keys stored in the KDC.  The KeySet type is provided
> to make this clear and to make separation of keys from other parts of
> the model clear.
> 
>   and integrity of the keys stored in the KDC.  Implementations of
> this standard MUST facilitate, to the extent possible, an
> administrator's ability to place more restrictive access controls on
> KeySets than on other principal data, and to arrange for more secure
> backup for KeySets.

If the purpose is to unequivocally state that keys must be protected
why don't we just say so ?

REPLACE WITH:

    The security of Kerberos 5 is completely dependent on the
    confidentiality and integrity of the keys. Implementations
    of this standard SHALL include appropriate measures to protect
    keys from unauthorized access. Protection form unauthorized
    access SHOULD also be extended to any backup of key material.
    Other principal data information does not need the same level
    of protection.

I removed "stored in the KDC" as keys may be stored elsewhere (for
example in LDAP).

Also I do not agree with the original where it claims that
implementations MUST make it possible to separate data. As long as keys
are protected it doesn't matter if they are separable form the
information model point of view IMO.
In fact they are not separable from principal data when using the
standard database in current implementations. I don't see why we should
make current implementations fall off the standard when separation is
not strictly needed.

If the wg *really* feels like it should strongly push separation in
LDAP based implementations then I suggest the following additional text.

ADDITIONAL TEXT:

    Implementations that use a general purpose storage (such as LDAP
    directories or SQL databases) that can be accessed by other agents
    beyond the KDC and related administrative client SHALL make it
    possible to separate access to key material from other principal
    data. Administrators SHOULD be allowed to apply stricter access
    control to key material while allowing more relaxed access to other
    principal data.

I think it is a little redundant, as normally you do separate data in
multiple attributes when dealing with LDAP, but other databases may not
do so normally (for example the SQL case), so it probably make sense.

Simo.

P.S. My English is far from perfect so I welcome corrections.

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 31 Mar 2010 15:05:51 -0400

> MAY allow less restrictive access to other data.

We're getting ahead of ourselves here.  This is a data model document, not 
a schema document.  Implementations of this document are schemas, and the 
goal was to REQUIRE schemas to separate KeySet and other data sufficiently 
well that an implementation of the schema would give the administrator the 
flexibility to do so operationally.  I think we've been trying to avoid, in 
this document, defining requirements for implementations of schemas based 
on it.

In any case, what Henry proposes here looks like requirements on the access 
controls affecting that data.  These are properly a matter of policy, and 
thus are up to the administrator, not us.  What we want to do at the 
present stage is ensure that the administrator will be able to set a policy 
like the above; particularly, that access controls on KeySet data can be 
set more restrictively than on other data.  Plus, of course, the backup 
issue Sam describes, and more generally, the ability to define separate 
policies and mechanisms for the management of keys.

-- Jeff