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 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=", where 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=", where 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=", where is the version of the keys. If the keys in the entry are encrypted with a private master key, the RDN MUST be "krbKeyVersion=+ krbKdcServicName=" where 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 = ", where 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?