One document matched: draft-ietf-krb-wg-kdc-model-05.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-05" ipr="trust200902">
  <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 month="July" year="2009" />

    <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="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>
    </section>

    <section title="Introduction">
      <t>The Kerberos version 5 authentication service described in <xref
      target="RFC4120"></xref> describes how a Key Distribution Service (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 administrate 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 so that neither
      an object oriented model or 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
      (eg principalName). If so an implementation MUST provide a name to name
      mapping to this document.</t>
    </section>

    <section title="How to interpret RFC2119 terms">
      <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 - eg an LDAP or SQL schema. The precise interpretation
      of terms from <xref target="RFC2119"></xref> therefore require some
      extra explanation. 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 - eg 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>

      <t>Note that any implementation of this model SHOULD be published as an
      RFC.</t>
    </section>

    <section title="Acknowledgments">
      <t>Love Hörnquist-Åstrand <lha@it.su.se> for important
      contributions.</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 MUST always use a
      normative reference to the relevant RFCs detailing the change in KDC
      function.</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 type of the
            principalName is not described in this document. It is a unique
            identifier and can be viewed as an opaque byte string which can be
            compared for equality.</t>

            <t>The attribute MAY be multivalued if the implmementation
            supports aliases. In that case one of the principalName values
            MUST be designated the canonical principalName and if the
            implementation supports enctypes which require salt then one of
            the values of principalName MUST be designated as the canonical
            salting principalName.</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 (temporarily) 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 (eg 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 ticket 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>Implementations 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 (e.g an LDAP
          schema) MUST be able to handle the general case of multiple KeySet
          associated with each principal.</t>
        </section>

        <section title="Principal: Remarks">
          <t>Traditionally a principal consists of a local-part and a realm
          denoted in string form by local-part@REALM. The realm concept is
          used to provide administrative boundaries and together with
          cross-realm authentication provides scalability to Kerberos 5.
          However the realm is not central to an administrative information
          model. For instance the initialization or creation of a realm is
          equivalent to creating a specific set of principals (krbtgt@REALM,
          etc) which is covered by the model and services described in this
          document. A realm is typically associated with policy covering (for
          instance) keying and password management. The management of such
          policy and their association to realms is beyond the scope of this
          document.</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 an
        implementation. It is expected that most implementations of this
        standard 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 completenes.</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 reason for separating the KeySet from the Principal is
          security. The security of Kerberos 5 depends absolutely on the
          security of the keys stored in the KDC. The KeySet type is provided
          to make this clear and to make separation of keys from other parts
          of the model clear.</t>

          <t>Implementations of this standard (eg an LDAP schema) MUST make a
          clear separation between the representation of KeySet from other
          information objects.</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.</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="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="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="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 applicability of the policy. Implementations SHOULD
            provide this attribute and MUST (if the attribute is implemented)
            describe the enumerated set of possible values.</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.</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>.</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>.</t>
          </section>

          <section title="Keying Policy">
            <t>A keying policy specifies the association of enctypes with new
            principals, i.e when a principal is created one of the possibly
            many applicable keying policies determine the set of keys to
            associate with the principal. In general the expression of a
            keying policy may require a Turing-complete language. This policy
            SHOULD be identified by the OID <TBD>.</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 backending 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 in theory
        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
      (at the time of writing - leifj) 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 is 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. etc.</t>
    </section>

    <section title="IANA Considerations">
      <t>This document requires the allocation of several OIDs.</t>
    </section>
  </middle>

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

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

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