Skip to main content

Last Call Review of draft-ietf-kitten-krb-auth-indicator-06
review-ietf-kitten-krb-auth-indicator-06-opsdir-lc-bradner-2017-01-10-00

Request Review of draft-ietf-kitten-krb-auth-indicator
Requested revision No specific revision (document currently at 07)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2017-01-06
Requested 2016-12-16
Authors Anupam Jain , Nathan Kinder , Nathaniel McCallum
I-D last updated 2017-01-10
Completed reviews Genart Last Call review of -04 by Robert Sparks (diff)
Opsdir Last Call review of -06 by Scott O. Bradner (diff)
Secdir Last Call review of -04 by Christian Huitema (diff)
Secdir Last Call review of -06 by Christian Huitema (diff)
Genart Telechat review of -06 by Robert Sparks (diff)
Assignment Reviewer Scott O. Bradner
State Completed
Request Last Call review on draft-ietf-kitten-krb-auth-indicator by Ops Directorate Assigned
Reviewed revision 06 (document currently at 07)
Result Ready
Completed 2017-01-10
review-ietf-kitten-krb-auth-indicator-06-opsdir-lc-bradner-2017-01-10-00
This is an OPS-DIR review of "Authentication Indicator in Kerberos Tickets"
(draft-ietf-kitten-krb-auth-indicator-04)

This draft documents a way to let a Kerberos-using service know how strong the
mechanism was that was used to authenticate a user.

This is an important issue.  One that, for example, Inernet2, has been
discussing for a while.  Since the same authentication system can be used by
services that have widely different authentication requirements, from simple
password to multi-factor or certificate-based, being able to let a service know
what level of security was used lets the service know if it should trust a
particular authentication.

This draft addresses the simplest part of a difficult problem.  The draft
provides a mechanism to pass
 information that a service could use to determine the level of authentication
 was used.  The (much)
harder problems include defining a consistent way to describe the
authentication levels (e.g. password/one
 time device/multi-factor/etc) in a way that provides the right level of
 information (vendor, mechanism the initial authentication to the
 authentication system is done, recertification requirements (e.g.  password
 aging)).
And , figuring out what to do if the strength did not meet the service’s
criteria - fail the authentication,
 return to the authentication service to request additional security?

This draft represents a fine, if small, initial building block.  There do not
seem to be any operational issues
 in the specific technology described by the draft but operational issues
 abound in getting from this draft to a useful solution to this issue.

imo - this draft is ready for publication

Scott