One document matched: draft-ietf-krb-wg-kdc-model-01.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="full3978" docName="draft-ietf-krb-wg-kdc-model-01">
  <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>Sektionen 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="February" year="2008"/>
    <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. 
The attribute SHOULD be single valued. If an implementation supports multiple values it MUST 
treat one of the values as special and allow it to be fetched as if it was a single value.</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="principalAliases">
	    <t>This multivalued attribute contains an unordered set of aliases for 
the principal.  Each alias SHOULD be unique within the administrative domain 
represented by the KDC. The syntax of an alias is an opaque identifier which can
be compared for equality. </t>
	  </section>
	</section>
	<section title="Principal: Associations">
	  <t>Each principal MAY be associated with 1 or more KeySet and MAY be associated with
1 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 implemenation 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>

    <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>

    <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>

    <!--    
        
    <section title="Remarks">
      <t>A few notes and TODOs:
<list>
	  <t>Do we want to model access control? I have received a few notes on that from Love. 
It will affect both the model and the security considerations but It may be relevant. The catch 
is that most implementations (SOAP, LDAP, etc) will have acl mechanisms separate from the data 
which makes modeling acls difficult. Perhaps there are certain aspects of access control which 
can be modeled with relative ease - for instance the ability to make an object immutable.</t>
	  <t>Explanatory text on a few of the basic attributes that doesn't just repeat the
section title.</t>
	  <t>Expand on the password policy types. Is the subdivision into quality and
management policies valid?</t>
	</list>
</t>
    </section>


From lha@it.su.se:

1 rename/deletion attack. rename attacks doesn't directly attack the
  database itself but rather the system that use kerberos. what is the
  system allow a helpdesk person to delete a system administrator account
  and the rename a user to that name and by that way end up with elevated
  rights in the a distributed filesystem.

  What if the helpdesk/sysadmin person removes the krbtgt for a realm (or
  cross realm krbtgt).

  Should there be a ordering of principals so they could be compared ?
  Should (some) principals be a allowed to be immutable ?
  Should (some) principals only be a allowed to modify itself ?
  Should principals belong to a class and rights to modify classes are the
  one that is used ?

  This all are all policies, but implementors should be aware of the issues
  to they can provide easy to use tools.

2 Access control, exposes points of attach to for a attacker, might how
  what principals have eleveated rights, etc.

    -->

  </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>