Last Call Review of draft-ietf-kitten-krb-auth-indicator-04
review-ietf-kitten-krb-auth-indicator-04-secdir-lc-huitema-2017-01-05-00

I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written primarily for the benefit of the security area
directors.  Document editors and WG chairs should treat these comments just
like any other last call comments.

This document defines a new type of Authorization Data for the Kerberos
protocol. The new data type is used to convey authentication strength
information to application services. It is intended to use when
implementations support different type of authentication, for example
password based, multi-factor, or public keys. The authentication strengths
are identified by either an URI identifying a Level of Assurance (LoA)
Profile registered with IANA (RFC 6711), or a site-defined string. These
identifiers are wrapped in an AD-CAMMAC container defined in RFC 7751. 

The document is almost ready, by I wish a few issues were addressed before
publication.

My first issue is that the document describes an update to the Kerberos
protocol specification, RFC 4120, but does not define the specific way in
which RFC 4120 is updated. Could the draft be updated to include something
like the section "6. Assigned Numbers" of RFC 7751? If I understand
correctly, the changes are a new ad-type number 97, pointing to a CAMMAC
container, in which the "elements" are encoded according to the syntax
specified in Appendix A of the draft. Having that explained succinctly would
help future readers.

My second issue is with the use of site-defined strings. I understand that
the site defined strings are defined by the administrator of a realm. What
happens if these strings appear outside the original realm, for example in
an environment connecting multiple realms? Don't we have a potential there
for name collision? Should there not be some guidance to implementers? 

I note that the proposed short string syntax forbids use of the ":"
character in site-defined strings. Did the WG look at the consequences of
that choice? If site administrators cannot use the URI like syntax, what is
the preferred way of defining unique strings and preventing collisions?

What are application services supposed to do when they encounter URI or
site-defined strings that they do not understand?

The ASN.1 syntax defines the element as a "SEQUENCE OF UTF8String". The
document mentions that "Each UTF8String value is a short string". How short
exactly should these strings be? How many of them should an application
expect in the "SEQUENCE OF" element? The syntax itself does not constrain
the length or number of these strings. Are we not worried with potential
interoperability issues? Could this be abused in some attacks? Should the
security considerations mention that?

-- Christian Huitema