1. Summary
The document shepherd is Benjamin Kaduk. The responsible Area Director
is Stephen Farrell.
This document provides a new authorization data container for Kerberos,
with functionality extending that of the existing AD-KDC-ISSUED container.
The new functionality allows a KDC to be able to validate that a ticket being
presented to the KDC contains authorization data issued by a KDC (in the same
realm), whereas AD-KDC-ISSUED only allows for the Kerberos application service
to perform that validation.
Since this is an update to the standards-track RFC 4120, it must also
be a standards-track document.
2. Review and Consensus
The review process for this document was quite spread out in time, with
action occurring in occasional bursts. Almost all of the Kerberos
experts who regularly participate in the WG have contributed to
reviewing this document at some point in its history, but not
necessarily all at the same time. There was a lot of discussion around
the time of the initial few revisions, but then a lull in activity.
Version -05 got a lot of review comments, which resulted in some
(substantive, but relatively minor) changes to the specification. It
was unclear what level of review those changes had received, after
essentially no comments were received during a WGLC period for the -08
(of the document with krb-wg in the document name),
so we solicited further comments at that time, and got thorough review
from two Kerberos experts, which the shepherd believes is sufficient.
These post-WGLC reviews were largely editorial, but there were four
issues of substance that were raised, two of which received heavy
discussion.
Discussion of the implicit criticality of authorization data in Kerberos
resulted in full consensus for the text in section 5.
The WG may choose to revisit the usage of critical authorization data in
Kerberos in future work, but that question does not need to be resolved
for this document to move forward.
Discussion of the binding of the CAMMAC to the ticket service principal
name resulted in full consensus for the text in the last paragraph of
section 8.
The desire for a consumer of the CAMMAC to exist or an IANA registry
for authorization types to exist prior to publication of this document
did not receive much discussion, but seems to be at least partially
resolved by the existence of draft-jain-kitten-krb-auth-indicator, which came
out after the concern was raised. Discussions in person at IETF 91
indicate that at least one participant wishes for publication of this
document to block on the creation of a IANA registries for ad-types and
key usage numbers, but the shepherd believes that the existing
(non-IANA) registries are sufficient.
This document had progressed to the RFC Editor's queue when an implementor
noted an issue with the security considerations text, that forbid certain use
cases involving propagating a CAMMAC from a cross-realm TGT into a
ticket issued by a KDC in a different realm. The document was called back
from the RFC Editor for revision, and another WGLC was held, for
draft-ietf-kitten-cammac-03, which passed without incident. The changes
since the previous WGLC are contained solely to the security considerations
and an author update.
Red Hat and MIT have collaborated to produce an implementation, including
some automated test cases using the CAMMAC.
3. Intellectual Property
Each author has confirmed conformance with BCP 78/79.
There are no IPR declarations against this document.
4. Other Points
This document makes no request of IANA. It allocates numbers in the
Kerberos authorization data types registry and the Kerberos key usage
registry, which are currently managed independently of IANA (see also
draft-ietf-kitten-kerberos-iana-registries). As mentioned above,
the shepherd does not believe that publication of this document must wait
for these registries to be transferred into IANA's control. The current
registrar for these Kerberos registries is a coauthor of the document
and assigned the numbers listed in it.
'idnits' has a few false positives: though this document Updates RFC 4120,
it does not contain any content copied from RFC 4120 (all content is new
in this document), so no disclaimer for pre-RFC5378 work is needed.
Additionally, the checker notes for various ASN.1 tags, "Looks like a
reference, but probably isn't". We are in the "probably" case, here.