Kerberos Authorization Data Container Authenticated by Multiple Message Authentication Codes (MACs)
draft-ietf-kitten-cammac-04

(Via drafts-lastcall-comment@iana.org): IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-kitten-cammac-04.txt, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any IANA actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, IANA does not object.

If this assessment is not accurate, please respond as soon as possible.

The following Last Call announcement was sent out:

From: The IESG
To: "IETF-Announce"
CC: kitten@ietf.org, kitten-chairs@ietf.org, kaduk@mit.edu, draft-ietf-kitten-cammac@ietf.org, stephen.farrell@cs.tcd.ie
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Kerberos Authorization Data Container Authenticated by Multiple MACs) to Proposed Standard


The IESG has received a request from the Common Authentication Technology
Next Generation WG (kitten) to consider the following document:
- 'Kerberos Authorization Data Container Authenticated by Multiple MACs'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2015-12-04. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document specifies a Kerberos Authorization Data container that
  supersedes AD-KDC-ISSUED.  It allows for multiple Message
  Authentication Codes (MACs) or signatures to authenticate the
  contained Authorization Data elements.  The multiple MACs are needed
  to mitigate shortcomings in the existing AD-KDC-ISSUED container.
  This document updates RFC 4120.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-kitten-cammac/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-kitten-cammac/ballot/


No IPR declarations have been submitted directly on this I-D.

This is a second last call for this document - an error was discovered
when this was in the RFC editor queue, it was taken back to the WG
and is now ready to jump all the hoops again.

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.

[Ballot comment]
I'd be happier if this document made it clear what, exactly, is being updated in RFC 4120.  I gather it's Section 6 of this document that's making the update, assigning an Authorization Data Types value (4120, Section 7.5.4) and a Key Usage Number (4120, Section 7.5.1).  Is that correct?  Might you change Section 6 to explicitly say that, and refer to the sections in 4120 that are being updated?

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-kitten-cammac-00, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any IANA actions.

While it is helpful for the IANA Considerations section of the document to remain in place upon publication, if the authors prefer to remove it, IANA doesn't object.

If this assessment is not accurate, please respond as soon as possible.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Kerberos Authorization Data Container Authenticated by Multiple MACs) to Proposed Standard


The IESG has received a request from the Common Authentication Technology
Next Generation WG (kitten) to consider the following document:
- 'Kerberos Authorization Data Container Authenticated by Multiple MACs'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2014-12-09. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  Abstract: This document specifies a Kerberos Authorization Data
  container that supersedes AD-KDC-ISSUED.  It allows for multiple
  Message Authentication Codes (MACs) or signatures to authenticate the
  contained Authorization Data elements.  This document updates RFC
  4120.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-kitten-cammac/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-kitten-cammac/ballot/


No IPR declarations have been submitted directly on this I-D.

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

The ASN.1 type specification for AD-CAMMAC was incomplete, missing
IMPORTS statements and a module header with OID; this addition is
believed to be uncontroversial.

There are not currently any implementations, but Red Hat and MIT plan
to collaborate to produce an implementation.  MIT has a partial
implementation of an en/decoder for the ASN.1 types.


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.