One document matched: draft-ietf-krb-wg-kdc-model-10.xml

<?xml version="1.0" encoding="US-ASCII"?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<rfc category="std" docName="draft-ietf-krb-wg-kdc-model-10"
     ipr="pre5378Trust200902">
  <front>
    <title abbrev="KDC Information Model">An information model for Kerberos
    version 5</title>

    <author fullname="Leif Johansson" surname="Johansson">
      <organization abbrev="SUNET">Swedish University Network</organization>

      <address>
        <postal>
          <street>Thulegatan 11</street>

          <city>Stockholm</city>
        </postal>

        <email>leifj@sunet.se</email>

        <uri>http://www.sunet.se</uri>
      </address>
    </author>

    <date day="31" month="May" year="2011" />

    <workgroup>KERBEROS WORKING GROUP</workgroup>

    <abstract>
      <t>This document describes an information model for Kerberos version 5
      from the point of view of an administrative service. There is no
      standard for administrating a kerberos 5 KDC. This document describes
      the services exposed by an administrative interface to a KDC.</t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">
      <t>The Kerberos version 5 authentication service described in <xref
      target="RFC4120"></xref> describes how a Key Distribution Center (KDC)
      provides authentication to clients. The standard does not stipulate how
      a KDC is managed and several "kadmin" servers have evolved. This
      document describes the services required to administer a KDC and the
      underlying information model assumed by a kadmin-type service.</t>

      <t>The information model is written in terms of "attributes" and
      "services" or "interfaces" but the use of these particular words must
      not be taken to imply any particular modeling paradigm. Neither an
      object oriented model nor an LDAP schema is intended. The author has
      attempted to describe in natural language the intended semantics and
      syntax of the components of the model. An LDAP schema (for instance)
      based on this model will be more precise in the expression of the syntax
      while preserving the semantics of this model.</t>

      <t>Implementations of this document MAY decide to change the names used
      (e.g. principalName). If so an implementation MUST provide a name to
      name mapping to this document.</t>
    </section>

    <section title="Requirements notation">
      <t>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 <xref
      target="RFC2119"></xref>.</t>

      <t>This document describes an information model for kerberos 5 but does
      not directly describe any mapping onto a particular schema- or modelling
      language. Hence an implementation of this model consists of a mapping to
      such a language - e.g. an LDAP or SQL schema. The precise interpretation
      of terms from <xref target="RFC2119"></xref> therefore require some
      extra explanation.</t>

      <t>The terms MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT mean that an
      implementation MUST provide a feature but does not mean that this
      feature MUST be REQUIRED by the implementation - e.g. an attribute is
      available in an LDAP schema but marked as OPTIONAL. If a feature must be
      implemented and REQUIRED this is made explicit in this model. The term
      MAY, OPTIONAL and RECOMMENDED means that an implementation MAY need to
      REQUIRE the feature due to the particular nature of the schema/modelling
      language. In some cases this is expressly forbidden by this model
      (feature X MUST NOT be REQUIRED by an implementation).</t>
    </section>

    <section title="Information model demarcation">
      <t>The information model specified in the next chapter describes
      objects, properties of those objects and relations between those
      objects. These elements comprise an abstract view of the data
      represented in a KDC. It is important to understand that the information
      model is not a schema. In particular the way objects are compared for
      equality beyond that which is implied by the specification of a syntax
      is not part of this specification. Nor is ordering specified between
      elements of a particular syntax.</t>

      <t>Further work on Kerberos will undoubtedly prompt updates to this
      information model to reflect changes in the functions performed by the
      KDC. Such extensions to the information model should always use a
      normative reference to the relevant RFCs detailing the change in KDC
      function.</t>

      <t>This model describes a number of elements related to password policy
      management. Not all of the elements in this model are unique to
      Kerberos; an LDAP implementation of this model should incorporate
      existing LDAP schema where functional overlap exists, rather than
      defining additional Kerberos-specific elements.</t>
    </section>

    <section title="Information model specification">
      <section title="Principal">
        <t>The fundamental entity stored in a KDC is the principal. The
        principal is associated to keys and generalizes the "user" concept.
        The principal MUST be implemented in full and MUST NOT be optional in
        an implementation</t>

        <section title="Principal: Attributes">
          <section title="principalName">
            <t>The principalName MUST uniquely identify the principal within
            the administrative context of the KDC. The principalName MUST be
            equivalent to the string representation of the principal name
            including, if applicable for the name type, the realm.</t>

            <t>The attribute MAY be multi-valued if the implementation
            supports aliases and/or enterprise names. In that case exactly one
            of the principalName values MAY be designated the canonical
            principalName and if the implementation supports enctypes which
            require salt then exactly one of the values of principalName MAY
            be designated as the canonical salting principalName.</t>

            <t>Implementations (i.e. schema) that support enterprise names
            and/or aliases SHOULD provide for efficient lookup of principal
            objects based on alias/enterprise name.</t>
          </section>

          <section title="principalNotUsedBefore">
            <t>The principal may not be used before this date. The syntax of
            the attribute MUST be semantically equivalent with the standard
            ISO date format. The attribute MUST be single-valued.</t>
          </section>

          <section title="principalNotUsedAfter">
            <t>The principal may not be used after this date. The syntax of
            the attribute MUST be semantically equivalent with the standard
            ISO date format. The attribute MUST be single-valued.</t>
          </section>

          <section title="principalIsDisabled">
            <t>A boolean attribute used to disable a principal. The attribute
            SHOULD default to false.</t>
          </section>

          <section title="principalNumberOfFailedAuthenticationAttempts">
            <t>This single-valued integer attribute contains a count of the
            number of times an authentication attempt was unsuccessful for
            this principal. Implementations SHOULD NOT allow this counter to
            be reset.</t>
          </section>

          <section title="principalLastFailedAuthentication">
            <t>This single-valued attribute contains the time and date for the
            last failed authentication attempt for this principal.</t>
          </section>

          <section title="principalLastSuccessfulAuthentication">
            <t>This single-valued attribute contains the time and date for the
            last successful authentication attempt for this principal.</t>
          </section>

          <section title="principalLastCredentialChangeTime">
            <t>This single-valued attribute contains the time and date for the
            last successful change of credential (e.g. password or private
            key) associated with this principal.</t>
          </section>

          <section title="principalCreateTime">
            <t>This single-valued attribute contains the time and date when
            this principal was created</t>
          </section>

          <section title="principalModifyTime">
            <t>This single-valued attribute contains the time and date when
            this principal was modified excluding credentials change.</t>
          </section>

          <section title="principalMaximumTicketLifetime">
            <t>This single-valued attribute contains the delta time in seconds
            representing the maximum lifetime for tickets issued for this
            principal.</t>
          </section>

          <section title="principalMaximumRenewableTicketLifetime">
            <t>This single-valued attribute contains the delta time in seconds
            representing the maximum amount of time a ticket may be renewed
            for.</t>
          </section>

          <section title="principalAllowedEnctype">
            <t>This OPTIONAL multi-valued attribute lists the enctypes allowed
            for this principal. If empty or absent any enctype supported by
            the implementation is allowed for this principal.</t>

            <t>This attribute is intended as a policy attribute and restricts
            all uses of enctypes including server, client, and session keys.
            Data models MAY choose to use policy objects in order to represent
            more complex decision mechanisms.</t>
          </section>
        </section>

        <section title="Principal: Associations">
          <t>Each principal MAY be associated with 0 or more KeySet and MAY be
          associated with 0 or more Policies. The KeySet is represented as an
          object in this model since it has attributes associated with it (the
          key version number). In typical situations the principal is
          associated with exactly 1 KeySet but implementations MUST NOT assume
          this case, i.e. an implementation of this standard MUST be able to
          handle the general case of multiple KeySet associated with each
          principal. Multiple KeySets may for instance be useful when
          performing a key rollover for a principal.</t>
        </section>
      </section>

      <section title="KeySet">
        <t>A KeySet is a set of keys associated with exactly one principal.
        This object and its associations MUST NOT be REQUIRED by a data-model.
        It is expected that most Kerberos implementations will use the
        set/change password protocol for all aspects of key management <xref
        target="I-D.ietf-krb-wg-kerberos-set-passwd"></xref>. This information
        model only includes these objects for the sake of completeness.</t>

        <t>If a server supports an enctype for a principal that enctype must
        be present in at least one key for the principal in question.</t>

        <section title="KeySet: Attributes">
          <section title="keySetVersionNumber">
            <t>This is traditionally called the key version number (kvno).
            This is a single-valued attribute containing a positive
            integer.</t>
          </section>
        </section>

        <section title="KeySet: Associations">
          <t>To each KeySet MUST be associated a set of 1 or more Keys.</t>
        </section>

        <section title="KeySet: Remarks">
          <t>The security of Kerberos 5 depends absolutely on the
          confidentiality and integrity of the keys stored in the KDC.
          Implementations of this standard MUST facilitate, to the extent
          possible, an administrator's ability to place more restrictive
          access controls on KeySets than on other principal data, and to
          arrange for more secure backup for KeySets.</t>
        </section>
      </section>

      <section title="Key">
        <t>Implementations of this model MUST NOT REQUIRE keys to be
        represented.</t>

        <section title="Key: Attributes">
          <section title="keyEncryptionType">
            <t>The enctype SHOULD be represented as an enumeration of the
            enctypes supported by the KDC using the string name ("encryption
            type") of the enctype from the IANA registry of Kerberos
            Encryption Type Numbers.</t>
          </section>

          <section title="keyValue">
            <t>The binary representation of the key data. This MUST be a
            single-valued octet string.</t>
          </section>

          <section title="keySaltValue">
            <t>The binary representation of the key salt. This MUST be a
            single-valued octet string.</t>
          </section>

          <section title="keyStringToKeyParameter">
            <t>This MUST be a single-valued octet string representing an
            opaque parameter associated with the enctype.</t>
          </section>

          <section title="keyNotUsedBefore">
            <t>This key MUST NOT be used before this date. The syntax of the
            attribute MUST be semantically equivalent with the standard ISO
            date format. This MUST be a single-valued attribute.</t>
          </section>

          <section title="keyNotUsedAfter">
            <t>This key MUST NOT be used after this date. The syntax of the
            attribute MUST be semantically equivalent with the standard ISO
            date format. This MUST be a single-valued attribute.</t>
          </section>

          <section title="keyIsDisabled">
            <t>This is a boolean attribute which SHOULD be set to false by
            default. If this attribute is true the key MUST NOT be used. This
            is used to temporarily disable a key.</t>
          </section>
        </section>

        <section title="Key: Associations">
          <t>None</t>
        </section>

        <section title="Key: Remarks">
          <t>The security of the keys is an absolute requirement for the
          operation of Kerberos 5. If keys are implemented adequate protection
          from unauthorized modification and disclosure MUST be available and
          REQUIRED by the implementation.</t>
        </section>
      </section>

      <section title="Policy">
        <t>Implementations SHOULD implement policy but MAY allow them to be
        OPTIONAL. The Policy should be thought of as a 'typed hole'. i.e. an
        opaque binary value paired with an identifier of type of data
        contained in the binary value. Both attributes (type and value) must
        be present.</t>

        <section title="Policy: Attributes">
          <section title="policyIdentifier">
            <t>The policyIdentifier MUST be unique within the local
            administrative context and MUST be globally unique. Possible types
            of identifiers include: <list>
                <t>An Object Identifier (OID)</t>

                <t>A URI</t>

                <t>A UUID</t>
              </list> The use of OIDs is RECOMMENDED for this purpose.</t>
          </section>

          <section title="policyIsCritical">
            <t>This boolean attribute indicates that the KDC MUST be able to
            correctly interpret and apply this policy for the key to be
            used.</t>
          </section>

          <section title="policyContent">
            <t>This is an optional single opaque binary value used to store a
            representation of the policy. In general a policy cannot be fully
            expressed using attribute-value pairs. The policyContent is
            OPTIONAL in the sense that an implementation MAY use it to store
            an opaque value for those policy-types which are not directly
            representable in that implementation.</t>
          </section>

          <section title="policyUse">
            <t>This is an optional single enumerated string value used to
            describe the use of the policy. Implementations SHOULD provide
            this attribute and MUST (if the attribute is implemented) describe
            the enumerated set of possible values. The intent is that this
            attribute be useful in providing an initial context-based
            filtering.</t>
          </section>
        </section>

        <section title="Mandatory-to-implement Policy">
          <t>All implementations MUST be able to represent the policies listed
          in this section. Implementations are not required to use the same
          underlying data-representation for the policyContent binary value
          but SHOULD use the same OIDs as the policyIdentifier. In general the
          expression of policy may require a Turing-complete language. This
          specification does not attempt to model policy expression
          language.</t>

          <section title="Password Quality Policy">
            <t>Password quality policy controls the requirements placed by the
            KDC on new passwords. This policy SHOULD be identified by the OID
            <TBD>.1.</t>
          </section>

          <section title="Password Management Policy">
            <t>Password management policy controls how passwords are changed.
            This policy SHOULD be identified by the OID <TBD>.2.</t>
          </section>

          <section title="Keying Policy">
            <t>A keying policy specifies the association of enctypes with new
            principals, e.g. when a principal is created one of the applicable
            keying policies is used to determine the set of keys to associate
            with the principal. This policy SHOULD be identified by the OID
            <TBD>.3.</t>
          </section>

          <section title="Ticket Flag Policy">
            <t>A ticket flag policy specifies the ticket flags allowed for
            tickets issued for a principal. This policy SHOULD be identified
            by the OID <TBD>.4.</t>
          </section>
        </section>
      </section>
    </section>

    <section title="Implementation Scenarios">
      <t>There are several ways to implement an administrative service for
      Kerberos 5 based on this information model. In this section we list a
      few of them.</t>

      <section title="LDAP backend to KDC">
        <t>Given an LDAP schema implementation of this information model it
        would be possible to build an administrative service by back-ending
        the KDC to a directory server where principals and keys are stored.
        Using the security mechanisms available on the directory server keys
        are protected from access by anyone apart from the KDC. Administration
        of the principals, policy, and other non-key data is done through the
        directory server while the keys are modified using the set/change
        password protocol <xref
        target="I-D.ietf-krb-wg-kerberos-set-passwd"></xref>.</t>
      </section>

      <section title="LDAP frontend to KDC">
        <t>An alternative way to provide a directory interface to the KDC is
        to implement an LDAP-frontend to the KDC which exposes all non-key
        objects as entries and attributes. As in the example above all keys
        are modified using the set/change password protocol <xref
        target="I-D.ietf-krb-wg-kerberos-set-passwd"></xref>. In this scenario
        the implementation would typically not use a traditional LDAP
        implementation but treat LDAP as an access protocol to data in the
        native KDC database.</t>
      </section>

      <section title="SOAP">
        <t>Given an XML schema implementation of this information model it
        would be possible to build a SOAP interface to the KDC. This
        demonstrates the value of creating an abstract information model which
        is mappable to multiple schema representations.</t>
      </section>

      <section title="Netconf">
        <t>Given a YAML implementation of this information model it would be
        possible to create a Netconf-based interface to the KDC, enabling
        management of the KDC from standard network management
        applications.</t>
      </section>
    </section>

    <section title="Security Considerations">
      <t>This document describes an abstract information model for Kerberos 5.
      The Kerberos 5 protocol depends on the security of the keys stored in
      the KDC. The model described here assumes that keys MUST NOT be
      transported in the clear over the network and furthermore that keys are
      treated as write-only attributes that SHALL only be modified (using the
      administrative interface) by the change-password protocol <xref
      target="I-D.ietf-krb-wg-kerberos-set-passwd"></xref>.</t>

      <t>Exposing the object model of a KDC typically implies that objects can
      be modified and/or deleted. In a KDC not all principals are created
      equal, so that for instance deleting krbtgt/EXAMPLE.COM@EXAMPLE.COM
      effectively disables the EXAMPLE.COM realm. Hence access control is
      paramount to the security of any implementation. This document does not
      mandate access control. This only implies that access control is beyond
      the scope of the standard information model, i.e. that access control
      may not be accessible via any protocol based on this model. If access
      control objects are exposed via an extension to this model the presence
      of access control may in itself provide points of attack by giving away
      information about principals with elevated rights etc.</t>
    </section>

    <section title="IANA Considerations">
      <t>This document requires the allocation of several OIDs marked
      <TBD> in section 4.4.2 above. IANA should allocate a new arc under
      1.3.6.1.5.2.5 (iso.org.dod.internet.security.kerberosV5.policies) named
      "kdcPolicy" and assign each of the policy OIDs a new number under this
      arc.</t>
    </section>

    <section title="Acknowledgments">
      <t>The author wishes to extend his thanks to Love
      Hörnquist-Åstrand <lha@kth.se> and Sam Hartman
      <hartmans@mit.edu> for their important contributions to this
      document.</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include='reference.RFC.2119.xml'?>

      <?rfc include='reference.RFC.4120.xml'?>

      <?rfc include='reference.RFC.3961.xml'?>
    </references>

    <references title="Informative References">
      <?rfc include='reference.I-D.ietf-krb-wg-kerberos-set-passwd'?>
    </references>
  </back>
</rfc>