INTERNET-DRAFT Donna Skibbie Kerberos Working Group IBM Intended Category: Standards Track 10 November 2000 Expires 10 May 2001 Kerberos KDC LDAP Schema draft-skibbie-krb-kdc-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 schema for storing attributes used by the MIT implementation 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 the following attributes: * Attributes defining a realm--These attributes map to attributes defined in the KDC.conf file of the MIT implementation. * Attributes defining principals--These attributes map to attributes defined in RFC 1510 [6] and the principal and administration databases of the MIT implementation. 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 five objectives. The first objective is to use LDAP schema definitions defined in RFC 2252 and RFC 2256. The second objective is to use LDAP schema definitions defined in existing LDAP implementations. The third objective is to provide a way of sharing common security attributes, such as password policy attributes, with non-Kerberos applications. The fourth objective is to provide a way of protecting keys and other sensitive information. The fifth objective is to promote inter-operability between different implementations of the Kerberos KDC. The following figure illustrates the KDC LDAP schema: :------------------: ------------: ----------- : KrbRealm, : : Any Entry : :Any Entry:<------: KrbRealmExt, :------->: with : : : n 1: and KrbPolicy : 1 1 : KrbPolicy : ----------- : : : (optional): 1: :------------------: ------------- : 1: : : : n: : :----------------: : : KrbMstrKey : master key value : : (optional) :------->optionally can be : :----------------: stored in any URL : address, such as : a private file : n: ------------------ ------------: : Any Entry : : Any Entry : : with : 1 1 : with : : KrbPrincipal :-------------------------->: KrbPolicy : : and KrbPolicy : : (optional): ------------------ ------------- 1: : 1 : :------------: 1: : n :----------: :------------: : KrbLog : : KrbKey : : : : (optional) : :----------: :------------: 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=", 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 * 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 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 objectclass: KrbPolicy The following is an example with the policy attributes configured in a referenced entry: DN: krbRealmName=PAYROLL, ou=Austin objectclass: KrbRealm objectclass: KrbRealmExt krbPolicyObject: cn=MyPolicy, ou=Austin DN: cn=MyPolicy, ou=Austin objectclass: PasswordPolicy objectclass: KrbPolicy 3.3 Master Key (KrbMstrKey) Entries (Optional) The schema provides an optional way of configuring master key attributes in LDAP. To use this optional configuration, the krbMstrKeyCfg attributes needs to be configured in the realm entry with the value KRBMSTRKEY. The attributes defining each master key in the realm are included in the KrbMstrKey structural object class. If the realm is configured for KRBMSTRKEY, the master key attributes for each master key must be stored in a master key entry that resides directly below the realm entry. The RDN of this entry must include the string "krbKeyVersion=", where is the version of the master key. The RDN also can include additional strings if this is required to uniquely identify the master key entry (or example, "krbKeyVersion=1 krbKDCServiceName=serverA"). The following attributes are required: * either the master key value (krbKeyValue) or the URL address where the master key is stored (krbKeyRef) * the encryption type of the master key (krbEncType) * the key version configured in the required RDN (krbKeyVersion) The following is an example of a realm configured for KRBMSTRKEY. In this example, the realm contains one master key entry, which is shared by all the KDC services in the realm. The master key value is stored in a private file accessible by all the KDC services in the realm. DN: krbKeyVersion=1, krbRealmName=PAYROLL, ou=Austin objectclass: KrbMstrKey krbEncType: 1 krbKeyVersion: 1 krbKeyRef: FILE://private/mstrkey 3.4 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 "@", where is the name of the principal and is the name of the realm. The Kerberos principal identity must be unique within the realm. The following figure 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 objectclass: KrbPrincipal krbPrincipalName: alice@PAYROLL 3.5 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 several 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 objectclass: KrbPrincipal krbPrincipalName: alice@PAYROLL 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 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 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 objectclass: KrbAlias krbAliasedObjectName: cn=Bob Jones, ou=Raleigh DN: cn=Bob Jones, ou=Raleigh objectclass: Person cn: Bob Jones 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.7 Principal Key (KrbKey) Entries (Optional) The attributes defining each secret key associated with a principal are included in the KrbKey structural object class. If a principal uses the default method of storing secret keys, the attributes defining each secret key associated with the principal must be stored in a KrbKey entry that resides directly under the principal entry. The RDN of this entry must include the string "krbKeyVersion=", where is the version of the key. The RDN also can include additional strings if this is required to uniquely identity the KrbKey entry (for example, "krbkeyVersion=1, krbEncType=1, krbSaltType=0). The following attributes are required: * the version of the key included in the required RDN (krbKeyVersion) * the key value (krbKeyValue), which must be encrypted with a master key * the encryption type of the key (krbEncType) * the version of the master key used to encrypted the key value (krbMstrKeyVersion) The creator of a KrbKey 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 be consistent with 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. As an alternative to the default method of storing secret keys, a principal can be configured to use a USERPASSWORD or PROPRIETARY method of storing secret keys. This is configured by adding the krbSecretKeyCfg attribute to the principal entry and configuring this attribute with a value of USERPASSWORD or PROPRIETARY. If a principal is configured for USERPASSWORD, the secret key of the principal is the password of the principal and this password is stored in the the userPassword attribute of the principal entry. If the principal is configured for PROPRIETARY, the secret key or keys of the principal is stored in a proprietary database not defined in the KDC LDAP schema. The following is an example of a configuration that uses the default method of storing secret keys. In this example, four KrbKey entries are configured for a single principal, each having a different set of encryption and salt types: DN: krbEncType=1 krbSaltType=0, cn=Alice Smith, cn=users, ou=Austin objectclass: KrbKey krbEncType: 1 krbKeyVersion: 1 krbMstrKeyVersion: 1 krbKeyValue: krbSaltType: 0 krbSaltValue: DN: krbEncType=1 krbSaltType=1, cn=Alice Smith, cn=users, ou=Austin objectclass: KrbKey krbEncType: 1 krbKeyVersion: 1 krbMstrKeyVersion: 1 krbKeyValue: krbSaltType: 1 krbSaltValue: DN: krbEncType=5 krbSaltType=0, cn=Alice Smith, cn=users, ou=Austin objectclass: KrbKey krbEncType: 5 krbKeyVersion: 1 krbMstrKeyVersion: 1 krbKeyValue: krbSaltType: 0 krbSaltValue: DN: krbEncType=5 krbSaltType=1, cn=Alice Smith, cn=users, ou=Austin objectclass: KrbKey krbEncType: 5 krbKeyVersion: 1 krbMstrKeyVersion: 1 krbKeyValue: krbSaltType: 1 krbSaltValue: 3.8 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 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.12 (DN) 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 dnMatch ) ( krbAdmKeyLocation-oid NAME 'krbAdmKeyLocation' SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 (DN) 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 dnMatch ) ( 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) 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.12 (IA5String) DESC 'A set of values indicating the current key version for each key type of a KrbKey entry generated for a Kerberos principal. Each value must one of the following formats: vvyyeess vvyyee where "vvyy" is four numeric characters indicating the current version of the key, "ee" is two numeric characters indicating the encryption type that was used to generate the key, and "ss" is two numeric characters indicating the salt type that was used to generate the key. ("ss" is omitted if the key was generated without a salt. See krbEncType for a list of supported encryption type values and krbSaltType for a list of supported salt type values.) For example, '"000201" indicates that 2 is the current version of a key that generated for a principal using DES encryption and no salt. As another example, "00010500" indicates that 1 is the current version of a key that was generated for a principal using triple DES encryption and a normal salt type value.' ) ( krbEncType-oid NAME 'krbEncType' SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 (integer) SINGLE-VALUE DESC 'A value defining the encryption type of a secret key. Possible values are: ENCTYPE_NULL 0x0000 ENCTYPE_DES_CBC_CRC 0x0001 (DES cbc mode with CRC-32) ENCTYPE_DES_CBC_MD4 0x0002 (DES cbc mode with RSA-MD4) ENCTYPE_DES_CBC_MD5 0x0003 (DES cbc mode with RSA-MD5) ENCTYPE_DES_CBC_RAW 0x0004 (DES cbc mode raw) ENCTYPE_DES3_CBC_SHA 0x0005 (DES-3 cbc mode with NIST-SHA) ENCTYPE_DES3_CBC_RAW 0x0006 (DES-3 cbc mode raw) ENCTYPE_RSA_PRIVKEY 0x00010000 (RSA private key; required for support of DCE) ENCTYPE_UNKNOWN 0x00020000' ) ( 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 krbEncType for encryption type values.' ) ( krbExtraData-oid NAME 'krbExtraData' SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 (IA5String) 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 ) ( krbKdcServiceName-oid NAME 'krbKdcServiceName' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 (directory string) SINGLE-VALUE DESC 'Name of a KDC service.' EQUALITY caseExactMatch ) ( 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 ) ( krbKeyExpires-oid NAME 'krbKeyExpires' SYNTAX 1.2.840.113556.1.4.906 (interval) SINGLE-VALUE DESC 'A value indicating the date and time when a key expires. ) ( krbKeyName-oid 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 ) ( krbKeyRef-oid NAME 'krbKeyRef' SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 (DN) SINGLE-VALUE DESC 'Location (specified in URL format) of a master key.' EQUALITY dnMatch ) ( krbKeyType-oid NAME 'krbKeyType' SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 (IA5String) DESC 'A set of Kerberos key types. Each key type is specified in one of the following formats: ee eess where "ee" is two numeric characters indicating the encryption type of the key, and "ss" is two numeric characters indicating the salt type of the key. ("ss" is omitted if the key type specifies a key generated without a salt. See krbEncType for a list of supported encryption type values and krbSaltType for a list of supported salt type values.) For example, '"01" 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.' ) ( krbKeyValue-oid NAME 'krbKeyValue' SYNTAX 1.3.6.1.4.1.1466.115.121.1.5 (binary) SINGLE-VALUE DESC 'Value of a secret key.' EQUALITY caseExactMatch ) ( krbKeyVersion-oid 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.' ) ( 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. ' ) ( krbMstrKeyCfg-oid NAME 'krbMstrKeyCfg' SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 (integer) SINGLE-VALUE DESC 'One of the following values indicating where master key attributes are stored: 1 = KRBMSTRKEY--master key attributes are stored in master key entries as defined in the KDC LDAP schema) 2 = PROPRIETARY (default)--master key attributes are stored in a proprietary database' ) ( krbMstrKeyVersion-oid NAME 'krbMstrKeyVersion' SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 (integer) SINGLE-VALUE DESC 'Version of a master key that was used to encrypt the secret key of a principal.' ) ( 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.' ) ( krbNextKeyVersion-oid NAME 'krbNextKeyVersion' SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 (integer) SINGLE-VALUE DESC 'Next version of a secret key.' ) ( 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 @.' 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.' 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, which indicates 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) ' ) ( krbSaltType-oid NAME 'krbSaltType' SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 (integer) SINGLE-VALUE DESC 'A value indicating the type of an associated salt value. This indicates how the salt value is determined. The available salt types 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' ) ( krbSaltTypeSupport-oid NAME 'krbSaltTypeSupport' SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 (integer) DESC 'Set of values defining the supported salt types.' ) ( krbSaltValue-oid NAME 'krbSaltValue' SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 (IA5String) SINGLE-VALUE DESC 'Value of a salt. A salt is used as a seed or offset to the algorithm used to generate a key from a password.Æ EQUALITY caseExactMatch ) ( krbSecretKeyCfg-oid 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 residing below the principal entry. 2 = USERPASSWORD -- The secret key is stored in the userPassword attribute of the entry representing the principal entry. 3 = PROPRIETARY -- The secret key is stored in a proprietary database. ) ( 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 trusted administration tools. ' EQUALITY dnMatch ) 5.2 Attribute Types Defined in the Netscape 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.' ) ( 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.' ) ( 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.' ) ( 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 'Value used to compute date and time when account will expire.' ) ( 1.2.840.113556.1.4.49 NAME 'badPasswordTime' SYNTAX 1.2.840.113556.1.4.906 (interval) SINGLE-VALUE DESC 'Value used to compute date and time of last unsuccessful logon attempt.' ) ( 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 'Number of unsuccessful attempts to authenticate with this account.' ) ( 1.2.840.113556.1.4.52 NAME 'lastLogon' SYNTAX 1.2.840.113556.1.4.906 (interval) SINGLE-VALUE DESC 'A value used to compute date and time of last successful logon' ) ( 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 'Number of previous versions of passwords that are stored' ) ( 1.2.840.113556.1.4.96 NAME 'pwdLastSet' SYNTAX 1.2.840.113556.1.4.906 (interval) SINGLE-VALUE DESC 'A value defining the date and time when the password was last set.' ) ( 1.2.840.113556.1.4.74 NAME 'maxPwdAge' SYNTAX 1.2.840.113556.1.4.906 (interval) SINGLE-VALUE DESC 'A value defining the maximum age of a password.' ) ( 1.2.840.113556.1.4.75 NAME 'maxRenewAge' SYNTAX 1.2.840.113556.1.4.906 (interval) SINGLE-VALUE DESC 'Value defining the maximum renewable lifetime of a ticket.' ) ( 1.2.840.113556.1.4.77 NAME 'maxTicketAge' SYNTAX 1.2.840.113556.1.4.906 (interval) SINGLE-VALUE DESC 'Value defining the maximum lifetime of a user ticket.' ) ( 1.2.840.113556.1.4.78 NAME 'minPwdAge' SYNTAX 1.2.840.113556.1.4.906 (interval) SINGLE-VALUE DESC 'Value used to compute minimum lifetime of a password.' ) ( 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 'Value defining the minimum length of 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. The following flags, which are defined in the Microsoft lmaccess.h file, are used in the 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.6.1.4.1.4228.1.12 NAME 'secAcctExpires' DESC ' ' SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 (generalizedTime) SINGLE-VALUE ) ( 1.3.6.1.4.1.4228.1.4 NAME 'secAcctValid' DESC ' ' SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 (boolean) SINGLE-VALUE ) 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) ) ( KrbKey-oid NAME 'KrbKey' DESC 'A structural object class for use in configuring an entry to represent a Kerberos key for an associated Kerberos principal. The entry representing the Kerberos key must reside directly below the entry representing the associated Kerberos principal and must have a creator identity that is either a KDC service in the realm, a Kerberos password administration service that is trusted in the realm, or an LDAP administrator or administration tool that is trusted in the realm. (The DN recorded by LDAP in the creatorsName attribute of the entry representing the Kerberos key must be listed in the krbKdcServiceObject, krbPwdServiceObject, or krbTrustedAdmObject attribute of the entry representing the realm.) The relationship between the entry representing the Kerberos key and the entry representing the associated Kerberos principal is many-to-one. This is because multiple Kerberos keys can be created for a single principal with each key having a different version number, encryption type, salt type, or KDC service identity. The RDN of the entry representing the Kerberos key must contain a string that indicates the contents of the krbKeyVersion attribute for that entry (for example, "krbKeyVersion=1"). If the contents of additional attributes are required to uniquely identity the entry, the RDN also must include this information (for example, "krbKeyVersion=1 krbEncType=DES krbSaltType=NORMAL").' SUP top Structural MUST ( krbKeyVersion $ krbEncType $ krbMstrKeyVersion ) MAY ( krbKdcServiceName $ krbKeyExpires $ krbKeyValue $ krbNextKeyVersion $ krbSaltType $ krbSaltValue ) ) ( 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-one. The RDN of the entry representing the Kerberos login activity must be "cn=KrbLog". SUP top Structural MUST ( cn ) MAY ( badPasswordTime $ badPwdCount $ lastLogon) ) ( KrbMstrKey-oid NAME 'KrbMstrKey' DESC 'A structural object class for use in configuring an entry to represent a Kerberos master key. The entry representing the Kerberos master key must reside directly below the entry representing the Kerberos realm. The relationship between the entry representing the Kerberos master key and the entry representing the associated Kerberos realm is many-to-one. This is because multiple Kerberos master keys can be created for a single realm with each key having a different version number or KDC service identity. The RDN of the entry representing the Kerberos master key must contain a string that indicates the contents of the krbKeyVersion attribute for that entry (for example, "krbKeyVersion=1"). If the contents of additional attributes are required to uniquely identity the entry, the RDN also must include this information (for example, "krbKeyVersion=1 krbKdcServiceName=serverA").' SUP KrbKey Structural MAY ( krbKeyName $ krbKeyRef ) ) ( 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 $ 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 $ krbSecretKeyCfg $ 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 $ krbMstrKeyCfg $ 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 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 are standardized, clients and servers written according to this specification which make use of update functionality are UNLIKELY TO INTER-OPERATE, or MAY INTER-OPERATE ONLY IF AUTHENTICATION IS REDUCED TO AN UNACCEPTABLY WEAK LEVEL. 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 needs to be considered when using the KDC LDAP schema: * Any identity that configures KDC attributes in LDAP is responsible for the ensuring that the attributes are transmitted securely to and from LDAP. If attributes must be 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 DES. * Any identity that adds a sub-tree entry to the krbPrincSubTree attribute of the realm entry is responsible for ensuring that this sub-tree provides a way of protecting KDC attributes so that only trusted identities can add, modify, or delete KDC attributes in an entry residing under the sub-tree. * Any identity that adds a reference to an entry with policy information is responsible for ensuring that this entry protects KDC policy attributes so that only trusted identities can add, modify, or delete these attributes. * The identity that creates the realm entry is responsible for protecting this entry so that only trusted identities can modify, delete, or add attributes in the entry; only trusted identities can rename or delete the entry; and only trusted identities can insert new entries under the entry. (The master key is inserted under the realm entry, so any identity that has permission to insert entries under the realm entry has permission to create a master key entry.) * The identity that creates the master key entry is responsible for: - 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 can read attributes in the entry. - encrypting the master key stored in krbKeyValue if this attribute is used to store the master key. * The identity that creates a KrbKey entry is responsible for: - protecting this 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. - storing the value in krbKeyValue as a key encrypted with a master key, as described previously in this document. * The identity that creates the KrbLog entry is responsible for protecting this entry so that only a KDC service in the realm can modify, delete, and insert attributes in this entry; and only a KDC service or a trusted identity in the realm can delete or rename this entry. * The KDC is responsible for the following: - ensuring that all KDC attributes are transmitted securely to and from LDAP. If attributes must be 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 DES. - ensuring that the KrbKey entry was created by an identity that is trusted in the realm before getting the attributes from this entry. - ensuring that the KrbLog entry was created by a KDC service in the realm before getting the attributes from this entry. * The LDAP administrator is responsible for the following: - If any principal entries in the realm are configured to store secret keys in the userPassword attribute, ensuring that LDAP 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 Kerberos. If the value in userPassword is hashed, this must be supported by the Kerberos client interfaces as well as the KDC. - Ensuring that the LDAP server and the LDAP backing database provides a way of auditing all additions, deletions, and modifications of attributes. - If the LDAP backing database is separate from the LDAP server, ensuring that all data transmitted over the network between the LDAP server and the backing database is transmitted using a security protocol with client and server authentication, and data integrity, and that all attributes stored in the LDAP backing database are protected. 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 May 10, 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. [12] 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. 11. Author's Address Donna Skibbie IBM Corporation 1140 Burnet Road Austin, TX 78758 Phone: (512) 838-3896 Email: donnas@us.ibm.com