Last Call Review of draft-ietf-kitten-krb-auth-indicator-06

Request Review of draft-ietf-kitten-krb-auth-indicator
Requested rev. 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
Draft 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 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 Bradner 
State Completed
Review review-ietf-kitten-krb-auth-indicator-06-opsdir-lc-bradner-2017-01-10
Reviewed rev. 06 (document currently at 07)
Review result Ready
Review completed: 2017-01-10


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