INTERNET-DRAFT                               Donna Skibbie
Kerberos Working Group                       Jonathan Trostle
Intended Category:  Standards Track          John Griffith
Expires 30 November 2002                     ADDITIONAL NAMES TBD
                                             30 May 2002


             Keys Extension for the Kerberos KDC LDAP Schema
              draft-skibbie-krb-kdckeys-ldap-schema-00.txt



1. Status Of This Memo

This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC 2026 [1].

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.



2. Abstract

This document defines a "Keys Extension Schema."  The Keys Extension
Schema extends the KDC LDAP schema defined in the work in progress
IETF document <draft-skibbie-krb-kdc-ldap-schema-01.txt> so that
key attributes used by implementations of Kerberos Version 5 Key
Distribution Center (KDC) service can be stored in a directory
that implements the Lightweight Directory Access Protocol (LDAP)
Version 3.  The directory must implement the LDAP Version 3
protocol as defined in RFC 2251 [2], RFC 2252 [3], RFC 2253 [4],
RFC 2256 [5], 2829 [6], and 2830 [7].

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 RFC 2119 [8].


3. Terms and Notations

This section lists the terms and notations used in this document.

3.1.  Terms

This document uses the following terms:

* distinguished name (DN)--A name that uniquely identifies an entry in
an LDAP directory.  A DN is comprised of one or more components,
separated by commas.  Each component consists of one or more attribute-
value assertions.  An example of a DN is "cn=Ben Gray,ou=editing,o=New
York Times,c=US".

* relative distinguished name (RDN)--The first component of a DN.  For
example, if the DN of an entry is "cn=John Doe,ou=Test,o=IBM,c=US", the
RDN of the entry is "cn=John Doe".  An RDN must uniquely identify an
entry from other entries that have the same parent entry.

* ancestor-descendent association--A relationship between two entries in
which the DN of one entry (referred to as the ancestor entry) is
included at the end of DN of the second entry (referred to as the
descendent entry).  For example, if the DN of one entry is "ou=Austin"
and the DN of a second entry is "cn=Jane Doe, cn=Managers, ou=Austin",
the two entries have an ancestor-descendent relationship with the first
entry referred to as the ancestor entry and the second entry referred to
as the descendent entry.

* parent-child association--A relationship between two entries in which
the DN of one entry (referred to the parent entry) is included in the
second through last components of the DN of the second entry (referred
to the child entry).  For example, if the DN of one entry is "ou=Austin"
and the DN of a second entry is "cn=Jane Doe, ou=Austin", the two
entries have a parent-child relationship with the first entry referred
to as the parent and the second entry referred to the child entry.  If
two entries have a parent-child relationship, the two entries also have
an ancestor-descendent relationship.

* reference association--A relationship between two entries in which one
entry (the referencing entry) contains an attribute that can be used to
find the second entry (the referenced entry).  For example, if one entry
contains an attribute that stores the DN of a second entry, the two
entries have a reference association with the first entry referred to as
the referencing entry and the second entry referred to as the referenced
entry.


3.2  Notations

The figures in this document uses the following notations:

* Boxes--A box, which is drawn with ":" and "-" characters, represents
an LDAP directory entry.

* Vertical lines--A vertical line, which is drawn with ":" characters
between an upper box and a lower box, represents a parent-child
relationship between the parent entry (the entry represented by the
upper box) and the child entry (the entry represented by the lower box).

* Double vertical lines--A double vertical line, which is drawn with
"::" characters between an upper box and a lower box, represents an
ancestor-descendent relationship between the DN of the ancestor entry
(the entry represented by the upper box) and the DN of the descendent
entry (the DN represented by the lower box).

* Arrows--An arrow, which is drawn with "-->" or "<--" characters
between two boxes, represents a reference association between a
referencing entry (the entry represented by the box where the arrow
begins) and a referenced entry (the entry represented by the box where
the arrow ends).

* Numbers--A set of two numbers drawn besides a vertical line, double
vertical line, or arrow indicates a numeric relationship between
associated entries.  For example, given that a vertical line represents
a parent-child association between entries, a "1" at the top of a
vertical line and an "n" at the bottom of the same line indicates that
this parent-child association allows for only one parent entry with
multiple child entries.

4. Overview

The Keys Extension Schema extends the KDC LDAP schema so that
information about master keys, principal keys or both may be stored in
the LDAP directory.  The schema is designed to meet four objectives.
The first objective is to use LDAP schema definitions defined in RFC
2252, RFC 2256, and existing LDAP implementations.  The second objective
is to provide a highly secure way of protecting keys.  The third
objective is to promote inter-operability between different
implementations of the Kerberos KDC.


4.1 Schema for Master Keys

Information about shared or private master keys MAY be stored in the
LDAP directory.  Shared master keys are shared by all the KDC services
in the realm.  Private master keys are private to each KDC service in
the realm.

If information about shared or private master keys is stored in the LDAP
directory, the directory MUST contain the following entries:

* one "cn=MKEYS" entry

* one or more "master key entries"

The following figure shows where these entries MUST reside in the
LDAPdirectory:

                   --------------------
                   : realm entry      :
                   : as defined in the:
                   : KDC LDAP schema  :
                   :                  :
                   :                  :
                   :                  :
                   --------------------
                           1:
                           1:
                    :------------------:
                    : cn=MKEYS entry   :
                    :                  :
                    :------------------:
                           1:
                           n:
                 ---------------------------
                 : master key entry        :
                 : (master key value       :
                 : is stored in here or    :
                 : a referenced URL        :
                 : address, such as a file):
                 ---------------------------



4.1.1.  cn=MKEYS entry

A cn=MKEYS entry represents a container for information on all master
keys in the realm.  A cn=MKEYS entry MAY be configured using the
container object class.

The DN of a cn=MKEYS entry MUST be in the following format:

* The RDN MUST be "cn=MKEYS".

* The second through last components MUST be the DN of the realm entry.

For example, the DN of a cn=MKEYS entry could be "cn=MKEYS,
krbRealmName=PAYROLL, ou=Austin".

The cn=MKEYS entry MUST have a cn attribute with a value of MKEYS.
There are no optional attributes in a cn=MKEYS entry.


4.1.2.  Master Key Entries

A master key entry represents information about a version of shared or
private master keys.  A master key entry MAY be configured using the
KrbMstrKey structural object class.

The DN of a master key entry MUST be in the following format:

* The RDN MUST include the string "krbKeyVersion=<version>", where
<version> is the version of the master key.  If the master key entry
represents a version of private master keys, the master key entry also
MUST include the string "krbServiceName=<service_name>", where
<service_name> is the name of a KDC service in the realm.

* The second through last components MUST be the DN of the cn=MKEYS
entry.

For example, the DN of a master key entry could be "krbKeyVersion=1,
cn=MKEYS, krbRealmName=PAYROLL, ou=Austin".

A master key entry MUST contain the following attributes:

* krbKeyVersion--This attribute MUST contains the version of the master
key or keys defined in this entry and this version MUST be must be the
same as the version specified in the RDN.

* one krbMstrKeyData attribute for each master key associated with the
master key version specified for this entry--This attribute MUST contain
the master key data or the URL address of the master key data, and
information on how the master key data was generated.  This information
MUST be in the following format:

0                             1
0  1  2  3  4  5  6  7  8  9  0  1  2  3  4
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+----------+-----------+
|enc  |salt |value|mkeylen  or|    salt   |mkey value|   salt    |
|type |type |orURL|mkeyURL len|    len    |or mkeyURL|   value   |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+----------+-----------+

where:

"enc type" is two decimal characters indicating the encryption
algorithm that was used to generate the master key.  See
krbEncTypeSupport in the referenced KDC LDAP schema document for a list
of encryption type values.

"salt type" is two decimal characters indicating the type of salt value
that was used to generate the master key.  See krbSaltTypeSupport in the
referenced KDC LDAP schema document for a list of salt type values.

"value or URL" is the decimal characters "00" if the master key value
is stored in krbMstrKeyData or "01" if the URL address of the master
key value is stored in krbMstrKeyData.

"mkeylen or mkeyref len" is four decimal characters indicating the
length (in bytes) of either the master key value or the URL address
where the master key is stored

"salt len" is four decimal characters indicating the length (in bytes)
of the salt value ("0000" if no salt value)

"mkey value or mkeyURL" is either the master key value or the URL
address where the master key is stored

"salt value" (if specified) is the salt value.

For example, "01990000080000#!#%@!#$" defines a master key value with a
length of 8 bytes and a value of "#!#%@!#$".  The key was generated
using DES encryption and no salt value.  As another example,
"05040100180006file://mypath/mkeymysalt" defines a master key that is
stored at the URL address of file://mypath/mkey and this URL address
has a length of 18 bytes.  The master key was generated using triple-
DES encryption with a special salt type value that has a length of 6
bytes and a value of "mysalt".'

The following is an example of a realm configured with two master key
entries, each of which is shared by all the KDC services in the realm.
One master key entry is for Version 1 of the master key.  The other
master key entry is for Version 2 of the master key.  Each master key
entry contains the values of two master keys:  a master key generated
with the DES algorithm and no salt and a master key generated with the
triple-DES algorithm and no salt.

   dn: cn=MKEYS, krbRealmName=PAYROLL, ou=Austin
   objectclass: Container
   cn: MKEYS

   dn: krbKeyVersion=1, cn=MKEYS, krbRealmName=PAYROLL, ou=Austin
   objectclass:  KrbMstrKey
   krbKeyVersion: 1
   krbMstrKeyData: 01990000080000#!#%@!#$
   krbMstrKeyData: 05990000140000++_#%@52_#%@52

   dn: krbKeyVersion=2, cn=MKEYS, krbRealmName=PAYROLL, ou=Austin
   objectclass:  KrbMstrKey
   krbKeyVersion: 2
   krbMstrKeyData: 019900000800001+0*&^23
   krbMstrKeyData: 05990000140000*^&2)(25_#%@52

The following is the same as the previous example except that the
"cn=MKEYS" entry is configured with a referral to a more trusted LDAP
server named TrustedLDAPServer.  Therefore, all entries residing under
"cn=MKEYS" (which, in this case are the two master key entries) are
serviced by TrustedLDAPServer.

   dn: cn=MKEYS, krbRealmName=PAYROLL, ou=Austin
   objectclass: referral
   objectclass: extensibleObject
   ref: ldap://TrustedLDAPServer/cn=MKEYS, krbRealmName=PAYROLL,
ou=Austin
   cn: MKEYS

In this example, the referenced server contains the following entries:

   dn: cn=MKEYS, krbRealmName=PAYROLL, ou=Austin
   objectclass: container
   cn: MKEYS

   dn: krbKeyVersion=1, cn=MKEYS, krbRealmName=PAYROLL, ou=Austin
   objectclass:  KrbMstrKey
   krbKeyVersion: 1
   krbMstrKeyData: 01990000080000#!#%@!#$
   krbMstrKeyData: 05990000140000++_#%@52_#%@52

   dn: krbKeyVersion=2, cn=MKEYS, krbRealmName=PAYROLL, ou=Austin
   objectclass:  KrbMstrKey
   krbKeyVersion: 2
   krbMstrKeyData: 019900000800001+0*&^23
   krbMstrKeyData: 05990000140000*^&2)(25_#%@52

The following is the same as the previous example with two exceptions:
a different master key entry is configured for each of two KDC services
in the realm, and the master key entries contain references to private
files where the actual master key values are stored.

   dn: cn=MKEYS, krbRealmName=PAYROLL, ou=Austin
   objectclass: referral
   ref: ldap://TrustedLDAPServer/cn=MKEYS, krbRealmName=PAYROLL,
ou=Austin

   dn: krbKeyVersion=1+kdcServiceName=serviceA, cn=MKEYS,
krbRealmName=PAYROLL, ou=Austin
   objectclass:  KrbMstrKey
   krbKeyVersion: 1
   krbKdcServiceName: serviceA
   krbMstrKeyData: 01990100220000file://serveraDES/mkeyV1
   krbMstrKeyData: 059900230000file://serveraDES3/mkeyV1

   dn: krbKeyVersion=2+kdcServiceName=ServiceA, cn=MKEYS,
krbRealmName=PAYROLL, ou=Austin
   objectclass:  KrbMstrKey
   krbKeyVersion: 2
   krbKdcServiceName: serviceA
   krbMstrKeyData: 01990100220000file://serveraDES/mkeyV2
   krbMstrKeyData: 05990100230000file://serveraDES3/mkeyV2

   dn: krbKeyVersion=1+kdcServiceName=serviceB, cn=MKEYS,
krbRealmName=PAYROLL, ou=Austin
   objectclass:  KrbMstrKey
   krbKeyVersion: 1
   krbKdcServiceName: serviceB
   krbMstrKeyData: 01990100220000file://serveraDES/mkeyV1
   krbMstrKeyData: 05990100230000file://serveraDES3/mkeyV1

   dn: krbKeyVersion=2+kdcServiceName=ServiceB, cn=MKEYS,
krbRealmName=PAYROLL, ou=Austin
   objectclass:  KrbMstrKey
   krbKeyVersion: 2
   krbKdcServiceName: serviceB
   krbMstrKeyData: 01990100220000file://serverbDES/mkeyV2
   krbMstrKeyData: 05990100230000file://serverbDES3/mkeyV2



4.2.  Schema for Principal Keys

Information about principal keys MAY be stored in the LDAP directory.
If so, the realm entry MUST contain a krbSecretKeyCfg attribute.  This
attribute MAY be configured using the KrbKeyCfg auxiliary object class.

The krbSecretKeyCfg attribute MUST contain one of the following values,
which specifies how the principal keys are stored:

   * KRBKEY
   * KRBKEY-SUBTREE
   * USERPASSWORD
   * AUTHPASSWORD


4.2.1.  KRBKEY Configuration

If the krbSecretKeyCfg attribute of the realm entry contains a value of
KRBKEY, the LDAP directory MUST contain one or more principal key
entries for each principal in the realm.  The following figure shows
where these entries MUST reside in the LDAP directory:

 ----------------------
 : principal          :
 : entry as defined   :
 : in the KDC LDAP    :
 : schema             :
 ----------------------
         1:
          :
         n:
 :---------------
 : principal key:
 : entry        :
 :              :
 :--------------:



4.2.1.1.  Principal Key Entries

A principal key entry represents information about a version of secret
keys that belong to a principal and that are encrypted with either a
shared or private master key.  A principal key entry MAY be configured
with the KrbKey structural object class.

The DN of a principal key entry MUST be in the following format:

* If the keys in the entry are encrypted with a shared master key, the
RDN MUST be "krbKeyVersion=<version>", where <version> is the version of
the keys.  If the keys in the entry are encrypted with a private master
key, the RDN MUST be "krbKeyVersion=<version>+
krbKdcServicName=<service_name>" where <version is the version of the
keys and <service_name> is the name of a KDC service.

* The second through last components MUST be the DN of the realm entry.

A principal key entry MUST contain the following attributes:

*  krbKeyVersion--this attribute MUST contain the key version as
specified in the RDN.

*  one krbKeyData attribute for each key corresponding to the key
version of this entry--each of these attributes MUST contain the
encrypted key value and information on how this value was generated.
The information MUST be in the following format.

0                             1
0  1  2  3  4  5  6  7  8  9  0  1  2  3  4
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+----------+-----------+
|enc  |salt |mkey |   key     |    salt   |  key     |   salt    |
|type |type |ver  |   len     |    len    | value    |   value   |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+----------+-----------+

where:

"enc type" is two decimal characters indicating the encryption
algorithm that was used to generate the key.  See krbEncTypeSupport
in the referenced KDC LDAP schema draft for a list of possible
encryption type values.

"salt type" is two decimal characters indicating the type of salt value
that was used to generate the key.  See krbSaltTypeSupport in the
referenced KDC LDAP schema document for a list of possible salt type
values.

"mkey version" is two decimal characters indicating the version of the
master key that was used to transform the key into an encrypted key

"key len" is four decimal characters indicating the length (in bytes)
of the encrypted key

"salt len" is four decimal characters indicating the length of the salt
value ("0000" if no salt value)

"key value" is the encrypted key

"salt value" (if specified) is the salt value.

For example, "01990000080000#!#%@!#$" defines an encrypted key with a
length of 8 bytes and a value of "#!#%@!#$".  The key was generated
using DES encryption and no salt value; then, encrypted with master key
version 0.  As another example, "05040000140006&*&*&*&*&*&*&*mysalt"
defines an encrypted key with a length of 14 bytes and a value of
"&*&*&*&*&*&*&*".  The key was generated using triple-DES encryption
with a special salt type value that has a length of 6 and a value of
"mysalt"; then, encrypted with master key version 0.'

The creator of a principal key entry must be a trusted DN (a DN that is
listed in either the krbKdcServiceObject, krbPwdServiceObject, or
krbTrustedAdmObject attribute of the realm entry).  The trusted
DN is responsible for doing the following:

1.  Get a secret password or a sequence of secret keys from the
principal.

2.  If a secret password is supplied, use a string-to-key
algorithm to generate a secret key for each supported key type.
The string-to-key algorithm must conform to the string-
to-key algorithm described in RFC 1510, taking into consideration
the salt type of the key type.

3.  If a sequence of secret keys is supplied, verify that each
key type is supported.

4.  Encrypt each secret key with each master key that is of the
same encryption type (or have one or more KDC services do this).

5.  Create a KrbKey entry for each encrypted secret key.  Store
the encrypted secret key in the KrbKey entry along with
information required to generate the encrypted secret key from a
password.

The following is an example.  In this example, a single
principal key entry is configured for Alice Smith.  The principal key
is a Version 1 entry and contains the value of two keys:  a key
generated with the DES algorithm and no salt and a key generated with
the triple-DES algorithm and a salt value of "mysalt".  Each key is
encrypted with master key Version 1, which is a master key that
is shared by all the KDC services in the realm.

  dn: krbKeyVersion=1, cn=Alice Smith, cn=users, ou=Austin
  objectclass: KrbKey
  krbKeyVersion: 1
  krbKeyData: 01990000080000#!#%@!#$
  krbKeyData: 05040000080006&*&*&*&*mysalt

The following is the same as the previous example except in this
example, each KDC service in the realm has its own master key.
Therefore, a different KrbKey entry is configured for each of the two
KDC services in the realm.

  dn: krbKeyVersion=1+krbKdcService=serverA, cn=Alice Smith, cn=users,
ou=Austin
  objectclass: KrbKey
  krbKeyVersion: 1
  krbKdcService: serverA
  krbKeyData: 01990000080000#!#%@!#$
  krbKeyData: 05040000080006&*&*&*&*mysalt

  dn: krbKeyVersion=1+krbKdcService=serverB, cn=Alice Smith, cn=users,
ou=Austin
  objectclass: KrbKey
  krbKeyVersion: 1
  krbKdcService: serverB
  krbKeyData: 01990000080000#12%@!#$
  krbKeyData: 05040000080006&2&3&*&*mysalt



4.2.2.  KRBKEY-SUBTREE Configuration

If the krbSecretKeyCfg attribute of the realm entry contains the value
of KRBKEY-SUBTREE, the LDAP directory MUST contain the following
entries:

* one "cn=KEYS" entry

* one or more principal key referral entries for each principal in the
realm

The following figure shows where these entries MUST reside in the LDAP
directory:

 ------------                      -------------------
 :any entry :                      : realm entry      :
 :as defined:                      : as defined in    :
 :in KDC    :                      : the KDC LDAP     :
 :LDAP      :<---------------------: schema           :
 :schema    : n                   1:                  :
 :          :                      :                  :
 ------------                      --------------------
     1::                                    1:
      ::                                    1:
      ::                           :------------------:
      ::                           : cn=KEYS entry    :
      ::                           :                  :
      ::                           :------------------:
      ::                                    1:
      ::                                    n:
----------------                   --------------------------
: principal    :                   : principal key referral :
: entry as     :<------------------: entry                  :
: defined in   : 1               n :                        :
: KDC LDAP     :                   :                        :
: schema       :                   :                        :
----------------                   --------------------------



4.2.2.1.  cn=KEYS Entry

A "cn=KEYS" entry represents a container for information on all
principal keys in the realm.  A "cn=KEYS" entry MAY be configured using
the container object class.

The DN of a CN=KEYS entry MUST be in the following format:

* The RDN MUST be "cn=KEYS".

* The remaining parts MUST logically be the DN of the realm entry.

For example, the DN of a cn=KEYS entry could be "cn=KEYS,
krbRealmName=PAYROLL, ou=Austin".

There are no required or optional attributes of a cn=KEYS entry.


4.2.2.2.  Principal Key Referral Entries

A principal key referral entry is the same as a principal key entry with
three exception.  The exceptions are:

* In the DN of a principal key referral entry, the RDN MUST include the
following attribute-value pair:  "krbPrincipalNameRef =
<principal_name>", where <principal_name> is the name of the principal
configured in the associated principal entry.

* In the DN of a principal key referral entry, the second through last
components MUST be the DN of the cn=KEYS entry.

* A principal key referral entry MUST contain the following attribute:
krbPrincipalNameRef, which MUST contain the same principal name that is
specified in the RDN of the entry.

A principal key referral entry MAY be configured with the KrbKey
structural object class and the KrbKeyRef auxiliary object class.

The following is an example of a KRBKEY-SUBTREE configuration.
In this example, the cn=KEYS entry is configured with a referral to
an LDAP server named TrustedLDAPServer.  Therefore, all entries under
cn=KEYS (including the key for Alice Smith) are serviced by an LDAP
server named LDAPServer.

   dn: cn=KEYS, krbRealmName=PAYROLL, ou=Austin
   objectclass: referral
   objectclass: extensibleObject
   ref: ldap://TrustedLDAPServer/cn=KEYS, krbRealmName=PAYROLL,
ou=Austin
   cn: KEYS

In this example, the referenced server contains the following entries:

   dn: cn=KEYS, krbRealmName=PAYROLL, ou=Austin
   objectclass: container
   cn: KEYS

   dn: krbKeyVersion=1+krbPrincipalNameRef=alice@realm1, cn=users,
ou=Austin, cn=KEYS, krbRealmName=PAYROLL, ou=Austin
   objectclass: KrbKey
   krbKeyVersion: 1
   krbPrincipalNameRef=alice@realm1
   krbKeyData: 01990000080000#!#%@!#$
   krbKeyData: 05040000080006&*&*&*&*mysalt



4.2.3.  USERPASSWORD Configuration

If the krbSecretKeyCfg attribute of the realm entry contains the value
of USERPASSWORD, each principal entry MUST contain a userPassword
attribute.  One of the values in the userPassword attribute MUST be the
secret key of the principal.


4.2.4.  AUTHPASSWORD Configuration

If the krbSecretKeyCfg attribute of the realm entry contains the value
of AUTHPASSWORD, each principal entry MUST contain an authPassword
attribute.  One of the values in the authPassword attribute MUST be the
secret key of the principal.


4. Syntaxes

The Keys Extension schema uses only syntaxes listed in RFC 2252.



5. Attribute Types

The Keys Extension schema uses the attribute types listed in this
section and RFC 2256.



5.1 New Attribute Types

(
1.3.18.0.2.4.1897
NAME 'krbKdcServiceName'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 (directory string)
SINGLE-VALUE
DESC 'Name of a KDC service.  The name must be the same as the name
specified in the serviceName attribute of the KDC service entry
referenced by the krbKdcServiceObject attribute of the realm entry.'
EQUALITY caseExactMatch
)

(
1.3.18.0.2.4.1882
NAME 'krbKeyData'
SYNTAX 1.3.6.1.4.1466.155.121.1.40 (octet string)
DESC 'A set of values with each value containing an encrypted key and
information about the encrypted key.'
)

(
1.3.18.0.2.4.1906
NAME 'krbKeyExpires'

SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 (Integer)
SINGLE-VALUE
DESC 'A value indicating the date and time when a key expires.
)

(
1.3.18.0.2.4.1910
NAME 'krbKeyName'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 (directory string)
SINGLE-VALUE
DESC 'Name of a secret key.'
EQUALITY caseExactMatch
)


(
1.3.18.0.2.4.1900
NAME 'krbKeyVersion'

SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 (Integer)
SINGLE-VALUE
DESC 'Version of a secret key; a monotomic increasing number
beginning with 1.'
)



(
1.3.18.0.2.4.1895
NAME 'krbMstrKeyData'
SYNTAX 1.3.6.1.4.1466.155.121.1.40 (octet string)
DESC 'A set of master key data with each master key data containing
either the master key value or the URL address where the master key
value is stored, and information about the master key.'
)


(
1.3.18.0.2.4.1896
NAME 'krbNextKeyVersion'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 (integer)
SINGLE-VALUE
DESC 'A value indicating the next version of a key.'

)

(
1.3.18.0.2.4.1894
NAME 'krbPrincipalDN'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 (DN)
SINGLE-VALUE
DESC 'Forward reference to an associated principal entry.'
EQUALITY distinguishedNameMatch
)
(
krbPrincipalNameRef-oid
NAME 'krbPrincipalNameRef'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 (directory string)
SINGLE-VALUE
DESC 'Forward reference to the name of an associated principal entry.'
EQUALITY caseExactMatch
)

(
1.3.18.0.2.4.1886
NAME 'krbSecretKeyCfg'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 (integer)
SINGLE-VALUE
DESC 'One of the following values indicating where the secret key
for a Kerberos principal is configured:
1 = KRBKEY (default) -- The secret key is stored in one or more
KrbKey entries with each KrbKey entry residing directly below the
associated principal entry.
2=  KRBKEY-SUBTREE -- The secret key is stored in one or more
principal key entries with each principal key entry residing directly
below an entry
with an RDN of "cn=KEYS" and with the "cn=KEYS" entry residing directly
below the realm entry.
3 = USERPASSWORD -- The secret key is stored in the userPassword
attribute of the principal entry.  The userPassword attribute is defined
in RFC 2256[5].
4 = AUTHPASSWORD -- The secret key is stored in the authPassword
attribute of the principal entry.  The authPassword attribute is defined
in RFC 3112[10].
)


6. Object Classes

The Keys Extension schema uses the object classes listed in this
section.

{
1.3.18.0.2.6.28
NAME 'container'
DESC "An object that can contain other objects.'
SUP top
STRUCTURAL
MUST ( cn )
)

(
1.3.18.0.2.6.362
NAME 'KrbKey'
DESC 'A structural object class for use in configuring an entry
to represent a set of Kerberos keys for an associated Kerberos
principal.'
SUP top
STRUCTURAL
MUST ( krbKeyVersion $ krbKeyData )
MAY ( krbKdcServiceName $ krbKeyExpires $ krbNextKeyVersion $
krbPrincipalDN)
)

(
KrbKeyRef-oid
NAME 'KrbKey'
DESC 'An auxiliary object class use in configuring the principal
name of an associated principal entry.
principal.'
SUP top
AUXILIARY
MUST ( krbKeyVersion $ krbKeyData )
MAY ( krbKdcServiceName $ krbKeyExpires $ krbNextKeyVersion $
krbPrincipalDN)
)

(
1.3.18.0.2.6.359
NAME 'KrbKeyCfg'
DESC '  An auxiliary object class for use in configuring the
krbSecretKeyCfg attribute in the realm entry, which defines
how the principal keys in the realm are configured.'
SUP top
AUXILIARY
MAY ( krbSecretKeyCfg )
)

(
1.3.18.0.2.6.361
NAME 'KrbMstrKey'
DESC 'A structural object class for use in configuring an entry
to represent a Kerberos master key.'
SUP top
STRUCTURAL
MUST (krbKeyVersion $ krbMstrKeyData)
MAY ( krbKdcServiceName $ krbKeyExpires $ krbKeyName $ krbNextKeyVersion
)




7. Security Considerations

---------------------------------------------------
     AUTHENTICATION DISCLOSURE:

     This document describes a directory access protocol
     that provides both read and update access.  Update
     access and read access to keying material requires
     secure authentication, but this document does
     not mandate implementation of any satisfactory
     authentication mechanisms.

     In accordance with RFC 2026, section 4.4.1, this
     specification is being considered by IESG as a
     proposed standard despite this limitation, for the
     following reasons:
        a. to encourage implementation and interoperability
     testing of these protocols (with or without update
     access) before they are deployed, and
        b. to encourage deployment and use of these
     protocols in read-only applications.  (e.g.
     applications where LDAPv3 is used as a query language
     for directories which are updated by some secure
     mechanism other than LDAP), and
        c. to avoid delaying the advancement and deployment
     of other Internet standards-track protocols which
     require the ability to query, but not update, LDAPv3
     directory servers.

     Readers are hereby warned that until mandatory
     authentication mechanisms that are as strong or stronger
     than Kerberos are standardized, clients and servers
     written according to this specification which make
     make use of update functionality or the reading
     of keying material are UNLIKELY TO INTER-OPERATE, or
     MAY INTER-OPERATE ONLY IF AUTHENTICATION IS REDUCED
     TO AN UNACCEPTABLY WEAK LEVEL.  (RFC 2829 [6]
     mandates that LDAP servers supporting authentication
     based on user ID and password implement the digest
     authentication protocol defined in RFC 2831 [9],
     but this mechanism is considered to be weaker
     than the Kerberos.)

     Implementers are hereby discouraged from deploying
     LDAPv3 clients or servers which implement the update
     functionality, until a Proposed Standard for mandatory
     authentication in LDAPv3 has been approved and
     published as an RFC.

------------------------------------------------------------


The following entities must be trusted to protect KDC attributes as
described in this section:

* Administrators of the Keys Extension schema
* KDC services that use the Keys Extension schema
* LDAP client libraries used to access the Keys Extension schema
* LDAP servers and backend databases with access to the Keys Extension
schema
* Administrators of LDAP servers and backend databases with access to
KDC attributes



7.1.  Security Considerations for Administrators of the Keys Extension
schema

All administrators of the Keys Extension schema must be trusted,
must comply with strict security controls, and must be responsible
for:

* Ensuring that KDC key attributes are configured in LDAP locations
that can be accessed only by LDAP servers that comply with the security
considerations described in "Section 7.4.  Security Considerations for
LDAP Servers and Backend Databases with Access to the Keys Extension
schema".

* If LDAP client libraries are used to access KDC key attributes,
ensuring that these libraries comply with the security
considerations described in "Section 7.3.  Security Considerations for
LDAP Client Libraries Used to Access the Keys Extension schema"

* Ensuring that KDC key attributes are transmitted securely to and from
the LDAP server.  If KDC key attributes are transmitted over the
network,
they must be transmitted using a security protocol with client and
server authentication, data integrity, and, if the attribute contains
key data, encryption that is as strong or stronger than triple-DES.

* If the MKEYS entry is configured in LDAP, protecting this entry
so that only a trusted identity in the realm can insert entries under
the MKEY entry.

* If a master key entry is configured in LDAP, protecting this entry so
that only trusted identities can modify, delete, or insert new
attributes in the entry; only trusted identities can rename or delete
the entry; and only a KDC service in the realm can read attributes in
the entry.

* If the realm is configured for KRBKEY or KRBKEY-SUBTREE:

    - protecting each KrbKey entry so that only trusted identities can
modify, delete, or insert attributes in this entry; only trusted
identities can rename this entry; only trusted identities and the
associated principal can delete this entry; and only a KDC service can
read attributes from this entry.

    - generating and encrypting the key value stored in each KrbKey
entry as described previously in this document.

    - if configured for KRBKEY-SUBTREE, protecting the KEYS entry
so that only KDC services in the realm can insert entries under
the KEYS entry.

* If the realm is configured for USERPASSWORD or AUTHPASSWORD,
protecting the userPassword or authPassword attribute so that only
trusted identities can insert, delete, modify, or read this attribute.



7.2.  Security Considerations for KDC Servers that Use the KDC LDAP
Schema

All KDC servers that use the Keys Extension schema must be trusted,
must be physically protected (for example, kept in a locked room),
must be carefully analyzed for security problems, and must be
responsible for:

* Using LDAP client libraries that comply with the security
considerations described in "Section 7.3.  Security Considerations for
LDAP Client Libraries Used to Access the Keys Extension schema."

* Transmitting KDC key attributes securely to and from LDAP.
If KDC key attributes are transmitted over the network, they must be
transmitted using a security protocol with strong client and server
authentication, data integrity, and, if the attribute contains key
data, encryption that is as strong or stronger than triple-DES.

* Before retrieving attributes from a KrbKey entry, verifying that the
entry was created by an identity that is trusted in the realm.



7.3.  Security Considerations for LDAP Client Libraries Used to Access
the Keys Extension schema

All LDAP client libraries that are used to access the KDC Keys
Extension schema must be trusted, must be carefully analyzed
for security problems, and must be responsible for protecting
KDC key information from other identities on the same machine.

If an LDAP client library cannot be obtained that meets
these security requirements, it would be possible to
develop a secure LDAP client library, which could be used
by KDC servers,administrators of KDC key data, and administrators
of LDAP servers that access KDC key data.  The estimated lines of
code required to develop such a library is included in the estimated
lines of code required to develop the libraries used by a secure
LDAP server.  (See the next section.)



7.4.  Security Considerations for LDAP Servers and Backend Databases
that Can Access the Keys Extension schema

All LDAP servers and backend databases of LDAP servers that have
access to the Keys Extension Schema must be trusted, must be physically
protected (for example, kept in a locked room), must be carefully
analyzed for security problems, and must be responsible for:

* If remote access is supported, providing a security protocol that can
be used to transmit attributes over the network.  The protocol must
support client and server authentication, data integrity, and an
encryption algorithm that is as strong or stronger than triple-DES.

* Providing a way to protect attributes from unauthorized access.

* Providing a way of to audit access to attributes.

* Replicating attributes only to other trusted LDAP servers and
backend databases, and replicating these attributes in a secure
manner. If KDC key attributes are transmitted over the network,
they must be transmitted using a security protocol with strong
client and server authentication, data integrity, and, if the
attribute contains key data, encryption that is as strong or
stronger than triple-DES.

* If Kerberos is used to authenticate the KDC to the LDAP server, then
the LDAP server secret key may not be accessible over the network.

If an LDAP server cannot be obtained that meets these security
requirements, it would be possible to develop a small, trusted
LDAP server that reads and writes only the attributes defined
in the Keys Extension schema.  The LDAP server could read and write
these attributes to a small trusted database, such as a database
used by a legacy KDC.  The estimated lines of code required to
develop such a server is:

    Backend routines for storing KDC
    key data in a trusted database:   4K of new code

    LDAP libraries and includes: 25K of ported/analyzed code from
                                 OpenLDAP source

    LDAP server (SLAPD):  12K of ported/analyzed code from OpenLDAP
                           source

    LDAP replication server (SLURPD):  2K of ported/analyzed code
                                       from OpenLDAP source



7.5.  Security Considerations for Administrators that Manage LDAP
Servers and Backend Database with Access to the Keys Extension schema

The administrator of each LDAP server and backend database with access
to attributes in the Keys Extension schema must be trusted,
must conform to strict security controls, and is responsible for:

* If LDAP client libraries are used to access the attributes in the
schema, ensuring that these libraries comply with the security
considerations described in "Section 7.3.  Security Considerations for
LDAP Client Libraries Used to Access the Keys Extension schema."

* Enabling auditing of LDAP servers and backend databases when
required.

* If USERPASSWORD or AUTHPASSWORD is configured,  ensuring that the LDAP
server is configured to encrypt and hash any data stored in this
attribute using algorithms that are as strong or stronger than the
algorithms used by the KDC.  If the value in userPassword or
authPassword is hashed, this must be supported by the Kerberos client
interfaces as well as the KDC.



8. Acknowledgments

This schema was developed as part of a working group effort of
The Open Group Directory Interoperability Forum.



9. Expiration Date

This draft expires XXXX XX, 2001.



10. Bibliography

[1] Bradner, S., "The Internet Standards Process -- Revision 3",
BCP 9, RFC 2026, October 1996.

[2] Wahl, M., Howes, T., and S. Kille, "Lightweight Directory
Access Protocol (v3)", RFC 2251, December 1997.

[3] Wahl, M., Coulbeck, A., Howes, T., and S. Kille, "Lightweight
X.500 Directory Access Protocol (v3): Attribute Syntax
Definitions", RFC 2252, December 1997.

[4] Wahl, M., Kille, S., and T. Howes, "Lightweight Directory
Access Protocol (v3): UTF-8 String Representation of
Distinguished Names", RFC 2253, December 1997.

[5] Wahl, M., "A Summary of the X.500(96) User Schema for use
with LDAPv3", RFC 2256, December 1997.

 [6] Wahl, M.  Authentication Methods for LDAP, Request for Comments
2829, May 2000.

[7] Hodges, J., Morgan, R., and Wahl, M., "Lighweight Directory Access
Protocol (v3): Extension for Transport Layer Security", RFC 2830, May
2000.

[8] Leach, P. and C. Newman, "Using Digest Authentication as a SASL
Mechanism", RFC 2831, May 2000.

[9] J. Kohl, C. Neuman. The Kerberos Network Authentication
Service (V5), Request for Comments 1510.

[10] Zeilenga, K.  "LDAP Authentication Password Schema," RFC 3112, May
2001.


11. Author's Address


Donna Skibbie
IBM Corporation
1140 Burnet Road
Austin, TX  78758
Phone:  (512) 838-3896
Email:  donnas@us.ibm.com

Jonathan Trostle
NEW ADDRESS TBD


John Griffith
Entegrity Solutions Corporation
32 DW Highway
Merrimack, NH  03054
Email: john.griffith@entegrity.com

NAMES AND ADDRESSES OF ADDITIONAL
AUTHORS TBD

Open Issues

* Wyllys Ingersoll:  Should IETF draft list lines of code?

* Tim Hahn:  Should the format of krbKeyData be in ASN.1 notation?

* Donna Skibbie:  Should this draft be information track?