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