Subject: prelim draft of kdc information model

From: Leif Johansson <[email-masked]>
Date: Thu, 03 Jul 2003 08:23:27 +0200

This is a first draft of the information model draft as discussed in SF. 
The draft
missed the -00 cutoff. Hopefully there will be an offline meeting about 
this in
Wienna (details will be posted on [email-masked] and [email-masked]).
I am prepared to give a short summary on the progress of this work at the wg
meeting if there is enough interest.

    /leifj

Network Working Group                                          Johansson
Internet-Draft                                      Stockholm university
Expires: August 30, 2003                                      March 2003

              An information model for Kerberos version 5
                 draft-ietf-johansson-krb-model-00.txt

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that other
   groups may also distribute working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time. It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at http://
   www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on August 30, 2003.

Copyright Notice

   Copyright (C) The Internet Society (2003). All Rights Reserved.

Abstract

   This document describes an information model for Kerberos version 5
   from the point of view of an administrative service. There is no
   standard for administrating a kerberos 5 KDC. This document describes
   the services exposed by an administrative interface to a KDC.

Johansson               Expires August 30, 2003                 [Page 1]

Internet-Draft    An information model for Kerberos version 5 March 2003

Table of Contents

   1.    Requirements notation  . . . . . . . . . . . . . . . . . . .  3
   2.    Motivation . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.    Information model  . . . . . . . . . . . . . . . . . . . . .  5
   3.1   Principal  . . . . . . . . . . . . . . . . . . . . . . . . .  5
   3.1.1 Attributes . . . . . . . . . . . . . . . . . . . . . . . . .  5
   3.1.2 Associations . . . . . . . . . . . . . . . . . . . . . . . .  5
   3.1.3 Remarks  . . . . . . . . . . . . . . . . . . . . . . . . . .  5
   3.2   KeySet . . . . . . . . . . . . . . . . . . . . . . . . . . .  5
   3.2.1 Attributes . . . . . . . . . . . . . . . . . . . . . . . . .  5
   3.2.2 Associations . . . . . . . . . . . . . . . . . . . . . . . .  5
   3.2.3 Remarks  . . . . . . . . . . . . . . . . . . . . . . . . . .  5
   3.3   Key  . . . . . . . . . . . . . . . . . . . . . . . . . . . .  6
   3.3.1 Attributes . . . . . . . . . . . . . . . . . . . . . . . . .  6
   3.3.2 Associations . . . . . . . . . . . . . . . . . . . . . . . .  6
   3.3.3 Remarks  . . . . . . . . . . . . . . . . . . . . . . . . . .  6
   3.4   Policy . . . . . . . . . . . . . . . . . . . . . . . . . . .  6
   3.4.1 Attributes . . . . . . . . . . . . . . . . . . . . . . . . .  6
   3.4.2 Password Policy  . . . . . . . . . . . . . . . . . . . . . .  6
   3.4.3 Key Policy . . . . . . . . . . . . . . . . . . . . . . . . .  6
   4.    Implementation Scenarios . . . . . . . . . . . . . . . . . .  7
   4.1   LDAP backend to KDC  . . . . . . . . . . . . . . . . . . . .  7
   4.2   LDAP frontend to KDC . . . . . . . . . . . . . . . . . . . .  7
   5.    Security Considerations  . . . . . . . . . . . . . . . . . .  8
         References . . . . . . . . . . . . . . . . . . . . . . . . .  9
         Author's Address . . . . . . . . . . . . . . . . . . . . . .  9
         Intellectual Property and Copyright Statements . . . . . . . 10

Johansson               Expires August 30, 2003                 [Page 2]

Internet-Draft    An information model for Kerberos version 5 March 2003

1. Requirements notation

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

Johansson               Expires August 30, 2003                 [Page 3]

Internet-Draft    An information model for Kerberos version 5 March 2003

2. Motivation

   The Kerberos version 5 authentication service described in [RFC1510]
   describes how a Key Distribution Service (KDC) provides
   authentication to clients. The standard does not stipulate how a KDC
   is managed and several "kadmin" servers have evolved. This document
   describes the services required to administrate a KDC and the
   underlying information model assumed by a kadmin service.

   The information model is written in terms of "attributes" and
   "services" or "interfaces" but the use of these particular words MUST
   NOT be taken to imply any particular modelling paradigm so that
   neither an object oriented model or an LDAP schema is intended. The
   author has attempted to describe in naturual language the intended
   semantics and syntax of the components of the model. An LDAP schema
   (say) based on this model will be more precise in the expression of
   the syntax while preserving the semantics of this model.

   Implementations of this document MAY decide to change the names used
   (eg principalName). If so an implementation MUST provide a name to
   name mapping to this document.

Johansson               Expires August 30, 2003                 [Page 4]

Internet-Draft    An information model for Kerberos version 5 March 2003

3. Information model

3.1 Principal

   The fundamental entity stored in a KDC is the principal. The
   principal is associated to keys and generalizes the "user" concept.

3.1.1 Attributes

3.1.1.1 principalName

   A principal MUST be uniquely identified withing the administrative
   context of the KDC by the principalName. The type of the
   principalName is not described in this document. It is a unique
   identifier and can be viewed as an opaque which can be compared for
   equality with.

3.1.2 Associations

   Each principal MUST be associated with exactly one KeySet.

3.1.3 Remarks

   Traditionally a principal consists of a local-part and a realm
   denoted in string form by local-part@REALM. The realm concept is used
   to provide administrative boundaries and together with cross-realm
   authentication provides scalability to Kerberos 5. However the realm
   is not central to an administrative information model. For instance
   the initialization or creation of a realm is equivalent to creating a
   specific set of principals (krbtgt@REALM, etc) which is covered by
   the model and services described in this document.

3.2 KeySet

   A KeySet is a set of keys associated with exactly one principal.

3.2.1 Attributes

3.2.1.1 Flags

3.2.2 Associations

   To each KeySet MUST be assocated a set of 1 or more Keys.

3.2.3 Remarks

   The reason for separating the KeySet from the Principal is security.

Johansson               Expires August 30, 2003                 [Page 5]

Internet-Draft    An information model for Kerberos version 5 March 2003

   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 preserve
   this distinction.

3.3 Key

3.3.1 Attributes

3.3.1.1 encryptionType

3.3.1.2 keyVersion

3.3.1.3 keyValue

3.3.1.4 saltType

3.3.1.5 saltValue

3.3.2 Associations

   None

3.3.3 Remarks

   The security of the keys is a requirement for the operation of
   Kerberos 5.

3.4 Policy

3.4.1 Attributes

3.4.2 Password Policy

3.4.2.1 Attributes

3.4.3 Key Policy

3.4.3.1 Attributes

Johansson               Expires August 30, 2003                 [Page 6]

Internet-Draft    An information model for Kerberos version 5 March 2003

4. Implementation Scenarios

   There are several ways to implement an administrative service for
   Kerberos 5 based on this information model. In this section we list a
   few of them.

4.1 LDAP backend to KDC

   Given an LDAP schema implementation of this information model it
   would be possible to build an administrative service by backending
   the KDC to a directory server where principals and keys are stored.
   Using the security mechanisms available on the directory server keys
   are protected from access by anyone apart from the KDC.
   Administration of the principals, policy and other non-key data is
   done through the directory server while the keys are modified using
   the set/change password protocol
   [I-D.ietf-krb-wg-kerberos-set-passwd].

4.2 LDAP frontend to KDC

   An alternative way to provide a directory interface to the KDC is to
   implement an LDAP-frontend to the KDC which exposes all non-key
   objects as entries and attributes. As in the example above all keys
   are modified using the set/change password protocol
   [I-D.ietf-krb-wg-kerberos-set-passwd]. In this scenario the
   implementation would typically not use a traditional LDAP
   implementation but treat LDAP as an access-protocol to data in the
   native KDC database.

Johansson               Expires August 30, 2003                 [Page 7]

Internet-Draft    An information model for Kerberos version 5 March 2003

5. Security Considerations

   This document describes an abstract information model for Kerberos 5.
   The Kerberos 5 protocol depends on the security of the keys stored in
   the KDC. The model described here assumes that keys MUST NOT be
   transported in the clear over the network and furthermore that keys
   are treated as write-only attributes that SHALL only be modified
   (using the administrative interface) by the change-password protocol
   [I-D.ietf-krb-wg-kerberos-set-passwd].

Johansson               Expires August 30, 2003                 [Page 8]

Internet-Draft    An information model for Kerberos version 5 March 2003

References

   [I-D.ietf-krb-wg-kerberos-set-passwd]
              Trostle, J., "Kerberos Set/Change Password: Version 2",
              draft-ietf-krb-wg-kerberos-set-passwd-00 (work in
              progress), May 2003.

   [RFC1510]  Kohl, J. and B. Neuman, "The Kerberos Network
              Authentication Service (V5)", RFC 1510, September 1993.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

Author's Address

   Leif Johansson
   Stockholm university
   Enheten för IT och Media
   Stockholm  SE-106 91

   EMail: [email-masked]
   URI:   http://people.su.se/~leifj/

Johansson               Expires August 30, 2003                 [Page 9]

Internet-Draft    An information model for Kerberos version 5 March 2003

Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   intellectual property or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; neither does it represent that it
   has made any effort to identify any such rights. Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11. Copies of
   claims of rights made available for publication and any assurances of
   licenses to be made available, or the result of an attempt made to
   obtain a general license or permission for the use of such
   proprietary rights by implementors or users of this specification can
   be obtained from the IETF Secretariat.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which may cover technology that may be required to practice
   this standard. Please address the information to the IETF Executive
   Director.

Full Copyright Statement

   Copyright (C) The Internet Society (2003). All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works. However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assignees.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION

Johansson               Expires August 30, 2003                [Page 10]

Internet-Draft    An information model for Kerberos version 5 March 2003

   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

Johansson               Expires August 30, 2003                [Page 11]

---

From: Sam Hartman <[email-masked]>
Date: Mon, 14 Jul 2003 03:49:51 -0400

Hi.  I just finished reading the KDC info draft.

This seems like a good start.

I would like to accomplish the following, perhaps at this IETF meeting perhaps later:

1) Understand how we view salt types and salts within this framework

2) Understand what flags we care about.

Before we finish this document we should also think about how it will
interact with Kerberos extensions.

---

From: Sam Hartman <[email-masked]>
Date: Mon, 14 Jul 2003 04:03:35 -0400

Two things that seem to be missing from this model are:

1) The information describing how principals are created.  This is a
   deficiency in current admin servers.  I probably want to be able to
   specify that a principal belongs to some principal type like user
   or -service when it is created and have that influence what is
   created for the principal.  For users I probably want to disallow
   use of the long-term key as a service.  At the current time, I
   might want to use AES for user principals but not for service
   principals.

2) Don't I want to be able to configure the enctypes and salttypes
    that future password changes will use per principal as well?

Both these points can probably be solved using the same mechanism.

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 15 Jul 2003 15:56:52 +0200 (CEST)

>     that future password changes will use per principal as well?

Yes, you probably do.  This saves the user or administrator from having to
explicitly specify a list of enctypes each time the password is changed.
This is particularly important with regard to service principals, where
the set of enctypes for which there are keys in the KDC must match that
supported by the server software.

---

From: Sam Hartman <[email-masked]>
Date: Tue, 15 Jul 2003 10:54:53 -0400

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

    Jeffrey> On Mon, 14 Jul 2003, Sam Hartman wrote:
    >> 2) Don't I want to be able to configure the enctypes and
    >> salttypes that future password changes will use per principal
    >> as well?

    Jeffrey> Yes, you probably do.  This saves the user or
    Jeffrey> administrator from having to explicitly specify a list of
    Jeffrey> enctypes each time the password is changed.  This is
    Jeffrey> particularly important with regard to service principals,
    Jeffrey> where the set of enctypes for which there are keys in the
    Jeffrey> KDC must match that supported by the server software.

I'd actually argue that it is particularly unimportant for server
software, where in an ideal world the application server's library
will rekey to only those keys it supports guaranteeing this match.

---

From: Ken Raeburn <[email-masked]>
Date: Mon, 21 Jul 2003 12:17:55 -0400

> will rekey to only those keys it supports guaranteeing this match.

I don't see any point in perpetuating the overloading we do in the MIT
database where the set of service key enctypes also describes the
encryption types supported by the application server software.  Given
that, in many cases I suspect there's no need for the service to have
more than one key and enctype.  Obviously, that enctype must be one
supported by the software, but there doesn't have to be a key for each
supported enctype.

Ken

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 21 Jul 2003 09:43:51 -0700

> supported by the software, but there doesn't have to be a key for each

Indeed, service principals need have no more than one key shared with
the KDC.

As I said, draft-ietf-krb-wg-kerberos-set-passwd-01.txt will have a
facility by which clients can tell the KDC what Kerberos features are
supported by the principal whose keys are changing.

The KDC needs to know at the very least what enctypes a service
principal accepts, for ticket session key enctype is the one thing that
is negotiated between a client and service by proxy in the KDC
exchanges.

As we've discussed before, the Kerberos extensions work will only add to
the number of things negotiated in this way and the KDC will have to
know what version of Kebreros V is supported by service principals, at
the very least.

Cheers,

Nico
--

---

From: Sam Hartman <[email-masked]>
Date: Mon, 21 Jul 2003 13:09:23 -0400

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

    Ken> Sam Hartman <[email-masked]> writes:
    >>  I'd actually argue that it is particularly unimportant for
    >> server software, where in an ideal world the application
    >> server's library will rekey to only those keys it supports
    >> guaranteeing this match.

    Ken> I don't see any point in perpetuating the overloading we do
    Ken> in the MIT database where the set of service key enctypes
    Ken> also describes the encryption types supported by the
    Ken> application server software.  

I think there are too many enctype related options, not too few.  If
you want to separate enctypes a service supports from keys that a
service has, I think that you should justify the additional complexity/options.

I agree that there is no need for both the supported enctypes and
keyed enctypes to be the same.  However I don't see any harm in doing
things this way and it is one less thing to configure or get out of
sync.

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 21 Jul 2003 10:18:42 -0700

>     Ken> application server software.  

SAM> I think there are too many enctype related options, not too
SAM> few.  If you want to separate enctypes a service supports from
SAM> keys that a service has, I think that you should justify the
SAM> additional complexity/options.

SAM> I agree that there is no need for both the supported enctypes
SAM> and keyed enctypes to be the same.  However I don't see any
SAM> harm in doing things this way and it is one less thing to
SAM> configure or get out of sync.

The complexity is in the password/key change protocol and we'll need
this for extensions anyways, which I think amply justifies the
additional complexity.

Besides, the number of UI options visible to users and/or admins
need not go up.  When changing a service principal's keys the
admin could be given the option of listing the enctypes that the
principal accepts in order of preference and the principal should
magically end up with a single key of the first enctype in that
list.  This list of acceptable enctypes need not be provided
every time that the service principal's keys change either.

Cheers,

Nico
--

---

From: Sam Hartman <[email-masked]>
Date: Mon, 21 Jul 2003 13:28:42 -0400

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

    Nicolas> The complexity is in the password/key change protocol and
    Nicolas> we'll need this for extensions anyways, which I think
    Nicolas> amply justifies the additional complexity.

No, we need one bit for extensions.  We don't need a set of enctypes.

    Nicolas> Besides, the number of UI options visible to users and/or
    Nicolas> admins need not go up.  

Then debugging becomes much harder.

Again, what benefit do you get from separating these options?

---

From: Ken Raeburn <[email-masked]>
Date: Thu, 31 Jul 2003 08:52:30 -0400

> Again, what benefit do you get from separating these options?

You get the option of having communication between the KDC and
application server always well-protected with a strong enctype, while
the client can choose to use a weaker session key type (e.g., if
that's all it supports).

Granted, you can also do this by only using one of the keys as the
service key, but then aren't you really just using the list of keys to
implement a list of enctypes?  That also implies a requirement for the
ability to indicate which one (or more?) of the multiple stored keys
may be used as the service key.

Ken

---

From: Sam Hartman <[email-masked]>
Date: Thu, 31 Jul 2003 13:26:05 -0400

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

    Ken> Granted, you can also do this by only using one of the keys
    Ken> as the service key, but then aren't you really just using the
    Ken> list of keys to implement a list of enctypes?  That also
    Ken> implies a requirement for the ability to indicate which one
    Ken> (or more?) of the multiple stored keys may be used as the
    Ken> service key.

No, you can also just leave this up to the KDC.