One document matched: draft-ietf-krb-wg-kdc-model-15.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-15"
     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="14" month="January" year="2013" />

    <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 <xref target="RFC4510"></xref> 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. In particular schema languages may have
      different conventions for caseing, eg camelCase vs use of '_' and '-' to
      separate 'words' in a name. Implementations MUST call out such
      conventions explicitly.</t>

      <t>Implementations of this document MUST be able to support default
      values for attributes as well as the ability to specify syntax for
      attribute values.</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 uses the standard normative key words ("MUST", "MUST
      NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT",
      "RECOMMENDED", "MAY", and "OPTIONAL") but does not reference <xref
      target="RFC2119"></xref>. The reason for this (which was discussed
      extensively in the kerberos WG) is as follows:</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 standard normative key
      word therefore require precise definition:</t>

      <t>The terms MUST or REQUIRED means that schema implementing this model
      must have a way to represent a feature (i.e that it is mandatory to
      implement in schema) but that unless otherwise specified the feature may
      represent an optional element in the chosen schema definition
      language.</t>

      <t>However MUST also means that a KDC or administrative interface
      implementing this information model MUST provide the feature and
      associated behavior consistent with schema.</t>

      <t>For instance, principalLastFailedAuthentication (cf below) represents
      the last time an authentication failed for a principal. In an LDAP
      schema (for instance) this may be represented as an optional attribute
      even though all KDCs implementing this specification must support this
      attribute.</t>

      <t>The terms MAY or OPTIONAL means that the feature is optional to
      implement by a KDC or administrative interface implementing this
      information model. It also means that the feature is optional to
      implement in schema.</t>

      <t>Implementors of schema should be aware that unless there is a way to
      represent critical but optional elements in the schema definition
      language confusion may arise when optional elements are used but not
      understood by all implementations in a particular deployment.</t>

      <t>The expression "MUST NOT be OPTIONAL" means that a feature is
      mandatory to implement ("MUST" cf above) and that additionally it must
      not be marked optional in the schema language. In particular this means
      that the feature is both mandatory to implement and must be present in
      all representations of the object to which it applies.</t>

      <t>The term SHOULD or RECOMMENDED means that the consequences of not
      implementing the feature as if it was described with the "MUST" keyword
      must be carefully weighed before choosing a different course. In
      particular this implies that interoperability concerns may arise from
      not following the recommended practice in schema that implements this
      model.</t>

      <t>The context will determine if the "SHOULD" key word applies to
      schema, or to underlying behaviour of the KDC or both. For instance,
      principalIsDisabled (cf below) SHOULD default to FALSE implies both a
      recommendation for the behaviour of KDCs aswell as a rekommendation for
      the representation of that behaviour in schema.</t>
    </section>

    <section title="Information model demarcation">
      <t>The inforsmation 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
            (section 2.1.1 of <xref target="RFC1964"></xref>) 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 MUST NOT be used before this date. The syntax of
            the attribute MUST be Internet Date/Time Format from <xref
            target="RFC3339"></xref>. The attribute MUST be single-valued.</t>
          </section>

          <section title="principalNotUsedAfter">
            <t>The Principal MUST NOT be used after this date. The syntax of
            the attribute MUST be Internet Date/Time Format from <xref
            target="RFC3339"></xref>. 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 boolean FALSE.</t>
          </section>

          <section title="principalLastCredentialChangeTime">
            <t>This single-valued attribute contains the time of the last
            successful change of credential (e.g. password or private key)
            associated with this Principal. The syntax of the attribute MUST
            be Internet Date/Time Format from <xref
            target="RFC3339"></xref>.</t>
          </section>

          <section title="principalCreateTime">
            <t>This single-valued attribute contains the time and date when
            this Principal was created. The syntax of the attribute MUST be
            Internet Date/Time Format from <xref target="RFC3339"></xref>.</t>
          </section>

          <section title="principalModifyTime">
            <t>This single-valued attribute contains the time and date when
            this Principal was last modified excluding credentials change. The
            syntax of the attribute MUST be Internet Date/Time Format from
            <xref target="RFC3339"></xref>.</t>
          </section>

          <section title="principalMaximumTicketLifetime">
            <t>This single-valued attribute contains the 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 this Principal.</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>In Kerberos principals are associated with zero or more symmetric
        secret keys, and each key has a key version number (kvno) and enctype.
        In this model we group keys by kvno into KeySet objects. A Principal
        can have zero or more KeySet objects associated with it, each of which
        MUST have one or more keys. Each KeySet is associated with exactly one
        principal. Schemas derived from this model MAY lack a direct analogue
        of KeySet as described in this document.</t>

        <t>It is expected that most Kerberos implementations will use a
        special-purpose interface for setting and changing Principal passwords
        and keys.</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. For any
        given enctype a KeySet MUST NOT contain more than one Key with that
        enctype.</t>

        <t>The security of Kerberos 5 depends absolutely on the
        confidentiality and integrity of the Key objects 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 title="KeySet: Attributes">
          <section title="kvno">
            <t>Also knowns as the key version number. This is a single-valued
            attribute containing a non-negative integer. This number is
            incremembed by one each time a key in the KeySet is changed.</t>
          </section>
        </section>

        <section title="KeySet: Associations">
          <t>To each KeySet MUST be associated a set of 1 or more Keys.</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. One example is
            'aes128-cts-hmac-sha1-96'.</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. This parameter is
            specified in the "string-to-key" method in section 3 of <xref
            target="RFC3961"></xref>.</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 globally unique. Possible types of
            identifiers include: <list>
                <t>An Object Identifier (OID) <xref
                target="RFC4517"></xref></t>

                <t>A URI <xref target="RFC3986"></xref></t>

                <t>A UUID <xref target="RFC4122"></xref></t>
              </list></t>

            <t>Implementations of this specification are expected to assign
            globally unique identifiers to the list of standard policy below
            in accordance with best-practice for identifier-management for the
            schema-language used.</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 Principal 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 that represent Policy objects 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.</t>
          </section>

          <section title="Password Management Policy">
            <t>Password management policy controls how passwords are
            changed.</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.</t>
          </section>

          <section title="Ticket Flag Policy">
            <t>A ticket flag policy specifies the ticket flags allowed for
            tickets issued for a principal.</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 has no IANA actions.</t>
    </section>

    <section title="Acknowledgments">
      <t>The author wishes to extend his thanks to Love
      Hörnquist-Åstrand and Sam Hartman 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'?>

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

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

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

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

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

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

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