Subject: Re: [kitten] Authentication Indicator in Kerberos tickets

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 1 Oct 2014 13:25:52 -0400 (EDT)

On Mon, 29 Sep 2014, Richard Feezel wrote:

> I would like to encourage the group to adopt this document as well.

[puts on chair hat]
Thanks for speaking up.  I think I would like to hear a little bit more
support from other WG participants before adopting this as a WG item,
though.

Does anyone else want to see us pick it up?  I think Nico was expressing
some opinions on how things like this should be done on IRC, so maybe he
would support it?
[takes off chair hat]

> I plan to do some trial implementation testing and would like to know what
> values I can safely use for the Authorization Data fields for CAMMAC and
> Authentication Indicators in advance of an official action by this group
> and the IANA?

The draft-ietf-krb-wg-cammac-10 assigns the ad-type number 96 for
AD-CAMMAC.
For the AUTHENTICATION-INDICATOR itself (hmm, that should be changed
to have an AD- prefix), there is not yet an assigned number, but
draft-ietf-kitten-kerberos-iana-registries-03 specifies that negative
integer values are for private or local use.  You are unlikely to
encounter trouble picking a ~random negative 32-bit signed integer and
using it for your local implementation, but should expect to change your
implementation when an official value is assigned.

Does that address your question?

-Ben Kaduk

---

From: Richard Feezel <[email-masked]>
Date: Wed, 1 Oct 2014 15:28:46 -0400

> some opinions on how things like this should be done on IRC, so maybe he
I too would like to hear from other members of the group.

> Does that address your question?
Yes, thanks.  One related question, would it be appropriate to ask the
author of  *draft-**jain-kitten-krb-auth-**indicator-01.txt* to include a
proposed ad-type value in the next revision?

-- 
Richard M Feezel
[email-masked]

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 1 Oct 2014 15:33:29 -0400 (EDT)

> proposed ad-type value in the next revision?

The authors would need to obtain one from the current registrar for them,
who reads this mailing list.  I'm not entirely sure what criteria are
required for the issuance of a number at this point, though.

-Ben

---

From: Tom Yu <[email-masked]>
Date: Wed, 01 Oct 2014 15:38:40 -0400

> required for the issuance of a number at this point, though.

I think it would be best for the working group to adopt the draft as a
WG draft before making any provisional number assignments.

---

From: Nico Williams <[email-masked]>
Date: Wed, 1 Oct 2014 19:08:29 -0500

IMO the WG should adopt this I-D.

Registrations for the LoA registry suitable for use with this AD would
be nice.

Nico
--

---

From: Simo Sorce <[email-masked]>
Date: Thu, 2 Oct 2014 12:13:31 -0400

On Wed, 1 Oct 2014 13:25:52 -0400 (EDT)
Benjamin Kaduk <[email-masked]> wrote:

> Does anyone else want to see us pick it up? 

I do!

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York

---

From: Jeffrey Altman <[email-masked]>
Date: Thu, 02 Oct 2014 21:06:16 -0400

> IMO the WG should adopt this I-D.

+1

> Registrations for the LoA registry suitable for use with this AD would

+1

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 3 Oct 2014 11:20:49 -0400 (EDT)

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