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

<?xml version="1.0" encoding="UTF-8"?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd">


<rfc category="std" ipr="trust200902" docName="draft-ietf-krb-wg-kdc-model-04">
  <front>
    <title abbrev="KDC Information Model">An information model for Kerberos version 5</title>
    <author surname="Johansson" fullname='Leif Johansson'>
      <organization abbrev="Stockholm university">Stockholm university</organization>
      <address>
	<postal>
	  <street>Avdelningen för IT och Media</street>
	  <code>SE-106 91</code>
	  <city>Stockholm</city>
	</postal>
	<email>leifj@it.su.se</email>
	<uri>http://people.su.se/~leifj/</uri>
      </address>
    </author>
    <date month="March" 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"/>.</t>
    </section>

    <section title="Introduction"><t>
      The Kerberos version 5 authentication service described in <xref target="RFC4120"/> 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"/> 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 MUST 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"/>. 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 must 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 URN</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"/>.</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" />. 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"/>.</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>None</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>