Re: [kitten] Authentication Indicator in Kerberos tickets

[Benjamin Kaduk <[e-mail]>]

Hi Nathaniel,

On Thu, 28 Aug 2014, Nathaniel McCallum wrote:

> The purpose of Authentication Indicators is to be able to assert some
> positive attributes about the authentication event itself in the ticket.
> This should also be usable in the case of S4U2Proxy.
>
> The draft can be found here:
> http://www.ietf.org/id/draft-jain-kitten-krb-auth-indicator-01.txt

I think we've seen sufficient interest to justify adopting this as a
working group document.  Please submit the next revision as
draft-ietf-kitten-krb-auth-indicator-00 so that the chairs can approve it
as a WG document.



As an individual, I have some comments about the text.

I think that the name of the authorization data type should have an AD-
prefix, that is, be AD-AUTHENTICATION-INDICATOR.

In section 3, the ad-data field contains the DER encoding of the ASN.1
type whose definition follows, not the "AD type".

This document is not the place to make normative statements about the
AD-CAMMAC.  So, the last paragraph of section 3 should not say that the
AD-CAMMAC element MAY be safely ignored.

Similarly, the CAMMAC document already has a mechanism for binding the
CAMMAC to the enclosing ticket in the definition of the kdc-verifier.  If
this document needs to say anything about such a binding, it should
probably just say that the KDC MUST include a kdc-verifier in the
containing CAMMAC, to provide a binding to the enclosing ticket.

The document lists RFCs 4120 and 4121 in the references sections, but does
not make citations to those references at any point in the main text.  I
am not sure that 4121 is necessary unless there is a desire to add, e.g.,
a GSS name attribute by which the authentication indicator may be
accessed.  For 4120, on the other hand, I think this document should
Update: 4120, and mention that in the abstract and introduction at least.

After the definition of the ASN.1 type AUTHENTICATION-INDICATOR, you have
"These values are short strings[...]".  In specification documents like
this, it's usually best to avoid generic pronouns like "these" and include
concrete bindings, as in "These UTF8String values are[...]".  Also, the
ASN.1 definition does not include the EXPLICIT TAGS and similar
boilerplate usually found when declaring Kerberos ASN.1 modules.  That
should be present unless we are trying to stuff this into an existing
module (in which case that should be stated).

In the abstract, I think it may be worth replacing "indicator of the
client's authentication strength" with "indicator of the strengh of the
client's authentication".

There are a few grammar nits (missing "the"s, mostly).  I can point them
out out-of-band if you don't want to duplicate time looking for them.


Thanks,

Ben