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

From: Greg Hudson <[email-masked]>
Date: Fri, 05 Sep 2014 10:57:46 -0400

> I have submitted a new draft for Kerberos Authentication Indicators
> and I'd like to start a discussion about moving the draft through the
> process.

I think the working group should adopt this document.  It's relatively
simple and it provides a first consumer for the CAMMAC container.  It
fits easily within the "new authorization data types" item in the
working group charter.

The general use case has plenty of history.  Deployments like MIT's have
been doing something similar with "root instance" principals for a long
time: people have one principal for day-to-day use, and another
principal with a name like "ghudson/root" with greater access.
Originally, root instance principals just had different (hopefully
better) passwords which don't get typed as often, but these days root
instance principals often require two-factor authentication.  The
authentication indicator allows the same kind of restriction without
requiring a separate principal for elevated access.

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 5 Sep 2014 17:18:55 -0400 (EDT)

> fits easily within the "new authorization data types" item in the

I agree that it's in the charter:

% Prepare, review, and advance standards-track and informational
%         specifications defining new authorization data types for carrying
%         supplemental information about the client to which a Kerberos
%         ticket has been issued and/or restrictions on what the ticket can
%         be used for.

This seems to be information about the client to which a ticket will be
issued.

-Ben

---

From: Richard Feezel <[email-masked]>
Date: Mon, 29 Sep 2014 21:03:30 -0400

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

I, too, have been wrestling with the challenge of how to represent
assertions about an authentication event which extend well beyond questions
of the technical strength of the authentication methodology.
The implications of an authentication event extend far beyond the question
of whether the technical mechanism should be trusted. The qualities of the
whole process of qualifying individual identities before technical
credentials are issued is often an important consideration when making
authorization decisions.

Another idea not specifically envisioned in the proposed approach, but well
within it's capability is the question of how to represent the
"circumstances" under which the user is authenticating. Such ideas as "User
is authenticating on their office computer during normal business hours"
could be represented and would, in some circumstances, very useful in
making risk-based authorizations decisions.

The proposed mechanism is a compact and yet generalized and extendible idea
which supports both global federation and localizable customization.

It is a perfect fit for the CAMMAC container which I also encourage the
group to quickly adopt.

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?

On Thu, Aug 28, 2014 at 12:36 PM, Nathaniel McCallum <[email-masked]>
wrote:

> I have submitted a new draft for Kerberos Authentication Indicators and
> I'd like to start a discussion about moving the draft through the
> process. I'm a newbie here, so any help would be greatly appreciated.
>
> 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
>
> For some background information, see the MIT krb5 project page:
> http://k5wiki.kerberos.org/wiki/Projects/Authentication_indicator
>
> Thanks!
>
> Nathaniel McCallum
>
> _______________________________________________
> Kitten mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/kitten
>

-- 
Richard M Feezel
[email-masked]