From: Howard Chu Date: Tue, 27 Oct 2009 01:13:30 +0000 (+0000) Subject: Rev 00 X-Git-Tag: ACLCHECK_0~163 X-Git-Url: https://git.sur5r.net/?a=commitdiff_plain;h=ad8cc79fecb280798cb5756ab9369b2846e63eb9;p=openldap Rev 00 --- diff --git a/doc/drafts/draft-chu-ldap-kdc-schema-xx.xml b/doc/drafts/draft-chu-ldap-kdc-schema-xx.xml new file mode 100644 index 0000000000..718825ec57 --- /dev/null +++ b/doc/drafts/draft-chu-ldap-kdc-schema-xx.xml @@ -0,0 +1,584 @@ + + + + + + + + + + + + + + + + +]> + + + + + + An LDAP Schema for Kerberos KDC Information + + + Symas Corp. +
+ + 18740 Oxnard Street, Suite 313A + Tarzana + California + 91356 + US + + +1 818 757-7087 + hyc@symas.com + http://www.symas.com +
+ + + + This document describes an LDAP schema for implementing the + Kerberos 5 + KDC Information Model. + It also defines additional elements which are not covered by the Information Model, + but are already in common use. + + + + + +
+ Both Kerberos and LDAP are frequently used separately for + distributed authentication. They can also be used in combination, + but typically their user databases remained separate. This distinction + in databases causes unnecessary duplication of data and administration + overhead. As such it is desirable for both systems to share a single + database. Since the LDAP data model is more general it is most + appropriate to store the Kerberos data in LDAP. + A number of Kerberos implementations already have support for + using LDAP as their KDC backing store. However, each implementation + uses its own schema, and the multiple schemas are mutually + incompatible. For the sake of interoperability and administrative + ease, it is important to define a single standard schema that can + be used uniformly by all Kerberos KDC implementations and interoperates + with existing LDAP specifications. +
+
+
+ The key words "MUST", "SHOULD", and "MAY" used in this document + are to be interpreted as described in + . + The OIDs defined below are derived from + + TBD.OID: + KRBSYN = TBD.OID.0 + KRBATTR = TBD.OID.1 + KRBOC = TBD.OID.2 + +
+
+ The attributes and classes defined in this document are summarized + below. +
+ The following attributes are defined in this document: + + + krbPrincipalName + krbPrincipalAliases + krbTicketMaxLife + krbTicketMaxRenewal + krbEncSaltTypes + krbRealmName + krbPrincipalRealm + krbKeySet + krbKeyVersion + krbTicketPolicy + krbExtraData + krbPrincNamingAttr + krbPrincContainer + krbPwdPolicy + krbLDAPURI + + + Additionally, some of the attributes defined in + LDAP Password Policy + are required. + + Note: The MIT/Novell schema includes a number of elements for storing the KDC configuration + in LDAP. The Information Model doesn't cover these aspects, so I've omitted them for now. + Do we need to add them? +
+
+ The following object classes are defined in this document: + + + krbKDCInfo + krbPrincipal + krbRealm + + + +
+
+
+
+ This section contains attribute definitions to be implemented + by KDCs supporting this schema: +
+ + ( KRBATTR.1 + NAME 'krbPrincipalName' + DESC 'Canonical principal name' + EQUALITY caseExactIA5Match + SUBSTR caseExactSubstringsMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 + SINGLE-VALUE ) + +
+
+ + ( KRBATTR.2 + NAME 'krbPrincipalAliases' + SUP krbPrincipalName ) + +
+ These attributes implement section 6.1.1.1 of the Information Model. The + krbPrincipalName attribute contains the canonical name of the principal. + Any aliases are stored in the krbPrincipalAliases attribute. Since the + krbPrincipalAliases attribute is a subtype of the krbPrincipalName + attribute, a search on krbPrincipalName will also search the aliases. + + +
+ + ( KRBATTR.3 + NAME 'krbTicketMaxLife' + EQUALITY integerMatch + ORDERING integerOrderingMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 + SINGLE-VALUE ) + +
+ This attribute implements section 6.1.1.11 of the Information Model. + It holds the maximum ticket lifetime in seconds for a principal. + + +
+ + ( KRBATTR.4 + NAME 'krbTicketMaxRenewal' + EQUALITY integerMatch + ORDERING integerOrderingMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 + SINGLE-VALUE ) + +
+ This attribute implements section 6.1.1.12 of the Information Model. + It holds the maximum time in seconds a ticket may be renewed for. + + +
+ + ( KRBATTR.5 + NAME 'krbEncSaltTypes' + EQUALITY caseIgnoreMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) + +
+ This attribute implements section 6.1.1.13 of the Information Model. + Holds the allowed encryption/salt type combinations for this principal. + If empty or absent any combination supported by the implementation is allowed. + + Note that sections 6.1.1.2 thru 6.1.1.10 are implemented using the + LDAP Password Policy schema. + + +
+ + ( KRBATTR.6 + NAME 'krbRealmName' + EQUALITY octetStringMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 ) + +
+
+ + ( KRBATTR.7 + NAME 'krbPrincipalRealm' + DESC 'DN of krbRealm entry' + SUP distinguishedName ) + +
+ These attributes provide information about the current realm. They provide + the minimal set of information required to implement section 6.1.3 of the + Information Model. + + +
+ + ( KRBATTR.8 + NAME 'krbKeyVersion' + EQUALITY integerMatch + ORDERING integerOrderingMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 + SINGLE-VALUE ) + +
+ This attribute implements section 6.2.1.1 of the Information Model. + It stores the version number of the current key. + + +
+ + ( KRBATTR.9 + NAME 'krbKeySet' + EQUALITY octetStringMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 ) + +
+ This attribute implements sections 6.3.1.1 thru 6.3.1.4 of the Information Model. + Sections 6.3.1.5 thru 6.3.1.7 are implemented using the LDAP Password Policy schema. + This attribute holds the principal's keys optionally encrypted with the + Master Key. The attribute is encoded using ASN.1 + DER. +
+##### The format of the value for this attribute is explained below, +##### KrbKeySet ::= SEQUENCE { +##### kvno [0] UInt32, +##### mkvno [1] UInt32 OPTIONAL, +##### keys [2] SEQUENCE OF KrbKey, +##### ... +##### } +##### +##### KrbKey ::= SEQUENCE { +##### salt [0] KrbSalt OPTIONAL, +##### key [1] EncryptionKey, +##### s2kparams [2] OCTET STRING OPTIONAL, +##### ... +##### } +##### +##### KrbSalt ::= SEQUENCE { +##### type [0] Int32, +##### salt [1] OCTET STRING OPTIONAL +##### } +##### +##### EncryptionKey ::= SEQUENCE { +##### keytype [0] Int32, +##### keyvalue [1] OCTET STRING +##### } +
+ +
+ + ( KRBATTR.10 + NAME 'krbTicketPolicy' + EQUALITY integerMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 + SINGLE-VALUE ) + +
+ This attribute is related to section 6.4 of the Information Model. It + defines the flags that a user is allowed or required to use in a ticket + request. +
+#krb5KDCFlagsSyntax SYNTAX ::= { +# WITH SYNTAX INTEGER +#-- initial(0), -- require as-req +#-- forwardable(1), -- may issue forwardable +#-- proxiable(2), -- may issue proxiable +#-- renewable(3), -- may issue renewable +#-- postdate(4), -- may issue postdatable +#-- server(5), -- may be server +#-- client(6), -- may be client +#-- invalid(7), -- entry is invalid +#-- require-preauth(8), -- must use preauth +#-- change-pw(9), -- change password service +#-- require-hwauth(10), -- must use hwauth +#-- ok-as-delegate(11), -- as in TicketFlags +#-- user-to-user(12), -- may use user-to-user auth +#-- immutable(13) -- may not be deleted +# ID { 1.3.6.1.4.1.5322.10.0.1 } +#} +
+ + +
+ + ( KRBATTR.11 + NAME 'krbExtraData' + EQUALITY octetStringMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 ) +
+ This attribute holds arbitrary data that may be needed by a particular + implementation. The values are encoded in ASN.1 DER. +
+##### The format of the values for this attribute is explained below, +##### ExtraData ::= SEQUENCE { +##### tag [0] OCTET STRING, +##### data [1] OCTET STRING +##### } +
+ + + The following four attributes are outside the scope of the Information Model + but may be useful in some deployments. +
+ + ( KRBATTR.12 + NAME 'krbPrincNamingAttr' + EQUALITY objectIdentifierMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 + SINGLE-VALUE ) +
+ This attribute records what attribute will be used to name + newly created principal entries. +
+ + ( KRBATTR.13 + NAME 'krbPrincContainer' + DESC 'DN of container entry for principals' + SUP distinguishedName + SINGLE-VALUE ) +
+ This attribute points to the container entry under which + new principal entries will be created. +
+ + ( KRBATTR.14 + NAME 'krbPwdPolicy' + DESC 'DN of password policy subentry' + SUP distinguishedName + SINGLE-VALUE ) +
+ This attribute points to the LDAP password policy subentry + containing the policy that should be applied to Kerberos principals. + + Note that in LDAP servers with full subentry support, the subentry's + subtree search specification defines what entries the subentry applies + to, so this attribute is unnecessary; it is provided merely for + informational purposes. +
+ + ( KRBATTR.15 + NAME 'krbLDAPURI' + DESC 'LDAP search parameters for locating principals' + SUP labeledURI ) +
+ This attribute contains LDAP URIs that the KDC will search when + locating principals. The URI values must conform to the syntax + defined in . As a special case, the URI + prefix "ldap:///" is taken to mean the current LDAP server. + +
+
+ This section contains class definitions to be implemented by KDCs + supporting the schema. + +
+ + ( KRBOC.1 NAME 'krbKDCInfo' SUP top AUXILIARY + MAY ( krbTicketMaxLife $ krbTicketMaxRenewal $ + krbEncSaltTypes $ krbTicketPolicy $ + krbKeySet $ krbKeyVersion ) ) + +
+
+ + ( KRBOC.2 NAME 'krbPrincipal' SUP krbKDCInfo AUXILIARY + MUST ( krbPrincipalName ) + MAY ( krbPrincipalAliases $ krbPrincipalRealm $ + krbExtraData ) ) + +
+ + +
+ + ( KRBOC.3 NAME 'krbRealm' SUP krbKDCInfo AUXILIARY + MUST ( krbRealmName ) + MAY ( krbPrincNamingAttr $ krbPrincContainer $ + krbPwdPolicy $ krbLDAPURI ) ) + +
+ Note that in a krbRealm object the krbKeySet and krbKeyVersion + attributes actually reflect the Master key for the realm. In this + case the krbKeySet's mkvno field and all other optional fields + are omitted. + +
+
+ Since the LDAP Password Policy is intimately involved in the + security mechanisms of this proposal, the directory should be treated + as more than just a passive data store. (The KDC can certainly read + the policy attributes and evaluate them itself, but that would mean + needlessly duplicating all of the functionality that is already + implemented in the directory server.) This means that for every + Kerberos authentication being serviced, a corresponding LDAP + operation must also be performed, in order to allow the password + policy mechanisms to operate. + The mechanism outlined here assumes that the plain LDAP credentials + and the Kerberos credentials are unified (or at least synchronized). In + that case, for every incoming Kerberos authentication request, the KDC + can issue an LDAP Compare request using the known credentials of + the user and the LDAP Password Policy control. The result of the request + will carry any relevant error codes if the account is disabled, the + password is expired, or various other failures. If preauthentication is + in use and the request is invalid, a Compare with known invalid + credentials may be used to update the password policy state. +
+ A number of data elements described in the Information Model are + delegated to the LDAP DSA for management. Details of their + usage are described here. +
+ Section 6.1.1.2 of the Information Model. This corresponds to the + pwdStartTime attribute. If the KDC is using LDAP requests to operate the + Password Policy mechanism then it does not need to reference or manipulate + this attribute directly. +
+
+ Section 6.1.1.3 of the Information Model. This corresponds to the + pwdEndTime attribute. If the KDC is using LDAP requests to operate the + Password Policy mechanism then it does not need to reference or manipulate + this attribute directly. +
+
+ Section 6.1.1.4 of the Information Model. + If the KDC is using LDAP requests to operate the + Password Policy mechanism then it does not need to reference or manipulate + this attribute directly. Otherwise, this effect is controlled by setting + the pwdStartTime attribute to a value greater than or equal to the + pwdEndTime attribute. +
+
+ Section 6.1.1.5 of the Information Model. + If the KDC is using LDAP requests to operate the + Password Policy mechanism then it does not need to reference or manipulate + this attribute directly. Otherwise, this value is obtained by counting the + number of values stored in the pwdFailureTime attribute. +
+
+ Section 6.1.1.6 of the Information Model. + If the KDC is using LDAP requests to operate the + Password Policy mechanism then it does not need to reference or manipulate + this attribute directly. Otherwise, this value is obtained by retrieving the + values stored in the pwdFailureTime attribute and selecting the most recent value. +
+
+ Section 6.1.1.7 of the Information Model. This corresponds to the + pwdLastSuccess attribute. + If the KDC is using LDAP requests to operate the + Password Policy mechanism then it does not need to reference or manipulate + this attribute directly. +
+
+ Section 6.1.1.8 of the Information Model. This corresponds to the + pwdChangedTime attribute. + If the KDC uses the LDAP Password Modify request + then it does not need to reference or manipulate + this attribute directly. +
+
+ Section 6.1.1.9 of the Information Model. This corresponds to the + createTimestamp attribute. + The KDC does not need to reference or manipulate this attribute directly. +
+
+ Section 6.1.1.10 of the Information Model. This corresponds to the + modifyTimestamp attribute. + The KDC does not need to reference or manipulate this attribute directly. +
+
+
+ The krbKeySet attribute is multi-valued but it is expected that + it will usually only contain one value. During a password change operation + the KDC may choose to keep one previous value present to allow currently + active clients to continue to operate using the previous key. How long to + retain this old password is unspecified here. Note also that the LDAP + Password Policy mechanism already has provisions for password history + management, so the krbKeySet attribute should not be used for + long-term password history tracking. +
+
+
+ This entire document is concerned with an implementation of a secure + distributed authentication mechanism. It should be understood that + the various keys used here are all sensitive pieces of data and must + be adequately protected using access controls and other mechanisms. + Likewise all communications between the KDC and DSA must be protected + whenever sensitive data is being referenced. + In common practice the KDC and DSA have been colocated on a + single host and communicated over a local + LDAP IPC session. As such it was + implied that the host security was equivalent for both. If a KDC is + configured to use a remote DSA, the remote host should be + configured with at least the same level of security as the KDC host, + and a secure channel MUST be used for the LDAP session. + Storing the Master Key in the DSA makes it even more + crucial that the LDAP host, service, and data files be adequately + protected. Backups of the LDAP database should also be encrypted to + protect the integrity of any keys contained therein. +
+
+ In accordance with the following registrations + are requested. +
+ [[List of OIDs, registration template goes here...]] +
+
+ [[List of Attribute and ObjectClass descriptors, template goes here...]] +
+
+
+ Thanks to Simo Sorce from Red Hat Inc. and Love Hörnquist Åstrand + from Apple Corp. for their feedback on this document. +
+ + + + &rfc2119; + &rfc3062; + &rfc4120; + &rfc4511; + &rfc4516; + &rfc4520; + &ppolicy; + &kdcmodel; + + + Abstract Syntax Notation One (ASN.1): Specification of basic notation + + + International Telecommunications Union + + + + + + + + + Information Technology - ASN.1 encoding rules: Specification of Basic + Encoding Rules (BER), Canonical Encoding Rules (CER) and + Distinguished Encoding Rules (DER) + + + International Telecommunications Union + + + + + + + + &ldapi; + + +