[kitten] Comments on draft-ietf-krb-wg-camac-08

[Sam Hartman <[e-mail]>]

Section 4:
I expect advice on whether this should be contained in ad-if-relevant
and on how an implementation that does understand this element should
process contained elements that it does not understand.

I believe this comment needs to be addressed prior to publication.



Section 5/6:

This document registers a new authorization data container but does not
provide a way to use that container.  Any authorization data designed to
fit within that container would require action from this working group
either to publish a document describing that authorization data or a
document establishing an IANA registry for authorization data.

I think that publishing a new authorization data container without a way
to legitimately use it dis not in the IETF's interest.  Either it won't
get used until we publish some document, in which case we're better off
holding off until that document is published and gaining implementation
experience with both.  Alternatively, it will get used by someone
squatting on a number, which is bad.

My recommendation is that we move the authorization data registry from
Kerberos IANA to section 6 here and remove section 5.
I feel reasonably strongly that publishing this document without either
an IETF consumer or an IANA registry is bad.


Section 7:

We only bind to the encrypted ticket part.  A KDC knows from the MAC
verification that it issued a ticket with the given encrypted part, but
has no confidence from that information what service key it encrypted
that ticket in nor the service name in the outer ticket.

How is a KDC supposed to make sure this authorization container was
issued to the service that claims to have received it.
At one level, you could argue that's a general issue with s4u and
similar.  At another level, we're introducing those mechanisms into the
IETF here, so I think we need to discuss that issue here.
we could either solve it in this document by including the principal
name to which the ticket is issued in something covered by the KDC MAC.
The obvious solution there would be to define an authorization data
element for an interested KDC to include.
Alternatively we could include an octet-string for KDC internal usage
that is covered by the MAC.

If we establish an IANA registry for authorization data types with
expert review or more liberal of a registration policy, then we could
document the issue without providing an explicit solution.