Technical Summary
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 Key Distribution Center
(KDC). This document describes the services exposed by an
administrative interface to a KDC.
Working Group Summary
This document represents the consensus of the Kerberos Working Group.
and will serve as the basis for further development of an LDAP schema.
Document Quality
As an information model, this document does not specify anything
that can be directly implemented. Rather, it forms the basis for
further work, such as the production of an LDAP schema which can be
used to support administration of a Kerberos KDC. Producing such
a schema is a chartered work item of the Kerberos Working Group.
In addition, while this document is not necessarily intended to
serve as a basis for KDC database design, it has been informed by
the design of several implementations, including some which are
able to use LDAP as a data store for the KDC database.
Personnel
The Document Shepherd for this document is Jeffrey Hutzelman.
The responsible Area Director is Stephen Farrell.
RFC Editor Notes
1. in the abstract, expand the acronym KDC
OLD:
a kerberos 5 KDC
NEW:
a kerberos 5 Key Distribution Center (KDC)
2. Use upper case "K" for Kerberos consistently
throughout when the term Kerberos is used.
The only exceptions I see are in draft
file names.
OLD:
kerberos
NEW:
Kerberos
3. Introduction, 1st paragraph, Don't refer to 4120 as a "standard"
OLD:
The Kerberos version 5 authentication service described in [RFC4120]
describes how a Key Distribution Center (KDC) provides authentication
to clients. The standard does not stipulate how a KDC is managed and
NEW:
The Kerberos version 5 authentication service described in [RFC4120]
describes how a Key Distribution Center (KDC) provides authentication
to clients. RFC 4120 does not stipulate how a KDC is managed and
4. 4.2.2, re-word
OLD:
To each KeySet MUST be associated a set of 1 or more Keys.
NEW:
Each KeySet MUST be associated with a set of 1 or more Keys.
5. 4.3, re-word
OLD:
Implementations of this model MUST NOT REQUIRE keys to be
represented.
NEW:
Implementations of this model MUST NOT force keys to be
represented. That is, a schema that REQUIRED a key to be
present would not meet this constraint.
6. 4.2.1.1, typo
OLD:
incremembed
NEW:
incremented
7. add a reference to 4.3.1.5 and 4.3.1.6
OLD:
4.3.1.5. keyNotUsedBefore
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.
4.3.1.6. keyNotUsedAfter
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.
NEW:
4.3.1.5. keyNotUsedBefore
This key MUST NOT be used before this date. The syntax of the
attribute MUST be semantically equivalent with the standard ISO date
format. [RFC3339] This MUST be a single-valued attribute.
4.3.1.6. keyNotUsedAfter
This key MUST NOT be used after this date. The syntax of the
attribute MUST be semantically equivalent with the standard ISO date
format. [RFC3339] This MUST be a single-valued attribute.
8. Add RFC 3339 as a normative reference to 9.1
NEW:
[RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on
the Internet: Timestamps", RFC 3339, July 2002.