Subject: please publish draft-skibbie-krb-kdc-ldap-schema-01.txt

From: "Donna Skibbie" <[email-masked]>
Date: Fri, 2 Mar 2001 17:39:41 -0600

Please publish draft-skibbie-krb-kdc-ldap-schema-01.txt.  This is an update
to the document already published named
draft-skibbie-krb-kdc-ldap-schema-00.txt.

Donna Skibbie, Architect
IBM Corporation; 11400 Burnet Road; Austin, TX 78758 USA
Tel.: +1(512)838-3896 T/L 678; Fax: 8597
[email-masked]

-------------------------------------------------------------------------
INTERNET-DRAFT                               Donna Skibbie
Kerberos Working Group                       IBM
Intended Category:  Standards Track          Jonathan Trostle
Expires 2 Sept 2001                          Cisco
                                             John Griffith
                                             Entegrity Solutions
                                             2 March 2001

                      Kerberos KDC LDAP Schema
              draft-skibbie-krb-kdc-ldap-schema-01.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 schema for storing attributes (with
the exception of key attributes) used by implementations of
Kerberos Version 5 Key Distribution Center (KDC) service 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], and RFC 2256 [5].  The schema defined in this
document is referred to as the "KDC LDAP schema."  The KDC
LDAP schema includes definitions for attributes defining a
realm, a realm policy, principals, and principal policies.
The KDC LDAP schema does NOT include definitions for attributes
used to store keys.

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 [6].

3. Overview

The KDC LDAP 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 way of sharing common security
attributes, such as password policy attributes, with non-Kerberos
applications.  The third objective is to provide a way of
protecting sensitive information.  The fourth objective is to
promote inter-operability between different implementations of the
Kerberos KDC.

The following figure illustrates the KDC LDAP schema:

                   --------------------          -------------
                   : DN:KrbRealmName= :          : Any DN    :
                   : <realm name>, ...:          : with      :
 -----------       : KrbRealm,        : optional : KrbPolicy :
 :Any DN   :<------: KrbRealmExt,     :--------->:           :
 :         : n    1: and (optionally) : 1    1   :           :
 -----------       : KrbPolicy        :          :           :
     1::           --------------------          -------------
      ::
      ::
      ::
      ::
     n::
 -------------------                           ------------:
 : Any DN with     :                           : Any DN    :
 : KrbPrincipal    : 1     optional          1 : with      :
 : and (optionally):-------------------------->: KrbPolicy :
 : KrbPolicy       :                           :           :
 -------------------                           -------------
      1:
       :
      1:
 :---------------------
 : DN: cn=KrbLog, ... :
 : KrbLog             :
 :                    :
 :--------------------:

The figure uses the following notations:

* Each box represents an LDAP directory entry used by a KDC.
The information in each box indicates whether the KDC
requires the entry to be assigned a special LDAP
distinguished name (DN) or contain KDC attributes, or both.
For example, the box in the top middle represents an entry
that must contain a DN with a relative distinguished name
(RDN) of "krbRealmName=<realm name>" (for example,
"krbRealmName=REALM1.COM, ou=Austin") and be configured with
KrbRealm, KrbRealmExt, and (optionally) KrbPolicy attributes.

* The vertical line between the KrbPrincipal and KrbLog
entries represents a parent-child directory information tree
(DIT) association between the DNs of these two entries.  (For
example, if the KrbPrincipal entry DN is "cn=Alice Smith,
cn=Managers, ou=Austin", the KrbLog entry DN must be
"cn=KrbLog, cn=Alice Smith, cn=Managers, ou=Austin".)

* The double vertical line between the entry at the top left
corner and the KrbPrincipal entry represents an ancestor-
child DIT association between the DNs of these two entries.
(For example, if the DN of the top left corner entry is
"ou=Austin", the DN of the KrbPrincipal entry could be
"cn=Alice Smith, cn=Managers, ou=Austin".)

* Each arrow represents an optional forward reference between
two entries.  (For example, the arrow from the KrbPrincipal
entry to the KrbPolicy entry indicates that the KrbPrincipal
entry optionally can be configured with an attribute
containing the DN of the KrbPolicy entry.)

3.1 Realm Entry

The attributes defining a realm are included in the KrbRealm
structural object class and the KrbRealmExt auxiliary object
class.  These attributes must be stored in an entry that is
referred to as the "realm entry."  The RDN of the realm entry must
be "krbRealmName=<realm_name>", where realm name is the name of
the realm.  The following attributes are required:

*  krbRealmName--The name of the realm

*  krbPrincSubTree--The DN of each entry representing a sub-tree
under which principals in the realm reside.  This attribute allows
the identity who configures the realm entry to determine which
sub-trees can be trusted to contain entries defining principals in
the realm.

*  krbKdcServiceObject--The DN of each entry representing a KDC
service in the realm.

The following is an example of a realm entry:

  DN: krbRealmName=PAYROLL, ou=Austin
  objectclass: KrbRealm
  krbRealmName: Payroll
  krbPrincSubTree: cn=users, ou=Austin
  objectclass: KrbRealmExt
  krbKdcServiceObject: serviceName=serverA, dc=payroll, ou=Austin
  krbKdcServiceObject: serviceName=serverB, dc=payroll, ou=Austin
  <additional KrbRealmExt attributes>

3.2 Realm Policy Attributes

The attributes defining the policy for the realm are included in
the KrbPolicy auxiliary object class.  These attributes must be
stored in the realm entry, an entry referenced by the
krbPolicyObject attribute of the realm entry, or both entries.
If the same policy attribute is stored in both entries, the
policy attribute in the realm entry takes precedence.

The following is an example with the policy attributes configured
in the realm entry:

  DN: krbRealmName=PAYROLL, ou=Austin
  objectclass: KrbRealm
  objectclass: KrbRealmExt
  <KrbRealm and KrbRealmExt attributes>
  objectclass: KrbPolicy
  <KrbPolicy attributes>

The following is an example with the policy attributes configured
in a referenced entry:

  DN: krbRealmName=PAYROLL, ou=Austin
  objectclass: KrbRealm
  objectclass: KrbRealmExt
  <KrbRealm and KrbRealmExt attributes>
  krbPolicyObject: cn=MyPolicy, ou=Austin

  DN: cn=MyPolicy, ou=Austin
  objectclass: PasswordPolicy
  <PasswordPolicy attributes>
  objectclass: KrbPolicy
  <KrbPolicy attributes>

3.3 Principal Entries

The attributes defining each principal in the realm are included
in the KrbPrincipal auxiliary object class.  These attributes can
be stored in any entry that meets the following requirements:

*  The entry must reside under a sub-tree listed in the
krbPrincSubTree attribute of the entry representing the realm in
which the principal will reside

*  The entry must not already be configured to represent a
Kerberos principal

The entry where the KrbPrincipal attributes are stored is
referred to as a "principal entry."  A principal entry must
contain the krbPrincipalName attribute.  This attribute contains
the Kerberos identity of the principal in the format
"<principal>@<realm>", where <principal> is the name of the
principal and <realm> is the name of the realm.   The Kerberos
principal identity must be unique within the realm.

The following is an example of a person entry configured
as a principal entry:

  DN: cn=Alice Smith, cn=users, ou=Austin
  objectclass: Person
  cn: Alice Smith
  <additional Person attributes>
  objectclass: KrbPrincipal
  krbPrincipalName: alice@PAYROLL
  <additional KrbPrincipal attributes>

3.4 Principals Associated with Other Entries (Optional)

The schema provides an optional way of associating a principal
entry with another entry through the use of aliases.  This
association is ignored by the KDC, but can be used by higher-
level applications to associate a principal with a target entry
and to verify that the target entry accepts this association.

There are three reasons why it might be necessary to configure
alias associations.  One reason is to allow an entry already
configured with a principal identity to be associated with other
principal identities.  Another reason is to allow an entry
configured in a remote part of the directory to be associated
with a principal identity configured in a local part of the
directory.  A third reason is to allow an entry configured in a
less secure part of the directory to be associated with a
principal identity configured in more secure part of the
directory.

The association is configured by doing both of the following:

*  adding the krbAliasedObjectName attribute from the KrbAlias
auxiliary object class to the principal entry and configuring
krbAliasedObjectName to reference the target entry

*  adding krbHintAliases attribute from the KrbAlias auxiliary
object class to the target entry and configuring krbHintAliases
attribute to reference the principal entry.

The following is an example in which the Alice Smith person
entry, which already is configured as the principal identity of
alice@PAYROLL, is associated with a second principal identity of
alice@PURCHASING.

  DN: cn=Alice Smith, cn=users, ou=Austin
  objectclass: Person
  cn: Alice Smith
  <additional Person attributes>
  objectclass: KrbPrincipal
  krbPrincipalName: alice@PAYROLL
  <additional KrbPrincipal attributes>
  objectclass:  KrbAlias
  krbHintAliases:  cn=alice@PURCHASING, krbRealmName=PURCHASING,
ou=Austin

  DN: cn=alice@PURCHASING, krbRealmName=PURCHASING, ou=Austin
  objectclass: Person
  cn: alice@PURCHASING
  sn: alice@PURCHASING
  objectclass: KrbPrincipal
  krbPrincipalName: alice@PURCHASING
  <additional KrbPrincipal attributes>
  objectclass:  KrbAlias
  krbAliasedObjectName:  cn=Alice Smith, cn=users, ou=Austin

The following is an example of an association between a principal
entry for bob@PAYROLL and a person entry for Bob Jones that
exists in a remote or more secure part of the directory:

  DN: cn=bob@PAYROLL, cn=users, ou=Austin
  objectclass: Person
  cn: bob@PAYROLL
  sn: bob@PAYROLL
  objectclass: KrbPrincipal
  krbPrincipalName: bob@PAYROLL
  <additional KrbPrincipal attributes>
  objectclass:  KrbAlias
  krbAliasedObjectName:  cn=Bob Jones, ou=Raleigh

  DN: cn=Bob Jones, ou=Raleigh
  objectclass: Person
  cn: Bob Jones
  <additional Person attributes>
  objectclass: KrbAlias
  krbHintAliases: cn=bob@PAYROLL, cn=users, ou=Austin

3.6 Principal Policy Attributes

The attributes defining the policy for the principal are included
in the KrbPolicy auxiliary object class.  These attributes must be
stored in the principal entry, an entry referenced by the
krbPolicyObject of the principal entry, or both entries.  If the
same policy attribute is stored in both entries, the policy
attribute in the principal entry takes precedence.

3.5 Principal Log (KrbLog) Entries

The attributes defining a login activity record for a principal
are included in the KrbLog structural object class.  These
attributes must be stored in the KrbLog entry that resides
directly below the principal entry.  The RDN of this entry must
be "cn=KrbLog".  The creator of this entry must be a DN that
represents a KDC service in the realm (a DN listed in the
krbKdcServiceObject attribute of the realm entry)

The following is an example of a KrbLog entry.

  DN: cn=KrbLog, cn=Alice Smith, cn=users, ou=Austin
  objectclass: KrbLog
  <KrbLog attributes>

4. Syntaxes

The KDC LDAP schema uses the following syntaxes in attribute type
definitions:

*  Syntaxes listed in RFC 2252

*  The interval syntax

The interval syntax is defined in the Microsoft Active Directory
schema.  The definition is as follows:

(
1.2.840.113556.1.4.906
NAME 'Interval'
DESC 'Large integer.  Use for 64-bit values.
)

5. Attribute Types

The KDC LDAP schema uses the attribute types listed in this
section and RFC 2256.

5.1 New Attribute Types

(
krbAdmAclDB-oid
NAME 'krbAdmAclDB'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 (directory string)
SINGLE-VALUE
DESC 'The location of an ACL database for a Kerberos
administration services,  The location must be specified as in
URL format; i.e., FILE://path/filename.'
EQUALITY caseExactMatch
)

(
krbAdmKeyLocation-oid
NAME 'krbAdmKeyLocation'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 (directory string)
SINGLE-VALUE
DESC 'The location of a keytab file containing the key used by
the Kerberos administration services,  The location must be
specified as in URL format; i.e., FILE://path/filename.'
EQUALITY caseExactMatch
)

(
krbAdmServiceObject-oid
NAME 'krbAdmServiceObject'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 (DN)
DESC 'A set of references to entries, with each entry
representing a Kerberos administration service in the realm.'
EQUALITY dnMatch
)

(
krbAliasedObjectName-oid
NAME 'krbAliasedObjectName'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 (DN)
SINGLE-VALUE
DESC 'Forward reference to the entry for which this entry is an
alias.'
EQUALITY dnMatch
)

(
krbAttributes-oid
NAME 'krbAttributes'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 (integer)
SINGLE-VALUE
DESC "A value containing one or more flags.  The following flags
are available:
KRB5_KDB_NEW_PRINC = 0x00008000
KRB5_KDB_PWCHANGE_SERVICE = 0x00002000
KRB5_KDB_REQUIRES_HW_AUTH = 0x00000100
KRB5_KDB_REQUIRES_PWCHANGE = 0x00000200
KRB5_KDB_SUPPORT_DESMD5 = 0x00004000
KRB5_KDB_DISALLOW_DUP_SKEY = 0x00000020
KRB5_KDB_DISALLOW_POSTDATED = 0x00000001
KRB5_KDB_DIALLOW_PROXIABLE = 0x00000010
KRB5_KDB_DISALLOW_RENEWABLE = 0x00000008
KRB5_KDB_DIALLOW_TGT_BASED = 0x00000004
USER_TO_USER = 0x00010000
KRB5_KDB_DISALLOW_SVR = 0x00001000'
)

(
krbCreatorsName-oid
NAME 'krbCreatorsName'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 (DN)
SINGLE-VALUE
DESC 'The identity that first added KrbPrincipal attributes to a
principal entry.  It is the responsibility of this identity to
add the krbCreatorsName attribute to the principal entry.  If a
principal entry does not contain a krbCreatorsName attribute, the
LDAP system-controlled creatorsName attribute is assumed to
contain the correct creator identity.'
EQUALITY dnMatch
)

(
krbCreateTimestamp-oid
NAME 'krbCreateTimestamp'
SYNTAX 1.2.840.113556.1.4.906 (interval)
SINGLE-VALUE
DESC 'The date and time when the identity stored in the
krbCreatorsName attribute first added the KrbPrincipal attributes
to a principal entry.  It is the responsibility of the identity
named in the krbCreatorsName attribute to add the
krbCreateTimestamp attribute to the principal entry.  '
)

(
krbCurKeyVersion-oid
NAME 'krbCurKeyVersion'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 (integer)
DESC 'A value indicating the current version of a key.'
)

(
krbEncTypeSupport-oid
NAME 'krbEncTypeSupport'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 (integer)
DESC 'A set of supported encryption type values.  See krbKeyType
for encryption type values.  The available values are:
  ENCTYPE_NULL 00
  ENCTYPE_DES_CBC_CRC 01 (DES cbc mode with CRC-32)
  ENCTYPE_DES_CBC_MD4 02 (DES cbc mode with RSA-MD4)
  ENCTYPE_DES_CBC_MD5 03 (DES cbc mode with RSA-MD5)
  ENCTYPE_DES_CBC_RAW  04 (DES cbc mode raw)
  ENCTYPE_DES3_CBC_SHA 05 (DES-3 cbc mode with NIST-SHA)
  ENCTYPE_DES3_CBC_RAW 06 (DES-3 cbc mode raw)
  ENCTYPE_RSA_PRIVKEY 91 (RSA private key; required for
support of DCE)
  ENCTYPE_UNKNOWN 99'
)

(
krbExtraData-oid
NAME 'krbExtraData'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 (directory string)
SINGLE-VALUE
DESC 'Extra data that is associated with a Kerberos principal and
that has an application-specific meaning.  This attribute is
provided to support the Kerberos kadmin APIs.'
EQUALITY 'caseExactMatch'
)

(
krbHintAliases-oid
NAME 'krbHintAliases'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 (DN)
DESC 'A set of backward references to entries that can serve as
aliases for this entry.'
EQUALITY dnMatch
)

(
krbKdcServiceObject-oid
NAME 'krbKdcServiceObject'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 (DN)
DESC 'A set of references to entries, with each entry
representing a KDC service in the realm.'
EQUALITY dnMatch
)

(
krbKeyType-oid
NAME 'krbKeyType'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 (IA5String)
DESC 'A set of key types.  Each key type is specified in
the following format:
0  1  2  3  4
+--+--+--+--+
| enc |salt |
|type |type |
+--+--+--+--+
where
"enc type" is two decimal characters indicating the encryption
type of the key.  See krbEncTypeSupport for a list of available
encryption type values.
"salt type" is two decimal characters indicating
the salt type of the key.  See krbSaltTypeSupport for a list of
available salt type values.
For example, "0199" indicates a key that is generated with DES
encryption and no salt.  As another example, "0500" indicates that
a key that is generated using triple DES encryption and a normal
salt type value.'
)

(
krbModifiersName-oid
NAME 'krbModifiersName'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 (DN)
SINGLE-VALUE
DESC 'The last modifier of any KDC attribute associated with a
principal entry.  It is the responsibility of the identity that
modifies any attributes associated with a principal entry to add
or update the  krbModifiersName attribute.  If a principal entry
does not contain a krbModifiersName attribute, the LDAP system-
controlled modifiersName attribute of this entry is used to get
the identity that last modified the principal entry.'
EQUALITY dnMatch
)

(
krbModifyTimestamp-oid
NAME 'krbModifyTimestamp'
SYNTAX 1.2.840.113556.1.4.906 (interval)
SINGLE-VALUE
DESC 'The date and time when the identity specified in the
krbModifiersName attribute made the last modification.  It is the
responsibility of the identity that made the modification to add
or update the krbModifyTimestamp attribute.  '
)

(
krbMultKeyVersionsOK-oid
NAME 'krbMultKeyVersionsOK'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 (boolean)
SINGLE-VALUE
DESC 'True if multiple versions of a key for each encryption type
can be stored for this account.'
)

(
krbPolicyName-oid
NAME 'krbPolicyName'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 (directory string)
SINGLE-VALUE
DESC 'Name for a Kerberos policy in the form <policy>@<realm>.
<policy> is the name of a policy and must be unique within
the realm.  <realm> is the name of the realm.  The realm
name must conform to the rules described in RFC 1510 and
must be the same as the realm name specified in the
krbRealmName attribute of the realm entry.'
EQUALITY caseExactMatch
)

(
krbPolicyObject-oid
NAME 'krbPolicyObject'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 (DN)
SINGLE-VALUE
DESC 'Forward reference to an entry containing policy
information.'
EQUALITY dnMatch
)

(
krbPrincipalName-oid
NAME 'krbPrincipalName'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 (directory string)
SINGLE-VALUE
DESC 'Kerberos principal identity for a user in the form
<principal>@<realm>. <principal> is the name of the principal
and must conform to the rules described in RFC 1510.  <realm> is
the realm name.  The realm name must conform to the rules
described in RFC 1510 and must be the same as the realm name
specified in the krbRealmName attribute of the realm entry.'
EQUALITY caseExactMatch
)

(
krbPrincipalType-oid
NAME 'krbPrincipalType'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 (integer)
SINGLE-VALUE
DESC 'Value defining the type of a principal.  The available
principal type values are:
0 = KRB5_NT_UNKNOWN
1 = KRB5_NT_PRINCIPAL
2 = KRB5_NT_SRV_INST
3 = KRB5_NT_SRV_HST
4 = KRB5_NT_SRV_XHST
5 = KRB5_NT_UID'
)

(
krbPrincSubTree-oid
NAME 'krbPrincSubTree
SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 (DN)
DESC 'A set of forward references to an entry that starts a sub-
tree where principals in the realm are configured.'
EQUALITY dnMatch
)

(
krbPwdServiceObject-oid
NAME 'krbPwdServiceObject'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 (DN)
DESC 'A set of references to entries, with each entry
representing a password service in the realm.'
EQUALITY dnMatch
)

(
krbRealmName-oid
NAME 'krbRealmName'
SYNTAX 1.3.6. 11.4.1.1466.115.121.1.15 (directory string)
SINGLE-VALUE
DESC 'Name of a security realm.  The realm name must
conform to the rules listed in RFC 1510.'
EQUALITY caseExactMatch
)

(
krbRedundancyPolicy-oid
NAME 'krbRedundancyPolicy'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 (integer)
SINGLE-VALUE
DESC 'One of the following values indicating which set of
attributes to use for those attributes that have the same logical
meaning:
01 -- Use the set of attributes from the Netscape or IBM/Tivoli
schema (default)
02 -- Use the set of attributes from the Microsoft schema.  The
following table lists the sets of attributes that have the same
logical meanings and the schema's in which these attributes are
defined:
-------------------------------------
Netscape or            Microsoft
IBM/Tivoli             Schema
Schema
-------------------------------------
passwordExpireTime     computed from pwdLastSet and maxPwdAge
passwordMaxAge         maxPwdAge
passwordMinAge         minPwdAge
passwordMinLength      minPwdLength
secAcctExpires         accountExpires
secAcctValid           userAccountControl (!ACCOUNT_DISABLE)
'
)

(
krbSaltTypeSupport-oid
NAME 'krbSaltTypeSupport'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 (integer)
DESC 'A set of values defining the supported salt types.  See the
krbKeyType attribute for a list of salt types. The available
values are:
  KRB5_KDB_SALTTYPE_NORMAL = 0
  KRB5_KDB_SALTTYPE_V4 = 1
  KRB5_KDB_SALTTYPE_NOREALM = 2
  KRB5_KDB_SALTTYPE_ONLYREALM = 3
  KRB5_KDB_SALTTYPE_SPECIAL = 4
  KRB5_KDB_SALTTYPE_AFS3 = 5
  KRB5_KDB_NO_SALT_VALUE = 99'
)

(
krbTaggedDataList-oid
NAME 'krbTaggedDataList'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.5 (binary)
DESC 'Set of tagged data structures that is associated with a
Kerberos principal and that is defined by a Kerberos kadmin
application.  This attribute is provided to support the Kerberos
kadmin APIs.'
)

(
krbTrustedAdmObject-oid
NAME 'krbTrustedAdmObject'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 (DN)
DESC 'A set of forward references to trusted administration tools.
'
EQUALITY dnMatch
)

5.2 Attribute Types Defined in the Netscape Schema

(
2.16.840.1.113730.3.1.97
NAME 'passwordMaxAge'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 (integer)
DESC 'Specifies, in seconds, the period of time passwords can be
used before they expire.'
)

(
1.3.18.0.2.4.465
NAME 'passwordMinAge'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 (integer)
DESC 'Specifies, in seconds, the period of time a password must
be in effect before a user can change it.'
)

(
2.16.840.1.113730.3.1.99
NAME 'passwordMinLength'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 (integer)
DESC 'Specifies the minimum number of characters required for a
user's password.'
)

5.3 Attribute Types Defined in the Microsoft Active Directory
Schema

(
1.2.840.113556.1.4.159
NAME 'accountExpires'
SYNTAX 1.2.840.113556.1.4.906 (interval)
SINGLE-VALUE
DESC 'A value indicating when the account will expire. The value
is stored as a large integer that represents the number of seconds
elapsed since 00:00:00, January 1, 1970. A value of TIMEQ_FOREVER
(-1) indicates that the account never expires.'
)

(
1.2.840.113556.1.4.49
NAME 'badPasswordTime'
SYNTAX 1.2.840.113556.1.4.906 (interval)
SINGLE-VALUE
DESC 'A value indicating the last time the user tried to log onto
the account using an incorrect password.  The value is stored as
a large integer that represents the number of seconds elapsed
since 00:00:00, January 1, 1970. A value of zero (0) means the
last password time is unknown.  Each KDC server in the realm
maintains its own badPasswordTime attribute.  To get an accurate
value for the user's last bad password time in the realm, the
badPasswordTime attribute of each KDC server must be queried, and
the largest value should be used.'
)

(
1.2.840.113556.1.4.12
NAME 'badPwdCount'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 (integer)
SINGLE-VALUE
DESC 'A value indicating the number of times the user tried
to log on to the account using an incorrect password.
A value of zero (0) indicates that the value is unknown.
Each KDC server in the realm maintains its own badPwdCount
attribute.To get an accurate value for the user's total bad
password attempts in the realm, the badPwdCount attribute of each
KDC server in the realm must be queried, and the sum of the values
should be used.'
)

(
1.2.840.113556.1.4.52
NAME 'lastLogon'
SYNTAX 1.2.840.113556.1.4.906 (interval)
SINGLE-VALUE
DESC 'A value indicating when the last logon occurred.
The value is stored as a large integer that represents
the number of seconds elapsed since 00:00:00, January 1, 1970.
A value of zero (0) means that the last logon time is
unknown. Each KDC server maintains its own lastLogon attribute.
To get an accurate value for the user's last logon in
the domain, the lastLogon attribute of each KDC server in the
realm must be queried, and the largest value should be used.'

)

(
1.2.840.113556.1.4.95
NAME 'pwdHistoryLength'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 (integer)
SINGLE-VALUE
DESC 'A value indicating the number of previous passwords saved
in the history list. The user cannot reuse a password that is in
the history list.'
)

(
1.2.840.113556.1.4.96
NAME 'pwdLastSet'
SYNTAX 1.2.840.113556.1.4.906 (interval)
SINGLE-VALUE
DESC 'A value indicating when the user last set the password.
The value is stored as a large integer that represents
the number of seconds elapsed since 00:00:00, January 1, 1970.
The system uses the value of this property and the maxPwdAge
property of the domain containing the user object to calculate
the password expiration date (sum of pwdLastSet for the user and
maxPwdAge of the user's domain).'
)

(
1.2.840.113556.1.4.74
NAME 'maxPwdAge'
SYNTAX 1.2.840.113556.1.4.906 (interval)
SINGLE-VALUE
DESC 'A value indicating the maximum amount of time, in seconds,
after which the password must be changed by the owner.'
)

(
1.2.840.113556.1.4.75
NAME 'maxRenewAge'
SYNTAX 1.2.840.113556.1.4.906 (interval)
SINGLE-VALUE
DESC 'Value indicating the maximum renewable lifetime, in seconds,
of a Kerberos ticket.'
)

(
1.2.840.113556.1.4.77
NAME 'maxTicketAge'
SYNTAX 1.2.840.113556.1.4.906 (interval)
SINGLE-VALUE
DESC 'A value indicating the maximum lifetime, in seconds,
of a Kerberos ticket.'
)

(
1.2.840.113556.1.4.78
NAME 'minPwdAge'
SYNTAX 1.2.840.113556.1.4.906 (interval)
SINGLE-VALUE
DESC 'A value indicating the minimum amount of time, in seconds,
before the password is allowed to be changed.'
)

(
1.2.840.113556.1.4.79
NAME 'minPwdLength'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 (integer)
SINGLE-VALUE
DESC 'A value indicating the minimum number of characters that
must
be typed in for a password.'
)

(
1.2.840.113556.1.4.8
NAME 'userAccountControl'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 (integer)
SINGLE-VALUE
DESC 'A value containing one or more attributes that apply to an
account.  Each attribute is set with a flag.  Refer to the
Microsoft Active Directory documentation for a complete list of
flags.  The following flags are used in this KDC LDAP schema:
UF_ACCOUNT_DISABLE =  0x0001
UF_DONT_EXPIRE_PASSWD  =  0x10000
UF_TRUSTED_FOR_DELEGATION =  0x80000
UF_USE_DES_KEY_ONLY  =  0x200000
UF_DONT_REQUIRE_PREAUTH =  0x400000'
)

5.4 Attribute Types Defined in the IBM/Tivoli Schema

(
1.3.18.0.2.4.463
NAME 'passwordDictFiles'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 (directory string)
DESC 'Password dictionary files.'
EQUALITY caseExactMatch
)

(
1.3.18.0.2.4.485
NAME 'passwordExpireTime'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 (generalizedTime)
DESC ' Defines, in YYYYMMDDHHMMSS format, the date and time when
a user password expires.'
)

(
1.3.18.0.2.4.499
NAME 'passwordMinDiffChars'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 (integer)
DESC 'Specifies the minimum number of different (unique)
characters required for a user's password.'
)

(
1.3.6.1.4.1.4228.1.12
NAME 'secAcctExpires'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 (generalizedTime)
SINGLE-VALUE
DESC 'The date when a security account expires.'
)

(
1.3.6.1.4.1.4228.1.4
NAME 'secAcctValid'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 (boolean)
SINGLE-VALUE
DESC 'A boolean value indicating whether a security account is
valid.'
)

6. Object Classes

The KDC LDAP schema uses the object classes listed in this
section.

(
KrbAlias-oid
NAME 'KrbAlias'
DESC 'An auxiliary object class for use in configuring an
association between an entry containing security identity
information and another entry.  The krbAliasedObjectName is
configured in the entry with a security identity information and
contains a forward reference to a target entry.  The
krbHintAliases attribute is configured in the target entry and
contains a backward reference to the entry with the security
identity information.  Kerberos ignores the forward and backward
references.  However, higher level applications can use these
references to associate a security identity with a target entry
and then verify that the target entry allows this association.
For example, a higher level application can use the forward
reference to associate an entry representing a Kerberos principal
with an entry representing a person, and then use the backward
reference to determine whether the entry representing the person
allows this association.'
SUP top
Auxiliary
MAY (krbAliasedObjectName krbHintAliases)
)

(
KrbLog-oid
NAME 'KrbLog'
DESC 'A structural object class for use in configuring an entry
to represent a Kerberos login activity record for an associated
Kerberos principal.  The entry representing the Kerberos login
activity record must reside directly below the entry representing
the associated Kerberos principal and must have a creator
identity that is a KDC service in the realm.  (The DN recorded by
LDAP in the creatorsName attribute of the entry representing the
Kerberos login activity record must be listed in the
krbKdcServiceObject attribute of the entry representing the
realm.)  The relationship between the entry representing the
Kerberos login activity record and the entry representing the
associated Kerberos principal is one-to-many.  This is because
multiple KrbLog entries can be crreated for a single principal
with each KrbLog entry maintained by a different KDC service.
The RDN of the entry representing the Kerberos login activity
must be "cn=KrbLog".
SUP top
Structural
MUST ( cn )
MAY ( badPasswordTime $ badPwdCount $ lastLogon)
)

(
KrbPolicy-oid
NAME 'KrbPolicy'
DESC '  An auxiliary object class for use in configuring Kerberos
policy attributes for an associated Kerberos principal or
Kerberos realm.  The Kerberos policy attributes can reside in the
entry representing the Kerberos principal or realm, the entry
referenced by the krbPolicyObject attribute of the entry
representing the Kerberos principal or realm, or both.  If the
same policy attribute is configured in both entries, the policy
attribute from the entry representing the principal or realm is
used.  Some Kerberos policy values can be configured using one of
two sets of attributes.  For these attributes, the
krbRedundancyPolicy attribute in the entry representing the realm
determines which set of attributes to use.  (For example, the
maximum password lifetime value can be stored in the maxPwdAge or
passwordMaxAge attribute.  The krbRedundancyPolicy attribute
determines which of these two attributes to use.)'
SUP top
Auxiliary
MAY ( accountExpires $ krbAttributes $ krbPolicyName $ maxPwdAge
$ maxRenewAge $ maxTicketAge $ minPwdAge $ minPwdLength $
krbMultKeyVersionsOK $ passwordExpireTime $ passwordDictFiles
$ passwordMaxAge $ passwordMinAge $ passwordMinDiffChars $
passwordMinLength $ pwdHistoryLength $ secAcctExpires $
secAcctValid $ userAccountControl)
)

(
KrbPrincipal-oid
NAME 'KrbPrincipal'
DESC 'An auxiliary class for use in configuring an entry to
represent a Kerberos principal.
SUP top
Auxiliary
MUST (krbPrincipalName)
MAY (krbCurKeyVersion $ krbCreatorsName $ krbCreateTimestamp $
krbExtraData $ krbModifiersName $ krbModifyTimestamp $
krbPolicyObject $ krbPrincipalType $ krbTaggedDataList $
pwdLastSet)
)

(
KrbRealm-oid
NAME 'KrbRealm'
DESC  A structural object class for use in configuring an entry
to represent a Kerberos realm.  The RDN of this entry must
contain a string that indicates the contents of the krbRealmName
attribute; for example, "krbRealmName=COM.XYZ".'
SUP top
Structural
MUST ( krbPrincSubTree $ krbRealmName )
)

(
KrbRealmExt-oid
NAME 'KrbRealmExt'
DESC 'An auxiliary object class for use in configuring additional
attributes in an entry representing a Kerberos realm.'
SUP KrbPolicy
Auxiliary
MAY ( krbAdmAclDB $ krbAdmServiceObject $ krbEncTypeSupport $
krbKdcServiceObject $ krbKeyType $ krbPolicyObject $
krbPwdServiceObject $ krbRedundancyPolicy $
krbSaltTypeSupport $ krbTrustedAdmObject )
)

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 sensitive information 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 private information are UNLIKELY TO
     INTER-OPERATE, or MAY INTER-OPERATE ONLY IF AUTHENTICATION
     IS REDUCED TO AN UNACCEPTABLY WEAK LEVEL.  (RFC 2829 [7]
     mandates that LDAP servers supporting authentication
     based on user ID and password implement the digest
     authentication protocol defined in RFC 2831 [8],
     but this mechanism is considered to be weaker
     than the Kerberos.)

     Implementers are hereby discouraged from deploying
     LDAPv3 clients or servers that implement the update
     functionality or the reading of sensitive information
     until a Proposed Standard for a strong mandatory
     authentication mechanism 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 KDC LDAP schema
* KDC services that use the KDC LDAP schema
* LDAP client libraries used to access the KDC LDAP schema
* LDAP servers and backend databases with access to the KDC LDAP
schema
* Administrators of LDAP servers and backend databases with access
to KDC attributes

7.1.  Security Considerations for Administrators of the KDC LDAP
Schema

All administrators of the KDC LDAP schema must be trusted and are
responsible for:

* Ensuring that KDC 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 KDC LDAP Schema".

* 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 KDC LDAP Schema"

* Ensuring that KDC attributes are transmitted securely to and
from the LDAP server.  If KDC attributes are transmitted over the
network, they must be transmitted using a security protocol with
client and server authentication and data integrity.

* Protecting the realm entry so that only trusted identities can
modify, delete, or add attributes in the entry; only trusted
identities can rename or delete the entry; only trusted identities
can insert new entries under the entry; and only trusted
identities can read the values in the krbKdcServiceObject,
krbPwdServiceObject, and krbTrustedAdmObject attributes.

* Protecting each LDAP sub-tree referenced by krbPrincSubTree so
that only trusted identities can add, modify, or delete KDC
attributes residing under the sub-tree.

* Protecting each LDAP entry referenced by krbPolicyObject so that
so that only trusted identities can add, modify, or delete
attributes in the entry.

* Before retrieving attributes from a KrbLog entry, verifying that
the entry was created by a KDC service in the realm.

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

All KDC servers that use the KDC LDAP schema must be trusted and
are responsible for:

* Using LDAP client routines that comply with the security
considerations described in "Section 7.3.  Security Considerations
for LDAP Client Libraries Used to Access the KDC LDAP Schema."

* Transmitting KDC attributes securely to and from LDAP.  If KDC
attributes are transmitted over the network, they must be
transmitted using a security protocol with client and server
authentication and data integrity.

* When creating a KrbLog entry, protecting this entry so that only
a KDC service in the realm can modify, delete, and insert this
entry; and only a KDC service or a trusted identity in the realm
can delete or rename this entry.

* Before retrieving attributes from a KrbLog entry, verifying that
the entry was created by KDC service in the realm.

7.3.  Security Considerations for LDAP Client Libraries Used to
Access the KDC LDAP Schema

All LDAP client libraries used to access the KDC LDAP schema must
be trusted and are responsible for protecting this information
from other identities on the same machine.

If a trusted LDAP client library cannot be obtained, it would be
possible to develop a trusted LDAP client library, which could be
used by KDC servers, administrators of the KDC LDAP schema, and
administrators of LDAP servers that access the KDC LDAP schema.
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 trusted LDAP server.  (See the next section.)

7.4.  Security Considerations for LDAP Servers and Backend
Databases that Can Access the KDC LDAP Schema

All LDAP servers and backend databases of LDAP servers that have
access to the KDC LDAP schema must be trusted and are responsible
for:

* If remote access is supported, providing a security protocol for
transmitting attributes over the network.  The protocol must
support client and server authentication and data integrity, and
must be as strong or stronger than the Kerberos authentication
protocol.

* Providing a way to protect attributes from unauthorized access.

* Providing a way 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 attributes are transmitted over the network
to a replica, they must be transmitted using a security protocol
with client and server authentication and data integrity.

* 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 it is impossible to obtain an LDAP server that meets the level
of trust described in this section, it would be possible to
develop a trusted LDAP server that reads and writes KDC attributes
to a small trusted database, such as a database used by a legacy
KDC.  The estimated lines of code required to develop such an LDAP
server is:

    Backend routines for storing KDC
    attributes 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 KDC LDAP Schema

The administrator of each LDAP server and backend database with
access to attributes in the KDC LDAP schema 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 KDC LDAP Schema."

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

* Ensuring that the LDAP servers will not allow a client to
authenticate its identity to the LDAP server using an
authentication protocol that is weaker than the Kerberos
authentication protocol.

8. Acknowledgments

The authors wish to thank the members of The Open Group Directory
Interoperability Forum for their contributions to this document.

9. Expiration Date

This draft expires September 2, 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] J. Kohl, C. Neuman. The Kerberos Network Authentication
Service (V5), Request for Comments 1510.

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

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

11. Authors' Addresses

Donna Skibbie
IBM Corporation
1140 Burnet Road
Austin, TX  78758
Phone:  (512) 838-3896
Email:  [email-masked]

Jonathan Trostle
Cisco Systems
170 W. Tasman Dr.
San Jose, CA  95134
E-mail: [email-masked]

John Griffith
Entegrity Solutions Corporation
32 DW Highway
Merrimack, NH  03054
Email: [email-masked]