https://k5wiki.kerberos.org/w/api.php?action=feedcontributions&user=Sbuckley&feedformat=atomK5Wiki - User contributions [en]2024-03-29T06:51:47ZUser contributionsMediaWiki 1.27.4https://k5wiki.kerberos.org/wiki?title=Release_1.9&diff=3297Release 1.92010-05-18T16:46:59Z<p>Sbuckley: /* Code quality */</p>
<hr />
<div>This is the preliminary proposed goal set for the '''krb5-1.9 release'''. Please provide comments on the krbdev list. This page organizes the goals by the "guiding principles" listed in the [[Roadmap|roadmap]].<br />
<br />
== Timeline ==<br />
<br />
This is only an approximate timeline.<br />
<br />
* 2010-09-01 -- make release branch<br />
* 2010-12-01 -- final release<br />
<br />
== Code quality ==<br />
<br />
* Python-based test framework [Greg, done, could be extended to include multi-realm test cases]<br />
* KDC refactoring [Tom Yu]<br />
* DAL cleanup [Greg Hudson]<br />
<br />
== Developer experience ==<br />
<br />
* NSS crypto back end? [Bob Lyea]<br />
* plugin framework evolution [Tom Yu, Zhanna Tsitkova]<br />
* Naming extensions back end for exposing constrained delegation chain [Luke, done, needs review]<br />
<br />
== Performance ==<br />
<br />
* account lockout performance improvements [Greg Hudson, done]<br />
<br />
== End-user experience ==<br />
<br />
== Administrator experience ==<br />
<br />
* [[Projects/Trace_logging|Trace logging]] [Greg Hudson]<br />
* Plugins for password sync [Tom Yu]<br />
* Plugins for password quality checks [Tom Yu]<br />
* OTP (only old SAM SecurID planned for now) [Tom Yu]<br />
* Configuration File Validator [Zhanna Tsitkova]<br />
<br />
== Protocol evolution ==<br />
<br />
* [[Projects/IAKERB|IAKERB]] [Luke, done]<br />
* [[Projects/Camellia_encryption|Camellia encryption]][Luke, mostly done, needs standardization]</div>Sbuckleyhttps://k5wiki.kerberos.org/wiki?title=Release_1.9&diff=3296Release 1.92010-05-18T16:46:31Z<p>Sbuckley: /* Administrator experience */</p>
<hr />
<div>This is the preliminary proposed goal set for the '''krb5-1.9 release'''. Please provide comments on the krbdev list. This page organizes the goals by the "guiding principles" listed in the [[Roadmap|roadmap]].<br />
<br />
== Timeline ==<br />
<br />
This is only an approximate timeline.<br />
<br />
* 2010-09-01 -- make release branch<br />
* 2010-12-01 -- final release<br />
<br />
== Code quality ==<br />
<br />
* Python-based test framework [Greg, done, could be extended to include multi=realm test cases]<br />
* KDC refactoring [Tom Yu]<br />
* DAL cleanup [Greg Hudson]<br />
<br />
== Developer experience ==<br />
<br />
* NSS crypto back end? [Bob Lyea]<br />
* plugin framework evolution [Tom Yu, Zhanna Tsitkova]<br />
* Naming extensions back end for exposing constrained delegation chain [Luke, done, needs review]<br />
<br />
== Performance ==<br />
<br />
* account lockout performance improvements [Greg Hudson, done]<br />
<br />
== End-user experience ==<br />
<br />
== Administrator experience ==<br />
<br />
* [[Projects/Trace_logging|Trace logging]] [Greg Hudson]<br />
* Plugins for password sync [Tom Yu]<br />
* Plugins for password quality checks [Tom Yu]<br />
* OTP (only old SAM SecurID planned for now) [Tom Yu]<br />
* Configuration File Validator [Zhanna Tsitkova]<br />
<br />
== Protocol evolution ==<br />
<br />
* [[Projects/IAKERB|IAKERB]] [Luke, done]<br />
* [[Projects/Camellia_encryption|Camellia encryption]][Luke, mostly done, needs standardization]</div>Sbuckleyhttps://k5wiki.kerberos.org/wiki?title=Release_1.9&diff=3295Release 1.92010-05-18T16:34:30Z<p>Sbuckley: /* Administrator experience */</p>
<hr />
<div>This is the preliminary proposed goal set for the '''krb5-1.9 release'''. Please provide comments on the krbdev list. This page organizes the goals by the "guiding principles" listed in the [[Roadmap|roadmap]].<br />
<br />
== Timeline ==<br />
<br />
This is only an approximate timeline.<br />
<br />
* 2010-09-01 -- make release branch<br />
* 2010-12-01 -- final release<br />
<br />
== Code quality ==<br />
<br />
* Python-based test framework [Greg, done, could be extended to include multi=realm test cases]<br />
* KDC refactoring [Tom Yu]<br />
* DAL cleanup [Greg Hudson]<br />
<br />
== Developer experience ==<br />
<br />
* NSS crypto back end? [Bob Lyea]<br />
* plugin framework evolution [Tom Yu, Zhanna Tsitkova]<br />
* Naming extensions back end for exposing constrained delegation chain [Luke, done, needs review]<br />
<br />
== Performance ==<br />
<br />
* account lockout performance improvements [Greg Hudson, done]<br />
<br />
== End-user experience ==<br />
<br />
== Administrator experience ==<br />
<br />
* [[Projects/Trace_logging|Trace logging]] [Greg Hudson]<br />
* Plugins for password sync [Tom Yu]<br />
* Plugins for password quality checks [Tom Yu]<br />
* OTP (only old SAM SecurID planned for now) [Tom Yu]<br />
<br />
== Protocol evolution ==<br />
<br />
* [[Projects/IAKERB|IAKERB]] [Luke, done]<br />
* [[Projects/Camellia_encryption|Camellia encryption]][Luke, mostly done, needs standardization]</div>Sbuckleyhttps://k5wiki.kerberos.org/wiki?title=Release_1.9&diff=3294Release 1.92010-05-18T16:33:29Z<p>Sbuckley: /* Protocol evolution */</p>
<hr />
<div>This is the preliminary proposed goal set for the '''krb5-1.9 release'''. Please provide comments on the krbdev list. This page organizes the goals by the "guiding principles" listed in the [[Roadmap|roadmap]].<br />
<br />
== Timeline ==<br />
<br />
This is only an approximate timeline.<br />
<br />
* 2010-09-01 -- make release branch<br />
* 2010-12-01 -- final release<br />
<br />
== Code quality ==<br />
<br />
* Python-based test framework [Greg, done, could be extended to include multi=realm test cases]<br />
* KDC refactoring [Tom Yu]<br />
* DAL cleanup [Greg Hudson]<br />
<br />
== Developer experience ==<br />
<br />
* NSS crypto back end? [Bob Lyea]<br />
* plugin framework evolution [Tom Yu, Zhanna Tsitkova]<br />
* Naming extensions back end for exposing constrained delegation chain [Luke, done, needs review]<br />
<br />
== Performance ==<br />
<br />
* account lockout performance improvements [Greg Hudson, done]<br />
<br />
== End-user experience ==<br />
<br />
== Administrator experience ==<br />
<br />
* [[Projects/Trace_logging|Trace logging]][Greg Hudson]<br />
* Plugins for password sync [Tom Yu]<br />
* Plugins for password quality checks [Tom Yu]<br />
* OTP (only old SAM SecurID planned for now) [Tom Yu]<br />
<br />
== Protocol evolution ==<br />
<br />
* [[Projects/IAKERB|IAKERB]] [Luke, done]<br />
* [[Projects/Camellia_encryption|Camellia encryption]][Luke, mostly done, needs standardization]</div>Sbuckleyhttps://k5wiki.kerberos.org/wiki?title=Release_1.9&diff=3293Release 1.92010-05-18T16:32:03Z<p>Sbuckley: /* Administrator experience */</p>
<hr />
<div>This is the preliminary proposed goal set for the '''krb5-1.9 release'''. Please provide comments on the krbdev list. This page organizes the goals by the "guiding principles" listed in the [[Roadmap|roadmap]].<br />
<br />
== Timeline ==<br />
<br />
This is only an approximate timeline.<br />
<br />
* 2010-09-01 -- make release branch<br />
* 2010-12-01 -- final release<br />
<br />
== Code quality ==<br />
<br />
* Python-based test framework [Greg, done, could be extended to include multi=realm test cases]<br />
* KDC refactoring [Tom Yu]<br />
* DAL cleanup [Greg Hudson]<br />
<br />
== Developer experience ==<br />
<br />
* NSS crypto back end? [Bob Lyea]<br />
* plugin framework evolution [Tom Yu, Zhanna Tsitkova]<br />
* Naming extensions back end for exposing constrained delegation chain [Luke, done, needs review]<br />
<br />
== Performance ==<br />
<br />
* account lockout performance improvements [Greg Hudson, done]<br />
<br />
== End-user experience ==<br />
<br />
== Administrator experience ==<br />
<br />
* [[Projects/Trace_logging|Trace logging]][Greg Hudson]<br />
* Plugins for password sync [Tom Yu]<br />
* Plugins for password quality checks [Tom Yu]<br />
* OTP (only old SAM SecurID planned for now) [Tom Yu]<br />
<br />
== Protocol evolution ==<br />
<br />
* [[Projects/IAKERB|IAKERB]]<br />
* [[Projects/Camellia_encryption|Camellia encryption]]</div>Sbuckleyhttps://k5wiki.kerberos.org/wiki?title=Release_1.9&diff=3292Release 1.92010-05-18T16:30:24Z<p>Sbuckley: /* Performance */</p>
<hr />
<div>This is the preliminary proposed goal set for the '''krb5-1.9 release'''. Please provide comments on the krbdev list. This page organizes the goals by the "guiding principles" listed in the [[Roadmap|roadmap]].<br />
<br />
== Timeline ==<br />
<br />
This is only an approximate timeline.<br />
<br />
* 2010-09-01 -- make release branch<br />
* 2010-12-01 -- final release<br />
<br />
== Code quality ==<br />
<br />
* Python-based test framework [Greg, done, could be extended to include multi=realm test cases]<br />
* KDC refactoring [Tom Yu]<br />
* DAL cleanup [Greg Hudson]<br />
<br />
== Developer experience ==<br />
<br />
* NSS crypto back end? [Bob Lyea]<br />
* plugin framework evolution [Tom Yu, Zhanna Tsitkova]<br />
* Naming extensions back end for exposing constrained delegation chain [Luke, done, needs review]<br />
<br />
== Performance ==<br />
<br />
* account lockout performance improvements [Greg Hudson, done]<br />
<br />
== End-user experience ==<br />
<br />
== Administrator experience ==<br />
<br />
* [[Projects/Trace_logging|Trace logging]]<br />
* Plugins for password sync<br />
* Plugins for password quality checks<br />
* OTP (only old SAM SecurID planned for now)<br />
<br />
== Protocol evolution ==<br />
<br />
* [[Projects/IAKERB|IAKERB]]<br />
* [[Projects/Camellia_encryption|Camellia encryption]]</div>Sbuckleyhttps://k5wiki.kerberos.org/wiki?title=Release_1.9&diff=3291Release 1.92010-05-18T16:29:40Z<p>Sbuckley: /* Code quality */</p>
<hr />
<div>This is the preliminary proposed goal set for the '''krb5-1.9 release'''. Please provide comments on the krbdev list. This page organizes the goals by the "guiding principles" listed in the [[Roadmap|roadmap]].<br />
<br />
== Timeline ==<br />
<br />
This is only an approximate timeline.<br />
<br />
* 2010-09-01 -- make release branch<br />
* 2010-12-01 -- final release<br />
<br />
== Code quality ==<br />
<br />
* Python-based test framework [Greg, done, could be extended to include multi=realm test cases]<br />
* KDC refactoring [Tom Yu]<br />
* DAL cleanup [Greg Hudson]<br />
<br />
== Developer experience ==<br />
<br />
* NSS crypto back end? [Bob Lyea]<br />
* plugin framework evolution [Tom Yu, Zhanna Tsitkova]<br />
* Naming extensions back end for exposing constrained delegation chain [Luke, done, needs review]<br />
<br />
== Performance ==<br />
<br />
* account lockout performance improvements<br />
<br />
== End-user experience ==<br />
<br />
== Administrator experience ==<br />
<br />
* [[Projects/Trace_logging|Trace logging]]<br />
* Plugins for password sync<br />
* Plugins for password quality checks<br />
* OTP (only old SAM SecurID planned for now)<br />
<br />
== Protocol evolution ==<br />
<br />
* [[Projects/IAKERB|IAKERB]]<br />
* [[Projects/Camellia_encryption|Camellia encryption]]</div>Sbuckleyhttps://k5wiki.kerberos.org/wiki?title=Release_1.9&diff=3290Release 1.92010-05-18T16:28:11Z<p>Sbuckley: /* Developer experience */</p>
<hr />
<div>This is the preliminary proposed goal set for the '''krb5-1.9 release'''. Please provide comments on the krbdev list. This page organizes the goals by the "guiding principles" listed in the [[Roadmap|roadmap]].<br />
<br />
== Timeline ==<br />
<br />
This is only an approximate timeline.<br />
<br />
* 2010-09-01 -- make release branch<br />
* 2010-12-01 -- final release<br />
<br />
== Code quality ==<br />
<br />
* Python-based test framework<br />
* KDC refactoring<br />
* DAL cleanup<br />
<br />
== Developer experience ==<br />
<br />
* NSS crypto back end? [Bob Lyea]<br />
* plugin framework evolution [Tom Yu, Zhanna Tsitkova]<br />
* Naming extensions back end for exposing constrained delegation chain [Luke, done, needs review]<br />
<br />
== Performance ==<br />
<br />
* account lockout performance improvements<br />
<br />
== End-user experience ==<br />
<br />
== Administrator experience ==<br />
<br />
* [[Projects/Trace_logging|Trace logging]]<br />
* Plugins for password sync<br />
* Plugins for password quality checks<br />
* OTP (only old SAM SecurID planned for now)<br />
<br />
== Protocol evolution ==<br />
<br />
* [[Projects/IAKERB|IAKERB]]<br />
* [[Projects/Camellia_encryption|Camellia encryption]]</div>Sbuckleyhttps://k5wiki.kerberos.org/wiki?title=Release_1.8&diff=3085Release 1.82009-12-31T03:09:43Z<p>Sbuckley: /* Administrator experience */</p>
<hr />
<div>This is the preliminary proposed goal set for the '''krb5-1.8 release'''. Please provide comments on the krbdev list. This page organizes the goals by the "guiding principles" listed in the [[Roadmap|roadmap]].<br />
<br />
== Timeline ==<br />
<br />
This is only an approximate timeline.<br />
<br />
* 2009-10-06 -- "halfway point" feature and integration test<br />
* 2010-01-04 -- make release branch<br />
* 2010-03-01 -- final release<br />
<br />
== Code quality ==<br />
<br />
* Move toward [[test-driven development]]<br />
* Increase conformance to coding style<br />
** See [[Coding style/Transition strategies]]<br />
** "[[Coding style/Reindenting|The great reindent]]"<br />
** Selective refactoring<br />
<br />
== Modularity ==<br />
<br />
* [[Projects/Crypto_modularity|Crypto modularity]]<br />
* Move toward improved KDB interface<br />
* Improved API for [[Projects/VerifyAuthData|verifying and interrogating authorization data]]<br />
<br />
== Performance ==<br />
<br />
* Investigate and remedy repeatedly-reported performance bottlenecks.<br />
* [[Projects/Encryption performance|Encryption performance]]<br />
<br />
== End-user experience ==<br />
<br />
* Reduce DNS dependence<br />
** Love's ccache auxiliary data proposal allows client library to track whether a KDC supports service principal referrals.<br />
<br />
== Administrator experience ==<br />
<br />
* Disable DES by default (1.8)<br />
* More versatile [[Projects/Enctype_config_enhancements|crypto configuration]], to simplify migration away from DES<br />
* [[Projects/Lockout|Lockout]] for repeated login failures<br />
<br />
== Protocol evolution ==<br />
<br />
* [[Projects/Fast negotiation|FAST enhancements]]<br />
* [[Projects/Services4User| S4U2Self/S4U2Proxy]]<br />
* [[Projects/Anonymous pkinit | Anonymous PKINIT]]</div>Sbuckleyhttps://k5wiki.kerberos.org/wiki?title=Main_Page&diff=3002Main Page2009-11-21T14:07:24Z<p>Sbuckley: /* Releases */</p>
<hr />
<div>__NOTOC__<br />
'''K5Wiki''' is a wiki supporting the development of [[MIT Kerberos]], a reference implementation of [[wp:Kerberos (protocol)|the Kerberos network authentication protocol]]. MIT Kerberos is a project of the [http://www.kerberos.org/ MIT Kerberos Consortium].<br />
<br />
This wiki serves both as a place for coordination of development efforts on MIT Kerberos and as a means for potential contributors and other interested people to become more involved with MIT Kerberos development. This wiki does not focus on the needs for the average end user, but it may nevertheless contain information that is useful to advanced users, such as system administrators who wish to make customizations.<br />
<br />
What can this wiki do for you?<br />
* I have a [[Asking questions|question]]<br />
* I want to [[Writing applications|write Kerberos application software]]<br />
* I want to [[Reporting bugs|report bugs]]<br />
* I want to [[Fixing bugs|fix bugs]]<br />
* I want to [[Learning about the code|learn more about the code]]<br />
* I have [[Suggesting enhancements|ideas for enhancements]]<br />
* I want to [[Contributing code|contribute code]]<br />
* I want to [[K5Wiki:Todo|help to improve this wiki]]<br />
<br />
== Releases ==<br />
<br />
The current release is [http://web.mit.edu/kerberos/krb5-1.7 krb5-1.7]. <br />
<br />
Feature Specifications for [[Release_1.7]]<br />
<br />
Additional information on future releases:<br />
<br />
* Development [[roadmap]]<br />
* [[Release 1.8]]<br />
<br />
== Users ==<br />
<br />
We recommend that end users use MIT Kerberos software packages built by their operating system vendor if possible, and use support resources provided by their site or by their vendor. For those users (typically system administrators) who have a need to build MIT Kerberos from source code, we have some resources available on this wiki.<br />
<br />
* [[Building]] the MIT Kerberos software<br />
* [[Reporting bugs]]<br />
* [[Suggesting enhancements]]<br />
* More [[user resources]]<br />
<br />
== System administrators ==<br />
<br />
We also recommend that most system administrators use MIT Kerberos software packages from their operating system vendor if possible.<br />
<br />
* [[Building]] the MIT Kerberos software<br />
* [[Reporting bugs]]<br />
* [[Suggesting enhancements]]<br />
* More [[sysadmin resources]]<br />
<br />
== Developers ==<br />
<br />
Developers can include end users who have a need to customize the MIT Kerberos source code, or who would like to contribute patches for new features or for bug fixes.<br />
<br />
* [[Developer resources]]<br />
<br />
=== Contributing ===<br />
<br />
* [[How to contribute]] to the MIT Kerberos software<br />
* [[Fixing bugs]]<br />
* [[Suggesting enhancements]]<br />
* [[Contributing code]]<br />
<br />
=== Background information ===<br />
<br />
* [[:Category:Policies|Policies for development]]<br />
* [[:Category:Lore|Lore]]<br />
<br />
=== Code quality ===<br />
<br />
* [[Coding style]]<br />
* [[Test-driven development]]<br />
* [[Manual_Testing|Manual testing procedures]]<br />
<br />
=== Planning ===<br />
<br />
* Development [[roadmap]]<br />
* [[Projects]]<br />
<br />
=== Communication ===<br />
<br />
* [[Release_Meeting_Minutes|Release Meeting Minutes]]<br />
* [http://blog.kerberos.org/ Blog]<br />
<br />
== Additional information ==<br />
<br />
* [[K5Wiki:Todo|A todo list for work needing doing on this wiki]]<br />
* [[Application_Maintenance|Notes on maintenance of the krb5 telnet/rlogin/gssftp applications]]<br />
<br />
We look forward to your contributions to K5Wiki and MIT Kerberos.</div>Sbuckleyhttps://k5wiki.kerberos.org/wiki?title=Main_Page&diff=3001Main Page2009-11-21T14:06:40Z<p>Sbuckley: /* Releases */</p>
<hr />
<div>__NOTOC__<br />
'''K5Wiki''' is a wiki supporting the development of [[MIT Kerberos]], a reference implementation of [[wp:Kerberos (protocol)|the Kerberos network authentication protocol]]. MIT Kerberos is a project of the [http://www.kerberos.org/ MIT Kerberos Consortium].<br />
<br />
This wiki serves both as a place for coordination of development efforts on MIT Kerberos and as a means for potential contributors and other interested people to become more involved with MIT Kerberos development. This wiki does not focus on the needs for the average end user, but it may nevertheless contain information that is useful to advanced users, such as system administrators who wish to make customizations.<br />
<br />
What can this wiki do for you?<br />
* I have a [[Asking questions|question]]<br />
* I want to [[Writing applications|write Kerberos application software]]<br />
* I want to [[Reporting bugs|report bugs]]<br />
* I want to [[Fixing bugs|fix bugs]]<br />
* I want to [[Learning about the code|learn more about the code]]<br />
* I have [[Suggesting enhancements|ideas for enhancements]]<br />
* I want to [[Contributing code|contribute code]]<br />
* I want to [[K5Wiki:Todo|help to improve this wiki]]<br />
<br />
== Releases ==<br />
<br />
The current release is [http://web.mit.edu/kerberos/krb5-1.7 krb5-1.7]. <br />
<br />
Feature Specifications for [[Release_1.7]]<br />
<br />
Additional information on future releases:<br />
<br />
* Development [[roadmap]]<br />
* [[Release 1.8]]<br />
<br />
== Users ==<br />
<br />
We recommend that end users use MIT Kerberos software packages built by their operating system vendor if possible, and use support resources provided by their site or by their vendor. For those users (typically system administrators) who have a need to build MIT Kerberos from source code, we have some resources available on this wiki.<br />
<br />
* [[Building]] the MIT Kerberos software<br />
* [[Reporting bugs]]<br />
* [[Suggesting enhancements]]<br />
* More [[user resources]]<br />
<br />
== System administrators ==<br />
<br />
We also recommend that most system administrators use MIT Kerberos software packages from their operating system vendor if possible.<br />
<br />
* [[Building]] the MIT Kerberos software<br />
* [[Reporting bugs]]<br />
* [[Suggesting enhancements]]<br />
* More [[sysadmin resources]]<br />
<br />
== Developers ==<br />
<br />
Developers can include end users who have a need to customize the MIT Kerberos source code, or who would like to contribute patches for new features or for bug fixes.<br />
<br />
* [[Developer resources]]<br />
<br />
=== Contributing ===<br />
<br />
* [[How to contribute]] to the MIT Kerberos software<br />
* [[Fixing bugs]]<br />
* [[Suggesting enhancements]]<br />
* [[Contributing code]]<br />
<br />
=== Background information ===<br />
<br />
* [[:Category:Policies|Policies for development]]<br />
* [[:Category:Lore|Lore]]<br />
<br />
=== Code quality ===<br />
<br />
* [[Coding style]]<br />
* [[Test-driven development]]<br />
* [[Manual_Testing|Manual testing procedures]]<br />
<br />
=== Planning ===<br />
<br />
* Development [[roadmap]]<br />
* [[Projects]]<br />
<br />
=== Communication ===<br />
<br />
* [[Release_Meeting_Minutes|Release Meeting Minutes]]<br />
* [http://blog.kerberos.org/ Blog]<br />
<br />
== Additional information ==<br />
<br />
* [[K5Wiki:Todo|A todo list for work needing doing on this wiki]]<br />
* [[Application_Maintenance|Notes on maintenance of the krb5 telnet/rlogin/gssftp applications]]<br />
<br />
We look forward to your contributions to K5Wiki and MIT Kerberos.</div>Sbuckleyhttps://k5wiki.kerberos.org/wiki?title=Main_Page&diff=3000Main Page2009-11-21T14:05:50Z<p>Sbuckley: /* Releases */</p>
<hr />
<div>__NOTOC__<br />
'''K5Wiki''' is a wiki supporting the development of [[MIT Kerberos]], a reference implementation of [[wp:Kerberos (protocol)|the Kerberos network authentication protocol]]. MIT Kerberos is a project of the [http://www.kerberos.org/ MIT Kerberos Consortium].<br />
<br />
This wiki serves both as a place for coordination of development efforts on MIT Kerberos and as a means for potential contributors and other interested people to become more involved with MIT Kerberos development. This wiki does not focus on the needs for the average end user, but it may nevertheless contain information that is useful to advanced users, such as system administrators who wish to make customizations.<br />
<br />
What can this wiki do for you?<br />
* I have a [[Asking questions|question]]<br />
* I want to [[Writing applications|write Kerberos application software]]<br />
* I want to [[Reporting bugs|report bugs]]<br />
* I want to [[Fixing bugs|fix bugs]]<br />
* I want to [[Learning about the code|learn more about the code]]<br />
* I have [[Suggesting enhancements|ideas for enhancements]]<br />
* I want to [[Contributing code|contribute code]]<br />
* I want to [[K5Wiki:Todo|help to improve this wiki]]<br />
<br />
== Releases ==<br />
<br />
The current release is [http://web.mit.edu/kerberos/krb5-1.7 krb5-1.7]. <br />
<br />
[[Release_1.7 Feature Specifications]]<br />
<br />
Additional information on future releases:<br />
<br />
* Development [[roadmap]]<br />
* [[Release 1.8]]<br />
<br />
== Users ==<br />
<br />
We recommend that end users use MIT Kerberos software packages built by their operating system vendor if possible, and use support resources provided by their site or by their vendor. For those users (typically system administrators) who have a need to build MIT Kerberos from source code, we have some resources available on this wiki.<br />
<br />
* [[Building]] the MIT Kerberos software<br />
* [[Reporting bugs]]<br />
* [[Suggesting enhancements]]<br />
* More [[user resources]]<br />
<br />
== System administrators ==<br />
<br />
We also recommend that most system administrators use MIT Kerberos software packages from their operating system vendor if possible.<br />
<br />
* [[Building]] the MIT Kerberos software<br />
* [[Reporting bugs]]<br />
* [[Suggesting enhancements]]<br />
* More [[sysadmin resources]]<br />
<br />
== Developers ==<br />
<br />
Developers can include end users who have a need to customize the MIT Kerberos source code, or who would like to contribute patches for new features or for bug fixes.<br />
<br />
* [[Developer resources]]<br />
<br />
=== Contributing ===<br />
<br />
* [[How to contribute]] to the MIT Kerberos software<br />
* [[Fixing bugs]]<br />
* [[Suggesting enhancements]]<br />
* [[Contributing code]]<br />
<br />
=== Background information ===<br />
<br />
* [[:Category:Policies|Policies for development]]<br />
* [[:Category:Lore|Lore]]<br />
<br />
=== Code quality ===<br />
<br />
* [[Coding style]]<br />
* [[Test-driven development]]<br />
* [[Manual_Testing|Manual testing procedures]]<br />
<br />
=== Planning ===<br />
<br />
* Development [[roadmap]]<br />
* [[Projects]]<br />
<br />
=== Communication ===<br />
<br />
* [[Release_Meeting_Minutes|Release Meeting Minutes]]<br />
* [http://blog.kerberos.org/ Blog]<br />
<br />
== Additional information ==<br />
<br />
* [[K5Wiki:Todo|A todo list for work needing doing on this wiki]]<br />
* [[Application_Maintenance|Notes on maintenance of the krb5 telnet/rlogin/gssftp applications]]<br />
<br />
We look forward to your contributions to K5Wiki and MIT Kerberos.</div>Sbuckleyhttps://k5wiki.kerberos.org/wiki?title=Main_Page&diff=2999Main Page2009-11-21T14:04:19Z<p>Sbuckley: /* Releases */</p>
<hr />
<div>__NOTOC__<br />
'''K5Wiki''' is a wiki supporting the development of [[MIT Kerberos]], a reference implementation of [[wp:Kerberos (protocol)|the Kerberos network authentication protocol]]. MIT Kerberos is a project of the [http://www.kerberos.org/ MIT Kerberos Consortium].<br />
<br />
This wiki serves both as a place for coordination of development efforts on MIT Kerberos and as a means for potential contributors and other interested people to become more involved with MIT Kerberos development. This wiki does not focus on the needs for the average end user, but it may nevertheless contain information that is useful to advanced users, such as system administrators who wish to make customizations.<br />
<br />
What can this wiki do for you?<br />
* I have a [[Asking questions|question]]<br />
* I want to [[Writing applications|write Kerberos application software]]<br />
* I want to [[Reporting bugs|report bugs]]<br />
* I want to [[Fixing bugs|fix bugs]]<br />
* I want to [[Learning about the code|learn more about the code]]<br />
* I have [[Suggesting enhancements|ideas for enhancements]]<br />
* I want to [[Contributing code|contribute code]]<br />
* I want to [[K5Wiki:Todo|help to improve this wiki]]<br />
<br />
== Releases ==<br />
<br />
The current release is [http://web.mit.edu/kerberos/krb5-1.7 krb5-1.7]. <br />
<br />
[[Release_1.7]]<br />
<br />
Additional information on future releases:<br />
<br />
* Development [[roadmap]]<br />
* [[Release 1.8]]<br />
<br />
== Users ==<br />
<br />
We recommend that end users use MIT Kerberos software packages built by their operating system vendor if possible, and use support resources provided by their site or by their vendor. For those users (typically system administrators) who have a need to build MIT Kerberos from source code, we have some resources available on this wiki.<br />
<br />
* [[Building]] the MIT Kerberos software<br />
* [[Reporting bugs]]<br />
* [[Suggesting enhancements]]<br />
* More [[user resources]]<br />
<br />
== System administrators ==<br />
<br />
We also recommend that most system administrators use MIT Kerberos software packages from their operating system vendor if possible.<br />
<br />
* [[Building]] the MIT Kerberos software<br />
* [[Reporting bugs]]<br />
* [[Suggesting enhancements]]<br />
* More [[sysadmin resources]]<br />
<br />
== Developers ==<br />
<br />
Developers can include end users who have a need to customize the MIT Kerberos source code, or who would like to contribute patches for new features or for bug fixes.<br />
<br />
* [[Developer resources]]<br />
<br />
=== Contributing ===<br />
<br />
* [[How to contribute]] to the MIT Kerberos software<br />
* [[Fixing bugs]]<br />
* [[Suggesting enhancements]]<br />
* [[Contributing code]]<br />
<br />
=== Background information ===<br />
<br />
* [[:Category:Policies|Policies for development]]<br />
* [[:Category:Lore|Lore]]<br />
<br />
=== Code quality ===<br />
<br />
* [[Coding style]]<br />
* [[Test-driven development]]<br />
* [[Manual_Testing|Manual testing procedures]]<br />
<br />
=== Planning ===<br />
<br />
* Development [[roadmap]]<br />
* [[Projects]]<br />
<br />
=== Communication ===<br />
<br />
* [[Release_Meeting_Minutes|Release Meeting Minutes]]<br />
* [http://blog.kerberos.org/ Blog]<br />
<br />
== Additional information ==<br />
<br />
* [[K5Wiki:Todo|A todo list for work needing doing on this wiki]]<br />
* [[Application_Maintenance|Notes on maintenance of the krb5 telnet/rlogin/gssftp applications]]<br />
<br />
We look forward to your contributions to K5Wiki and MIT Kerberos.</div>Sbuckleyhttps://k5wiki.kerberos.org/wiki?title=Release_1.7&diff=2998Release 1.72009-11-21T14:03:03Z<p>Sbuckley: </p>
<hr />
<div>'''[http://web.mit.edu/kerberos/krb5-1.7/ How to Get MIT Kerberos Release 1.7]'''<br />
<br />
<br />
'''Release 1.7 Feature Specifications'''<br />
<br />
[[Projects/AEAD encryption API]]<br />
The Microsoft SSPI provides an interface for in-place encryption of messages (see MS-KILE section 3.4.5.4ff). This interface also permits additional data to be included in the checksum generated to protect integrity. Such a facility is called authenticated encryption with additional data (AEAD). The SSPI works at the GSS-API layer, rather than the raw Kerberos layer.<br />
<br />
This project proposes to extend the raw Kerberos cryptographic API (krb5_c_*) in order to make it possible to implement these SSPI facilities in an extension to the GSS-API. The ultimate consumer of these applications is typically DCE-style RPC, although the facilities could be used by other applications.<br />
<br />
[[Projects/Aliases]]<br />
This project proposes to add two features. The first is support for Unicode principal names and case insensitive principal search. The goal of this project is to get behavior more similar to Microsoft and to search for principals in a manner that supports international use somewhat better. This includes case insensitive search and support for ignoring accents in search.<br />
<br />
Protocol extensions for general internationalization or character set conversion are specifically out of scope. The second feature is generalized support for name canonicalization and server principal aliases. <br />
<br />
[[Projects/FAST]]<br />
FAST is a pre-authentication framework for Kerberos. It includes a mechanism for tunneling pre-authentication exchanges using armoured KDC messages. FAST provides increased resistance to passive password guessing attacks. <br />
<br />
[[Projects/GSSAPI DCE]]<br />
The GSS-API DCE project proposes to add functionality found in SSPI to MIT Kerberos; this functionality includes support for AEAD and support sufficient to implement DCE RPC on top of MIT Kerberos. This project depends on and is a companion to Projects/AEAD encryption API. <br />
<br />
[[Projects/Master Key Migration]]<br />
This project will provide the ability to add a new master key (with an enctype differing from the current master key) to the master key principal and stash file and then migrate the encryption of existing principals long term keys to use the new master key. In addition deletion of master keys will be provided. <br />
<br />
[[Projects/Masterkey Keytab Stash]]<br />
The point of this small project is to change the format of the master key stash file to that of a keytab type file. This will allow the master key's KVNO to be stored along with its enctype and key data which in turn will enable an efficient implementation of master key updating. <br />
<br />
[[Projects/PAC and principal APIs]]<br />
Microsoft Windows uses a data structure called the PAC in order to convey authorization information. See the expired draft-brezak-win2k-krb-authz-00 for documentation. The PAC is logically a set of type-length-value elements. That is, it is a collection of typed data items, and lengths are associated with each type. Typically the data items are NDR encoded. This API provides facilities to create and sign a PAC and to extract a given typed buffer from a PAC. NDR encoders and decoders are not provided.<br />
<br />
<br />
[[Projects/RFC 3244]]<br />
The RFC 3244 project adds support for the Microsoft set password protocol server to MIT Kerberos. In addition, it adds support for both that protocol and the traditional kpasswd protocol over TCP. This protocol is added for better compatibility with Microsoft Windows. <br />
<br />
[[Projects/RFC 4537]]<br />
RFC 4537 defines an encryption type negotiation extension to Kerberos. This option allows clients and servers to use a stronger or faster bulk encryption mechanism even if the KDC does not support it. The client indicates a set of supported encryption types in the ap-req. If the server chooses one of these encryption types then it proposes a subkey in the ap-rep with an encryption type different than that selected by the client.<br />
<br />
[[Projects/Remove krb4]]<br />
The goal of this project is to remove most of the krb4 code from the Kerberos source code base.<br />
<br />
[[Projects/VerifyAuthData]]<br />
The goals of this project are to:<br />
<br />
* change the behaviour of krb5_rd_req() to always verify known authorization data elements<br />
* provide an attribute-based GSS interface for inquiry and submission of authorization information ([http://www.ietf.org/id/draft-ietf-kitten-gssapi-naming-exts-05.txt draft-ietf-kitten-gssapi-naming-exts])<br />
* provide an attribute-based plugin interface for verification and serialization of authorization information<br />
* encourage the use of positive authorization data by providing sample KDC and application plugins<br />
<br />
[[Projects/domain realm referrals]]<br />
Eliminates the need for the domain_realm mapping table on the client side, in the common case, by implementing minimal referral (draft-ietf-krb-wg-kerberos-referrals) support in the KDC and providing the mapping information to clients through that protocol. Modern client code (MIT, Heimdal, and Microsoft, at least) should contain all the support needed to take advantage of this.<br />
<br />
[[Projects/replay cache collision avoidance]]<br />
In order to avoid false positives we require that the replay cache data structure store sufficient data to be able to distinguish between two authenticators while at the same time maintaining compatibility with existing deployments.</div>Sbuckleyhttps://k5wiki.kerberos.org/wiki?title=Release_1.7&diff=2997Release 1.72009-11-21T14:02:43Z<p>Sbuckley: </p>
<hr />
<div>'''[http://web.mit.edu/kerberos/krb5-1.7/ How to Get MIT Kerberos Release 1.7]'''<br />
'''<br />
<br />
Release 1.7 Feature Specifications'''<br />
<br />
[[Projects/AEAD encryption API]]<br />
The Microsoft SSPI provides an interface for in-place encryption of messages (see MS-KILE section 3.4.5.4ff). This interface also permits additional data to be included in the checksum generated to protect integrity. Such a facility is called authenticated encryption with additional data (AEAD). The SSPI works at the GSS-API layer, rather than the raw Kerberos layer.<br />
<br />
This project proposes to extend the raw Kerberos cryptographic API (krb5_c_*) in order to make it possible to implement these SSPI facilities in an extension to the GSS-API. The ultimate consumer of these applications is typically DCE-style RPC, although the facilities could be used by other applications.<br />
<br />
[[Projects/Aliases]]<br />
This project proposes to add two features. The first is support for Unicode principal names and case insensitive principal search. The goal of this project is to get behavior more similar to Microsoft and to search for principals in a manner that supports international use somewhat better. This includes case insensitive search and support for ignoring accents in search.<br />
<br />
Protocol extensions for general internationalization or character set conversion are specifically out of scope. The second feature is generalized support for name canonicalization and server principal aliases. <br />
<br />
[[Projects/FAST]]<br />
FAST is a pre-authentication framework for Kerberos. It includes a mechanism for tunneling pre-authentication exchanges using armoured KDC messages. FAST provides increased resistance to passive password guessing attacks. <br />
<br />
[[Projects/GSSAPI DCE]]<br />
The GSS-API DCE project proposes to add functionality found in SSPI to MIT Kerberos; this functionality includes support for AEAD and support sufficient to implement DCE RPC on top of MIT Kerberos. This project depends on and is a companion to Projects/AEAD encryption API. <br />
<br />
[[Projects/Master Key Migration]]<br />
This project will provide the ability to add a new master key (with an enctype differing from the current master key) to the master key principal and stash file and then migrate the encryption of existing principals long term keys to use the new master key. In addition deletion of master keys will be provided. <br />
<br />
[[Projects/Masterkey Keytab Stash]]<br />
The point of this small project is to change the format of the master key stash file to that of a keytab type file. This will allow the master key's KVNO to be stored along with its enctype and key data which in turn will enable an efficient implementation of master key updating. <br />
<br />
[[Projects/PAC and principal APIs]]<br />
Microsoft Windows uses a data structure called the PAC in order to convey authorization information. See the expired draft-brezak-win2k-krb-authz-00 for documentation. The PAC is logically a set of type-length-value elements. That is, it is a collection of typed data items, and lengths are associated with each type. Typically the data items are NDR encoded. This API provides facilities to create and sign a PAC and to extract a given typed buffer from a PAC. NDR encoders and decoders are not provided.<br />
<br />
<br />
[[Projects/RFC 3244]]<br />
The RFC 3244 project adds support for the Microsoft set password protocol server to MIT Kerberos. In addition, it adds support for both that protocol and the traditional kpasswd protocol over TCP. This protocol is added for better compatibility with Microsoft Windows. <br />
<br />
[[Projects/RFC 4537]]<br />
RFC 4537 defines an encryption type negotiation extension to Kerberos. This option allows clients and servers to use a stronger or faster bulk encryption mechanism even if the KDC does not support it. The client indicates a set of supported encryption types in the ap-req. If the server chooses one of these encryption types then it proposes a subkey in the ap-rep with an encryption type different than that selected by the client.<br />
<br />
[[Projects/Remove krb4]]<br />
The goal of this project is to remove most of the krb4 code from the Kerberos source code base.<br />
<br />
[[Projects/VerifyAuthData]]<br />
The goals of this project are to:<br />
<br />
* change the behaviour of krb5_rd_req() to always verify known authorization data elements<br />
* provide an attribute-based GSS interface for inquiry and submission of authorization information ([http://www.ietf.org/id/draft-ietf-kitten-gssapi-naming-exts-05.txt draft-ietf-kitten-gssapi-naming-exts])<br />
* provide an attribute-based plugin interface for verification and serialization of authorization information<br />
* encourage the use of positive authorization data by providing sample KDC and application plugins<br />
<br />
[[Projects/domain realm referrals]]<br />
Eliminates the need for the domain_realm mapping table on the client side, in the common case, by implementing minimal referral (draft-ietf-krb-wg-kerberos-referrals) support in the KDC and providing the mapping information to clients through that protocol. Modern client code (MIT, Heimdal, and Microsoft, at least) should contain all the support needed to take advantage of this.<br />
<br />
[[Projects/replay cache collision avoidance]]<br />
In order to avoid false positives we require that the replay cache data structure store sufficient data to be able to distinguish between two authenticators while at the same time maintaining compatibility with existing deployments.</div>Sbuckleyhttps://k5wiki.kerberos.org/wiki?title=Release_1.7&diff=2996Release 1.72009-11-21T14:02:29Z<p>Sbuckley: </p>
<hr />
<div>'''[http://web.mit.edu/kerberos/krb5-1.7/ How to Get MIT Kerberos Release 1.7]'''<br />
'''<br />
Release 1.7 Feature Specifications'''<br />
<br />
[[Projects/AEAD encryption API]]<br />
The Microsoft SSPI provides an interface for in-place encryption of messages (see MS-KILE section 3.4.5.4ff). This interface also permits additional data to be included in the checksum generated to protect integrity. Such a facility is called authenticated encryption with additional data (AEAD). The SSPI works at the GSS-API layer, rather than the raw Kerberos layer.<br />
<br />
This project proposes to extend the raw Kerberos cryptographic API (krb5_c_*) in order to make it possible to implement these SSPI facilities in an extension to the GSS-API. The ultimate consumer of these applications is typically DCE-style RPC, although the facilities could be used by other applications.<br />
<br />
[[Projects/Aliases]]<br />
This project proposes to add two features. The first is support for Unicode principal names and case insensitive principal search. The goal of this project is to get behavior more similar to Microsoft and to search for principals in a manner that supports international use somewhat better. This includes case insensitive search and support for ignoring accents in search.<br />
<br />
Protocol extensions for general internationalization or character set conversion are specifically out of scope. The second feature is generalized support for name canonicalization and server principal aliases. <br />
<br />
[[Projects/FAST]]<br />
FAST is a pre-authentication framework for Kerberos. It includes a mechanism for tunneling pre-authentication exchanges using armoured KDC messages. FAST provides increased resistance to passive password guessing attacks. <br />
<br />
[[Projects/GSSAPI DCE]]<br />
The GSS-API DCE project proposes to add functionality found in SSPI to MIT Kerberos; this functionality includes support for AEAD and support sufficient to implement DCE RPC on top of MIT Kerberos. This project depends on and is a companion to Projects/AEAD encryption API. <br />
<br />
[[Projects/Master Key Migration]]<br />
This project will provide the ability to add a new master key (with an enctype differing from the current master key) to the master key principal and stash file and then migrate the encryption of existing principals long term keys to use the new master key. In addition deletion of master keys will be provided. <br />
<br />
[[Projects/Masterkey Keytab Stash]]<br />
The point of this small project is to change the format of the master key stash file to that of a keytab type file. This will allow the master key's KVNO to be stored along with its enctype and key data which in turn will enable an efficient implementation of master key updating. <br />
<br />
[[Projects/PAC and principal APIs]]<br />
Microsoft Windows uses a data structure called the PAC in order to convey authorization information. See the expired draft-brezak-win2k-krb-authz-00 for documentation. The PAC is logically a set of type-length-value elements. That is, it is a collection of typed data items, and lengths are associated with each type. Typically the data items are NDR encoded. This API provides facilities to create and sign a PAC and to extract a given typed buffer from a PAC. NDR encoders and decoders are not provided.<br />
<br />
<br />
[[Projects/RFC 3244]]<br />
The RFC 3244 project adds support for the Microsoft set password protocol server to MIT Kerberos. In addition, it adds support for both that protocol and the traditional kpasswd protocol over TCP. This protocol is added for better compatibility with Microsoft Windows. <br />
<br />
[[Projects/RFC 4537]]<br />
RFC 4537 defines an encryption type negotiation extension to Kerberos. This option allows clients and servers to use a stronger or faster bulk encryption mechanism even if the KDC does not support it. The client indicates a set of supported encryption types in the ap-req. If the server chooses one of these encryption types then it proposes a subkey in the ap-rep with an encryption type different than that selected by the client.<br />
<br />
[[Projects/Remove krb4]]<br />
The goal of this project is to remove most of the krb4 code from the Kerberos source code base.<br />
<br />
[[Projects/VerifyAuthData]]<br />
The goals of this project are to:<br />
<br />
* change the behaviour of krb5_rd_req() to always verify known authorization data elements<br />
* provide an attribute-based GSS interface for inquiry and submission of authorization information ([http://www.ietf.org/id/draft-ietf-kitten-gssapi-naming-exts-05.txt draft-ietf-kitten-gssapi-naming-exts])<br />
* provide an attribute-based plugin interface for verification and serialization of authorization information<br />
* encourage the use of positive authorization data by providing sample KDC and application plugins<br />
<br />
[[Projects/domain realm referrals]]<br />
Eliminates the need for the domain_realm mapping table on the client side, in the common case, by implementing minimal referral (draft-ietf-krb-wg-kerberos-referrals) support in the KDC and providing the mapping information to clients through that protocol. Modern client code (MIT, Heimdal, and Microsoft, at least) should contain all the support needed to take advantage of this.<br />
<br />
[[Projects/replay cache collision avoidance]]<br />
In order to avoid false positives we require that the replay cache data structure store sufficient data to be able to distinguish between two authenticators while at the same time maintaining compatibility with existing deployments.</div>Sbuckleyhttps://k5wiki.kerberos.org/wiki?title=Release_1.7&diff=2995Release 1.72009-11-21T14:01:44Z<p>Sbuckley: </p>
<hr />
<div>'''[http://web.mit.edu/kerberos/krb5-1.7/ How to Get MIT Kerberos Release 1.7]'''<br />
<br />
[[Projects/AEAD encryption API]]<br />
The Microsoft SSPI provides an interface for in-place encryption of messages (see MS-KILE section 3.4.5.4ff). This interface also permits additional data to be included in the checksum generated to protect integrity. Such a facility is called authenticated encryption with additional data (AEAD). The SSPI works at the GSS-API layer, rather than the raw Kerberos layer.<br />
<br />
This project proposes to extend the raw Kerberos cryptographic API (krb5_c_*) in order to make it possible to implement these SSPI facilities in an extension to the GSS-API. The ultimate consumer of these applications is typically DCE-style RPC, although the facilities could be used by other applications.<br />
<br />
[[Projects/Aliases]]<br />
This project proposes to add two features. The first is support for Unicode principal names and case insensitive principal search. The goal of this project is to get behavior more similar to Microsoft and to search for principals in a manner that supports international use somewhat better. This includes case insensitive search and support for ignoring accents in search.<br />
<br />
Protocol extensions for general internationalization or character set conversion are specifically out of scope. The second feature is generalized support for name canonicalization and server principal aliases. <br />
<br />
[[Projects/FAST]]<br />
FAST is a pre-authentication framework for Kerberos. It includes a mechanism for tunneling pre-authentication exchanges using armoured KDC messages. FAST provides increased resistance to passive password guessing attacks. <br />
<br />
[[Projects/GSSAPI DCE]]<br />
The GSS-API DCE project proposes to add functionality found in SSPI to MIT Kerberos; this functionality includes support for AEAD and support sufficient to implement DCE RPC on top of MIT Kerberos. This project depends on and is a companion to Projects/AEAD encryption API. <br />
<br />
[[Projects/Master Key Migration]]<br />
This project will provide the ability to add a new master key (with an enctype differing from the current master key) to the master key principal and stash file and then migrate the encryption of existing principals long term keys to use the new master key. In addition deletion of master keys will be provided. <br />
<br />
[[Projects/Masterkey Keytab Stash]]<br />
The point of this small project is to change the format of the master key stash file to that of a keytab type file. This will allow the master key's KVNO to be stored along with its enctype and key data which in turn will enable an efficient implementation of master key updating. <br />
<br />
[[Projects/PAC and principal APIs]]<br />
Microsoft Windows uses a data structure called the PAC in order to convey authorization information. See the expired draft-brezak-win2k-krb-authz-00 for documentation. The PAC is logically a set of type-length-value elements. That is, it is a collection of typed data items, and lengths are associated with each type. Typically the data items are NDR encoded. This API provides facilities to create and sign a PAC and to extract a given typed buffer from a PAC. NDR encoders and decoders are not provided.<br />
<br />
<br />
[[Projects/RFC 3244]]<br />
The RFC 3244 project adds support for the Microsoft set password protocol server to MIT Kerberos. In addition, it adds support for both that protocol and the traditional kpasswd protocol over TCP. This protocol is added for better compatibility with Microsoft Windows. <br />
<br />
[[Projects/RFC 4537]]<br />
RFC 4537 defines an encryption type negotiation extension to Kerberos. This option allows clients and servers to use a stronger or faster bulk encryption mechanism even if the KDC does not support it. The client indicates a set of supported encryption types in the ap-req. If the server chooses one of these encryption types then it proposes a subkey in the ap-rep with an encryption type different than that selected by the client.<br />
<br />
[[Projects/Remove krb4]]<br />
The goal of this project is to remove most of the krb4 code from the Kerberos source code base.<br />
<br />
[[Projects/VerifyAuthData]]<br />
The goals of this project are to:<br />
<br />
* change the behaviour of krb5_rd_req() to always verify known authorization data elements<br />
* provide an attribute-based GSS interface for inquiry and submission of authorization information ([http://www.ietf.org/id/draft-ietf-kitten-gssapi-naming-exts-05.txt draft-ietf-kitten-gssapi-naming-exts])<br />
* provide an attribute-based plugin interface for verification and serialization of authorization information<br />
* encourage the use of positive authorization data by providing sample KDC and application plugins<br />
<br />
[[Projects/domain realm referrals]]<br />
Eliminates the need for the domain_realm mapping table on the client side, in the common case, by implementing minimal referral (draft-ietf-krb-wg-kerberos-referrals) support in the KDC and providing the mapping information to clients through that protocol. Modern client code (MIT, Heimdal, and Microsoft, at least) should contain all the support needed to take advantage of this.<br />
<br />
[[Projects/replay cache collision avoidance]]<br />
In order to avoid false positives we require that the replay cache data structure store sufficient data to be able to distinguish between two authenticators while at the same time maintaining compatibility with existing deployments.</div>Sbuckleyhttps://k5wiki.kerberos.org/wiki?title=Release_1.7&diff=2994Release 1.72009-11-21T14:01:26Z<p>Sbuckley: </p>
<hr />
<div>[http://web.mit.edu/kerberos/krb5-1.7/ link How to Get MIT Kerberos Release 1.7]<br />
<br />
[[Projects/AEAD encryption API]]<br />
The Microsoft SSPI provides an interface for in-place encryption of messages (see MS-KILE section 3.4.5.4ff). This interface also permits additional data to be included in the checksum generated to protect integrity. Such a facility is called authenticated encryption with additional data (AEAD). The SSPI works at the GSS-API layer, rather than the raw Kerberos layer.<br />
<br />
This project proposes to extend the raw Kerberos cryptographic API (krb5_c_*) in order to make it possible to implement these SSPI facilities in an extension to the GSS-API. The ultimate consumer of these applications is typically DCE-style RPC, although the facilities could be used by other applications.<br />
<br />
[[Projects/Aliases]]<br />
This project proposes to add two features. The first is support for Unicode principal names and case insensitive principal search. The goal of this project is to get behavior more similar to Microsoft and to search for principals in a manner that supports international use somewhat better. This includes case insensitive search and support for ignoring accents in search.<br />
<br />
Protocol extensions for general internationalization or character set conversion are specifically out of scope. The second feature is generalized support for name canonicalization and server principal aliases. <br />
<br />
[[Projects/FAST]]<br />
FAST is a pre-authentication framework for Kerberos. It includes a mechanism for tunneling pre-authentication exchanges using armoured KDC messages. FAST provides increased resistance to passive password guessing attacks. <br />
<br />
[[Projects/GSSAPI DCE]]<br />
The GSS-API DCE project proposes to add functionality found in SSPI to MIT Kerberos; this functionality includes support for AEAD and support sufficient to implement DCE RPC on top of MIT Kerberos. This project depends on and is a companion to Projects/AEAD encryption API. <br />
<br />
[[Projects/Master Key Migration]]<br />
This project will provide the ability to add a new master key (with an enctype differing from the current master key) to the master key principal and stash file and then migrate the encryption of existing principals long term keys to use the new master key. In addition deletion of master keys will be provided. <br />
<br />
[[Projects/Masterkey Keytab Stash]]<br />
The point of this small project is to change the format of the master key stash file to that of a keytab type file. This will allow the master key's KVNO to be stored along with its enctype and key data which in turn will enable an efficient implementation of master key updating. <br />
<br />
[[Projects/PAC and principal APIs]]<br />
Microsoft Windows uses a data structure called the PAC in order to convey authorization information. See the expired draft-brezak-win2k-krb-authz-00 for documentation. The PAC is logically a set of type-length-value elements. That is, it is a collection of typed data items, and lengths are associated with each type. Typically the data items are NDR encoded. This API provides facilities to create and sign a PAC and to extract a given typed buffer from a PAC. NDR encoders and decoders are not provided.<br />
<br />
<br />
[[Projects/RFC 3244]]<br />
The RFC 3244 project adds support for the Microsoft set password protocol server to MIT Kerberos. In addition, it adds support for both that protocol and the traditional kpasswd protocol over TCP. This protocol is added for better compatibility with Microsoft Windows. <br />
<br />
[[Projects/RFC 4537]]<br />
RFC 4537 defines an encryption type negotiation extension to Kerberos. This option allows clients and servers to use a stronger or faster bulk encryption mechanism even if the KDC does not support it. The client indicates a set of supported encryption types in the ap-req. If the server chooses one of these encryption types then it proposes a subkey in the ap-rep with an encryption type different than that selected by the client.<br />
<br />
[[Projects/Remove krb4]]<br />
The goal of this project is to remove most of the krb4 code from the Kerberos source code base.<br />
<br />
[[Projects/VerifyAuthData]]<br />
The goals of this project are to:<br />
<br />
* change the behaviour of krb5_rd_req() to always verify known authorization data elements<br />
* provide an attribute-based GSS interface for inquiry and submission of authorization information ([http://www.ietf.org/id/draft-ietf-kitten-gssapi-naming-exts-05.txt draft-ietf-kitten-gssapi-naming-exts])<br />
* provide an attribute-based plugin interface for verification and serialization of authorization information<br />
* encourage the use of positive authorization data by providing sample KDC and application plugins<br />
<br />
[[Projects/domain realm referrals]]<br />
Eliminates the need for the domain_realm mapping table on the client side, in the common case, by implementing minimal referral (draft-ietf-krb-wg-kerberos-referrals) support in the KDC and providing the mapping information to clients through that protocol. Modern client code (MIT, Heimdal, and Microsoft, at least) should contain all the support needed to take advantage of this.<br />
<br />
[[Projects/replay cache collision avoidance]]<br />
In order to avoid false positives we require that the replay cache data structure store sufficient data to be able to distinguish between two authenticators while at the same time maintaining compatibility with existing deployments.</div>Sbuckleyhttps://k5wiki.kerberos.org/wiki?title=Release_1.7&diff=2993Release 1.72009-11-21T13:59:23Z<p>Sbuckley: </p>
<hr />
<div> [[Projects/AEAD encryption API]]<br />
The Microsoft SSPI provides an interface for in-place encryption of messages (see MS-KILE section 3.4.5.4ff). This interface also permits additional data to be included in the checksum generated to protect integrity. Such a facility is called authenticated encryption with additional data (AEAD). The SSPI works at the GSS-API layer, rather than the raw Kerberos layer.<br />
<br />
This project proposes to extend the raw Kerberos cryptographic API (krb5_c_*) in order to make it possible to implement these SSPI facilities in an extension to the GSS-API. The ultimate consumer of these applications is typically DCE-style RPC, although the facilities could be used by other applications.<br />
<br />
[[Projects/Aliases]]<br />
This project proposes to add two features. The first is support for Unicode principal names and case insensitive principal search. The goal of this project is to get behavior more similar to Microsoft and to search for principals in a manner that supports international use somewhat better. This includes case insensitive search and support for ignoring accents in search.<br />
<br />
Protocol extensions for general internationalization or character set conversion are specifically out of scope. The second feature is generalized support for name canonicalization and server principal aliases. <br />
<br />
[[Projects/FAST]]<br />
FAST is a pre-authentication framework for Kerberos. It includes a mechanism for tunneling pre-authentication exchanges using armoured KDC messages. FAST provides increased resistance to passive password guessing attacks. <br />
<br />
[[Projects/GSSAPI DCE]]<br />
The GSS-API DCE project proposes to add functionality found in SSPI to MIT Kerberos; this functionality includes support for AEAD and support sufficient to implement DCE RPC on top of MIT Kerberos. This project depends on and is a companion to Projects/AEAD encryption API. <br />
<br />
[[Projects/Master Key Migration]]<br />
This project will provide the ability to add a new master key (with an enctype differing from the current master key) to the master key principal and stash file and then migrate the encryption of existing principals long term keys to use the new master key. In addition deletion of master keys will be provided. <br />
<br />
[[Projects/Masterkey Keytab Stash]]<br />
The point of this small project is to change the format of the master key stash file to that of a keytab type file. This will allow the master key's KVNO to be stored along with its enctype and key data which in turn will enable an efficient implementation of master key updating. <br />
<br />
[[Projects/PAC and principal APIs]]<br />
Microsoft Windows uses a data structure called the PAC in order to convey authorization information. See the expired draft-brezak-win2k-krb-authz-00 for documentation. The PAC is logically a set of type-length-value elements. That is, it is a collection of typed data items, and lengths are associated with each type. Typically the data items are NDR encoded. This API provides facilities to create and sign a PAC and to extract a given typed buffer from a PAC. NDR encoders and decoders are not provided.<br />
<br />
<br />
[[Projects/RFC 3244]]<br />
The RFC 3244 project adds support for the Microsoft set password protocol server to MIT Kerberos. In addition, it adds support for both that protocol and the traditional kpasswd protocol over TCP. This protocol is added for better compatibility with Microsoft Windows. <br />
<br />
[[Projects/RFC 4537]]<br />
RFC 4537 defines an encryption type negotiation extension to Kerberos. This option allows clients and servers to use a stronger or faster bulk encryption mechanism even if the KDC does not support it. The client indicates a set of supported encryption types in the ap-req. If the server chooses one of these encryption types then it proposes a subkey in the ap-rep with an encryption type different than that selected by the client.<br />
<br />
[[Projects/Remove krb4]]<br />
The goal of this project is to remove most of the krb4 code from the Kerberos source code base.<br />
<br />
[[Projects/VerifyAuthData]]<br />
The goals of this project are to:<br />
<br />
* change the behaviour of krb5_rd_req() to always verify known authorization data elements<br />
* provide an attribute-based GSS interface for inquiry and submission of authorization information ([http://www.ietf.org/id/draft-ietf-kitten-gssapi-naming-exts-05.txt draft-ietf-kitten-gssapi-naming-exts])<br />
* provide an attribute-based plugin interface for verification and serialization of authorization information<br />
* encourage the use of positive authorization data by providing sample KDC and application plugins<br />
<br />
[[Projects/domain realm referrals]]<br />
Eliminates the need for the domain_realm mapping table on the client side, in the common case, by implementing minimal referral (draft-ietf-krb-wg-kerberos-referrals) support in the KDC and providing the mapping information to clients through that protocol. Modern client code (MIT, Heimdal, and Microsoft, at least) should contain all the support needed to take advantage of this.<br />
<br />
[[Projects/replay cache collision avoidance]]<br />
In order to avoid false positives we require that the replay cache data structure store sufficient data to be able to distinguish between two authenticators while at the same time maintaining compatibility with existing deployments.</div>Sbuckleyhttps://k5wiki.kerberos.org/wiki?title=Release_1.7&diff=2992Release 1.72009-11-21T13:59:08Z<p>Sbuckley: </p>
<hr />
<div> [[Projects/AEAD encryption API]]<br />
<br />
<br />
The Microsoft SSPI provides an interface for in-place encryption of messages (see MS-KILE section 3.4.5.4ff). This interface also permits additional data to be included in the checksum generated to protect integrity. Such a facility is called authenticated encryption with additional data (AEAD). The SSPI works at the GSS-API layer, rather than the raw Kerberos layer.<br />
<br />
This project proposes to extend the raw Kerberos cryptographic API (krb5_c_*) in order to make it possible to implement these SSPI facilities in an extension to the GSS-API. The ultimate consumer of these applications is typically DCE-style RPC, although the facilities could be used by other applications.<br />
<br />
[[Projects/Aliases]]<br />
This project proposes to add two features. The first is support for Unicode principal names and case insensitive principal search. The goal of this project is to get behavior more similar to Microsoft and to search for principals in a manner that supports international use somewhat better. This includes case insensitive search and support for ignoring accents in search.<br />
<br />
Protocol extensions for general internationalization or character set conversion are specifically out of scope. The second feature is generalized support for name canonicalization and server principal aliases. <br />
<br />
[[Projects/FAST]]<br />
FAST is a pre-authentication framework for Kerberos. It includes a mechanism for tunneling pre-authentication exchanges using armoured KDC messages. FAST provides increased resistance to passive password guessing attacks. <br />
<br />
[[Projects/GSSAPI DCE]]<br />
The GSS-API DCE project proposes to add functionality found in SSPI to MIT Kerberos; this functionality includes support for AEAD and support sufficient to implement DCE RPC on top of MIT Kerberos. This project depends on and is a companion to Projects/AEAD encryption API. <br />
<br />
[[Projects/Master Key Migration]]<br />
This project will provide the ability to add a new master key (with an enctype differing from the current master key) to the master key principal and stash file and then migrate the encryption of existing principals long term keys to use the new master key. In addition deletion of master keys will be provided. <br />
<br />
[[Projects/Masterkey Keytab Stash]]<br />
The point of this small project is to change the format of the master key stash file to that of a keytab type file. This will allow the master key's KVNO to be stored along with its enctype and key data which in turn will enable an efficient implementation of master key updating. <br />
<br />
[[Projects/PAC and principal APIs]]<br />
Microsoft Windows uses a data structure called the PAC in order to convey authorization information. See the expired draft-brezak-win2k-krb-authz-00 for documentation. The PAC is logically a set of type-length-value elements. That is, it is a collection of typed data items, and lengths are associated with each type. Typically the data items are NDR encoded. This API provides facilities to create and sign a PAC and to extract a given typed buffer from a PAC. NDR encoders and decoders are not provided.<br />
<br />
<br />
[[Projects/RFC 3244]]<br />
The RFC 3244 project adds support for the Microsoft set password protocol server to MIT Kerberos. In addition, it adds support for both that protocol and the traditional kpasswd protocol over TCP. This protocol is added for better compatibility with Microsoft Windows. <br />
<br />
[[Projects/RFC 4537]]<br />
RFC 4537 defines an encryption type negotiation extension to Kerberos. This option allows clients and servers to use a stronger or faster bulk encryption mechanism even if the KDC does not support it. The client indicates a set of supported encryption types in the ap-req. If the server chooses one of these encryption types then it proposes a subkey in the ap-rep with an encryption type different than that selected by the client.<br />
<br />
[[Projects/Remove krb4]]<br />
The goal of this project is to remove most of the krb4 code from the Kerberos source code base.<br />
<br />
[[Projects/VerifyAuthData]]<br />
The goals of this project are to:<br />
<br />
* change the behaviour of krb5_rd_req() to always verify known authorization data elements<br />
* provide an attribute-based GSS interface for inquiry and submission of authorization information ([http://www.ietf.org/id/draft-ietf-kitten-gssapi-naming-exts-05.txt draft-ietf-kitten-gssapi-naming-exts])<br />
* provide an attribute-based plugin interface for verification and serialization of authorization information<br />
* encourage the use of positive authorization data by providing sample KDC and application plugins<br />
<br />
[[Projects/domain realm referrals]]<br />
Eliminates the need for the domain_realm mapping table on the client side, in the common case, by implementing minimal referral (draft-ietf-krb-wg-kerberos-referrals) support in the KDC and providing the mapping information to clients through that protocol. Modern client code (MIT, Heimdal, and Microsoft, at least) should contain all the support needed to take advantage of this.<br />
<br />
[[Projects/replay cache collision avoidance]]<br />
In order to avoid false positives we require that the replay cache data structure store sufficient data to be able to distinguish between two authenticators while at the same time maintaining compatibility with existing deployments.</div>Sbuckleyhttps://k5wiki.kerberos.org/wiki?title=Release_1.7&diff=2991Release 1.72009-11-21T13:57:43Z<p>Sbuckley: </p>
<hr />
<div> [[Projects/AEAD encryption API]]<br />
<br />
<br />
The Microsoft SSPI provides an interface for in-place encryption of messages (see MS-KILE section 3.4.5.4ff). This interface also permits additional data to be included in the checksum generated to protect integrity. Such a facility is called authenticated encryption with additional data (AEAD). The SSPI works at the GSS-API layer, rather than the raw Kerberos layer.<br />
<br />
This project proposes to extend the raw Kerberos cryptographic API (krb5_c_*) in order to make it possible to implement these SSPI facilities in an extension to the GSS-API. The ultimate consumer of these applications is typically DCE-style RPC, although the facilities could be used by other applications.<br />
<br />
[[Projects/Aliases]]<br />
This project proposes to add two features. The first is support for Unicode principal names and case insensitive principal search. The goal of this project is to get behavior more similar to Microsoft and to search for principals in a manner that supports international use somewhat better. This includes case insensitive search and support for ignoring accents in search.<br />
<br />
Protocol extensions for general internationalization or character set conversion are specifically out of scope. The second feature is generalized support for name canonicalization and server principal aliases. <br />
<br />
[[Projects/FAST]]<br />
FAST is a pre-authentication framework for Kerberos. It includes a mechanism for tunneling pre-authentication exchanges using armoured KDC messages. FAST provides increased resistance to passive password guessing attacks. <br />
<br />
[[Projects/GSSAPI DCE]]<br />
The GSS-API DCE project proposes to add functionality found in SSPI to MIT Kerberos; this functionality includes support for AEAD and support sufficient to implement DCE RPC on top of MIT Kerberos. This project depends on and is a companion to Projects/AEAD encryption API. <br />
<br />
[[Projects/Master Key Migration]]<br />
This project will provide the ability to add a new master key (with an enctype differing from the current master key) to the master key principal and stash file and then migrate the encryption of existing principals long term keys to use the new master key. In addition deletion of master keys will be provided. <br />
<br />
[[Projects/Masterkey Keytab Stash]]<br />
The point of this small project is to change the format of the master key stash file to that of a keytab type file. This will allow the master key's KVNO to be stored along with its enctype and key data which in turn will enable an efficient implementation of master key updating. <br />
<br />
[[Projects/PAC and principal APIs]]<br />
Microsoft Windows uses a data structure called the PAC in order to convey authorization information. See the expired draft-brezak-win2k-krb-authz-00 for documentation. The PAC is logically a set of type-length-value elements. That is, it is a collection of typed data items, and lengths are associated with each type. Typically the data items are NDR encoded. This API provides facilities to create and sign a PAC and to extract a given typed buffer from a PAC. NDR encoders and decoders are not provided.<br />
<br />
<br />
[[Projects/RFC 3244]]<br />
The RFC 3244 project adds support for the Microsoft set password protocol server to MIT Kerberos. In addition, it adds support for both that protocol and the traditional kpasswd protocol over TCP. This protocol is added for better compatibility with Microsoft Windows. <br />
<br />
[[Projects/RFC 4537]]<br />
RFC 4537 defines an encryption type negotiation extension to Kerberos. This option allows clients and servers to use a stronger or faster bulk encryption mechanism even if the KDC does not support it. The client indicates a set of supported encryption types in the ap-req. If the server chooses one of these encryption types then it proposes a subkey in the ap-rep with an encryption type different than that selected by the client.<br />
<br />
[[Projects/Remove krb4]]<br />
The goal of this project is to remove most of the krb4 code from the Kerberos source code base.<br />
<br />
[[Projects/VerifyAuthData]]<br />
The goals of this project are to:<br />
<br />
* change the behaviour of krb5_rd_req() to always verify known authorization data elements<br />
* provide an attribute-based GSS interface for inquiry and submission of authorization information ([http://www.ietf.org/id/draft-ietf-kitten-gssapi-naming-exts-05.txt draft-ietf-kitten-gssapi-naming-exts])<br />
* provide an attribute-based plugin interface for verification and serialization of authorization information<br />
* encourage the use of positive authorization data by providing sample KDC and application plugins<br />
<br />
[[Projects/domain realm referrals]]<br />
[[Projects/replay cache collision avoidance]]</div>Sbuckleyhttps://k5wiki.kerberos.org/wiki?title=Release_1.7&diff=2990Release 1.72009-11-21T13:53:44Z<p>Sbuckley: </p>
<hr />
<div> [[Projects/AEAD encryption API]]<br />
<br />
<br />
The Microsoft SSPI provides an interface for in-place encryption of messages (see MS-KILE section 3.4.5.4ff). This interface also permits additional data to be included in the checksum generated to protect integrity. Such a facility is called authenticated encryption with additional data (AEAD). The SSPI works at the GSS-API layer, rather than the raw Kerberos layer.<br />
<br />
This project proposes to extend the raw Kerberos cryptographic API (krb5_c_*) in order to make it possible to implement these SSPI facilities in an extension to the GSS-API. The ultimate consumer of these applications is typically DCE-style RPC, although the facilities could be used by other applications.<br />
<br />
[[Projects/Aliases]]<br />
This project proposes to add two features. The first is support for Unicode principal names and case insensitive principal search. The goal of this project is to get behavior more similar to Microsoft and to search for principals in a manner that supports international use somewhat better. This includes case insensitive search and support for ignoring accents in search.<br />
<br />
Protocol extensions for general internationalization or character set conversion are specifically out of scope. The second feature is generalized support for name canonicalization and server principal aliases. <br />
<br />
[[Projects/FAST]]<br />
FAST is a pre-authentication framework for Kerberos. It includes a mechanism for tunneling pre-authentication exchanges using armoured KDC messages. FAST provides increased resistance to passive password guessing attacks. <br />
<br />
[[Projects/GSSAPI DCE]]<br />
The GSS-API DCE project proposes to add functionality found in SSPI to MIT Kerberos; this functionality includes support for AEAD and support sufficient to implement DCE RPC on top of MIT Kerberos. This project depends on and is a companion to Projects/AEAD encryption API. <br />
<br />
[[Projects/Master Key Migration]]<br />
[[Projects/Masterkey Keytab Stash]]<br />
[[Projects/PAC and principal APIs]]<br />
[[Projects/RFC 3244]]<br />
[[Projects/RFC 4537]]<br />
[[Projects/Remove krb4]]<br />
[[Projects/VerifyAuthData]]<br />
[[Projects/domain realm referrals]]<br />
[[Projects/replay cache collision avoidance]]</div>Sbuckleyhttps://k5wiki.kerberos.org/wiki?title=Release_1.7&diff=2989Release 1.72009-11-21T13:53:11Z<p>Sbuckley: </p>
<hr />
<div> [[Projects/AEAD encryption API]]<br />
<br />
<br />
The Microsoft SSPI provides an interface for in-place encryption of messages (see MS-KILE section 3.4.5.4ff). This interface also permits additional data to be included in the checksum generated to protect integrity. Such a facility is called authenticated encryption with additional data (AEAD). The SSPI works at the GSS-API layer, rather than the raw Kerberos layer.<br />
<br />
This project proposes to extend the raw Kerberos cryptographic API (krb5_c_*) in order to make it possible to implement these SSPI facilities in an extension to the GSS-API. The ultimate consumer of these applications is typically DCE-style RPC, although the facilities could be used by other applications.<br />
<br />
[[Projects/Aliases]]<br />
This project proposes to add two features. The first is support for Unicode principal names and case insensitive principal search. The goal of this project is to get behavior more similar to Microsoft and to search for principals in a manner that supports international use somewhat better. This includes case insensitive search and support for ignoring accents in search.<br />
<br />
Protocol extensions for general internationalization or character set conversion are specifically out of scope. The second feature is generalized support for name canonicalization and server principal aliases. <br />
<br />
[[Projects/FAST]]<br />
FAST is a pre-authentication framework for Kerberos. It includes a mechanism for tunneling pre-authentication exchanges using armoured KDC messages. FAST provides increased resistance to passive password guessing attacks. <br />
[[Projects/GSSAPI DCE]]<br />
[[Projects/Master Key Migration]]<br />
[[Projects/Masterkey Keytab Stash]]<br />
[[Projects/PAC and principal APIs]]<br />
[[Projects/RFC 3244]]<br />
[[Projects/RFC 4537]]<br />
[[Projects/Remove krb4]]<br />
[[Projects/VerifyAuthData]]<br />
[[Projects/domain realm referrals]]<br />
[[Projects/replay cache collision avoidance]]</div>Sbuckleyhttps://k5wiki.kerberos.org/wiki?title=Release_1.7&diff=2988Release 1.72009-11-21T13:52:41Z<p>Sbuckley: </p>
<hr />
<div> [[Projects/AEAD encryption API]]<br />
<br />
<br />
The Microsoft SSPI provides an interface for in-place encryption of messages (see MS-KILE section 3.4.5.4ff). This interface also permits additional data to be included in the checksum generated to protect integrity. Such a facility is called authenticated encryption with additional data (AEAD). The SSPI works at the GSS-API layer, rather than the raw Kerberos layer.<br />
<br />
This project proposes to extend the raw Kerberos cryptographic API (krb5_c_*) in order to make it possible to implement these SSPI facilities in an extension to the GSS-API. The ultimate consumer of these applications is typically DCE-style RPC, although the facilities could be used by other applications.<br />
<br />
[[Projects/Aliases]]<br />
This project proposes to add two features. The first is support for Unicode principal names and case insensitive principal search. The goal of this project is to get behavior more similar to Microsoft and to search for principals in a manner that supports international use somewhat better. This includes case insensitive search and support for ignoring accents in search.<br />
<br />
Protocol extensions for general internationalization or character set conversion are specifically out of scope. The second feature is generalized support for name canonicalization and server principal aliases. <br />
<br />
[[Projects/FAST]]<br />
[[Projects/GSSAPI DCE]]<br />
[[Projects/Master Key Migration]]<br />
[[Projects/Masterkey Keytab Stash]]<br />
[[Projects/PAC and principal APIs]]<br />
[[Projects/RFC 3244]]<br />
[[Projects/RFC 4537]]<br />
[[Projects/Remove krb4]]<br />
[[Projects/VerifyAuthData]]<br />
[[Projects/domain realm referrals]]<br />
[[Projects/replay cache collision avoidance]]</div>Sbuckleyhttps://k5wiki.kerberos.org/wiki?title=Release_1.7&diff=2987Release 1.72009-11-21T13:51:38Z<p>Sbuckley: </p>
<hr />
<div> [[Projects/AEAD encryption API]]<br />
<br />
This project proposes to add two features. The first is support for Unicode principal names and case insensitive principal search. The goal of this project is to get behavior more similar to Microsoft and to search for principals in a manner that supports international use somewhat better. This includes case insensitive search and support for ignoring accents in search.<br />
<br />
Protocol extensions for general internationalization or character set conversion are specifically out of scope. The second feature is generalized support for name canonicalization and server principal aliases. <br />
<br />
[[Projects/Aliases]]<br />
[[Projects/FAST]]<br />
[[Projects/GSSAPI DCE]]<br />
[[Projects/Master Key Migration]]<br />
[[Projects/Masterkey Keytab Stash]]<br />
[[Projects/PAC and principal APIs]]<br />
[[Projects/RFC 3244]]<br />
[[Projects/RFC 4537]]<br />
[[Projects/Remove krb4]]<br />
[[Projects/VerifyAuthData]]<br />
[[Projects/domain realm referrals]]<br />
[[Projects/replay cache collision avoidance]]</div>Sbuckleyhttps://k5wiki.kerberos.org/wiki?title=Release_1.7&diff=2986Release 1.72009-11-20T22:27:20Z<p>Sbuckley: </p>
<hr />
<div> [[Projects/AEAD encryption API]]<br />
[[Projects/Aliases]]<br />
[[Projects/FAST]]<br />
[[Projects/GSSAPI DCE]]<br />
[[Projects/Master Key Migration]]<br />
[[Projects/Masterkey Keytab Stash]]<br />
[[Projects/PAC and principal APIs]]<br />
[[Projects/RFC 3244]]<br />
[[Projects/RFC 4537]]<br />
[[Projects/Remove krb4]]<br />
[[Projects/VerifyAuthData]]<br />
[[Projects/domain realm referrals]]<br />
[[Projects/replay cache collision avoidance]]</div>Sbuckleyhttps://k5wiki.kerberos.org/wiki?title=Release_1.7&diff=2985Release 1.72009-11-20T22:26:54Z<p>Sbuckley: </p>
<hr />
<div> [[Projects/AEAD encryption API]]<br />
[[Projects/Aliases]]<br />
[[Projects/FAST]]<br />
[[Projects/GSSAPI DCE]]<br />
[[Projects/Master Key Migration]]<br />
[[Projects/Masterkey Keytab Stash]]<br />
[[ Projects/PAC and principal APIs]]<br />
[[Projects/RFC 3244]]<br />
[[ Projects/RFC 4537]]<br />
[[Projects/Remove krb4]]<br />
[[ Projects/VerifyAuthData]]<br />
[[ Projects/domain realm referrals]]<br />
[[ Projects/replay cache collision avoidance]]</div>Sbuckleyhttps://k5wiki.kerberos.org/wiki?title=Release_1.7&diff=2984Release 1.72009-11-20T22:26:22Z<p>Sbuckley: </p>
<hr />
<div> [[Projects/AEAD encryption API]]<br />
[[Projects/Aliases]]<br />
[[Projects/FAST]]<br />
[[Projects/GSSAPI DCE]]<br />
[[Projects/Master Key Migration]]<br />
[[Projects/Masterkey Keytab Stash]]<br />
[[ Projects/PAC and principal APIs]]<br />
[[Projects/RFC 3244]]<br />
[[ Projects/RFC 4537]]<br />
[[Projects/Remove krb4]]<br />
[[ Projects/VerifyAuthData]]<br />
[[ Projects/domain realm referrals]]<br />
[[ Projects/replay cache collision avoidance]]</div>Sbuckleyhttps://k5wiki.kerberos.org/wiki?title=Release_1.7&diff=2983Release 1.72009-11-20T22:24:55Z<p>Sbuckley: New page: AEAD encryption API Aliases ConstrainedDelegation Projects/Encryption performance Projects/Enctype config enhancements Projects/FAST Projects/GSSAPI DCE [[Projects/Master ...</p>
<hr />
<div>[[AEAD encryption API]]<br />
Aliases<br />
ConstrainedDelegation<br />
Projects/Encryption performance<br />
Projects/Enctype config enhancements<br />
[[Projects/FAST]]<br />
[[Projects/GSSAPI DCE]]<br />
[[Projects/Master Key Migration]]<br />
[[Projects/Masterkey Keytab Stash]]<br />
[[ Projects/PAC and principal APIs]]<br />
[[Projects/RFC 3244]]<br />
[[ Projects/RFC 4537]]<br />
[[Projects/Remove krb4]]<br />
[[ Projects/VerifyAuthData]]<br />
[[ Projects/domain realm referrals]]<br />
[[ Projects/replay cache collision avoidance]]</div>Sbuckleyhttps://k5wiki.kerberos.org/wiki?title=Release_1.8&diff=2890Release 1.82009-11-03T01:09:00Z<p>Sbuckley: /* Protocol evolution */</p>
<hr />
<div>This is the preliminary proposed goal set for the '''krb5-1.8 release'''. Please provide comments on the krbdev list. This page organizes the goals by the "guiding principles" listed in the [[Roadmap|roadmap]].<br />
<br />
== Timeline ==<br />
<br />
This is only an approximate timeline.<br />
<br />
* 2009-10-06 -- "halfway point" feature and integration test<br />
* 2010-01-04 -- make release branch<br />
* 2010-03-01 -- final release<br />
<br />
== Code quality ==<br />
<br />
* Move toward [[test-driven development]]<br />
* Increase conformance to coding style<br />
** See [[Coding style/Transition strategies]]<br />
** "The great reindent"?<br />
** Selective refactoring<br />
<br />
== Modularity ==<br />
<br />
* [[Projects/Crypto_modularity|Crypto modularity]]<br />
* Move toward improved KDB interface<br />
* Improved API for [[Projects/VerifyAuthData|verifying and interrogating authorization data]]<br />
<br />
== Performance ==<br />
<br />
* Investigate and remedy repeatedly-reported performance bottlenecks.<br />
* [[Projects/Encryption performance|Encryption performance]]<br />
<br />
== End-user experience ==<br />
<br />
* Reduce DNS dependence<br />
** Love's ccache auxiliary data proposal allows client library to track whether a KDC supports service principal referrals.<br />
<br />
== Administrator experience ==<br />
<br />
* Disable DES by default (1.8)<br />
* More versatile [[Projects/Enctype_config_enhancements|crypto configuration]], to simplify migration away from DES<br />
* [[Projects/Lockout|Lockout]] for repeated login failures<br />
* [[Projects/Trace logging|Trace logging]] for easier troubleshooting<br />
<br />
== Protocol evolution ==<br />
<br />
* FAST enhancements<br />
* [[Projects/Services4User| S4U2Self/S4U2Proxy]]<br />
* [[Projects/Anonymous pkinit | Anonymous PKINIT]]</div>Sbuckleyhttps://k5wiki.kerberos.org/wiki?title=Release_1.8&diff=2889Release 1.82009-11-03T01:08:27Z<p>Sbuckley: /* Protocol evolution */</p>
<hr />
<div>This is the preliminary proposed goal set for the '''krb5-1.8 release'''. Please provide comments on the krbdev list. This page organizes the goals by the "guiding principles" listed in the [[Roadmap|roadmap]].<br />
<br />
== Timeline ==<br />
<br />
This is only an approximate timeline.<br />
<br />
* 2009-10-06 -- "halfway point" feature and integration test<br />
* 2010-01-04 -- make release branch<br />
* 2010-03-01 -- final release<br />
<br />
== Code quality ==<br />
<br />
* Move toward [[test-driven development]]<br />
* Increase conformance to coding style<br />
** See [[Coding style/Transition strategies]]<br />
** "The great reindent"?<br />
** Selective refactoring<br />
<br />
== Modularity ==<br />
<br />
* [[Projects/Crypto_modularity|Crypto modularity]]<br />
* Move toward improved KDB interface<br />
* Improved API for [[Projects/VerifyAuthData|verifying and interrogating authorization data]]<br />
<br />
== Performance ==<br />
<br />
* Investigate and remedy repeatedly-reported performance bottlenecks.<br />
* [[Projects/Encryption performance|Encryption performance]]<br />
<br />
== End-user experience ==<br />
<br />
* Reduce DNS dependence<br />
** Love's ccache auxiliary data proposal allows client library to track whether a KDC supports service principal referrals.<br />
<br />
== Administrator experience ==<br />
<br />
* Disable DES by default (1.8)<br />
* More versatile [[Projects/Enctype_config_enhancements|crypto configuration]], to simplify migration away from DES<br />
* [[Projects/Lockout|Lockout]] for repeated login failures<br />
* [[Projects/Trace logging|Trace logging]] for easier troubleshooting<br />
<br />
== Protocol evolution ==<br />
<br />
* FAST enhancements<br />
* [[Projects/Services4User| S4U2Self/S4U2Proxy]]<br />
* [[Projects/Anonymous pkinit]]</div>Sbuckleyhttps://k5wiki.kerberos.org/wiki?title=Release_1.8&diff=2888Release 1.82009-11-03T01:07:53Z<p>Sbuckley: /* Protocol evolution */</p>
<hr />
<div>This is the preliminary proposed goal set for the '''krb5-1.8 release'''. Please provide comments on the krbdev list. This page organizes the goals by the "guiding principles" listed in the [[Roadmap|roadmap]].<br />
<br />
== Timeline ==<br />
<br />
This is only an approximate timeline.<br />
<br />
* 2009-10-06 -- "halfway point" feature and integration test<br />
* 2010-01-04 -- make release branch<br />
* 2010-03-01 -- final release<br />
<br />
== Code quality ==<br />
<br />
* Move toward [[test-driven development]]<br />
* Increase conformance to coding style<br />
** See [[Coding style/Transition strategies]]<br />
** "The great reindent"?<br />
** Selective refactoring<br />
<br />
== Modularity ==<br />
<br />
* [[Projects/Crypto_modularity|Crypto modularity]]<br />
* Move toward improved KDB interface<br />
* Improved API for [[Projects/VerifyAuthData|verifying and interrogating authorization data]]<br />
<br />
== Performance ==<br />
<br />
* Investigate and remedy repeatedly-reported performance bottlenecks.<br />
* [[Projects/Encryption performance|Encryption performance]]<br />
<br />
== End-user experience ==<br />
<br />
* Reduce DNS dependence<br />
** Love's ccache auxiliary data proposal allows client library to track whether a KDC supports service principal referrals.<br />
<br />
== Administrator experience ==<br />
<br />
* Disable DES by default (1.8)<br />
* More versatile [[Projects/Enctype_config_enhancements|crypto configuration]], to simplify migration away from DES<br />
* [[Projects/Lockout|Lockout]] for repeated login failures<br />
* [[Projects/Trace logging|Trace logging]] for easier troubleshooting<br />
<br />
== Protocol evolution ==<br />
<br />
* FAST enhancements<br />
* Anonymous PKINIT<br />
* [[Projects/Services4User| S4U2Self/S4U2Proxy]]<br />
* [[Projects/Anonymous pkinit]]</div>Sbuckleyhttps://k5wiki.kerberos.org/wiki?title=Projects/VerifyAuthData&diff=2704Projects/VerifyAuthData2009-09-21T16:18:40Z<p>Sbuckley: /* Approvals */</p>
<hr />
<div>{{project-review|2009-09-18}}<br />
<br />
<includeonly>[[Category: early stage projects]]</includeonly><br />
<br />
==Background==<br />
<br />
The goals of this project are to:<br />
<br />
* change the behaviour of krb5_rd_req() to always verify known authorization data elements<br />
* provide an attribute-based GSS interface for inquiry and submission of authorization information ([http://www.ietf.org/id/draft-ietf-kitten-gssapi-naming-exts-05.txt draft-ietf-kitten-gssapi-naming-exts])<br />
* provide an attribute-based plugin interface for verification and serialization of authorization information<br />
* encourage the use of positive authorization data by providing sample KDC and application plugins<br />
<br />
==Architecture==<br />
<br />
A new opaque type, an authorization data context (krb5_authdata_context) provides an attribute-based accessor onto a set of authorization data elements. The operations which one can perform on this context roughly mirror those specified in draft-ietf-kitten-gssapi-naming-exts.<br />
<br />
An authorization data context is always created and verified by krb5_rd_req(); one can also be submitted to krb5_mk_req(). Access to it is provided via the krb5_auth_con_get_authdata_context() API. The public interface is provided via draft-ietf-kitten-gssapi-naming-exts.<br />
<br />
The authorization data context encapsulates a set of authorization data <i>systems</i>, each which provide support for one or more authorization data types. Each system is instantiated as a <i>module</i>, one for each authorization data type. This is modelled closely on the client-side preauthentication SPI. The set of systems is extensible at runtime through a plug-in interface.<br />
<br />
If an authorization data system fails to verify an element, then krb5_rd_req() will fail; however, unknown elements are still ignored (behaviour which is backwards compatible but not compliant with RFC 4120). We may want to revisit this.<br />
<br />
===Windows PAC===<br />
An authorization data system for the Windows 2000 PAC is built into libkrb5, as a wrapper around the krb5_pac APIs introduced in MIT Kerberos 1.7. Each PAC buffer is surfaced as a separate attribute. A vendor that wished to surface fields within buffers (for example, SIDs representing a user's group membership) could do so by registering the appropriate plug-in, avoiding the overhead of building a NDR parser into libkrb5. Indeed, as long as all authorization data systems are re-entrant, the plug-in could call into krb5_authdata_get_attribute() to build upon the existing PAC parsing code.<br />
<br />
===Initiator/acceptor data===<br />
Systems that implement the AD_USAGE_AP_REQ usage can serialize attributes for inclusion in an AP-REQ. The "greet_client" plugin is one such system: it conveys a single string from initiator to acceptor in the authorization data of the AP-REQ authenticator. (AD_USAGE_TGS_REQ is also supported.) Plugins that only need to verify and inquiry about KDC issued authorization data, such as the Windows 2000 PAC, advertise the AD_USAGE_KDC_ISSUED usage.<br />
<br />
===KDC===<br />
The existing KDC authorization data SPI contributed by Apple and Novell is unchanged by this project (except for a minor change to support AD-KDCIssued plug-ins). However, in order to encourage the use of positive authorization data, we have provided helper routines for marshalling and verifying AD-KDCIssued, as well sample application- and KDC-side plugins. A few hundred lines of code in total, they may be easily adapted to vendor-specific requirements such as NFSv4, POSIX, or SAML. Further, an enterprising developer might choose to build a KDC authorization data plugin on top of the authorization data ontexts APIs (and perform the majority of work in a "client" plug-in).<br />
<br />
==Implementation==<br />
<br />
===GSS===<br />
<br />
====Naming extension APIs====<br />
<br />
The reader is referred to draft-ietf-kitten-gssapi-naming-exts for details. The following new APIs are defined in gssapi_ext.h:<br />
<br />
* gss_display_name_ext()<br />
* gss_inquire_name()<br />
* gss_get_name_attribute()<br />
* gss_set_name_attribute()<br />
* gss_delete_name_attribute()<br />
* gss_export_name_composite()<br />
* gss_map_name_to_any()<br />
* gss_release_any_name_mapping()<br />
<br />
The following changes were made from draft-ietf-kitten-gssapi-naming-exts-05 (obviously, until the draft becomes an RFC, we may expect further changes):<br />
<br />
* the <i>output</i> argument of gss_map_name_to_any() is a pointer to gss_any_t (presumably this is a typo in the document)<br />
* the <i>authenticated</i>, <i>asserted</i> and <i>all_attrs</i> arguments to gss_inquire_name() are pointers to gss_buffer_set_t<br />
<br />
====Changes to mechanism glue====<br />
<br />
The mechglue exports the naming extension functions named above. New files have been added to implement them, and the gss_mechanism type updated accordingly. Note that the mechglue does not provide its own attribute store: as such, the naming extensions APIs must be used with mechanism names. This may require the caller to explicitly canonicalize the name first.<br />
<br />
====Changes to SPNEGO====<br />
<br />
Wrappers for the naming extension APIs have been added to SPNEGO.<br />
<br />
====Changes to Kerberos 5 mechanism====<br />
<br />
All of the naming extension APIs, save for gss_display_name_ext(), have been implemented in the Kerberos 5 mechanism. Most of the code is to be found in [http://src.mit.edu/opengrok/xref/users/lhoward/authdata/src/lib/gssapi/krb5/naming_exts.c naming_exts.c].<br />
<br />
Previously, a Kerberos 5 mechanism name was represented by the type krb5_principal. This is now a structure containing an authorization data context as well as the principal name:<br />
<br />
<pre><br />
typedef struct _krb5_gss_name_rec {<br />
krb5_principal princ; /* immutable */<br />
k5_mutex_t lock; /* protects ad_context only for now */<br />
krb5_authdata_context ad_context;<br />
} krb5_gss_name_rec, *krb5_gss_name_t;<br />
</pre><br />
<br />
Note that the lock protects ad_context only; the principal name is immutable. The initialization of ad_context is deferred until an attribute it set or authorization data imported. Some helper APIs are provided to manage the creation, copying and destruction of Kerberos 5 mechanism names.<br />
<br />
A summary of changes to existing functions follows, excluding changes required to use the new krb5_gss_name_t data structure:<br />
<br />
=====krb5_gss_init_sec_context()=====<br />
<br />
Note: the terms "flatten" and "export" are used interchangeably below and hereafter.<br />
<br />
* If the initiator name has an authorization data context, then the authorization data for all AD_USAGE_TGS_REQ systems is flattened, and included in the TGS request and stored in the credentials cache<br />
* If the initiator name has an authorization data context, then the authorization data for all AD_USAGE_AP_REQ systems is flattened, and included in the AP request<br />
<br />
=====krb5_gss_import_name()=====<br />
<br />
* Support is added for importing composite names that include authorization data elements (note that re-imported names will lose their authenticated state)<br />
<br />
=====krb5_gss_inquire_name()=====<br />
<br />
This new function is a wrapper around krb5_authdata_get_attribute_types().<br />
<br />
=====krb5_gss_get_name_attribute()=====<br />
<br />
This new function is a wrapper around krb5_authdata_get_attribute().<br />
<br />
=====krb5_gss_set_name_attribute()=====<br />
<br />
This new function is a wrapper around krb5_authdata_set_attribute().<br />
<br />
=====krb5_gss_delete_name_attribute()=====<br />
<br />
This new function is a wrapper around krb5_authdata_delete_attribute().<br />
<br />
=====krb5_gss_map_name_to_any()=====<br />
<br />
This new function is a wrapper around krb5_authdata_export_internal().<br />
<br />
=====krb5_gss_release_any_name_mapping()=====<br />
<br />
This new function is a wrapper around krb5_authdata_free_internal().<br />
<br />
=====krb5_gss_export_name_composite()=====<br />
<br />
This new function is a wrapper around krb5_authdata_export_attributes().<br />
<br />
=====krb5_gss_display_name_ext()=====<br />
<br />
This is not yet implemented.<br />
<br />
=====krb5_gss_accept_sec_context()=====<br />
<br />
* Update to use kg_XXX_name() helper functions<br />
* Extract authorization data context from authentication context and store in source name<br />
<br />
===libkrb5===<br />
<br />
====Changes====<br />
<br />
The following fixes were made to existing functions in libkrb5:<br />
<br />
* The file-based credentials cache did not support negative authorization data types<br />
* krb5_get_cred_from_kdc_opt() did not handle TGS-REQ submitted authorization data correctly: it should be submitted in the first service ticket request only (because in the referral case, the TGS will copy it into the returned ticket), and any returned referral tickets must be marked as containing authorization data so they are not inappropriately re-used<br />
<br />
====Public APIs====<br />
<br />
=====krb5_make_authdata_kdc_issued()=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_make_authdata_kdc_issued(krb5_context context,<br />
const krb5_keyblock *key,<br />
krb5_const_principal issuer,<br />
krb5_authdata *const *authdata,<br />
krb5_authdata ***ad_kdcissued);<br />
</pre><br />
<br />
This function both encodes and signs AD-KDCIssued authorization data (RFC 4120 section 5.2.6.2). A set of authorization data containing a single AD-KDCIssued element is returned to the caller.<br />
<br />
=====krb5_verify_authdata_kdc_issued()=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_verify_authdata_kdc_issued(krb5_context context,<br />
const krb5_keyblock *key,<br />
const krb5_authdata *ad_kdcissued,<br />
krb5_principal *issuer,<br />
krb5_authdata ***authdata);<br />
</pre><br />
<br />
This function both decodes and verifies AD-KDCIssued authorization data (RFC 4120 section 5.2.6.2). The issuer and unwrapped authorization data are returned to the caller.<br />
<br />
====Exported, private APIs====<br />
<br />
=====krb5int_free_data_list()=====<br />
<br />
<pre><br />
void KRB5_CALLCONV krb5int_free_data_list<br />
(krb5_context context, krb5_data *data);<br />
</pre><br />
<br />
Frees an array of krb5_data objects, terminated by the last element's data member being NULL.<br />
<br />
=====krb5_authdata_context_init()=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_authdata_context_init(krb5_context kcontext,<br />
krb5_authdata_context *pcontext);<br />
</pre><br />
<br />
Initialises an authorization data context, loading both built- and plug-in authorization data systems. Note that in the present implementation, the plug-in list is not cached between calls to this function; this may change in the future.<br />
<br />
=====krb5_authdata_context_free()=====<br />
<br />
<pre><br />
void KRB5_CALLCONV<br />
krb5_authdata_context_free(krb5_context kcontext,<br />
krb5_authdata_context context);<br />
</pre><br />
<br />
Releases and authorization data context.<br />
<br />
=====krb5_authdata_get_attribute_types()=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_authdata_get_attribute_types(krb5_context kcontext,<br />
krb5_authdata_context context,<br />
krb5_data **verified_attrs,<br />
krb5_data **asserted_attrs,<br />
krb5_data **all_attrs);<br />
</pre><br />
<br />
Returns the union of attributes supported by all registered authorization data systems. Note that the meaning of all_attrs is unclear from draft-ietf-kitten-gssapi-naming-exts; we may remove this in the future.<br />
<br />
=====krb5_authdata_get_attribute()=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_authdata_get_attribute(krb5_context kcontext,<br />
krb5_authdata_context context,<br />
const krb5_data *attribute,<br />
krb5_boolean *authenticated,<br />
krb5_boolean *complete,<br />
krb5_data *value,<br />
krb5_data *display_value,<br />
int *more);<br />
</pre><br />
<br />
Retrieves an attribute named by <i>attribute</i> from the set of authorization data systems. Note that presently a single attribute type cannot be federated amongst multiple systems. <i>more</i> must be set to -1 on the first call; this function should be called repeatedly until more is 0, or an error returned.<br />
<br />
=====krb5_authdata_set_attribute()=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_authdata_set_attribute(krb5_context kcontext,<br />
krb5_authdata_context context,<br />
krb5_boolean complete,<br />
const krb5_data *attribute,<br />
const krb5_data *value);<br />
</pre><br />
<br />
Sets/adds an attribute value. Whether an attribute is multi-valued or not is left to the authorization data system. To replace an attribute's every value delete the attribute's values first with krb5_authdata_delete_attribute().<br />
<br />
Return values: EEXIST indicates the attribute already exists, EINVAL indicates an invalid argument, ENOENT indicates that the attribute type is not recognised by any authorization data system.<br />
<br />
=====krb5_authdata_delete_attribute()=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_authdata_delete_attribute(krb5_context kcontext,<br />
krb5_authdata_context context,<br />
const krb5_data *attribute);<br />
</pre><br />
<br />
Deletes an attribute.<br />
<br />
=====krb5_authdata_import_attributes()=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_authdata_import_attributes(krb5_context kcontext,<br />
krb5_authdata_context context,<br />
krb5_flags usage,<br />
krb5_authdata **authdata_to_import);<br />
</pre><br />
<br />
Imports a set of authorization data with the given usage. Typically usage will be AD_USAGE_MASK, to indicate to all registered authorization data systems to import the authorization data. There is no way to convey the authorization data's authentication state using this function.<br />
<br />
=====krb5_authdata_export_attributes()=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_authdata_export_attributes(krb5_context kcontext,<br />
krb5_authdata_context context,<br />
krb5_flags usage,<br />
krb5_authdata ***pauthdata);<br />
</pre><br />
<br />
Exports, or flattens, the authorization data context's systems' attributes into a set of Kerberos authorization data. The usage argument is used to determine which systems will be called, so that only the authorization data appropriate to the type of request being made is exported.<br />
<br />
=====krb5_authdata_export_internal()=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_authdata_export_internal(krb5_context kcontext,<br />
krb5_authdata_context context,<br />
krb5_boolean restrict_authenticated,<br />
const char *module_name,<br />
void **ptr);<br />
</pre><br />
<br />
Exports an internal representation of the authorization data state. This might, for example, be used to retrieve an operating system-specific representation of authorization information, such as a struct ucred.<br />
<br />
=====krb5_authdata_free_internal()=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_authdata_free_internal(krb5_context kcontext,<br />
krb5_authdata_context context,<br />
const char *module_name,<br />
void *ptr);<br />
</pre><br />
<br />
Frees an internal representation exported by krb5_authdata_export_internal().<br />
<br />
=====krb5_authdata_context_copy()=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_authdata_context_copy(krb5_context kcontext,<br />
krb5_authdata_context src,<br />
krb5_authdata_context *pdst);<br />
</pre><br />
<br />
Duplicates an authorization data context. In the present implementation this involves reloading the authorization data plug-in list, which could be expensive, so this should be used sparingly.<br />
<br />
=====krb5_auth_con_get_authdata_context()=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_auth_con_get_authdata_context(krb5_context context,<br />
krb5_auth_context auth_context,<br />
krb5_authdata_context *ad_context);<br />
</pre><br />
<br />
Retrieves the authorization data context associated with an authentication context. This is a weak reference; if the caller wishes to retain a reference to this after the authentication context has been destroyed, it should make a copy or take ownership by calling krb5_auth_con_set_authdata_context(... NULL).<br />
<br />
=====krb5_auth_con_set_authdata_context()=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_auth_con_set_authdata_context(krb5_context context,<br />
krb5_auth_context auth_context,<br />
krb5_authdata_context ad_context);<br />
</pre><br />
<br />
Sets the authorization data context associated with an authentication context. The context will be freed by krb5_auth_con_free(), so if the caller wishes to retain ownership it should call krb5_auth_con_set_authdata_context(... NULL). This API usage is in line with the management of other pointer types associated with an authentication context.<br />
<br />
=====encode_krb5_ad_kdcissued()=====<br />
<br />
ASN.1 encoder for AD-KDCIssued.<br />
<br />
=====decode_krb5_ad_kdcissued()=====<br />
<br />
ASN.1 decoder for AD-KDCIssued.<br />
<br />
=====krb5_free_ad_kdcissued()=====<br />
<br />
<pre><br />
void KRB5_CALLCONV<br />
krb5_free_ad_kdcissued(krb5_context context, krb5_ad_kdcissued *val);<br />
</pre><br />
<br />
Free a krb5_ad_kdcissued structure; this structure is only used within libkrb5.<br />
<br />
====Non-exported, private APIs====<br />
<br />
<pre><br />
krb5_error_code<br />
krb5int_authdata_verify(krb5_context context,<br />
krb5_authdata_context,<br />
krb5_flags usage,<br />
const krb5_auth_context *auth_context,<br />
const krb5_keyblock *key,<br />
const krb5_ap_req *ap_req);<br />
</pre><br />
<br />
Verifies and imports authorization data from an AP-REQ.<br />
<br />
===SPI===<br />
<br />
This section describes the service provider interface (SPI) used by the authorization data context functions. Presently plug-ins are initialised upon creation of an authorization data context, however that may not be always the case; plug-ins should be careful to distinguish between plug-in initialisation and request initialisation. State associated with a specific set of authorization data should be managed by the latter.<br />
<br />
The dispatch table is below:<br />
<br />
<pre><br />
typedef struct krb5plugin_authdata_client_ftable_v0 {<br />
char *name;<br />
krb5_authdatatype *ad_type_list;<br />
authdata_client_plugin_init_proc init;<br />
authdata_client_plugin_fini_proc fini;<br />
authdata_client_plugin_flags_proc flags;<br />
authdata_client_request_init_proc request_init;<br />
authdata_client_request_fini_proc request_fini;<br />
authdata_client_get_attribute_types_proc get_attribute_types;<br />
authdata_client_get_attribute_proc get_attribute;<br />
authdata_client_set_attribute_proc set_attribute;<br />
authdata_client_delete_attribute_proc delete_attribute;<br />
authdata_client_import_attributes_proc import_attributes;<br />
authdata_client_export_attributes_proc export_attributes;<br />
authdata_client_export_internal_proc export_internal;<br />
authdata_client_free_internal_proc free_internal;<br />
authdata_client_copy_context_proc copy_context;<br />
authdata_client_verify_proc verify;<br />
} krb5plugin_authdata_client_ftable_v0;<br />
</pre><br />
<br />
<i>ad_type_list</i> is a zero terminated list of authorization data types supported by the system; a system's methods will be invoked once for each type, however they all share the same request context (state).<br />
<br />
All methods are optional unless otherwise indicated.<br />
<br />
====plugin_init()====<br />
<br />
<pre><br />
typedef krb5_error_code<br />
(*authdata_client_plugin_init_proc)(krb5_context context,<br />
void **plugin_context);<br />
</pre><br />
<br />
This is the plug-in initialisation function. It is called at plug-in initialisation. It is called no more than once for each constructed authorization data context, and may be called fewer times (if plug-in information is cached); however, plug-ins should not leak if this function is called multiple times. There is a matching call to fini() for each call to init().<br />
<br />
This function is mandatory to implement.<br />
<br />
====plugin_fini()====<br />
<br />
<pre><br />
typedef void<br />
(*authdata_client_plugin_fini_proc)(krb5_context kcontext,<br />
void *plugin_context);<br />
</pre><br />
<br />
This is the plug-in finalizer.<br />
<br />
This function is mandatory to implement.<br />
<br />
====plugin_flags()====<br />
<br />
<pre><br />
typedef void<br />
(*authdata_client_plugin_flags_proc)(krb5_context kcontext,<br />
void *plugin_context,<br />
krb5_authdatatype ad_type,<br />
krb5_flags *flags);<br />
</pre><br />
<br />
This function is called to indicate the usages supported by the authorization data system for a particular authorization data type. Usages are as follows:<br />
<br />
<pre><br />
#define AD_USAGE_AS_REQ 0x01<br />
#define AD_USAGE_TGS_REQ 0x02<br />
#define AD_USAGE_AP_REQ 0x04<br />
#define AD_USAGE_KDC_ISSUED 0x08<br />
#define AD_USAGE_MASK 0x0F<br />
#define AD_INFORMATIONAL 0x10<br />
</pre><br />
<br />
If AD_INFORMATIONAL is unset, then a plug-in failure will cause an error to be returned to the caller and other systems not invoked (except for non-fatal errors such as an attribute not being found, in which case all systems are tried).<br />
<br />
This function is not mandatory to implement, but a module that does not return flags will never be called.<br />
<br />
====request_init()====<br />
<br />
<pre><br />
typedef krb5_error_code<br />
(*authdata_client_request_init_proc)(krb5_context kcontext,<br />
struct _krb5_authdata_context *context,<br />
void *plugin_context,<br />
void **request_context);<br />
</pre><br />
<br />
Initialises state for a new authorization data context.<br />
<br />
This function is mandatory to implement.<br />
<br />
====request_fini()====<br />
<br />
<pre><br />
typedef void<br />
(*authdata_client_request_fini_proc)(krb5_context kcontext,<br />
struct _krb5_authdata_context *context,<br />
void *plugin_context,<br />
void *request_context);<br />
</pre><br />
<br />
Releases state associated with an authorization data context.<br />
<br />
This function is mandatory to implement.<br />
<br />
====import_attributes()====<br />
<br />
<pre><br />
typedef krb5_error_code<br />
(*authdata_client_import_attributes_proc)(krb5_context kcontext,<br />
struct _krb5_authdata_context *context,<br />
void *plugin_context,<br />
void *request_context,<br />
krb5_authdata **authdata,<br />
krb5_boolean kdc_issued_flag,<br />
krb5_const_principal issuer);<br />
</pre><br />
<br />
Instructs the authorization data system to load its state from serialised authorization data. <i>plugin_context</i> and <i>request_context</i> point to initialised values. The system can assume that <i>authdata</i> only contains authorization data that it recognises.<br />
<br />
If <i>kdc_issued_flag</i> is TRUE, then the imported authorization data was extracted from authenticated KDC issued authorization data. <i>issuer</i> is an optional argument indicating <br />
<br />
====get_attribute_types()====<br />
<br />
<pre><br />
typedef krb5_error_code<br />
(*authdata_client_get_attribute_types_proc)(krb5_context kcontext,<br />
struct _krb5_authdata_context *context,<br />
void *plugin_context,<br />
void *request_context,<br />
krb5_data **verified,<br />
krb5_data **asserted,<br />
krb5_data **all_attrs);<br />
</pre><br />
<br />
Enumerates attribute types supported by the authorization data system. <i>verified</i>, <i>asserted</i>, and <i>all_attrs</i> have the same meaning as defined in draft-ietf-kitten-gssapi-naming-exts-05 (except that <i>verified</i> should be read as <i>authenticated</i>).<br />
<br />
====get_attribute()====<br />
<br />
<pre><br />
typedef krb5_error_code<br />
(*authdata_client_get_attribute_proc)(krb5_context kcontext,<br />
struct _krb5_authdata_context *context,<br />
void *plugin_context,<br />
void *request_context,<br />
const krb5_data *attribute,<br />
krb5_boolean *authenticated,<br />
krb5_boolean *complete,<br />
krb5_data *value,<br />
krb5_data *display_value,<br />
int *more);<br />
</pre><br />
<br />
Retrieves a single attribute value from an authorization data system. If the attribute is unrecognised, ENOENT should be returned. Note that federation of a single attribute across multiple authorization data systems is not supported at present. Authorization data systems must be re-entrant so that more granular systems can be built on top of less granular systems.<br />
<br />
====set_attribute()====<br />
<br />
<pre><br />
typedef krb5_error_code<br />
(*authdata_client_set_attribute_proc)(krb5_context kcontext,<br />
struct _krb5_authdata_context *context,<br />
void *plugin_context,<br />
void *request_context,<br />
krb5_boolean complete,<br />
const krb5_data *attribute,<br />
const krb5_data *value);<br />
</pre><br />
<br />
Sets or adds a single attribute value to an authorization data system. If the attribute is unrecognised, ENOENT should be returned. If the attribute cannot accept any more values (either because it is single-valued or the same value is already present), then EEXIST should be returned.<br />
<br />
====delete_attribute()====<br />
<br />
<pre><br />
typedef krb5_error_code<br />
(*authdata_client_delete_attribute_proc)(krb5_context kcontext,<br />
struct _krb5_authdata_context *context,<br />
void *plugin_context,<br />
void *request_context,<br />
const krb5_data *attribute);<br />
</pre><br />
<br />
Removes an attribute from an authorization data system.<br />
<br />
====export_attributes()====<br />
<br />
<pre><br />
typedef krb5_error_code<br />
(*authdata_client_export_attributes_proc)(krb5_context kcontext,<br />
struct _krb5_authdata_context *context,<br />
void *plugin_context,<br />
void *request_context,<br />
krb5_flags usage,<br />
krb5_authdata ***authdata);<br />
</pre><br />
<br />
Flattens authorization data for the requested usage, for use in a KDC or AP request.<br />
<br />
====export_internal()====<br />
<br />
<pre><br />
typedef krb5_error_code<br />
(*authdata_client_export_internal_proc)(krb5_context kcontext,<br />
struct _krb5_authdata_context *context,<br />
void *plugin_context,<br />
void *request_context,<br />
krb5_boolean restrict_authenticated,<br />
void **ptr);<br />
</pre><br />
<br />
Exports some internal representation of authorization data. If <i>restrict_authenticated</i> is TRUE, only authenticated attributes will be included.<br />
<br />
====free_internal()====<br />
<br />
<pre><br />
typedef void<br />
(*authdata_client_free_internal_proc)(krb5_context kcontext,<br />
struct _krb5_authdata_context *context,<br />
void *plugin_context,<br />
void *request_context,<br />
void *ptr);<br />
</pre><br />
<br />
Releases representation returned by export_internal().<br />
<br />
====copy()====<br />
<br />
<pre><br />
typedef krb5_error_code<br />
(*authdata_client_copy_context_proc)(krb5_context kcontext,<br />
struct _krb5_authdata_context *context,<br />
void *plugin_context,<br />
void *request_context,<br />
void *dst_plugin_context,<br />
void *dst_request_context);<br />
</pre><br />
<br />
Copies state from <i>request_context</i> to <i>dst_request_context</i>. <i>dst_request_context</i> is a newly initialised context.<br />
<br />
The plug-in should not assume that <i>plugin_context</i> and <i>dst_plugin_context</i> are different values.<br />
<br />
This function is mandatory to implement.<br />
<br />
====verify()====<br />
<br />
<pre><br />
typedef krb5_error_code<br />
(*authdata_client_verify_proc)(krb5_context kcontext,<br />
struct _krb5_authdata_context *context,<br />
void *plugin_context,<br />
void *request_context,<br />
const krb5_auth_context *auth_context,<br />
const krb5_keyblock *key,<br />
const krb5_ap_req *req);<br />
</pre><br />
<br />
Verifies authorization data from an AP request. This function need not be implemented by negative authorization systems or systems that expect authorization data to be marked AD-KDCIssued (although is likely that in either case, some validation of the content of the authorization data may be required; this is better done in the import_attributes method).<br />
<br />
===KDC===<br />
<br />
The only changes to the KDC are as follows:<br />
<br />
* Add a session_key argument to kdb_sign_auth_data_req, for database backends that wish to use AD-KDCIssued<br />
* In do_tgs_req(), ensure that the session key is made available to handle_authdata()<br />
* In handle_authdata(), give preference to plug-ins over internal systems<br />
* Rename krb5plugin_authdata_ftable_vX to krb5plugin_server_authdata_ftable_vX (typedefs to the old types are retained)<br />
<br />
==Example==<br />
<br />
===greet_client===<br />
<br />
Note the "greet:greeting" attribute; rather than being issued by the KDC, this was set on the claimant credential's name using gss_set_name_attribute(), and conveyed in the AP-REQ. The acceptor retrieves it like any other attribute, but note it is not marked "Authenticated". (By changing the flags in the greet plug-in, it's also possible to have the data conveyed in the TGS-REQ, and thus the service ticket.)<br />
<br />
<pre><br />
% ./t_namingexts test.keytab<br />
init module "greet", ad_type -42, flags 00000014<br />
init module "mspac", ad_type 128, flags 00000008<br />
Source name: host/test.de.padl.com@DE.PADL.COM<br />
<br />
Attribute mspac: Authenticated Complete <br />
<br />
050000000000000001000000b001000058000000000000000a00000034000000<br />
...<br />
<br />
Attribute mspac:logon-info Authenticated Complete <br />
<br />
01100800cccccccca001000000000000000002006ed28d68cd25ca01ffffffff<br />
...<br />
<br />
Attribute mspac:client-info Authenticated Complete <br />
<br />
802862d64026ca012a0068006f00730074002f00720061006e0064002e006400<br />
...<br />
<br />
Attribute mspac:upn-dns-info Authenticated Complete <br />
<br />
2a00100016004000000000000000000068006f00730074002f00720061006e00<br />
...<br />
<br />
Attribute mspac:server-checksum Authenticated Complete <br />
<br />
100000004b12be9500319e6fb731cb07<br />
<br />
Attribute mspac:privsvr-checksum Authenticated Complete <br />
<br />
76ffffff812d7a725e999ca41dd6e51fdc64d501<br />
<br />
Attribute greet:greeting Complete <br />
<br />
48656c6c6f2c206163636570746f7220776f726c6421<br />
Exported name:<br />
<br />
0402000b06092a864886f71201020200000021686f73742f72616e642e64652e<br />
...<br />
</pre><br />
<br />
===greet_server===<br />
<br />
This plug-in is a simple demonstration of the generation and verification of positive (KDC issued) authorization data.<br />
<br />
==Tools==<br />
<br />
===klist===<br />
<br />
A new option, -d, has been added to klist which enumerates the authorization data types submitted with the TGS request. It does not include authorization data added by the KDC (because that is only available to the service).<br />
<br />
<pre><br />
$ klist -d<br />
Ticket cache: FILE:/tmp/krb5cc_1002<br />
Default principal: Administrator@BERLIN.DE.PADL.COM<br />
<br />
Valid starting Expires Service principal<br />
09/01/09 14:49:15 09/02/09 00:49:15 krbtgt/BERLIN.DE.PADL.COM@BERLIN.DE.PADL.COM<br />
renew until 09/02/09 14:49:15<br />
09/01/09 14:49:20 09/02/09 00:49:15 krbtgt/DE.PADL.COM@BERLIN.DE.PADL.COM<br />
renew until 09/02/09 14:49:15, AD types: -50<br />
09/01/09 14:49:20 09/02/09 00:49:15 host/kreuz.de.padl.com@BERLIN.DE.PADL.COM<br />
renew until 09/02/09 14:49:15, AD types: -50<br />
09/01/09 14:49:20 09/02/09 00:49:15 host/kreuz.de.padl.com@DE.PADL.COM<br />
renew until 09/02/09 14:49:15, AD types: -50<br />
09/01/09 14:49:38 09/02/09 00:49:15 krbtgt/DE.PADL.COM@BERLIN.DE.PADL.COM<br />
renew until 09/02/09 14:49:15<br />
09/01/09 14:49:38 09/02/09 00:49:15 host/kreuz.de.padl.com@BERLIN.DE.PADL.COM<br />
renew until 09/02/09 14:49:15<br />
09/01/09 14:49:38 09/02/09 00:49:15 host/kreuz.de.padl.com@DE.PADL.COM<br />
renew until 09/02/09 14:49:15<br />
</pre><br />
<br />
==Open issues==<br />
<br />
* Should we force RFC 4120 compliance and have krb5_rd_req() fail if any authorization data element not enclosed in AD-IF-RELEVANT is unknown?<br />
* Should we refactor the server side auth data plugin interface to more closely mirror this one?<br />
<br />
==Status==<br />
<br />
Code is in the users/lhoward/authdata branch.<br />
==Review==<br />
<br />
This section documents the review of the project according to [[Project policy]].<br />
It is divided into multiple sections. First, approvals should be listed. To list an approval type<br />
:<nowiki>#~~~~</nowiki><br />
on its own line.<br />
The next section is for summarizing discussion, which should take place on krbdev@mit.edu. Provide links to the archive at http://mailman.mit.edu/pipermail/krbdev/ if appropriate. Blocking objections can be noted with <nowiki>{{project-block}}</nowiki>.<br />
<br />
===Approvals===<br />
[[User:Sbuckley|Steve]] 16:18, 21 September 2009 (UTC)<br />
<br />
===Discussion===</div>Sbuckleyhttps://k5wiki.kerberos.org/wiki?title=Projects/VerifyAuthData&diff=2703Projects/VerifyAuthData2009-09-21T16:18:21Z<p>Sbuckley: /* Status */</p>
<hr />
<div>{{project-review|2009-09-18}}<br />
<br />
<includeonly>[[Category: early stage projects]]</includeonly><br />
<br />
==Background==<br />
<br />
The goals of this project are to:<br />
<br />
* change the behaviour of krb5_rd_req() to always verify known authorization data elements<br />
* provide an attribute-based GSS interface for inquiry and submission of authorization information ([http://www.ietf.org/id/draft-ietf-kitten-gssapi-naming-exts-05.txt draft-ietf-kitten-gssapi-naming-exts])<br />
* provide an attribute-based plugin interface for verification and serialization of authorization information<br />
* encourage the use of positive authorization data by providing sample KDC and application plugins<br />
<br />
==Architecture==<br />
<br />
A new opaque type, an authorization data context (krb5_authdata_context) provides an attribute-based accessor onto a set of authorization data elements. The operations which one can perform on this context roughly mirror those specified in draft-ietf-kitten-gssapi-naming-exts.<br />
<br />
An authorization data context is always created and verified by krb5_rd_req(); one can also be submitted to krb5_mk_req(). Access to it is provided via the krb5_auth_con_get_authdata_context() API. The public interface is provided via draft-ietf-kitten-gssapi-naming-exts.<br />
<br />
The authorization data context encapsulates a set of authorization data <i>systems</i>, each which provide support for one or more authorization data types. Each system is instantiated as a <i>module</i>, one for each authorization data type. This is modelled closely on the client-side preauthentication SPI. The set of systems is extensible at runtime through a plug-in interface.<br />
<br />
If an authorization data system fails to verify an element, then krb5_rd_req() will fail; however, unknown elements are still ignored (behaviour which is backwards compatible but not compliant with RFC 4120). We may want to revisit this.<br />
<br />
===Windows PAC===<br />
An authorization data system for the Windows 2000 PAC is built into libkrb5, as a wrapper around the krb5_pac APIs introduced in MIT Kerberos 1.7. Each PAC buffer is surfaced as a separate attribute. A vendor that wished to surface fields within buffers (for example, SIDs representing a user's group membership) could do so by registering the appropriate plug-in, avoiding the overhead of building a NDR parser into libkrb5. Indeed, as long as all authorization data systems are re-entrant, the plug-in could call into krb5_authdata_get_attribute() to build upon the existing PAC parsing code.<br />
<br />
===Initiator/acceptor data===<br />
Systems that implement the AD_USAGE_AP_REQ usage can serialize attributes for inclusion in an AP-REQ. The "greet_client" plugin is one such system: it conveys a single string from initiator to acceptor in the authorization data of the AP-REQ authenticator. (AD_USAGE_TGS_REQ is also supported.) Plugins that only need to verify and inquiry about KDC issued authorization data, such as the Windows 2000 PAC, advertise the AD_USAGE_KDC_ISSUED usage.<br />
<br />
===KDC===<br />
The existing KDC authorization data SPI contributed by Apple and Novell is unchanged by this project (except for a minor change to support AD-KDCIssued plug-ins). However, in order to encourage the use of positive authorization data, we have provided helper routines for marshalling and verifying AD-KDCIssued, as well sample application- and KDC-side plugins. A few hundred lines of code in total, they may be easily adapted to vendor-specific requirements such as NFSv4, POSIX, or SAML. Further, an enterprising developer might choose to build a KDC authorization data plugin on top of the authorization data ontexts APIs (and perform the majority of work in a "client" plug-in).<br />
<br />
==Implementation==<br />
<br />
===GSS===<br />
<br />
====Naming extension APIs====<br />
<br />
The reader is referred to draft-ietf-kitten-gssapi-naming-exts for details. The following new APIs are defined in gssapi_ext.h:<br />
<br />
* gss_display_name_ext()<br />
* gss_inquire_name()<br />
* gss_get_name_attribute()<br />
* gss_set_name_attribute()<br />
* gss_delete_name_attribute()<br />
* gss_export_name_composite()<br />
* gss_map_name_to_any()<br />
* gss_release_any_name_mapping()<br />
<br />
The following changes were made from draft-ietf-kitten-gssapi-naming-exts-05 (obviously, until the draft becomes an RFC, we may expect further changes):<br />
<br />
* the <i>output</i> argument of gss_map_name_to_any() is a pointer to gss_any_t (presumably this is a typo in the document)<br />
* the <i>authenticated</i>, <i>asserted</i> and <i>all_attrs</i> arguments to gss_inquire_name() are pointers to gss_buffer_set_t<br />
<br />
====Changes to mechanism glue====<br />
<br />
The mechglue exports the naming extension functions named above. New files have been added to implement them, and the gss_mechanism type updated accordingly. Note that the mechglue does not provide its own attribute store: as such, the naming extensions APIs must be used with mechanism names. This may require the caller to explicitly canonicalize the name first.<br />
<br />
====Changes to SPNEGO====<br />
<br />
Wrappers for the naming extension APIs have been added to SPNEGO.<br />
<br />
====Changes to Kerberos 5 mechanism====<br />
<br />
All of the naming extension APIs, save for gss_display_name_ext(), have been implemented in the Kerberos 5 mechanism. Most of the code is to be found in [http://src.mit.edu/opengrok/xref/users/lhoward/authdata/src/lib/gssapi/krb5/naming_exts.c naming_exts.c].<br />
<br />
Previously, a Kerberos 5 mechanism name was represented by the type krb5_principal. This is now a structure containing an authorization data context as well as the principal name:<br />
<br />
<pre><br />
typedef struct _krb5_gss_name_rec {<br />
krb5_principal princ; /* immutable */<br />
k5_mutex_t lock; /* protects ad_context only for now */<br />
krb5_authdata_context ad_context;<br />
} krb5_gss_name_rec, *krb5_gss_name_t;<br />
</pre><br />
<br />
Note that the lock protects ad_context only; the principal name is immutable. The initialization of ad_context is deferred until an attribute it set or authorization data imported. Some helper APIs are provided to manage the creation, copying and destruction of Kerberos 5 mechanism names.<br />
<br />
A summary of changes to existing functions follows, excluding changes required to use the new krb5_gss_name_t data structure:<br />
<br />
=====krb5_gss_init_sec_context()=====<br />
<br />
Note: the terms "flatten" and "export" are used interchangeably below and hereafter.<br />
<br />
* If the initiator name has an authorization data context, then the authorization data for all AD_USAGE_TGS_REQ systems is flattened, and included in the TGS request and stored in the credentials cache<br />
* If the initiator name has an authorization data context, then the authorization data for all AD_USAGE_AP_REQ systems is flattened, and included in the AP request<br />
<br />
=====krb5_gss_import_name()=====<br />
<br />
* Support is added for importing composite names that include authorization data elements (note that re-imported names will lose their authenticated state)<br />
<br />
=====krb5_gss_inquire_name()=====<br />
<br />
This new function is a wrapper around krb5_authdata_get_attribute_types().<br />
<br />
=====krb5_gss_get_name_attribute()=====<br />
<br />
This new function is a wrapper around krb5_authdata_get_attribute().<br />
<br />
=====krb5_gss_set_name_attribute()=====<br />
<br />
This new function is a wrapper around krb5_authdata_set_attribute().<br />
<br />
=====krb5_gss_delete_name_attribute()=====<br />
<br />
This new function is a wrapper around krb5_authdata_delete_attribute().<br />
<br />
=====krb5_gss_map_name_to_any()=====<br />
<br />
This new function is a wrapper around krb5_authdata_export_internal().<br />
<br />
=====krb5_gss_release_any_name_mapping()=====<br />
<br />
This new function is a wrapper around krb5_authdata_free_internal().<br />
<br />
=====krb5_gss_export_name_composite()=====<br />
<br />
This new function is a wrapper around krb5_authdata_export_attributes().<br />
<br />
=====krb5_gss_display_name_ext()=====<br />
<br />
This is not yet implemented.<br />
<br />
=====krb5_gss_accept_sec_context()=====<br />
<br />
* Update to use kg_XXX_name() helper functions<br />
* Extract authorization data context from authentication context and store in source name<br />
<br />
===libkrb5===<br />
<br />
====Changes====<br />
<br />
The following fixes were made to existing functions in libkrb5:<br />
<br />
* The file-based credentials cache did not support negative authorization data types<br />
* krb5_get_cred_from_kdc_opt() did not handle TGS-REQ submitted authorization data correctly: it should be submitted in the first service ticket request only (because in the referral case, the TGS will copy it into the returned ticket), and any returned referral tickets must be marked as containing authorization data so they are not inappropriately re-used<br />
<br />
====Public APIs====<br />
<br />
=====krb5_make_authdata_kdc_issued()=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_make_authdata_kdc_issued(krb5_context context,<br />
const krb5_keyblock *key,<br />
krb5_const_principal issuer,<br />
krb5_authdata *const *authdata,<br />
krb5_authdata ***ad_kdcissued);<br />
</pre><br />
<br />
This function both encodes and signs AD-KDCIssued authorization data (RFC 4120 section 5.2.6.2). A set of authorization data containing a single AD-KDCIssued element is returned to the caller.<br />
<br />
=====krb5_verify_authdata_kdc_issued()=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_verify_authdata_kdc_issued(krb5_context context,<br />
const krb5_keyblock *key,<br />
const krb5_authdata *ad_kdcissued,<br />
krb5_principal *issuer,<br />
krb5_authdata ***authdata);<br />
</pre><br />
<br />
This function both decodes and verifies AD-KDCIssued authorization data (RFC 4120 section 5.2.6.2). The issuer and unwrapped authorization data are returned to the caller.<br />
<br />
====Exported, private APIs====<br />
<br />
=====krb5int_free_data_list()=====<br />
<br />
<pre><br />
void KRB5_CALLCONV krb5int_free_data_list<br />
(krb5_context context, krb5_data *data);<br />
</pre><br />
<br />
Frees an array of krb5_data objects, terminated by the last element's data member being NULL.<br />
<br />
=====krb5_authdata_context_init()=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_authdata_context_init(krb5_context kcontext,<br />
krb5_authdata_context *pcontext);<br />
</pre><br />
<br />
Initialises an authorization data context, loading both built- and plug-in authorization data systems. Note that in the present implementation, the plug-in list is not cached between calls to this function; this may change in the future.<br />
<br />
=====krb5_authdata_context_free()=====<br />
<br />
<pre><br />
void KRB5_CALLCONV<br />
krb5_authdata_context_free(krb5_context kcontext,<br />
krb5_authdata_context context);<br />
</pre><br />
<br />
Releases and authorization data context.<br />
<br />
=====krb5_authdata_get_attribute_types()=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_authdata_get_attribute_types(krb5_context kcontext,<br />
krb5_authdata_context context,<br />
krb5_data **verified_attrs,<br />
krb5_data **asserted_attrs,<br />
krb5_data **all_attrs);<br />
</pre><br />
<br />
Returns the union of attributes supported by all registered authorization data systems. Note that the meaning of all_attrs is unclear from draft-ietf-kitten-gssapi-naming-exts; we may remove this in the future.<br />
<br />
=====krb5_authdata_get_attribute()=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_authdata_get_attribute(krb5_context kcontext,<br />
krb5_authdata_context context,<br />
const krb5_data *attribute,<br />
krb5_boolean *authenticated,<br />
krb5_boolean *complete,<br />
krb5_data *value,<br />
krb5_data *display_value,<br />
int *more);<br />
</pre><br />
<br />
Retrieves an attribute named by <i>attribute</i> from the set of authorization data systems. Note that presently a single attribute type cannot be federated amongst multiple systems. <i>more</i> must be set to -1 on the first call; this function should be called repeatedly until more is 0, or an error returned.<br />
<br />
=====krb5_authdata_set_attribute()=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_authdata_set_attribute(krb5_context kcontext,<br />
krb5_authdata_context context,<br />
krb5_boolean complete,<br />
const krb5_data *attribute,<br />
const krb5_data *value);<br />
</pre><br />
<br />
Sets/adds an attribute value. Whether an attribute is multi-valued or not is left to the authorization data system. To replace an attribute's every value delete the attribute's values first with krb5_authdata_delete_attribute().<br />
<br />
Return values: EEXIST indicates the attribute already exists, EINVAL indicates an invalid argument, ENOENT indicates that the attribute type is not recognised by any authorization data system.<br />
<br />
=====krb5_authdata_delete_attribute()=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_authdata_delete_attribute(krb5_context kcontext,<br />
krb5_authdata_context context,<br />
const krb5_data *attribute);<br />
</pre><br />
<br />
Deletes an attribute.<br />
<br />
=====krb5_authdata_import_attributes()=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_authdata_import_attributes(krb5_context kcontext,<br />
krb5_authdata_context context,<br />
krb5_flags usage,<br />
krb5_authdata **authdata_to_import);<br />
</pre><br />
<br />
Imports a set of authorization data with the given usage. Typically usage will be AD_USAGE_MASK, to indicate to all registered authorization data systems to import the authorization data. There is no way to convey the authorization data's authentication state using this function.<br />
<br />
=====krb5_authdata_export_attributes()=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_authdata_export_attributes(krb5_context kcontext,<br />
krb5_authdata_context context,<br />
krb5_flags usage,<br />
krb5_authdata ***pauthdata);<br />
</pre><br />
<br />
Exports, or flattens, the authorization data context's systems' attributes into a set of Kerberos authorization data. The usage argument is used to determine which systems will be called, so that only the authorization data appropriate to the type of request being made is exported.<br />
<br />
=====krb5_authdata_export_internal()=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_authdata_export_internal(krb5_context kcontext,<br />
krb5_authdata_context context,<br />
krb5_boolean restrict_authenticated,<br />
const char *module_name,<br />
void **ptr);<br />
</pre><br />
<br />
Exports an internal representation of the authorization data state. This might, for example, be used to retrieve an operating system-specific representation of authorization information, such as a struct ucred.<br />
<br />
=====krb5_authdata_free_internal()=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_authdata_free_internal(krb5_context kcontext,<br />
krb5_authdata_context context,<br />
const char *module_name,<br />
void *ptr);<br />
</pre><br />
<br />
Frees an internal representation exported by krb5_authdata_export_internal().<br />
<br />
=====krb5_authdata_context_copy()=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_authdata_context_copy(krb5_context kcontext,<br />
krb5_authdata_context src,<br />
krb5_authdata_context *pdst);<br />
</pre><br />
<br />
Duplicates an authorization data context. In the present implementation this involves reloading the authorization data plug-in list, which could be expensive, so this should be used sparingly.<br />
<br />
=====krb5_auth_con_get_authdata_context()=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_auth_con_get_authdata_context(krb5_context context,<br />
krb5_auth_context auth_context,<br />
krb5_authdata_context *ad_context);<br />
</pre><br />
<br />
Retrieves the authorization data context associated with an authentication context. This is a weak reference; if the caller wishes to retain a reference to this after the authentication context has been destroyed, it should make a copy or take ownership by calling krb5_auth_con_set_authdata_context(... NULL).<br />
<br />
=====krb5_auth_con_set_authdata_context()=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_auth_con_set_authdata_context(krb5_context context,<br />
krb5_auth_context auth_context,<br />
krb5_authdata_context ad_context);<br />
</pre><br />
<br />
Sets the authorization data context associated with an authentication context. The context will be freed by krb5_auth_con_free(), so if the caller wishes to retain ownership it should call krb5_auth_con_set_authdata_context(... NULL). This API usage is in line with the management of other pointer types associated with an authentication context.<br />
<br />
=====encode_krb5_ad_kdcissued()=====<br />
<br />
ASN.1 encoder for AD-KDCIssued.<br />
<br />
=====decode_krb5_ad_kdcissued()=====<br />
<br />
ASN.1 decoder for AD-KDCIssued.<br />
<br />
=====krb5_free_ad_kdcissued()=====<br />
<br />
<pre><br />
void KRB5_CALLCONV<br />
krb5_free_ad_kdcissued(krb5_context context, krb5_ad_kdcissued *val);<br />
</pre><br />
<br />
Free a krb5_ad_kdcissued structure; this structure is only used within libkrb5.<br />
<br />
====Non-exported, private APIs====<br />
<br />
<pre><br />
krb5_error_code<br />
krb5int_authdata_verify(krb5_context context,<br />
krb5_authdata_context,<br />
krb5_flags usage,<br />
const krb5_auth_context *auth_context,<br />
const krb5_keyblock *key,<br />
const krb5_ap_req *ap_req);<br />
</pre><br />
<br />
Verifies and imports authorization data from an AP-REQ.<br />
<br />
===SPI===<br />
<br />
This section describes the service provider interface (SPI) used by the authorization data context functions. Presently plug-ins are initialised upon creation of an authorization data context, however that may not be always the case; plug-ins should be careful to distinguish between plug-in initialisation and request initialisation. State associated with a specific set of authorization data should be managed by the latter.<br />
<br />
The dispatch table is below:<br />
<br />
<pre><br />
typedef struct krb5plugin_authdata_client_ftable_v0 {<br />
char *name;<br />
krb5_authdatatype *ad_type_list;<br />
authdata_client_plugin_init_proc init;<br />
authdata_client_plugin_fini_proc fini;<br />
authdata_client_plugin_flags_proc flags;<br />
authdata_client_request_init_proc request_init;<br />
authdata_client_request_fini_proc request_fini;<br />
authdata_client_get_attribute_types_proc get_attribute_types;<br />
authdata_client_get_attribute_proc get_attribute;<br />
authdata_client_set_attribute_proc set_attribute;<br />
authdata_client_delete_attribute_proc delete_attribute;<br />
authdata_client_import_attributes_proc import_attributes;<br />
authdata_client_export_attributes_proc export_attributes;<br />
authdata_client_export_internal_proc export_internal;<br />
authdata_client_free_internal_proc free_internal;<br />
authdata_client_copy_context_proc copy_context;<br />
authdata_client_verify_proc verify;<br />
} krb5plugin_authdata_client_ftable_v0;<br />
</pre><br />
<br />
<i>ad_type_list</i> is a zero terminated list of authorization data types supported by the system; a system's methods will be invoked once for each type, however they all share the same request context (state).<br />
<br />
All methods are optional unless otherwise indicated.<br />
<br />
====plugin_init()====<br />
<br />
<pre><br />
typedef krb5_error_code<br />
(*authdata_client_plugin_init_proc)(krb5_context context,<br />
void **plugin_context);<br />
</pre><br />
<br />
This is the plug-in initialisation function. It is called at plug-in initialisation. It is called no more than once for each constructed authorization data context, and may be called fewer times (if plug-in information is cached); however, plug-ins should not leak if this function is called multiple times. There is a matching call to fini() for each call to init().<br />
<br />
This function is mandatory to implement.<br />
<br />
====plugin_fini()====<br />
<br />
<pre><br />
typedef void<br />
(*authdata_client_plugin_fini_proc)(krb5_context kcontext,<br />
void *plugin_context);<br />
</pre><br />
<br />
This is the plug-in finalizer.<br />
<br />
This function is mandatory to implement.<br />
<br />
====plugin_flags()====<br />
<br />
<pre><br />
typedef void<br />
(*authdata_client_plugin_flags_proc)(krb5_context kcontext,<br />
void *plugin_context,<br />
krb5_authdatatype ad_type,<br />
krb5_flags *flags);<br />
</pre><br />
<br />
This function is called to indicate the usages supported by the authorization data system for a particular authorization data type. Usages are as follows:<br />
<br />
<pre><br />
#define AD_USAGE_AS_REQ 0x01<br />
#define AD_USAGE_TGS_REQ 0x02<br />
#define AD_USAGE_AP_REQ 0x04<br />
#define AD_USAGE_KDC_ISSUED 0x08<br />
#define AD_USAGE_MASK 0x0F<br />
#define AD_INFORMATIONAL 0x10<br />
</pre><br />
<br />
If AD_INFORMATIONAL is unset, then a plug-in failure will cause an error to be returned to the caller and other systems not invoked (except for non-fatal errors such as an attribute not being found, in which case all systems are tried).<br />
<br />
This function is not mandatory to implement, but a module that does not return flags will never be called.<br />
<br />
====request_init()====<br />
<br />
<pre><br />
typedef krb5_error_code<br />
(*authdata_client_request_init_proc)(krb5_context kcontext,<br />
struct _krb5_authdata_context *context,<br />
void *plugin_context,<br />
void **request_context);<br />
</pre><br />
<br />
Initialises state for a new authorization data context.<br />
<br />
This function is mandatory to implement.<br />
<br />
====request_fini()====<br />
<br />
<pre><br />
typedef void<br />
(*authdata_client_request_fini_proc)(krb5_context kcontext,<br />
struct _krb5_authdata_context *context,<br />
void *plugin_context,<br />
void *request_context);<br />
</pre><br />
<br />
Releases state associated with an authorization data context.<br />
<br />
This function is mandatory to implement.<br />
<br />
====import_attributes()====<br />
<br />
<pre><br />
typedef krb5_error_code<br />
(*authdata_client_import_attributes_proc)(krb5_context kcontext,<br />
struct _krb5_authdata_context *context,<br />
void *plugin_context,<br />
void *request_context,<br />
krb5_authdata **authdata,<br />
krb5_boolean kdc_issued_flag,<br />
krb5_const_principal issuer);<br />
</pre><br />
<br />
Instructs the authorization data system to load its state from serialised authorization data. <i>plugin_context</i> and <i>request_context</i> point to initialised values. The system can assume that <i>authdata</i> only contains authorization data that it recognises.<br />
<br />
If <i>kdc_issued_flag</i> is TRUE, then the imported authorization data was extracted from authenticated KDC issued authorization data. <i>issuer</i> is an optional argument indicating <br />
<br />
====get_attribute_types()====<br />
<br />
<pre><br />
typedef krb5_error_code<br />
(*authdata_client_get_attribute_types_proc)(krb5_context kcontext,<br />
struct _krb5_authdata_context *context,<br />
void *plugin_context,<br />
void *request_context,<br />
krb5_data **verified,<br />
krb5_data **asserted,<br />
krb5_data **all_attrs);<br />
</pre><br />
<br />
Enumerates attribute types supported by the authorization data system. <i>verified</i>, <i>asserted</i>, and <i>all_attrs</i> have the same meaning as defined in draft-ietf-kitten-gssapi-naming-exts-05 (except that <i>verified</i> should be read as <i>authenticated</i>).<br />
<br />
====get_attribute()====<br />
<br />
<pre><br />
typedef krb5_error_code<br />
(*authdata_client_get_attribute_proc)(krb5_context kcontext,<br />
struct _krb5_authdata_context *context,<br />
void *plugin_context,<br />
void *request_context,<br />
const krb5_data *attribute,<br />
krb5_boolean *authenticated,<br />
krb5_boolean *complete,<br />
krb5_data *value,<br />
krb5_data *display_value,<br />
int *more);<br />
</pre><br />
<br />
Retrieves a single attribute value from an authorization data system. If the attribute is unrecognised, ENOENT should be returned. Note that federation of a single attribute across multiple authorization data systems is not supported at present. Authorization data systems must be re-entrant so that more granular systems can be built on top of less granular systems.<br />
<br />
====set_attribute()====<br />
<br />
<pre><br />
typedef krb5_error_code<br />
(*authdata_client_set_attribute_proc)(krb5_context kcontext,<br />
struct _krb5_authdata_context *context,<br />
void *plugin_context,<br />
void *request_context,<br />
krb5_boolean complete,<br />
const krb5_data *attribute,<br />
const krb5_data *value);<br />
</pre><br />
<br />
Sets or adds a single attribute value to an authorization data system. If the attribute is unrecognised, ENOENT should be returned. If the attribute cannot accept any more values (either because it is single-valued or the same value is already present), then EEXIST should be returned.<br />
<br />
====delete_attribute()====<br />
<br />
<pre><br />
typedef krb5_error_code<br />
(*authdata_client_delete_attribute_proc)(krb5_context kcontext,<br />
struct _krb5_authdata_context *context,<br />
void *plugin_context,<br />
void *request_context,<br />
const krb5_data *attribute);<br />
</pre><br />
<br />
Removes an attribute from an authorization data system.<br />
<br />
====export_attributes()====<br />
<br />
<pre><br />
typedef krb5_error_code<br />
(*authdata_client_export_attributes_proc)(krb5_context kcontext,<br />
struct _krb5_authdata_context *context,<br />
void *plugin_context,<br />
void *request_context,<br />
krb5_flags usage,<br />
krb5_authdata ***authdata);<br />
</pre><br />
<br />
Flattens authorization data for the requested usage, for use in a KDC or AP request.<br />
<br />
====export_internal()====<br />
<br />
<pre><br />
typedef krb5_error_code<br />
(*authdata_client_export_internal_proc)(krb5_context kcontext,<br />
struct _krb5_authdata_context *context,<br />
void *plugin_context,<br />
void *request_context,<br />
krb5_boolean restrict_authenticated,<br />
void **ptr);<br />
</pre><br />
<br />
Exports some internal representation of authorization data. If <i>restrict_authenticated</i> is TRUE, only authenticated attributes will be included.<br />
<br />
====free_internal()====<br />
<br />
<pre><br />
typedef void<br />
(*authdata_client_free_internal_proc)(krb5_context kcontext,<br />
struct _krb5_authdata_context *context,<br />
void *plugin_context,<br />
void *request_context,<br />
void *ptr);<br />
</pre><br />
<br />
Releases representation returned by export_internal().<br />
<br />
====copy()====<br />
<br />
<pre><br />
typedef krb5_error_code<br />
(*authdata_client_copy_context_proc)(krb5_context kcontext,<br />
struct _krb5_authdata_context *context,<br />
void *plugin_context,<br />
void *request_context,<br />
void *dst_plugin_context,<br />
void *dst_request_context);<br />
</pre><br />
<br />
Copies state from <i>request_context</i> to <i>dst_request_context</i>. <i>dst_request_context</i> is a newly initialised context.<br />
<br />
The plug-in should not assume that <i>plugin_context</i> and <i>dst_plugin_context</i> are different values.<br />
<br />
This function is mandatory to implement.<br />
<br />
====verify()====<br />
<br />
<pre><br />
typedef krb5_error_code<br />
(*authdata_client_verify_proc)(krb5_context kcontext,<br />
struct _krb5_authdata_context *context,<br />
void *plugin_context,<br />
void *request_context,<br />
const krb5_auth_context *auth_context,<br />
const krb5_keyblock *key,<br />
const krb5_ap_req *req);<br />
</pre><br />
<br />
Verifies authorization data from an AP request. This function need not be implemented by negative authorization systems or systems that expect authorization data to be marked AD-KDCIssued (although is likely that in either case, some validation of the content of the authorization data may be required; this is better done in the import_attributes method).<br />
<br />
===KDC===<br />
<br />
The only changes to the KDC are as follows:<br />
<br />
* Add a session_key argument to kdb_sign_auth_data_req, for database backends that wish to use AD-KDCIssued<br />
* In do_tgs_req(), ensure that the session key is made available to handle_authdata()<br />
* In handle_authdata(), give preference to plug-ins over internal systems<br />
* Rename krb5plugin_authdata_ftable_vX to krb5plugin_server_authdata_ftable_vX (typedefs to the old types are retained)<br />
<br />
==Example==<br />
<br />
===greet_client===<br />
<br />
Note the "greet:greeting" attribute; rather than being issued by the KDC, this was set on the claimant credential's name using gss_set_name_attribute(), and conveyed in the AP-REQ. The acceptor retrieves it like any other attribute, but note it is not marked "Authenticated". (By changing the flags in the greet plug-in, it's also possible to have the data conveyed in the TGS-REQ, and thus the service ticket.)<br />
<br />
<pre><br />
% ./t_namingexts test.keytab<br />
init module "greet", ad_type -42, flags 00000014<br />
init module "mspac", ad_type 128, flags 00000008<br />
Source name: host/test.de.padl.com@DE.PADL.COM<br />
<br />
Attribute mspac: Authenticated Complete <br />
<br />
050000000000000001000000b001000058000000000000000a00000034000000<br />
...<br />
<br />
Attribute mspac:logon-info Authenticated Complete <br />
<br />
01100800cccccccca001000000000000000002006ed28d68cd25ca01ffffffff<br />
...<br />
<br />
Attribute mspac:client-info Authenticated Complete <br />
<br />
802862d64026ca012a0068006f00730074002f00720061006e0064002e006400<br />
...<br />
<br />
Attribute mspac:upn-dns-info Authenticated Complete <br />
<br />
2a00100016004000000000000000000068006f00730074002f00720061006e00<br />
...<br />
<br />
Attribute mspac:server-checksum Authenticated Complete <br />
<br />
100000004b12be9500319e6fb731cb07<br />
<br />
Attribute mspac:privsvr-checksum Authenticated Complete <br />
<br />
76ffffff812d7a725e999ca41dd6e51fdc64d501<br />
<br />
Attribute greet:greeting Complete <br />
<br />
48656c6c6f2c206163636570746f7220776f726c6421<br />
Exported name:<br />
<br />
0402000b06092a864886f71201020200000021686f73742f72616e642e64652e<br />
...<br />
</pre><br />
<br />
===greet_server===<br />
<br />
This plug-in is a simple demonstration of the generation and verification of positive (KDC issued) authorization data.<br />
<br />
==Tools==<br />
<br />
===klist===<br />
<br />
A new option, -d, has been added to klist which enumerates the authorization data types submitted with the TGS request. It does not include authorization data added by the KDC (because that is only available to the service).<br />
<br />
<pre><br />
$ klist -d<br />
Ticket cache: FILE:/tmp/krb5cc_1002<br />
Default principal: Administrator@BERLIN.DE.PADL.COM<br />
<br />
Valid starting Expires Service principal<br />
09/01/09 14:49:15 09/02/09 00:49:15 krbtgt/BERLIN.DE.PADL.COM@BERLIN.DE.PADL.COM<br />
renew until 09/02/09 14:49:15<br />
09/01/09 14:49:20 09/02/09 00:49:15 krbtgt/DE.PADL.COM@BERLIN.DE.PADL.COM<br />
renew until 09/02/09 14:49:15, AD types: -50<br />
09/01/09 14:49:20 09/02/09 00:49:15 host/kreuz.de.padl.com@BERLIN.DE.PADL.COM<br />
renew until 09/02/09 14:49:15, AD types: -50<br />
09/01/09 14:49:20 09/02/09 00:49:15 host/kreuz.de.padl.com@DE.PADL.COM<br />
renew until 09/02/09 14:49:15, AD types: -50<br />
09/01/09 14:49:38 09/02/09 00:49:15 krbtgt/DE.PADL.COM@BERLIN.DE.PADL.COM<br />
renew until 09/02/09 14:49:15<br />
09/01/09 14:49:38 09/02/09 00:49:15 host/kreuz.de.padl.com@BERLIN.DE.PADL.COM<br />
renew until 09/02/09 14:49:15<br />
09/01/09 14:49:38 09/02/09 00:49:15 host/kreuz.de.padl.com@DE.PADL.COM<br />
renew until 09/02/09 14:49:15<br />
</pre><br />
<br />
==Open issues==<br />
<br />
* Should we force RFC 4120 compliance and have krb5_rd_req() fail if any authorization data element not enclosed in AD-IF-RELEVANT is unknown?<br />
* Should we refactor the server side auth data plugin interface to more closely mirror this one?<br />
<br />
==Status==<br />
<br />
Code is in the users/lhoward/authdata branch.<br />
==Review==<br />
<br />
This section documents the review of the project according to [[Project policy]].<br />
It is divided into multiple sections. First, approvals should be listed. To list an approval type<br />
:<nowiki>#~~~~</nowiki><br />
on its own line.<br />
The next section is for summarizing discussion, which should take place on krbdev@mit.edu. Provide links to the archive at http://mailman.mit.edu/pipermail/krbdev/ if appropriate. Blocking objections can be noted with <nowiki>{{project-block}}</nowiki>.<br />
<br />
===Approvals===<br />
<br />
===Discussion===</div>Sbuckleyhttps://k5wiki.kerberos.org/wiki?title=Projects/Lockout&diff=2702Projects/Lockout2009-09-21T15:49:09Z<p>Sbuckley: /* Approvals */</p>
<hr />
<div>{{project-review|2009-09-18}}<br />
<br />
<includeonly>[[Category: early stage projects]]</includeonly><br />
==Background==<br />
<br />
This project aims to provide principal lockout functionality similar to that of Active Directory and the LDAP password policy draft (draft-behera-ldap-password-policy). After a certain number of preauthentication failures with a given time limit, a principal will be locked out from authenticating for a certain period of time.<br />
<br />
Note: lockout only works with principals that require preauthentication.<br />
<br />
==Design==<br />
<br />
===Lockout policy===<br />
<br />
There are three new attributes associated with a Kerberos administrative policy:<br />
<br />
* pw_max_fail (maximum number of attempts before lockout)<br />
* pw_failcnt_interval (period after which bad preauthentication count will be reset)<br />
* pw_lockout_duration (period in which lockout is enforced; a duration of zero means that the principal must be manually unlocked)<br />
<br />
There are four attributes which associated with a principal:<br />
<br />
* last_success (time of last preauthentication success)<br />
* last_failed (time of last preauthentication failure)<br />
* fail_auth_count (number of preauthentication failures)<br />
* lockout time<br />
<br />
Only the latter is actually a new attribute. These four attributes are non-replicated: that is, each KDC has its own set of values. The lockout time is stored in TL data; all other attributes reuse existing fields in the principal entry. (However, the lockout time is surfaced as an explicit attribute at the kadm5 layer.)<br />
<br />
====Mapping to LDAP password policy draft====<br />
<br />
This mapping is provided for convenience only; no attempt has been made to re-use the same attribute names for the LDAP KDB backend, owing to the existing divergence between the two schema.<br />
<br />
{| border="1"<br />
|+ Attribute mapping<br />
! kadm5 attribute !! draft-behera-ldap-password-policy !! KDB LDAP schema<br />
|-<br />
! pw_max_fail<br />
| pwdMaxFailure || krbPwdMaxFailure<br />
|-<br />
! pw_failcnt_interval<br />
| pwdFailureCountInterval || krbPwdFailureCountInterval<br />
|-<br />
! pw_lockout_duration<br />
| pwdLockoutDuration || krbPwdLockoutDuration<br />
|-<br />
! last_success<br />
| - || krbLastSuccessfulAuth<br />
|-<br />
! last_failed<br />
| pwdFailureTime || krbLastFailedAuth<br />
|-<br />
! fail_auth_count<br />
| n(failures in window) || krbLoginFailedCount<br />
|-<br />
! locked_time<br />
| pwdAccountLockedTime || krbPwdPrincipalLockedTime<br />
|}<br />
<br />
===Replication===<br />
<br />
For DB2 backends, per-principal lockout state will be per KDC: replicated updates will not overwrite this information. (Care is taken to both avoid sending non-replicated updates, as well as to avoid updating them.) Because of this, the effective value of pw_max_fail is N * pw_max_fail, where N is the number of KDCs in the realm.<br />
<br />
For LDAP backends, we always attempt to update the lockout count; we assume the LDAP client library can chase referrals, or that it is multi-master. Ideally the administrator should be able to configure some attributes on the LDAP server as non-replicated, but doing so is vendor-specific.<br />
<br />
===Before authentication===<br />
<br />
The following pseudo-code checks whether a principal is already locked:<br />
<br />
<pre><br />
if ( entry.locked_time != 0 &&<br />
( policy.lockout_duration == 0 ||<br />
now < entry.locked_time + policy.lockout_duration ) )<br />
result ::= CLIENT_REVOKED<br />
</pre><br />
<br />
===After authentication===<br />
<br />
<pre><br />
if ( preauth_success )<br />
{<br />
entry.fail_auth_count ::= 0<br />
if (entry.locked_time)<br />
entry.locked_time ::= 0<br />
entry.last_success ::= now<br />
}<br />
else if ( preauth_failure )<br />
{<br />
if (policy.failcnt_interval != 0 &&<br />
now > entry.last_failed + policy.failcnt_interval)<br />
{<br />
/* automatically unlock account after failcnt_interval */<br />
entry.fail_auth_count ::= 0<br />
entry.locked_time ::= 0<br />
}<br />
entry.last_failed ::= now<br />
entry.fail_auth_count ::= entry.fail_auth_count + 1<br />
if (policy.max_fail != 0 &&<br />
entry.fail_auth_count >= policy.max_fail)<br />
{<br />
entry.locked_time ::= now<br />
}<br />
}<br />
</pre><br />
<br />
==Implementation details==<br />
<br />
===KDC===<br />
<br />
Lockout policy is implemented within the backend itself; the previous code that managed static lockouts on the master KDC has been removed. The implementation makes use of the KRB5_KDB_METHOD_CHECK_POLICY_AS and KRB5_KDB_METHOD_AUDIT_AS methods introduced in MIT 1.7, so no architectural changes to the KDC were required.<br />
<br />
====KRB5_KDB_METHOD_CHECK_POLICY_AS====<br />
<br />
This implements the logic described in "before authentication", above. The policy associated with the principal is retrieved from the policy database, and then it is determined whether the account is locked. If the account is locked, KRB5KDC_ERR_CLIENT_REVOKED is returned.<br />
<br />
====KRB5_KDB_METHOD_AUDIT_AS====<br />
<br />
This implements the logic described in "after authentication", above.<br />
<br />
Backend-specific implementation notes follow:<br />
<br />
=====DB2=====<br />
<br />
If the entry needs to be updated, it is updated directly with krb5_db2_db_put_principal(); thus, this modification is not added to the update (replication) log. This should not present a problem as the only attributes being managed are non-replicated ones.<br />
<br />
=====LDAP=====<br />
<br />
Presently, if the entry needs to be updated, it is updated directly with krb5_ldap_put_principal(). If the LDAP server we are connected to supports RFC 4525 (modify increment), then we use that to atomically update krbLoginFailedCount; otherwise, we assert the old value. Unfortunately, it's not possible to assert the old value if the failed count was previously zero, as krb5_ldap_put_principal() has no way of distinguishing between the attribute being previously absent and it being zero-valued. (True, if this was really a problem, we could use some magic TL data to indicate its presence.) So, there will always be a race here. (But there is an issue anyway if the server does not support RFC 4525, because the update may fail.)<br />
<br />
===kdb5_util===<br />
<br />
Two new dump formats are defined:<br />
<br />
* kdb5_util load_dump version 6<br />
* ipropx<br />
<br />
The former is the new default version; the previous version can be requested with the -r13 option to kdb5_util. The ipropx format is specified by passing the -iN option when dumping (where N is a version number indicating the highest version the caller is willing to accept). There is no corresponding option on load, as the header contains the version information.<br />
<br />
The principal change is support for replicating lockout policies: three integer fields are added, corresponding to the three new fields added to the policy structure. The policy dump format now contains (effectively) an extensibility marker, in that unknown fields after the last recognised field are ignored.<br />
<br />
The ipropx format also adds a version number to its header:<br />
<br />
<pre><br />
ipropx version last_sno last_seconds last_useconds<br />
</pre><br />
<br />
Finally, kdb5_util passes the "merge_nra" argument to the database. The backend can use this as a hint to merge non-replicated attributes from the previous instance upon promotion.<br />
<br />
===kprop/iprop===<br />
<br />
This is the most complicated part: in order to provide per-KDC lockout counts, as well as support replication of lockout policy, some changes have been made to the replication protocols. Note that this applies to the DB2 backend only; it's anticipated that LDAP deployments will use the directory server's native replication protocol (except perhaps for some special migration cases).<br />
<br />
We define the following attributes of a principal as non-replicated attributes:<br />
<br />
* last_success<br />
* last_failed<br />
* fail_auth_count<br />
* any TL data values with a negative TL data type<br />
<br />
Non-replicated attributes have the following properties:<br />
<br />
* they are not added to the replication log (by being committed to the database directly, or by being masked out by ulog_conv_2logentry())<br />
* when applying incremental updates, they are masked out<br />
* when applying full updates, the values from the existing database are merged in<br />
<br />
A new RPC is added to the iprop service, IPROP_FULL_RESYNC_EXT. This adds an integer argument indicating the highest ipropx dump format the caller is willing to accept. The iprop service passes this argument to kdb5_util when generating the dump.<br />
<br />
There are no changes to the behaviour of IPROP_FULL_RESYNC; kpropd will fall back to this RPC if IPROP_FULL_RESYNC_EXT is unavailable. Nor are there any changes to GET_UPDATES: there are no backwards incompatible changes to the principal data format (there is no incremental replication of policies).<br />
<br />
===kadmin===<br />
<br />
A new kadm5 API version is defined, KADM5_API_VERSION_3. This adds support for managing lockout policies as well as the per-principal lockout time. The client library will fall back to KADM5_API_VERSION_2 if the remote server does not support the protocol variant. The RPC protocol itself has not changed (no new procedures are added). Instead, additional fields are encoded at the XDR layer based on the negotiated version.<br />
<br />
<pre><br />
#define KADM5_PW_MAX_FAILURE 0x100000<br />
#define KADM5_PW_FAILURE_COUNT_INTERVAL 0x200000<br />
#define KADM5_PW_LOCKOUT_DURATION 0x400000<br />
<br />
#define KADM5_API_VERSION_3 (KADM5_API_VERSION_MASK|0x03)<br />
</pre><br />
<br />
The following field is added to kadm5_principal_ent_rec, conditional on KADM5_API_VERSION_3:<br />
<br />
<pre><br />
krb5_timestamp locked_time<br />
</pre><br />
<br />
The following fields are added to kadm5_policy_ent_rec, conditional on KADM5_API_VERSION_3:<br />
<br />
<pre><br />
krb5_kvno pw_max_fail<br />
krb5_deltat pw_failcnt_interval<br />
krb5_deltat pw_lockout_duration<br />
</pre><br />
<br />
==Tools==<br />
<br />
===kadmin===<br />
<br />
kadmin has been enhanced with the following arguments for managing lockout policies:<br />
<br />
* -maxfailure<br />
* -failurecountinterval<br />
* -lockoutduration<br />
<br />
Additionally, one can pass the -unlock option to modprinc to explicitly force a principal to be unlocked.<br />
<br />
==Open Issues==<br />
<br />
* Currently it is not possible to manually unlock a principal across all KDCs, because the lockout time is a non-replicated attribute. We could make it a replicated attribute, but this would mean that a principal automatically unlocked on the master KDC would then be unlocked on all others (because we do not distinguish between manual and automatic unlocking).<br />
* We need to move towards convergence with the LDAP password policy draft, but that is a bigger issue and I didn't wish to begin addressing that within the limited scope of this project.<br />
<br />
==Status==<br />
<br />
Code is in the users/lhoward/lockout branch.<br />
<br />
Currently have tested:<br />
<br />
* lockout with DB2 backend<br />
* v2 kadmin with v3 kadmind<br />
* v3 kadmin with v3 kadmind<br />
* v3 kpropd with v3 kadmind<br />
<br />
Need to test:<br />
<br />
* lockout with LDAP backend<br />
* v2 kpropd with v3 kadmind<br />
* v3 kpropd with v2 kadmind<br />
* v3 kadmin with v2 kadmind<br />
==Review==<br />
<br />
This section documents the review of the project according to [[Project policy]].<br />
It is divided into multiple sections. First, approvals should be listed. To list an approval type<br />
:<nowiki>#~~~~</nowiki><br />
on its own line.<br />
The next section is for summarizing discussion, which should take place on krbdev@mit.edu. Provide links to the archive at http://mailman.mit.edu/pipermail/krbdev/ if appropriate. Blocking objections can be noted with <nowiki>{{project-block}}</nowiki>.<br />
<br />
===Approvals===<br />
[[User:Sbuckley|Steve]] 15:49, 21 September 2009 (UTC)<br />
<br />
===Discussion===</div>Sbuckleyhttps://k5wiki.kerberos.org/wiki?title=Projects/Lockout&diff=2701Projects/Lockout2009-09-21T15:48:13Z<p>Sbuckley: </p>
<hr />
<div>{{project-review|2009-09-18}}<br />
<br />
<includeonly>[[Category: early stage projects]]</includeonly><br />
==Background==<br />
<br />
This project aims to provide principal lockout functionality similar to that of Active Directory and the LDAP password policy draft (draft-behera-ldap-password-policy). After a certain number of preauthentication failures with a given time limit, a principal will be locked out from authenticating for a certain period of time.<br />
<br />
Note: lockout only works with principals that require preauthentication.<br />
<br />
==Design==<br />
<br />
===Lockout policy===<br />
<br />
There are three new attributes associated with a Kerberos administrative policy:<br />
<br />
* pw_max_fail (maximum number of attempts before lockout)<br />
* pw_failcnt_interval (period after which bad preauthentication count will be reset)<br />
* pw_lockout_duration (period in which lockout is enforced; a duration of zero means that the principal must be manually unlocked)<br />
<br />
There are four attributes which associated with a principal:<br />
<br />
* last_success (time of last preauthentication success)<br />
* last_failed (time of last preauthentication failure)<br />
* fail_auth_count (number of preauthentication failures)<br />
* lockout time<br />
<br />
Only the latter is actually a new attribute. These four attributes are non-replicated: that is, each KDC has its own set of values. The lockout time is stored in TL data; all other attributes reuse existing fields in the principal entry. (However, the lockout time is surfaced as an explicit attribute at the kadm5 layer.)<br />
<br />
====Mapping to LDAP password policy draft====<br />
<br />
This mapping is provided for convenience only; no attempt has been made to re-use the same attribute names for the LDAP KDB backend, owing to the existing divergence between the two schema.<br />
<br />
{| border="1"<br />
|+ Attribute mapping<br />
! kadm5 attribute !! draft-behera-ldap-password-policy !! KDB LDAP schema<br />
|-<br />
! pw_max_fail<br />
| pwdMaxFailure || krbPwdMaxFailure<br />
|-<br />
! pw_failcnt_interval<br />
| pwdFailureCountInterval || krbPwdFailureCountInterval<br />
|-<br />
! pw_lockout_duration<br />
| pwdLockoutDuration || krbPwdLockoutDuration<br />
|-<br />
! last_success<br />
| - || krbLastSuccessfulAuth<br />
|-<br />
! last_failed<br />
| pwdFailureTime || krbLastFailedAuth<br />
|-<br />
! fail_auth_count<br />
| n(failures in window) || krbLoginFailedCount<br />
|-<br />
! locked_time<br />
| pwdAccountLockedTime || krbPwdPrincipalLockedTime<br />
|}<br />
<br />
===Replication===<br />
<br />
For DB2 backends, per-principal lockout state will be per KDC: replicated updates will not overwrite this information. (Care is taken to both avoid sending non-replicated updates, as well as to avoid updating them.) Because of this, the effective value of pw_max_fail is N * pw_max_fail, where N is the number of KDCs in the realm.<br />
<br />
For LDAP backends, we always attempt to update the lockout count; we assume the LDAP client library can chase referrals, or that it is multi-master. Ideally the administrator should be able to configure some attributes on the LDAP server as non-replicated, but doing so is vendor-specific.<br />
<br />
===Before authentication===<br />
<br />
The following pseudo-code checks whether a principal is already locked:<br />
<br />
<pre><br />
if ( entry.locked_time != 0 &&<br />
( policy.lockout_duration == 0 ||<br />
now < entry.locked_time + policy.lockout_duration ) )<br />
result ::= CLIENT_REVOKED<br />
</pre><br />
<br />
===After authentication===<br />
<br />
<pre><br />
if ( preauth_success )<br />
{<br />
entry.fail_auth_count ::= 0<br />
if (entry.locked_time)<br />
entry.locked_time ::= 0<br />
entry.last_success ::= now<br />
}<br />
else if ( preauth_failure )<br />
{<br />
if (policy.failcnt_interval != 0 &&<br />
now > entry.last_failed + policy.failcnt_interval)<br />
{<br />
/* automatically unlock account after failcnt_interval */<br />
entry.fail_auth_count ::= 0<br />
entry.locked_time ::= 0<br />
}<br />
entry.last_failed ::= now<br />
entry.fail_auth_count ::= entry.fail_auth_count + 1<br />
if (policy.max_fail != 0 &&<br />
entry.fail_auth_count >= policy.max_fail)<br />
{<br />
entry.locked_time ::= now<br />
}<br />
}<br />
</pre><br />
<br />
==Implementation details==<br />
<br />
===KDC===<br />
<br />
Lockout policy is implemented within the backend itself; the previous code that managed static lockouts on the master KDC has been removed. The implementation makes use of the KRB5_KDB_METHOD_CHECK_POLICY_AS and KRB5_KDB_METHOD_AUDIT_AS methods introduced in MIT 1.7, so no architectural changes to the KDC were required.<br />
<br />
====KRB5_KDB_METHOD_CHECK_POLICY_AS====<br />
<br />
This implements the logic described in "before authentication", above. The policy associated with the principal is retrieved from the policy database, and then it is determined whether the account is locked. If the account is locked, KRB5KDC_ERR_CLIENT_REVOKED is returned.<br />
<br />
====KRB5_KDB_METHOD_AUDIT_AS====<br />
<br />
This implements the logic described in "after authentication", above.<br />
<br />
Backend-specific implementation notes follow:<br />
<br />
=====DB2=====<br />
<br />
If the entry needs to be updated, it is updated directly with krb5_db2_db_put_principal(); thus, this modification is not added to the update (replication) log. This should not present a problem as the only attributes being managed are non-replicated ones.<br />
<br />
=====LDAP=====<br />
<br />
Presently, if the entry needs to be updated, it is updated directly with krb5_ldap_put_principal(). If the LDAP server we are connected to supports RFC 4525 (modify increment), then we use that to atomically update krbLoginFailedCount; otherwise, we assert the old value. Unfortunately, it's not possible to assert the old value if the failed count was previously zero, as krb5_ldap_put_principal() has no way of distinguishing between the attribute being previously absent and it being zero-valued. (True, if this was really a problem, we could use some magic TL data to indicate its presence.) So, there will always be a race here. (But there is an issue anyway if the server does not support RFC 4525, because the update may fail.)<br />
<br />
===kdb5_util===<br />
<br />
Two new dump formats are defined:<br />
<br />
* kdb5_util load_dump version 6<br />
* ipropx<br />
<br />
The former is the new default version; the previous version can be requested with the -r13 option to kdb5_util. The ipropx format is specified by passing the -iN option when dumping (where N is a version number indicating the highest version the caller is willing to accept). There is no corresponding option on load, as the header contains the version information.<br />
<br />
The principal change is support for replicating lockout policies: three integer fields are added, corresponding to the three new fields added to the policy structure. The policy dump format now contains (effectively) an extensibility marker, in that unknown fields after the last recognised field are ignored.<br />
<br />
The ipropx format also adds a version number to its header:<br />
<br />
<pre><br />
ipropx version last_sno last_seconds last_useconds<br />
</pre><br />
<br />
Finally, kdb5_util passes the "merge_nra" argument to the database. The backend can use this as a hint to merge non-replicated attributes from the previous instance upon promotion.<br />
<br />
===kprop/iprop===<br />
<br />
This is the most complicated part: in order to provide per-KDC lockout counts, as well as support replication of lockout policy, some changes have been made to the replication protocols. Note that this applies to the DB2 backend only; it's anticipated that LDAP deployments will use the directory server's native replication protocol (except perhaps for some special migration cases).<br />
<br />
We define the following attributes of a principal as non-replicated attributes:<br />
<br />
* last_success<br />
* last_failed<br />
* fail_auth_count<br />
* any TL data values with a negative TL data type<br />
<br />
Non-replicated attributes have the following properties:<br />
<br />
* they are not added to the replication log (by being committed to the database directly, or by being masked out by ulog_conv_2logentry())<br />
* when applying incremental updates, they are masked out<br />
* when applying full updates, the values from the existing database are merged in<br />
<br />
A new RPC is added to the iprop service, IPROP_FULL_RESYNC_EXT. This adds an integer argument indicating the highest ipropx dump format the caller is willing to accept. The iprop service passes this argument to kdb5_util when generating the dump.<br />
<br />
There are no changes to the behaviour of IPROP_FULL_RESYNC; kpropd will fall back to this RPC if IPROP_FULL_RESYNC_EXT is unavailable. Nor are there any changes to GET_UPDATES: there are no backwards incompatible changes to the principal data format (there is no incremental replication of policies).<br />
<br />
===kadmin===<br />
<br />
A new kadm5 API version is defined, KADM5_API_VERSION_3. This adds support for managing lockout policies as well as the per-principal lockout time. The client library will fall back to KADM5_API_VERSION_2 if the remote server does not support the protocol variant. The RPC protocol itself has not changed (no new procedures are added). Instead, additional fields are encoded at the XDR layer based on the negotiated version.<br />
<br />
<pre><br />
#define KADM5_PW_MAX_FAILURE 0x100000<br />
#define KADM5_PW_FAILURE_COUNT_INTERVAL 0x200000<br />
#define KADM5_PW_LOCKOUT_DURATION 0x400000<br />
<br />
#define KADM5_API_VERSION_3 (KADM5_API_VERSION_MASK|0x03)<br />
</pre><br />
<br />
The following field is added to kadm5_principal_ent_rec, conditional on KADM5_API_VERSION_3:<br />
<br />
<pre><br />
krb5_timestamp locked_time<br />
</pre><br />
<br />
The following fields are added to kadm5_policy_ent_rec, conditional on KADM5_API_VERSION_3:<br />
<br />
<pre><br />
krb5_kvno pw_max_fail<br />
krb5_deltat pw_failcnt_interval<br />
krb5_deltat pw_lockout_duration<br />
</pre><br />
<br />
==Tools==<br />
<br />
===kadmin===<br />
<br />
kadmin has been enhanced with the following arguments for managing lockout policies:<br />
<br />
* -maxfailure<br />
* -failurecountinterval<br />
* -lockoutduration<br />
<br />
Additionally, one can pass the -unlock option to modprinc to explicitly force a principal to be unlocked.<br />
<br />
==Open Issues==<br />
<br />
* Currently it is not possible to manually unlock a principal across all KDCs, because the lockout time is a non-replicated attribute. We could make it a replicated attribute, but this would mean that a principal automatically unlocked on the master KDC would then be unlocked on all others (because we do not distinguish between manual and automatic unlocking).<br />
* We need to move towards convergence with the LDAP password policy draft, but that is a bigger issue and I didn't wish to begin addressing that within the limited scope of this project.<br />
<br />
==Status==<br />
<br />
Code is in the users/lhoward/lockout branch.<br />
<br />
Currently have tested:<br />
<br />
* lockout with DB2 backend<br />
* v2 kadmin with v3 kadmind<br />
* v3 kadmin with v3 kadmind<br />
* v3 kpropd with v3 kadmind<br />
<br />
Need to test:<br />
<br />
* lockout with LDAP backend<br />
* v2 kpropd with v3 kadmind<br />
* v3 kpropd with v2 kadmind<br />
* v3 kadmin with v2 kadmind<br />
==Review==<br />
<br />
This section documents the review of the project according to [[Project policy]].<br />
It is divided into multiple sections. First, approvals should be listed. To list an approval type<br />
:<nowiki>#~~~~</nowiki><br />
on its own line.<br />
The next section is for summarizing discussion, which should take place on krbdev@mit.edu. Provide links to the archive at http://mailman.mit.edu/pipermail/krbdev/ if appropriate. Blocking objections can be noted with <nowiki>{{project-block}}</nowiki>.<br />
<br />
===Approvals===<br />
<br />
===Discussion===</div>Sbuckleyhttps://k5wiki.kerberos.org/wiki?title=Projects/Services4User&diff=2173Projects/Services4User2009-08-24T12:01:17Z<p>Sbuckley: /* Approvals */</p>
<hr />
<div>{{project-review| 08/28/2009 }} <br />
<br />
Working code is in the [http://src.mit.edu/fisheye/browse/krb5/users/lhoward/s4u users/lhoward/s4u] branch.<br />
<br />
<includeonly>[[Category: early stage projects]]</includeonly><br />
<br />
==Background==<br />
<br />
[http://msdn.microsoft.com/en-us/library/cc246071(PROT.13).aspx [MS-SFU]] describes two extensions to the Kerberos protocol:<br />
<br />
* S4U2Self, or protocol transition, which enables a service to acquire a ticket from an arbitrary principal to itself (the service is trusted to have authenticated the principal)<br />
* S4U2Proxy, or constrained delegation, which enables a service to use a client's ticket to itself to request another ticket for delegation<br />
<br />
Together, these extensions are referred to as Services4User, or S4U.<br />
<br />
The KDC will typically make some authorization checks before permitting the above: for S4U2Self, a flag on the service indicating that it is "trusted to authenticate for delegation" and, for S4U2Proxy, a set of server principals to which the service is permitted to delegate to. There is already some KDC-side support for these protocols in MIT Kerberos 1.7 (although supporting S4U2Proxy requires explicit backend support that is not included with the standard distribution, and S4U2Self does not support some protocol extensions Microsoft made in Windows 2008).<br />
<br />
This proposal is principally concerned with the client-side (or, more correctly, service-side) implementation of S4U, although we have also updated the KDC and kadmin to more completely support S4U2Self.<br />
<br />
==Protocol extensions==<br />
<br />
===S4U2Self===<br />
<br />
Readers are referred to [MS-SFU] for protocol details, but the premise behind S4U2Self is that a service requests a ticket from itself, to itself, presenting some additional preauthentication data containing the name of the user it has presumably authenticated. The KDC, after making any access checks, returns a ticket with the client-name rewritten to that in the preauthentication data. The server name is unchanged.<br />
<br />
There are two types of PA data:<br />
<br />
* [http://msdn.microsoft.com/en-us/library/cc246089(PROT.13).aspx PA-FOR-USER], introduced in Windows 2003, which consists of the "user name" (client principal) and a checksum of the PA data with the TGT session key<br />
* [http://msdn.microsoft.com/en-us/library/cc246091(PROT.13).aspx PA_S4U_X509_USER], introduced in Windows 2008, which includes the TGS-REQ nonce to bind the S4U request to the TGS-REQ, as well as allowing the user to be identified with an X.509 certificate rather than a name.<br />
<br />
The protocol itself is quite complicated, particularly where cross-realm authentication is concerned, so I refer the reader to [MS-SFU] for further details.<br />
<br />
We introduce the following key usage types to krb5.h:<br />
<br />
<pre><br />
/* Defined in [MS-SFU] */<br />
#define KRB5_KEYUSAGE_PA_S4U_X509_USER_REQUEST 26 /* XXX note conflict with above */<br />
#define KRB5_KEYUSAGE_PA_S4U_X509_USER_REPLY 27 /* XXX note conflict with above */<br />
</pre><br />
<br />
and the following PA data types (although PA-FOR-USER is present since 1.7):<br />
<br />
<pre><br />
#define KRB5_PADATA_FOR_USER 129 /* username protocol transition request */<br />
#define KRB5_PADATA_S4U_X509_USER 130 /* certificate protocol transition request */<br />
</pre><br />
<br />
Flags for use with PA_S4U_X509_USER are also defined in k5-int.h:<br />
<br />
<pre><br />
#define KRB5_S4U_OPTS_CHECK_LOGON_HOURS 0400000000 /* check logon hour restrictions */<br />
#define KRB5_S4U_OPTS_USE_REPLY_KEY_USAGE 0x20000000 /* sign with usage 27 instead of 26 */<br />
</pre><br />
<br />
One important change from 1.7 is that the KDC no longer requires that the S4U2Self user principal be an enterprise principal name (UPN). KDCs that assumed this must be updated.<br />
<br />
===S4U2Proxy===<br />
<br />
Again, refer to [MS-SFU] for protocol details, but in this case the service presents a ticket (from an AP-REQ) to the KDC in the additional tickets field, whilst requesting a ticket from itself to the service to which it wishes to delegate. (A new KDC option, CNAME-IN-ADDL-TKT, is used to disambiguate this from user-to-user authentication.) The KDC, after making any access checks, returns a ticket from the additional ticket client to the delegatee.<br />
<br />
The CNAME-IN-ADDL-TKT option is present since 1.7:<br />
<br />
<pre><br />
#define KDC_OPT_CNAME_IN_ADDL_TKT 0x00020000<br />
</pre><br />
<br />
==Proposed APIs==<br />
<br />
The only public interface to Services4User is through GSS-API. We will need to export krb5 APIs for GSS to use, and possibly the kvno tool (for testing); it's probably not necessary to indirect these through an kaccess, though.<br />
<br />
These APIs are defined in gssapi_ext.h and were designed by Nicolas Williams. Note: a mechanism need only implement gss_acquire_cred_impersonate_XXX(), as the mechglue implements gss_add_cred_impersonate_XXX() in terms of it.<br />
<br />
There is presently no support for certificate-based protocol transition.<br />
<br />
===S4U2Self===<br />
<br />
====gss_acquire_cred_impersonate_name====<br />
<br />
<pre><br />
OM_uint32 KRB5_CALLCONV<br />
gss_acquire_cred_impersonate_name(<br />
OM_uint32 *, /* minor_status */<br />
const gss_cred_id_t, /* impersonator_cred_handle */<br />
const gss_name_t, /* desired_name */<br />
OM_uint32, /* time_req */<br />
const gss_OID_set, /* desired_mechs */<br />
gss_cred_usage_t, /* cred_usage */<br />
gss_cred_id_t *, /* output_cred_handle */<br />
gss_OID_set *, /* actual_mechs */<br />
OM_uint32 *); /* time_rec */<br />
</pre><br />
<br />
This function uses <i>impersonator_cred_handle</i> to acquire a credential for <i>desired_name</i>. Only the initiator credential usage is supported by Kerberos. The returned credential can be passed into gss_init_sec_context(), and is a "proxy" credential (it can be used for constrained delegation without an explicit call to gss_acquire_cred_impersonate_cred(); think of it as equivalent to a delegated credential handle returned by gss_accept_sec_context()).<br />
<br />
====gss_add_cred_impersonate_name====<br />
<br />
<pre><br />
OM_uint32 KRB5_CALLCONV<br />
gss_add_cred_impersonate_name(<br />
OM_uint32 *, /* minor_status */<br />
gss_cred_id_t, /* input_cred_handle */<br />
const gss_cred_id_t, /* impersonator_cred_handle */<br />
const gss_name_t, /* desired_name */<br />
const gss_OID, /* desired_mech */<br />
gss_cred_usage_t, /* cred_usage */<br />
OM_uint32, /* initiator_time_req */<br />
OM_uint32, /* acceptor_time_req */<br />
gss_cred_id_t *, /* output_cred_handle */<br />
gss_OID_set *, /* actual_mechs */<br />
OM_uint32 *, /* initiator_time_rec */<br />
OM_uint32 *); /* acceptor_time_rec */<br />
</pre><br />
<br />
===S4U2Proxy===<br />
<br />
====gss_accept_sec_context====<br />
<br />
krb5_gss_accept_sec_context() has been changed such that, if the delegated credential handle parameter is non-NULL, and the verifier credential's usage is GSS_C_BOTH, a delegated credential handle will always be returned, and GSS_C_DELEG_FLAG will be set. This "proxy" credential can be passed directly to gss_init_sec_context() (for constrained delegation).<br />
<br />
====gss_acquire_cred_impersonate_cred====<br />
<br />
<pre><br />
OM_uint32 KRB5_CALLCONV<br />
gss_acquire_cred_impersonate_cred(<br />
OM_uint32 *, /* minor_status */<br />
const gss_cred_id_t, /* impersonator_cred_handle */<br />
const gss_cred_id_t, /* subject_cred_handle */<br />
OM_uint32, /* time_req */<br />
const gss_OID_set, /* desired_mechs */<br />
gss_cred_usage_t, /* cred_usage */<br />
gss_cred_id_t *, /* output_cred_handle */<br />
gss_OID_set *, /* actual_mechs */<br />
OM_uint32 *); /* time_rec */<br />
</pre><br />
<br />
This function uses <i>impersonator_cred_handle</i> to acquire a credential for <i>subject_cred_handle</i>. Only the initiator credential usage is supported by Kerberos. The returned credential can be passed into gss_init_sec_context(). (For the Kerberos mechanism, the S4U2Proxy request is deferred until gss_init_sec_context(), because only at that point is the target name known.)<br />
<br />
For Kerberos, <i>subject_cred_handle</i> will be used to acquire a service ticket to the impersonation principal. This is of somewhat dubious utility, as if you possess the subject's TGT, you can acquire credentials in the normal way. But this interface may be useful to other GSS mechanisms, and is implemented for completeness.<br />
<br />
Note that typically applications will not need to call this function. Constrained delegated credential handles returned by gss_accept_sec_context(), as well as credential handles returned by gss_acquire_cred_impersonate_name(), can be passed directly into gss_init_sec_contxet().<br />
<br />
====gss_add_cred_impersonate_cred====<br />
<br />
<pre><br />
OM_uint32 KRB5_CALLCONV<br />
gss_add_cred_impersonate_cred(<br />
OM_uint32 *, /* minor_status */<br />
gss_cred_id_t, /* input_cred_handle */<br />
const gss_cred_id_t, /* impersonator_cred_handle */<br />
const gss_cred_id_t, /* subject_cred_handle */<br />
const gss_OID, /* desired_mech */<br />
gss_cred_usage_t, /* cred_usage */<br />
OM_uint32, /* initiator_time_req */<br />
OM_uint32, /* acceptor_time_req */<br />
gss_cred_id_t *, /* output_cred_handle */<br />
gss_OID_set *, /* actual_mechs */<br />
OM_uint32 *, /* initiator_time_rec */<br />
OM_uint32 *); /* acceptor_time_rec */<br />
</pre><br />
<br />
==Implementation details==<br />
<br />
Most of the implementation can be found in [http://src.mit.edu/fisheye/browse/krb5/users/lhoward/s4u/src/lib/krb5/krb/s4u_creds.c src/lib/krb5/krb/s4u_creds.c].<br />
<br />
A new flag, KRB5_GC_NO_STORE, has been added to all the krb5_get_credentials APIs, which causes the retrieved credentials to be not stored in the credentials cache. A summary of additional flags (API compatible with Heimdal, although the actual values may differ) is below:<br />
<br />
<pre><br />
#define KRB5_GC_NO_STORE 8 /* do not store in credentials cache */<br />
#define KRB5_GC_FORWARDABLE 16 /* acquire forwardable tickets */<br />
#define KRB5_GC_NO_TRANSIT_CHECK 32 /* disable transited check */<br />
#define KRB5_GC_CONSTRAINED_DELEGATION 64 /* constrained delegation */<br />
</pre><br />
<br />
===S4U2Self===<br />
<br />
====API====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_get_credentials_for_user(krb5_context context, krb5_flags options,<br />
krb5_ccache ccache, krb5_creds *in_creds,<br />
krb5_data *subject_cert,<br />
krb5_creds **out_creds)<br />
</pre><br />
<br />
krb5_get_credentials_for_user() does the following:<br />
<br />
* checks the credentials cache for an existing ticket<br />
* identifies the user's realm using an AS-REQ, if a certificate or enterprise principal name is being used<br />
* acquires a TGT to the user's realm<br />
* makes the S4U2Self request, following any referrals<br />
* if KRB5_GC_NO_STORE is unset, stores the ticket in the credentials cache<br />
<br />
Both variants of S4U2Self are supported.<br />
<br />
The following data types are introduced into k5-int.h, along with their complementary encode/decode/free routines. Note that these types are not exposed via exported APIs.<br />
<br />
<pre><br />
typedef struct _krb5_pa_for_user {<br />
krb5_principal user;<br />
krb5_checksum cksum;<br />
krb5_data auth_package;<br />
} krb5_pa_for_user;<br />
<br />
typedef struct _krb5_s4u_userid {<br />
krb5_int32 nonce;<br />
krb5_principal user;<br />
krb5_data subject_cert;<br />
krb5_flags options;<br />
} krb5_s4u_userid;<br />
<br />
typedef struct _krb5_pa_s4u_x509_user {<br />
krb5_s4u_userid user_id;<br />
krb5_checksum cksum;<br />
} krb5_pa_s4u_x509_user;<br />
</pre><br />
<br />
====KDC====<br />
<br />
* S4U2Self client names are no longer required to be an enterprise principal name, as they were in 1.7<br />
* the Windows 2008 variant of S4U2Self is supported<br />
* kadmin has been updated to support the ok_to_auth_as_delegate (and, for completeness) no_auth_data_required attributes. Services with ok_to_auth_as_delegate are allowed to use S4U2Self<br />
<br />
===S4U2Proxy===<br />
<br />
====API====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_get_credentials_for_proxy(krb5_context context,<br />
krb5_flags options,<br />
krb5_ccache ccache,<br />
krb5_creds *in_creds,<br />
krb5_ticket *evidence_tkt,<br />
krb5_creds **out_creds)<br />
</pre><br />
<br />
krb5_get_credentials_for_proxy() does the following:<br />
<br />
* checks the credentials cache for an existing ticket<br />
* makes the S4U2Proxy request<br />
* if KRB5_GC_NO_STORE is unset, stores the ticket in the credentials cache<br />
<br />
Note: most of the logic for this is now in krb5_get_credentials(), so we could probably remove this function entirely. The one difference is that, because krb5_get_credentials() doesn't have access to the decrypted second ticket, verifying the KDC response correctly is not possible. On the other hand, GSS now uses krb5_get_credentials() because it also has no access to the decrypted second ticket (although it does have enough information to verify that the KDC supports S4U2Proxy).<br />
<br />
I am in favour of removing this API if we wish to remove the kvno support for S4U2Proxy.<br />
<br />
====KDC====<br />
<br />
There are no changes from 1.7. Note that the backend must validate that the evidence ticket was issued by the KDC. In the Windows case, this is done by validating the KDC signature on the PAC. (The MIT KDC will reject constrained delegation requests unless the backend implements a SIGN_AUTH_DATA method.)<br />
<br />
==Future ideas==<br />
<br />
* Do we wish to offer APIs for certificate based S4U2Self?<br />
* Would it be interesting/useful to offer a SAML variant of S4U2Self?<br />
<br />
==Tools==<br />
<br />
The kvno utility has been updated to support the -U user option (for S4U2Self) and the -P option (for S4U2Proxy, which changes the meaning of the additional service arguments to be delegatees).<br />
<br />
==Status==<br />
<br />
Implementation-wise, S4U2Self and S4U2Proxy are presently working against Windows 2008. A test program can be found in src/tests/gssapi/t_s4u.c. I have tested both a single- and two-realm (child domain) setup. Also, S4U2Self has been tested against a MIT 1.8 KDC.<br />
<br />
==Review==<br />
<br />
This section documents the review of the project according to [[Project policy]].<br />
It is divided into multiple sections. First, approvals should be listed. To list an approval type<br />
:<nowiki>#~~~~</nowiki><br />
on its own line.<br />
The next section is for summarizing discussion, which should take place on krbdev@mit.edu. Provide links to the archive at http://mailman.mit.edu/pipermail/krbdev/ if appropriate. Blocking objections can be noted with <nowiki>{{project-block}}</nowiki>.<br />
<br />
===Approvals===<br />
sbuckley<br />
<br />
===Discussion===</div>Sbuckleyhttps://k5wiki.kerberos.org/wiki?title=KrbWeb_Outline_of_Work&diff=710KrbWeb Outline of Work2008-10-09T14:34:41Z<p>Sbuckley: /* Suggested Activities */</p>
<hr />
<div>'''<font size="5">Towards Kerberizing Web Identity and Services</font>'''<br />
<br />
<br />
<br />
<font size="5">Abstract</font><br />
<br />
Today, authentication and authorization are addressed in an incoherent, often site-specific fashion on the Internet overall and the Web specifically. This situation stems from many factors including the evolution, design, implementation, and deployment history of HTTP and HTTP-based systems in particular, and Internet protocols in general. Kerberos is a widely-implemented and widely-deployed authentication substrate with a long history in various communities and vendor products. Here we outline the history of "Web identity", "Web Single Sign-On", "Web Services" and "Web Services Stacks", and present how Kerberos fits into this picture today. Relevant "user stories" are then presented, as well as technological use cases along with a taxonomy of extant Web-relevant security technologies. From this we present an overall general architecture model and suggested activities for working towards more cohesive and widely deployed Kerberos-based Web authentication infrastructure. <br />
<br />
<br />
;Authors (alphabetical):<br />
:Jeff Hodges, Kings Mountain Systems<br />
:Josh Howlett, JANET<br />
:Leif Johansson, Stockholm University<br />
:RL "Bob" Morgan, Internet2 / University of Washington<br />
<br />
[[Category:Kerberos and web pages]]<br />
<br />
==Introduction==<br />
<br />
In this paper we attempt to provide a high-level overview of how authentication of end users, and to some extent their authorization, fits into the Web landscape -- and Kerberos' place in that picture along with its strengths and gaps. We follow with a brief presentation of "user stories" -- simple statements of what end users, deployers, and enterprises desire in terms of their security-related experiences when using the Web. Next, we discuss technological use cases, specific web-relevant security technologies, and some overall requirements such technologies should meet. Then we touch briefly on implementation and deployment technologies -- e.g. browsers and application development libraries, before closing the paper with a presentation of an architectural model, suggested activities, recommendations, and analysis. <br />
<br />
==Acknowledgments==<br />
<br />
The authors are grateful for the support of the [http://www.kerberos.org/ MIT Kerberos Consortium]. We also acknowledge and thank Love Hörnquist Åstrand, Steve Buckley, Michael Gettes, Ken Raeburn, Tom Yu, and Larry Zhu for their input and comments.<br />
<br />
==Related Pages==<br />
<br />
[[KrbWeb_Backlog|"Backlog" Page]] <br />
<br />
Steve's [[KrbWeb_Buckley-BoardMtgPresoAndNotes-2008-07-24|"slides and notes from the Consortium Board meeting"]] from 24-Jul-2008<br />
<br />
==Overview==<br />
<br />
===A Short History of Web Identity===<br />
<br />
For a system that was originally intended to facilitate collaboration between physicists, it is remarkable how ubiquitous Web technologies have become. It is no exaggeration to claim that the HTTP protocol defined in RFC 2616 is the ''de facto'' transport for applications operating between internetworked hosts. This is due, in part, to HTTP's success in meeting its authors' goal of defining a generic, stateless, protocol which can be used for many tasks beyond its use for hypertext transfer', but perhaps mainly to the convenience of using a common transport in an Internet composed of networks with diverse capabilities and policies.<br />
<br />
====The Primordial Identity Soup====<br />
<br />
HTTP's standard authentication capabilities, [http://en.wikipedia.org/wiki/Basic_access_authentication Basic] and [http://en.wikipedia.org/wiki/Digest_access_authentication Digest], are specified in RFC 2617. The most obvious deficiencies of these protocols, such as capture of credentials on-the-wire, were widely appreciated at the time, and the response was to remedy them using SSL (and subsequently TLS). However, the user experience provided by browsers implementing these methods was deemed by many as "poor" (for example, the bland username and password dialog) and also was effectively "unbrandable". So while these methods were deployed within the Enterprise (typically to protect Intranets and programmatic web services), they were largely ignored by the broader Web development community, where so-called [http://en.wikipedia.org/wiki/Form_based_authentication Form-based authentication] became dominant.<br />
<br />
Unlike Basic and Digest authentication, which are typically implemented in the web server -- at a system level -- Form-based authentication is typically implemented at the web application level. The application uses XHTML elements to construct a Form, typically consisting of username and password fields (and increasingly also a ''captcha'' dialog). The user enters his credentials into the Form, which is submitted to the application using the HTTP POST method.<br />
<br />
The paradigm of using TLS-protected Forms for user authentication and X.509-based server authentication became extremely common, and it remains the most common approach to authentication and establishing trust. However, this paradigm is not without drawbacks. The most significant problems include:<br />
<br />
* [http://en.wikipedia.org/wiki/Phishing Phishing] of credentials<br />
* Excessive numbers of credentials<br />
* Inconsistent and complex user experience<br />
* Privacy violations<br />
* Ad-hoc and unstandardized<br />
* not a system-level approach<br />
<br />
These drawbacks can be viewed as symptoms of this paradigm's failure to scale with the explosive growth of the Web. This confounded early attempts to improve HTTP authentication (for example, attempts to leverage [http://en.wikipedia.org/wiki/Simple_Authentication_and_Security_Layer SASL] (RFC 4422)) which might have permitted the use of a Kerberos mechanism) because the Web had not yet attained the scale and significance where the symptoms had developed to the chronic level that we observe today, and so consequently there was no obvious case for significant alterations to protocols or implementations.<br />
<br />
====Birth of Web Single Sign-On and Identity====<br />
<br />
The need for some notion of "Web [http://en.wikipedia.org/wiki/Single_sign-on single sign-on]" -- termed "Web SSO" -- was perceived by various disparate parties from the mid-1990s onwards. Often this occurred in a commercial, higher educational, or governmental enterprise setting. Many roughly similar solutions were concocted roughly in parallel, and the practice continues right to the present day. Some examples are the [http://www.stanford.edu/services/webauth/ WebAuth] system concocted and deployed at Stanford University (mid-to-late 1990s), [http://en.wikipedia.org/wiki/Pubcookie PubCookie] from University of Washington, and Yale's [http://www.ja-sig.org/products/cas/ Central Authentication System (CAS)].<br />
<br />
The first OS-vendor-driven effort to improve Web authentication, and provide users a cohesive notion of web-based "identity" as well as Web SSO, was [http://en.wikipedia.org/wiki/Windows_Live_ID Microsoft's Passport service]. However, Passport failed to gain any lasting traction, beyond Microsoft's own services, for reasons of trust. Technically, Microsoft's initial Passport SSO protocol was flawed, reducing confidence in this aspect of the system. More critically, Passport was perceived by potential consumers of the system - and others - as a vehicle that could hand Microsoft a monopoly in Internet identity. Passport's importance began to diminish in 2004 when Microsoft canceled the contracts with the most significant consumers of Passport, including eBay and Monster.com.<br />
<br />
In parallel with Passport, a Technical Committee (TC) within [http://www.oasis-open.org OASIS] -- the [http://www.oasis-open.org/committees/security Security Services TC (SSTC)] -- was established to define [http://en.wikipedia.org/wiki/Saml SAML], an open XML-based identity system derived from two earlier specifications, S2ML and AuthXML. SAML was the first, and is the most successful, technology for [http://en.wikipedia.org/wiki/Federated_identity federated identity]. The SAML specifications were quickly leveraged by the [http://en.wikipedia.org/wiki/Single_sign-on Liberty Alliance], a broad vendor and "deploying organizations" consortium initially reacting to the perceived threat from Passport, for their own [http://www.projectliberty.org/liberty/resource_center/specifications/specifications_archives/liberty_alliance_phase_i_1_0_specifications ID-FF (Identity Federation Framework)] specifications.<br />
<br />
In contrast to Passport, which was conceived as a wholly centralized identity system, federated identity is an approach in which a website (normally called the Service Provider, or SP) delegates responsibility for user authentication (and sometimes user authorization) to a trusted third party (normally called an Identity Provider, or IdP) with which the user is affiliated. The relationship between one or more IdP(s) and one or more SP(s) that have federated is often called a "federation" (the Liberty Alliance refers to this as a Circle of Trust).<br />
<br />
====Evolution Towards Federated Identity====<br />
<br />
However, Federated Identity does not replace Form-based authentication, nor was it ever intended to. Federated identity is independent of the authentication technique used by the IdP (although the authentication method may sometimes be a property of the authentication event about which the IdP informs the SP). Federated Identity can, however, be used to move the deployment of Form-based authentication from the SP to the IdP, alleviating the SP of the burden of authenticating user credentials and implementing the processes require to issue and manage those. It also means that, in general, a user only needs to maintain a single identity per federation.<br />
<br />
SAML, and the Liberty Alliance specifications in particular, are perceived to focus primarily on finding solutions for Enterprise and eCommerce use-cases. In the case of the Liberty Alliance framework, the federated identity technology is complemented by non-technological deliverables, such as federation governance models, security best practices, and deployment guidelines. While comprehensive, some within the Web development community viewed this approach to federated identity as unnecessarily complex for various use cases - and not scaleable to the Internet community at large (though these contentions are debatable). More philosophically, there was also opposition to what many (largely incorrectly) perceived as SAML's leanings towards "Enterprise-centric" identity, in which the user's identity is associated with some corporate entity issuing assertions on the user's behalf, than it is with the natural person represented by that identity.<br />
<br />
The [http://www.openid.net/ OpenID] protocol, and the "user-centric" movement that espouses it, is the clearest manifestation of this.<br />
<br />
Many argue that the claimed "user-centric" properties of OpenID are a distraction, and that SAML can be profiled equivalently such that it is no less "user-centric". While accurate, OpenID implementations, being optimized for abject simplicity, can be easier to deploy than some SAML implementations. For example, OpenID is not burdened by any notions of trust, whose subtleties add significantly to the SAML specification, and thus implementation and deployment complexity of SAML profiles reflecting and accommodating trust nuances. <br />
<br />
Relieved of these burdens, OpenID has seen significant deployments - but, almost invariably, only for applications where the consumer of the OpenID identity does not require a significant level of trust in the assertion (which, owing to the way in which the protocol operates, is equivalent to the level of trust that can be attributed to the DNS). Therefore, while OpenID is satisfactory for low-value applications it is perceived by many as typically not appropriate for higher-value applications.<br />
<br />
====From Identity Monopoly to Identity Metasystem====<br />
<br />
The recognition of the diversity of identity technologies, and the requirements of the applications consuming the identities, is a key feature of Kim Cameron's widely referenced ''Laws of Identity'' in which he proposes the need for (or perhaps the inevitable reality of) the ''Identity Metasystem''. Cameron was a vocal critic of Microsoft Passport and was subsequently recruited by Microsoft as its Chief Identity Architect. In the ''Laws of Identity'', Cameron proposes seven axiomatic properties of identity systems that, he claims, must be observed for any identity system to succeed. While the ''Laws of Identity'' have been subject to criticism, it is a nonetheless important document in that it expounds the philosophical underpinnings of the identity architecture being developed by Microsoft in the wake of Passport.<br />
<br />
====Emergence of Web Services====<br />
<br />
The notion of "Web Services" emerged in the late 1990s, becoming widely visible with IBM and Microsoft et al's submission of the ''Simple Object Access Protocol (SOAP) 1.1'' specification to the W3C (as a "W3C Note") in the spring of 2000. SOAP consists of highly tailorable XML-encoded protocol messages capable of encapsulating arbitrary data. They can be employed in either remote procedure call (RPC) or message passing styles. <br />
<br />
"Web Services" were felt by these practitioners to essentially exclusively consist of SOAP messages conveyed by HTTP, effectively excluding other extant protocols with well-defined URI schemes, e.g. FTP, LDAP, IMAP, etc., from the "web services party". <br />
<br />
A year later, IBM-Microsoft produced the ''Web Services Description Language (WSDL) 1.1'' W3C note in Spring 2001. It essentially defines an "interface description language" for SOAP-based protocols, which is purportedly an aid to developers. <br />
<br />
Security in the SOAP context -- authentication, confidentiality, and integrity protection -- was originally left as an afterthought, i.e. as an exercise for developers and deployers. Two years after SOAP's initial emergence, the WS-Security specification was publicly announced by IBM and Microsoft in Spring 2002. It specifies a framework for attaching essentially any type and/or number of "security tokens" (such as a Kerberos ticket) to SOAP messages, as well as cryptographically binding tokens to messages. This provides a means for data origin authentication on a per-message basis. This can be built upon to provide high-level security abstractions, e.g. for streams of messages.<br />
<br />
By then, 2002, it was clear that there was no industry-wide cohesive vision of what constituted "web services", other than a nominal agreement of them being SOAP-based, nor was there a single "home" for web services specification development. The lack of a home was, and still is, illustrated by the work on various aspects of the broad web services notion being spread across a plethora of fora: privately (e.g. the IBM-Microsoft "workshop process"), in the W3C, in the Web Services Interoperability (WS-I) organization, in OASIS, and in the Liberty Alliance Project.<br />
<br />
====Web Services Stacks and Identity====<br />
<br />
Given the fragmentation of the broader web services community noted above, it is not surprising that more than one "web services stack" has emerged. By "stack" we mean a full-featured specification suite addressing messaging and transport binding, interface description language, security framework, resource discovery, authentication and security token services, and web single sign-on. <br />
<br />
The two major extant SOAP-based web services stacks are the Liberty Alliance's ''Identity Web Services Framework'' (ID-WSF) and IBM-Microsoft-Et-Al's ''WS-*'' (dubya-ess star). Both meet the definition of "stack" given above. Both utilize SOAP-based messages and employ WS-Security as well as WSDL. However, they diverge as one goes further "up the stack". Yet, both stacks feature the key notion of federated identity being conveyed between the browser-accessible web-based "world" and back-end "web services"-based systems. <br />
<br />
ID-WSF specifies use of SAMLv2-based security tokens (though other token types may be profiled for use) and leverages SAMLv2's Web Browser SSO Profile for web single sign-on. The authentication service leverages a SASL-based authentication exchange thus supporting the plethora of extant SASL mechanisms, e.g. Kerberos. ID-WSF is designed with the notion of a user's identity being a first-order component of the context of interactions. For example, discovery service requests are implicitly made in the context of the identity of the user causing the request to be made, e.g. "'''I''' am asking for '''my''' service locations", as well as being able to express target identity contexts, e.g. "'''I''' am asking for '''her''' calendar service". While ID-WSF's specifications explicitly allow for extensions and profiling, where these are possible are carefully constrained. ID-WSF was designed to be concretely implementable and deployable directly from the original specification suite with no further profiling required.<br />
<br />
The composition of the WS-* stack is somewhat difficult to pin down in that IBM and Microsoft each have their own perspective on what constitutes the WS-* stack, and also because the specifications are strewn across a landscape including their private "workshop process", as well as OASIS, W3C, and WS-I. The WS-* specifications are designed to be freely "composable" -- one can pick and choose which ones to utilize in solving a particular use case. This is often cited as the rationale for the specifications' style of unconstrained XML element extensibility (in contrast to ID-WSF's constrained approach). In order to concretely implement WS-* to solve some given use case(s), one must leverage the WS-I "profile" specifications in concert with the WS-* protocol specifications. The notion of identity attained in the system will depend upon the selection of which aspects of WS-* are implemented as well as the profiling choices made.<br />
<br />
===Kerberizing Web Identity & Services===<br />
<br />
The use of Kerberos as an authentication mechanism for web applications has a long history in certain communities, notably Higher Education and Research as well as large-scale Enterprises. Extending Kerberos to address web authentication in these communities was typically driven by a desire to reuse technology which was well understood and widely deployed. This motivation has become even more pronounced with the wide deployment of [http://en.wikipedia.org/wiki/Active_directory Active Directory]. There is, therefore, a significant body of experience relating to the use of Kerberos for the Web and related technologies (Web services, XML, identity federations, and so forth) which can be used to formulate a strategy for future work in this field.<br />
<br />
This document tries to describe a number of missing pieces of the puzzle which when combined can help the Kerberos Consortium release the full potential of Kerberos as an authentication technology for the web.<br />
<br />
====Credentials Delegation====<br />
<br />
An important feature of Kerberos is the ability to forward tickets -- i.e the ability to delegate credentials to remote services where they can be used by that service to act on behalf of the user. When the services are simple traditional host-based services (e.g. ssh or telnet) the credentials-delegation picture is relatively uncomplicated: it just works. This picture changes dramatically with the advent of web-based applications needing access to user credentials in order to authenticate to kerberized backend services. This is sometimes referred to as "n-tier". The classical example is the web frontend to a kerberiezd IMAP server. As long as the authentication mechanism for the web application is basic access authentication or form-based authentication, i.e it has access to the user password, the web application can obtain a TGT -- but at the cost of compromising the secrecy of the user's Kerberos password. <br />
<br />
=====Enterprise Web SSO and Credentials Delegation=====<br />
<br />
Identity management in large-scale deployments of web applications has resulted in the deployment of governance solutions for web single sign-on (Web SSO). Open source products like [http://shibboleth.internet2.edu/ Shibboleth], [http://www.stanford.edu/services/webauth/ WebAuth], [http://www.ja-sig.org/products/cas/ CAS], and [http://en.wikipedia.org/wiki/Pubcookie PubCookie], as well as commercial products like [http://www.passlogix.com/ Passlogix], [http://www.actividentity.com/ ActivIdentity], [http://www.avencis.net/ Avencis SSOX], are often deployed as central points of authentication for multiple web applications in the enterprise. These systems are often seen as meeting several different requirements involving compliance (e.g. [http://en.wikipedia.org/wiki/Sarbanes_oxley Sarbanes-Oxley] (S-OX)) and auditing. However, the enterprise SSO makes Kerberos credentials delegation quite difficult. Some products (e.g. PubCookie) have the ability to forward TGTs from the point of authentication to the web application but these are exceptions rather than the rule.<br />
<br />
Combining enterprise SSO with kerberized backend services is often quite difficult if one wants to hang on to the "[http://www.cs.princeton.edu/~jrex/teaching/spring2005/reading/saltzer84.pdf end-to-end principle]" -- which in this context means to maintain a cryptographic connection between the ticket sent to the backend service and the end user credential used to originally authenticate with the IdP in the single sign-on environment. The success of Active Directory led to the introduction (by Microsoft) of a new way to do credentials delegation: [http://msdn.microsoft.com/en-us/library/aa480585.aspx s4u2self] (aka "constrained delegation"). In this model -- as opposed to the end-to-end end model -- the KDC delegates the right to a "service" principal to impersonate a user to a set of services. In our webmail example the service principal would be associated with the web application itself and the KDC would delegate to it the right to obtain IMAP service tickets for any user. The idea is that the web frontend is trusted to properly authenticate the user, by whatever means, allowing the KDC to delegate part of its responsibility to this service principal. This idea is sometimes called "air gap" security and while not as strong as end-to-end n-tier authentication it is nevertheless often good enough for many applications.<br />
<br />
=====User Driven Credentials Delegation=====<br />
<br />
The advent of "Web 2.0" web applications, notably social networking sites like Facebook, Linked-In and large scale software-as-a-service (SaaS) providers like Hotmail and gmail led to the creation of yet another type of credentials delegation paradigm: user driven credentials delegation whereby a user is asked to provide authorization for each time a service needs to be able to access another service with the rights of that user. The typical example is Facebook wanting access to the users Hotmail address book in order to setup relationships with "buddies" on Facebook. The OAuth protocol (cf below) has built-in support for this type of case-by-case credentials delegation. Although the Kerberos V5 specification, RFC 4120, has allowances for implementations to craft such "user driven" behavior, such behavior is not typically implemented and/or materialized to users. <br />
<!-- There is no correspondence to this model in Kerberos today. --><br />
<br />
However, credentials delegation in Kerberos <!-- , given its lack of support for user-driven credentials delegation and the gaps in the model that does exist, --> still remains one of its truly unique properties -- no other widely deployed security protocol has the ability to pass credentials between members of a multi-tiered architecture.<br />
<br />
====Efficiency Concerns====<br />
<br />
With Active Directory came the notion of the PAC - a data structure included in an extension to the ticket which includes what amounts to authorization data associated with the session. We will return to this notion below when discussing Level of Assurance (LoA) transport and SAML profiles for Kerberos. However it is worth noting that the inclusion of authorization information in the Kerberos protocol has adverse side-effects. When Kerberos is used as an HTTP authentication mechanism (cf Negotiate below) as opposed to being hidden behind an SSO abstraction layer such as the SAML Web Browser SSO Profile or a commercial Web SSO such as any of the products listed above - any extension to the ticket that adds significantly to the payload of the HTTP handshake may be noticeable by users in terms of overall system response time. <br />
<br />
Experiences with Active Directory in large-scale deployments (with many groups) shows that the PAC can often grow to ~20k which has a performance impact on HTTP especially when the browser needs to open and process several connections in order to render a single "page" to the user. Modern browsers are optimized for keeping multiple HTTP connections open in parallel and it is not uncommon for single user views ("pages") to result in 100s of connections to the server. In order to address this problem any protocol and/or authentication mechanism employing Kerberos will need a form of session identifier or other way of efficiently re-using the fact of initial authentication for multiple subsequent connections -- for example the "session resumption" feature of TLS (RFC 4346).<br />
<br />
===Summary===<br />
<br />
The Web authentication landscape is therefore highly complex and diverse, both in terms of technology and politics. The contrast with the Enterprise space, where Kerberos is virtually ubiquitous, could hardly be starker. The goal of this document is to explore how Kerberos might be used as a bridge over the "authentication gap" that separates these worlds.<br />
<br />
The document uses the following methodology :<br />
<br />
* First, a set of user stories are presented. A user story describes a particular outcome that a user wants.<br />
* Secondly, a set of use-cases are developed that bind the user stories into scenarios that can be generalized to address other similar problems.<br />
* Thirdly, there is a discussion of all existing technologies that might contribute.<br />
* Finally, a number of activities are proposed that are intended to supplement or extend these technologies in order to realize the use-cases.<br />
<br />
==User Stories==<br />
<br />
A user story is a statement describing a specific desire by a specific type of user in order to achieve a specific value. User stories often appear in agile development frameworks (e.g. SCRUM) and are used as a tool for evaluating the effectiveness of development activities. A user story often takes the form of a single sentence of the form "A wants to do B in order to achieve C".<br />
<br />
We have chosen to describe requirements as user-stories in an attempt to make the requirements easier to evaluate from the point of view of various stake-holders.<br />
<br />
===Notes===<br />
<br />
The term "web-based" is used to denote both "Internet-based" sites/services (connotes likelihood of "third-party"-ness in the overall interactions involved (e.g. ISPs, hosting providers, site/service-providing entity (e.g. bank, store, etc) may figure in the packets' path between user and the site/service process(es), and "enterprise-based" (aka "intranet-based") sites/services (connotes possibility of a range from "single-party"-ness to high "third-party"-ness, depending upon the characteristics of the "enterprise". <br />
<br />
The term "site/services" is simply used at this time to consciously acknowledge the range of web-based possibilities from simple static web pages, to wikis, to fancy full-featured sites offering a range of "services", e.g. Google, Yahoo, AOL, etc. <br />
<br />
A "site/service-providing entity" is also referred to as a "service provider (SP)".<br />
<br />
<br />
===General: Users===<br />
<br />
====Simplicity====<br />
<br />
<pre><br />
US1: Users want to reduce the number of sign-on technologies <br />
and credentials that they are required to use to access web-based <br />
sites/services.<br />
</pre><br />
<br />
====Transparency====<br />
<br />
<pre><br />
UT1: Users want to reduce the number of authentication steps taken <br />
when using online services.<br />
</pre><br />
<pre><br />
UT2: Users want to use mobile devices when authenticating to online <br />
services.<br />
</pre><br />
<br />
====Flexibility====<br />
<pre><br />
UF1: People want to assert different identity information in different <br />
contexts, e.g. to be able to "don" different roles when interacting with <br />
either the same or different site(s)/service(s). E.g. to be able to <br />
interact with a given bank in the role of either an individual consumer, <br />
or an officer of a company which is also the same bank's customer. <br />
</pre><br />
<br />
<pre><br />
UF2: Users want to use untrusted devices (e.g.. an airport Internet kiosk, <br />
a borrowed device) to access sites/services without compromising their <br />
credentials. <br />
</pre><br />
<br />
===General: Service Providers===<br />
<br />
<pre><br />
S1: Service providers that consume identities from third-party identity <br />
providers want to reduce and/or minimize the number of sign-on <br />
technologies that they are required to support.This applies to both <br />
Internet-based and enterprise-based SPs. <br />
</pre><br />
<br />
<pre><br />
S2: Service providers want to be able to manage and minimize the risks <br />
they assume when providing authenticated web-based sites/services. <br />
</pre><br />
<br />
===Financial Services===<br />
<br />
<pre><br />
FS1: Web-based financial services want to avoid phishing, and have their <br />
experience adhere to the "General: Service Providers" user-stories noted <br />
above. <br />
</pre><br />
<pre><br />
FS2: Customers of web-based financial services want to avoid phishing.<br />
</pre><br />
<pre><br />
FS3: Customers of web-based financial services want their experience of <br />
using the site/services to adhere to the "General: Users" user-stories <br />
noted above.<br />
</pre><br />
<br />
Note: essentially all web-based sites/services (and their users) are <br />
subject to phishing attacks. It would seem that the main reason to single <br />
out Financial Services SPs is that the attack results with them can be <br />
particularly devastating.<br />
<br />
===Federation===<br />
<pre><br />
F1: Deployers of web-based portal services with kerberized backend-services <br />
need to be able to use federated identity with N-tier authentication.<br />
</pre><br />
<br />
<pre><br />
F2: Grid services (in environments where PK-INIT is used) in the US Federal <br />
sector need to fulfill policy requirements that authentication be done <br />
using smartcards.<br />
</pre><br />
<br />
<pre><br />
F3: SAML service provider with a large number of affiliated Identity <br />
Providers requires a way to determine which Identity Provider a user is <br />
affiliated with, so that it knows where to request assertions for the user'. <br />
</pre><br />
<br />
<pre><br />
F4: The IT management at two or more federated partners need to define <br />
conventions, or an agreement, governing the use of a federated business <br />
process that is secured using Kerberos.<br />
</pre><br />
<br />
===Enterprise===<br />
<br />
<pre><br />
E1: Enterprise SOA architects want flexible life-cycle management for <br />
identities used for SOA.<br />
</pre><br />
<br />
<pre><br />
E2: Enterprise security officers want secure authentication for SOA.<br />
</pre><br />
<br />
<pre><br />
E3: Enterprise system integrators want interoperability between <br />
web service implementations from major vendors.<br />
</pre><br />
<br />
<pre><br />
E4: Enterprise identity architects want SSO-support in popular browsers <br />
with credential delegation capabilities turned on by default.<br />
</pre><br />
<br />
<pre><br />
E5: Enterprise identity architects want to be able to extend existing <br />
cookie-based SSO systems with support for Kerberos backchannel <br />
authentication and credentials delegation.<br />
</pre><br />
<br />
==Use Cases==<br />
<br />
TODO: complete mapping user-stories to use-cases (user story given as (N))<br />
<br />
The use-cases are divided between three categories<br />
<br />
* ''Back Channel'' - this describes transactions between service providers occur directly, without relying on user-wielded tools (typically, although not exclusively, a web browser) to act as an intermediary. E.g. an ecommerce site interacting directly with a user's banking site, without re-directing communications through the user's web browser. These transactions may either be invoked in response to an action performed by a user (for example, logging into a service provider) or be initiated automatically by software agents.<br />
* ''Front Channel'' - this describes interactions between service providers occurring indirectly via a user-wielded tool -- typically, although not exclusively, a web browser -- to mediate. These transactions are normally invoked in response to an action performed by a user (for example, logging into a service provider).<br />
* ''Front and Back Channel combined'' - this describes interactions that involve elements of Front and Back Channel activity (for example, a Back Channel transaction that is authorized using a token that was established previously in an earlier authentication event while the user was online).<br />
<br />
===Back channel===<br />
<br />
====Intra Enterprise====<br />
<br />
A large organization is deploying an increasing number of web services. Initial deployments, which were typically few in number, relied on the use of shared secrets for authentication and TLS for transport security. Although the web services are mainly SOAP-based, using HTTP for transport, the use of Negotiate or message-layer security is very uncommon.<br />
<br />
As the deployments of web services expands, the management of the shared secrets becomes an issue (E2). There is also increasing concern that certain properties of shared secret authentication, or the practices used to manage them, while acceptable during the initial deployments on low-value applications (such as hard-coding secrets into applications), are not appropriate for higher-value applications. The most common action taken is to move to the use of client certificates which, for an organization of this size and complexity, necessitates the acquisition of a web services governance solution. Such products are often based on an ESB (Enterprise Service Bus) and sometimes employ other transports besides HTTP (for example, various message-oriented protocols such as MQ or XMPP).<br />
<br />
The motivation for using Kerberos with these web services is to simplify the management of their security requirements (E1). However, the web services are perceived as distinct from the existing business infrastructure, and so consequently these services are often treated as a single administrative domain isolated from everything except those business systems which they connect. Therefore, the security properties of Kerberos are unlikely to be an important criterion in any evaluation against alternative mechanisms. It also means that Kerberos administration, in order to be a viable option, must integrate into the various web service governance solutions that exist.<br />
<br />
====Business-to-Business====<br />
<br />
A business needs to integrate with another business using a SOAP-based web service (E3). One or both of these businesses may already be in possession of an existing enterprise-wide SOAP-deployment similar to the one described in the previous use-case. The requirements of the security model are typically fairly simple (for example, there are no n-tier issues). As before, shared secrets are used authenticate endpoints, using either TLS or IPSec for transport security. The use of any transport for SOAP other than HTTP is very uncommon.<br />
<br />
The motivation for the use of Kerberos in this use-case may be to leverage each business' pre-existing Kerberos infrastructure, and possibly an existing cross-realm trust, in order to avoid establishing a special-purpose trust infrastructure (E2).<br />
<br />
The main difference between this use-case and the one that was described previously is that typically only a small number of web services are required for each pair of Business-to-Business relationships. Therefore, establishing and managing cross-realm trust must be perceived as a low barrier to the adoption of this trust-model.<br />
<br />
===Front channel===<br />
<br />
Business-to-employee and Business-to-customer use-cases typically involve front-channel exchanges through the user's (customer or employee) browser. Most technologies involved in front-channel authentication (for example, SAML Web SSO) currently use Form-based username and password authentication, even if other mechanisms are supported.<br />
<br />
The motivation to use Kerberos might be to provide a better user-experience. Information Card in combination with Kerberos could also be used to provide a consistent and simplified user experience for web-based authentication. The same is true (to a lesser extent) for Negotiate-based authentication.<br />
<br />
====Business-to-employee====<br />
<br />
In this use-case, the business issues credentials to the employee (E1). These could be used to provide access to both internal corporate resources, and resources offered by third-parties (such as SaaS providers).<br />
<br />
====Business-to-customer====<br />
<br />
In the case where the business issued credentials to customers, the primary challenge would be identity provisioning and management: a user would typically need to obtain and negotiate the use of credentials from multiple realms, obviating the single sign-on benefits of Kerberos.<br />
<br />
This could be mitigated through either the use of Kerberos cross-realm operation, or identity federation technologies (for example, the SAML Web SSO Profile) where Kerberos could be used to authenticate the user at an Identity Provider trusted by those businesses that the customer interacts with. If this were intended to solve the general problem (that is, for most users, for most service providers), there are a number of challenges; these include ''Identity Provider Discovery'' (how does a business determine which Identity Provider a customer is affiliated with, assuming a model involving multiple Identity Providers), technical trust model and governance.<br />
<br />
===Front and Back Channel Composition===<br />
<br />
====Credentials Delegation====<br />
<br />
A recently merged company wishes to provide the newly-united workforces with a single web portal providing access to various back-end services that, owing to delays in the re-organization of the respective IT functions, will remain administratively separate for some time. The provision of email is a core function of the web portal, which therefore needs to access a set of IMAP servers in these separate administrative domains. To avoid the need to issue new credentials to users, SAML-based Web SSO is used to provide federated authentication by the SAML Identity Providers operated by each IT function. These Identity Providers trusted could provide the web portal with delegate-able credentials for their own IMAP server(s) (E5).<br />
<br />
====Level-of-Assurance transport====<br />
<br />
Many services have policies attached to their use that stipulate which type(s) of credentials are acceptable (often called the ''level of assurance'') (E2). In scenarios where the service itself is authenticating the user's credentials, the policy is normally trivial to enforce using technical means because the service has visibility of the authentication event.<br />
<br />
However in a distributed environment the authentication of user credentials is often performed by a third party, out of the control of the service. There are several examples from within the US federal sector where services may require the use of smartcard technology and where there is also a desire to provide a federated web front-end (normally to extend access to users affiliated with trusted organizations).<br />
<br />
However, there is currently no way to communicate information about the authentication event (except in a few corner cases involving PK-INIT). Although SAML defines n element that enables an Identity Provider to express an ''Authentication Context'', it is unspecified how this should be used in a Kerberos deployment.<br />
<br />
==Security Technologies==<br />
<br />
The security technologies relevant to the HTTP-based Web can be divided into three overall categories:<br />
<br />
* ''Transport security'' is provided by the underlying transport protocol. The security service only acts at the socket or datagram layers between two hosts, and bindings to high-level security measures tend to be non-existent. Credentials are usually issued to hosts (if datagram-based) or services (if socket-based).<br />
* ''Application security'' is provided by the application protocol in combination with, or independent of, substrate transport security. Credentials are usually allocated to an application, and the users accessing those applications. Applications may, in some circumstances, leverage user credentials to act on a user's behalf. This is referred to as "impersonation" and/or "delegation" depending upon the detailed context.<br />
* ''Message security'' describes an approach where (application) protocol messages are individually cryptographically bound to security tokens they convey directly and/or indirectly (by reference). With such an approach, the protocol messages may be conveyed over different transports (e.g. HTTP, SMTP, TCP, etc), or stored on intermediate or endpoint systems, while retaining intact their originating security context (modulo any allowances for message modification in-transit). <br />
<br />
===Transport security===<br />
<br />
HTTP is the common transport in web-orientated architectures. Transport security is usually provided using TLS and X.509 PKI.<br />
<br />
Kerberos-based alternatives (existing and proposed) include:<br />
<br />
* Kerberos with IPSec.<br />
<br />
* Negotiate.<br />
<br />
* A specification describing a Kerberos-based cipher suite for TLS exists ([http://www.ietf.org/rfc/rfc2712.txt RFC2712]), and has seen at least two implementations ([http://www.openssl.org OpenSSL], [http://java.sun.com/javase/6/docs/technotes/guides/security/jgss/lab/part2.html JGSS]), but is widely regarded as flawed.<br />
<br />
* A recently-expired [http://tools.ietf.org/html/draft-santesson-tls-gssapi-03 draft] describes extensions to [http://tools.ietf.org/html/rfc4279 RFC4279] to enable dynamic key sharing in distributed environments using a GSS mechanism, and then import that shared key as the "Pre-Shared Key" to complete the TLS handshake. The TLS Working Group [http://www.ietf.org/mail-archive/web/tls/current/msg01887.html has argued] that user principal authentication is an application-level concern, and so this work appears to have stalled.<br />
<br />
Other transports, such as [http://www.xmpp.org XMPP], are available. However it is likely that architectures requiring the use of two or more transports would emphasize the use of message-based security, because the transports' respective security properties are not necessarily functionally equivalent. Where multiple web services are deployed from the same application server it is common to use a web service governance solution which abstracts the service business logic from the transports.<br />
<br />
In summary, HTTP is almost always used - but sometimes other transports are also used. In this case the logical way to provide security is to use message-based security.<br />
<br />
===Application security===<br />
<br />
====Negotiate====<br />
<br />
"Negotiate" is the collective name of a loosely defined set of HTTP authentication mechanisms that provide a simple 2-way [http://en.wikipedia.org/wiki/GSS-API GSS-API] handshake with the HTTP server. The most commonly deployed variant, "Simple And Protected Negotiate (SPNEGO)", defined in RFC 4559, uses the SPNEGO GSS-API mechanism, itself defined in RFC 4178. Other implementations use the Kerberos5 GSS-API mechanism (RFC 4121) instead. Updates to RFC 4559 have been discussed.<br />
<br />
It is worth noting that Negotiate authentication does not protect the HTTP request, because they are sent unprotected during the GSS-API handshake (which is itself encoded within an HTTP header). This authentication method is therefore not advised in some use-cases; in particular, REST-style web-services cannot in general be protected using Negotiate alone. Note that this is the case with all present authentication techniques that are conveyed within an HTTP message itself, e.g. in the HTTP message headers: Basic, Digest, and Negotiate. <br />
<br />
Negotiate suffers from a lack of mutual authentication and support for multiple-roundtrip GSS-API mechanisms. Earlier attempts (in the IETF) of introducing SASL-based authentication for HTTP showed that in order to gain wide acceptance any multiple-roundtrip HTTP authentication mechanism has to be able to deal with consecutive HTTP/1.1 connections being sent to different TCP endpoints (e.g. if a concentrator is deployed at the server). This implies that the authentication mechanism needs to support some form of state management. At least two different proposals have been put forward for solving this problem; one in http://tools.ietf.org/html/draft-johansson-http-gss where state management is done in the HTTP layer and one in http://tools.ietf.org/html/draft-zhu-negoex where state management is done in the GSS-API layer.<br />
<br />
====Information Card====<br />
<br />
;Introduction :<br />
<br />
"Information Card" is an identity technology based on the notion of a smart client, the identity selector (IS), under the control of a user, that can interact with a relying party(RP), and optionally an identity provider (IdP), to accomplish application signon and delivery of user information to the RP. Both IS-RP and IS-IdP interactions use the WS-Trust protocol (part of the WS-* suite). WS-Trust is intended to be a "meta" authentication protocol that can in theory permit a security token to be delivered to the RP in whatever format it requires, independent of the method the client uses to authenticate to the IdP. The identity selector has a user interface that presents the user's authentication options in the form of cards. A card can be "managed", meaning that it is issued by an IdP, and requires authentication to that IdP when used. Or, a card can be "self-issued", meaning it is generated within the identity selector, and uses a keypair managed by the selector to authenticate to the RP.<br />
<br />
Though Microsoft is the initial developer and evangelist of Information Card, many other companies and projects are developing compatible software and contributing to the technology specifications. The Information Card Foundation (http://www.informationcard.net/) was formed in 2008 to promote the technology. Microsoft's Information Card client (known generically as an "identity selector" or "identity agent") is called CardSpace. Since it is the most well-known implementation, many people (incorrectly) refer to the whole technology as CardSpace. The Information Card concept was originally developed by Kim Cameron of Microsoft as part of an "Identity Metasystem" concept, so this term is also used for this technology. The technology is now being standardized in an OASIS technical committee called the Identity Metasystem Interoperability TC (http://www.oasis-open.org/committees/imi/).<br />
<br />
The Information Card specifications define the authentication methods supported between identity selectors and IdPs (in the managed card case). Kerberos is one of these methods. The others are: X.509 cert, username/password, and self-issued card (technically a SAML token).<br />
<br />
;Kerberos authentication from Identity Selector to IdP :<br />
The Identity Selector (IS; an end-user client-side tool) can authenticate to an IdP using Kerberos. The WS-Security Kerberos Token Profile is used, underlying the WS-Trust protocol that does the security token request. An IdP supporting Kerberos authentication would be an application server from the Kerberos point of view. It doesn't appear that any of the existing Information Card IdP software supports Kerberos authentication however, so this is an opportunity for improvement. Microsoft's IdP (which probably won't be available until 2009) will support all four defined methods, including Kerberos.<br />
<br />
;Kerberos token delivery to the RP :<br />
WS-Trust operates by delivering security tokens to RPs to authenticate clients. WS-Trust is (or claims to be) token agnostic, meaning it can carry anything, but for a token format to be used interoperably its nature and handling by IdP and RP must be specified. Information Card defines the use of SAML tokens for self-issued cards and these have commonly been used as tokens in managed cards also. It would be possible to define a Kerberos token. Such a token (presumably a KRB_AP_REQ) would be generated by the IdP, carried by WS-Trust from IdP to IS and from IS to RP, and processed by Kerberos software at the RP. There is no such token defined at this time. Recent comments from Microsoft about supporting cross-technology delegation imply that it might be implementing delivery of Kerberos tokens via WS-Trust.<br />
<br />
;Identity Selector as standard authentication UI :<br />
Information Card technology has been introduced as an approach for browser authentication to web applications, since the web is obviously widely-used and urgently in need of better authentication solutions. The selector concept, however, can apply to any instance of user authentication. This might involve extending selectors to support other protocols, or adding the use of WS-Trust for authentication to existing systems. In particular the Identity Selector could be a user interface for Kerberos initial authentication in some scenarios.<br />
<br />
====OAuth====<br />
<br />
;Introduction :<br />
<br />
OAuth (http://oauth.net/) is a specification for interoperable support of delegated access to web-based resources. It is designed to support a particular common use case: a user of one web-based service (for example, a photo-sharing service, called the OAuth service provider) has protected resources (for example, photos) that the user would like to make accessible via another web-based service (for example, a social-networking service, called the OAuth consumer). This is often done today by the consumer service obtaining from the user their username and password on the service provider. The goal of OAuth is to avoid this practice. This done by defining service points to permit an access token to be produced by the service provider and delivered to the consumer via the browser. This token can then be used (after some transformation) to access the service provider via an OAuth-defined HTTP authentication method.<br />
<br />
OAuth was developed by an adhoc group, based on similar specs from a number of web technology companies (e.g. Google, Yahoo!). Its current version is 1.0. There are several implementations for different languages and platforms, and some initial deployments. Google in particular defines extensive support (http://code.google.com/apis/accounts/docs/OAuth.html).<br />
<br />
OAuth has no defined relationship to Kerberos or any other existing authentication technology at this time. Note that since the tokens are both issued and consumed by the service provider, their internal format and semantics can be whatever the service provider wants. For example, the validity period of the token is not defined in the spec or represented in the protocol; it is entirely up to the issuer.<br />
<br />
The standard OAuth scenario is referred to as "three-legged" since it involves the consumer, the provider, and the user who must indicate consent and transport the access token. There is interest in "two-legged" scenarios where the OAuth HTTP authentication method is used simply between consumer and provider, not on behalf of some user. In this case it would be an alternative to other HTTP authentication methods such as Basic or X.509/SSL. <br />
<br />
;Opportunities :<br />
<br />
There has been recent discussion about profiling OAuth with SAML in order to permit the encapsulation of SAML assertions (that might convey, for example, information about the user) in the OAuth protocol exchange, in conjunction with the otherwise OAuth-specific cryptographic credentials. As an alternative, Kerberos tickets could be sent either instead of or in conjunction with such SAML assertions. This could be appealing for a Kerberos-oriented OAuth service provider.<br />
<br />
OAuth defines an initial registration and key-exchange step betwen consumer and service provider. In a scenario where consumer and provider use Kerberos this step could be skipped if a method to bootstrap OAuth keys from Kerberos were defined.<br />
<br />
====OpenID====<br />
<br />
[https://spaces.internet2.edu/display/kerweb/OpenID] <font size="1">(reference material)</font><br />
<br />
OpenID Identity Providers (OPs) ''could'' employ Kerberos to authenticate their users and this approach for an OpenID OP would probably be quite useful as a means for an enterprise to stand up an OP in front of its existing authentication infrastructure. It is unclear how common this approach will be but it as been argued that enterprise passwords would become less exposed by something like this since users typically pick the same password for their blog/yammer/amazon account as the password used at work since it is easier to remember it. This practice exposes the enterprise credential to additional risk. There is very little an enterprise security officer could do about this except to provide an alternative and reasonably safe way to reuse the enterprise authentication.<br />
<br />
===Message security===<br />
<br />
====Security Strategies for Message-based architectures====<br />
<br />
Good message-based implementations understand that there are multiple SOAP transports and provide an interface for plugging in new ones, however in practice SOAP transports other than HTTP rarely occur when performance isn't an issue.<br />
<br />
SOAP method calls are either secured at the transport or message layer or both. The "official" way to secure SOAP is to use WS-Security but transport-layer security is much more common especially in the cross-domain cases. In this case it is not uncommon for IPSEC to be used to provide a tunnel between the client and the server and for the HTTP-based SOAP-calls to be unauthenticated in this tunnel. When tunnels are not practical it is common for HTTPS (TLS) to be used in combination with a username and clear-text password.<br />
<br />
The reason for using Kerberos may be any of:<br />
<br />
* Kerberos is easier to use once deployed and if the service endpoint is one of many published by "A" then maintaining username and passwords will be unpractical for the same reasons that maintaining lots of password-based user identities would be impractical. In this case Kerberos provides life-cycle management for the identities used to secure the web service.<br />
* Kerberos is the default security service used by the application framework used to develop and deploy the service endpoint.<br />
* Kerberos is chosen because security policy mandates the use of Kerberos for identities.<br />
<br />
There are (therefore) two ways to authenticate SOAP using Kerberos and if we ignore the possibility of using Kerberos with IPSEC for now:<br />
<br />
* by securing the transport.<br />
* by securing the SOAP messages.<br />
<br />
====The WS-* suite====<br />
[https://spaces.internet2.edu/display/kerweb/WS-*] <font size="1">(reference material)</font><br />
<br />
WS-* ("dubya ess star") denotes a suite of web services specifications promulgated by IBM, Microsoft and various collaborators. Unlike the SAML and ID-WSF specifications, only a few of the WS-* specifications have been subject to an open standardization process and subsequently their quality can be generously described as variable.<br />
<br />
Of these specifications, there are three that are central to WS-* security<br />
<br />
* WS-Security: this specification defines how security tokens are bound to messages. WS-* has defined security token profiles for SAML and Kerberos, amongst others, that can be leveraged by this specification. WS-* officially employs WS-Security-based ''messaging'' security techniques almost exclusively.<br />
* WS-Trust: this specification defines how to exchange (request, issue, renew, cancel) security tokens with web services. These tokens may be used in a variety of ways; for example, as evidence to authorize access to a web service.<br />
* WS-Federation: this specification is a specialization of WS-Trust that defines how to exchange security tokens in a federated context.<br />
<br />
In the Web and Kerberos context, the most important of these is WS-Trust as it provides the mechanisms for using tokens that might be a Kerberos ticket or a SAML assertion) to establish and leverage trust. WS-Trust also plays a key role in the Information Cards technology, another specialization of WS-Trust.<br />
<br />
=====WS-Security Kerberos Token Profile=====<br />
<br />
[https://spaces.internet2.edu/display/kerweb/WS-Security+Kerberos+Token+Profile] <font size="1">(reference material)</font> <br />
[''message security'']<br />
<br />
The WS-Security Kerberos Token Profile defines how to use Kerberos service tickets (specifically, the KRB-AP-REQ message) as a security token. The acquisition of the token is out-of-scope.<br />
<br />
The Kerberos message is attached to the SOAP message using the <wsse:BinarySecurityToken> element. Six different types are supported, including RFC 1510-style, RFC 4120-style and their equivalent GSS-API encapsulations. The octet sequence is encoded using the indicated method.<br />
<br />
This specification does not support the KRB-AP-REP message, and so consequently neither Kerberos mutual authentication, nor GSS-API channel bindings, are supported. In practice, therefore, this specification needs to be combined with transport layer security (e.g. TLS).<br />
<br />
====OASIS Security Assertion Mark-up Language (SAML)====<br />
<br />
[https://spaces.internet2.edu/display/kerweb/SAML] <font size="1">(reference material)</font><br />
<br />
SAML provides a suite of XML-based protocols that enables different security domains to exchange security data about user principals.<br />
<br />
Broadly, the SAML specifications define:<br />
<br />
* the ''assertion'', a security token that can express a user principal's authentication status, authorizations and other general attribute information.<br />
* ''protocols'', that are primarily used to request assertions about a user principal.<br />
* ''bindings'', that define how protocols are bound to certain transports (such as SOAP).<br />
* ''profiles'', that constrain the use of assertions, protocols and bindings to realize specific use-cases (such as the "Web SSO Profile").<br />
* ''federation metadata'', that allows security domains to express information (primarily configuration data, such as a public key) about themselves to other security domains.<br />
<br />
Although SAML focuses primarily on the passing of messages to federate identities in different security domains for Web SSO applications, the architecture of SAML allows discrete functional elements to be re-used in other contexts, allowing a broad range of potential applications. For example, the SAML assertion has been re-used in many other technologies - even technologies, such as WS-Federation implementations, which are competitive with SAML as a whole. Consequently it can be argued that the categorization of SAML as 'message security' is a generalization, depending on which particular ''SAML profile'' is being examined, and how it is specifically crafted in concert with the target protocol(s).<br />
<br />
SAML does not stipulate the use of any particular trust model(s), although X.509-based trust establishment and TLS is widely used in practice.<br />
<br />
There are several ways in which SAML, in terms of either SAML assertions themselves or the SAML profiles, can or could interface with Kerberos:<br />
<br />
;The SAML Identity Provider (IdP) uses Kerberos to validate usernames and passwords supplied by users on webpage forms<br />
:The main benefit offered by this configuration is that it allow users to use the same credentials to access resources protected by both SAML and Kerberos, offering users greater convenience. This is achievable with little or no modifications to the SAML IdP, and is a configuration that is likely to be used by IdP deployments today. <br />
<br />
;The IdP uses Kerberos authentication at the HTTP layer - e.g. Negotiate or NTLM<br />
:The main benefit offered by this configuration is that it permits the use of Kerberos-based SSO to authenticate to the SAML IdP, offering greater convenience to users. This is achievable with little or no modifications to the SAML IdP, and is a configuration that is known to be used by many IdP deployments today. <br />
<br />
;The IdP issues SAML assertions containing Kerberos tickets as an attribute<br />
:It would allow a SAML Relying Party to acquire a Kerberos ticket that it could use subsequently to authenticate, as another principal, against a Kerberos protected resource. The main benefit is that it could be used to support n-tier web-based use-cases (such as the webmail use-case), offering greater convenience to users and possibly reduce the abuse of user credentials by providing applications with delegable credentials. This would require modifications (possibly not too significant) to the SAML IdP. <br />
<br />
;The KDC includes a SAML assertion and/or authentication response message encapsulated in KDC-issued authorization data<br />
:It would allow the KDC to issue SAML assertions (or perhaps SAML messages in general) to Kerberos services. The main benefit is that this could be used to complement Kerberos-based authentication and/or provide richer authorization. This would probably require modification (probably reasonably significant) to the KDC. <br />
<br />
;The SP uses Negotiate to find the preferred IdP of the user (aka IdP discovery) based on the Kerberos-realm in the GSSAPI authentication request.<br />
:The benefit of this is that it reduces or eliminates the need to use GUI-based IdP Discovery (the commonest form of IdP discovery), which scales poorly and introduces UI considerations such as localization and accessibility. This is achievable with little modification to the SAML SP. It has already been implemented on SWITCH's "Where Are You From" service (but not used in their production federation). <br />
<br />
;A GSSAPI peer implementing the proposed GSSAPI naming extensions receives a SAML attribute assertion as part of a GSSAPI protocol exchange<br />
:While not strictly tied to Kerberos this may provide a way to tie in with other uses of the GSS-API naming extensions.<br />
<br />
====Liberty Alliance Identity Web Services Framework====<br />
[https://spaces.internet2.edu/display/kerweb/ID-WSF] <font size="1">(reference material)</font><br />
<br />
The Identity Web Services Framework (ID-WSF) is a set of specifications from the Liberty Alliance that builds on SAML to provide a full-featured web services stack that leverages WS-Security as its encapsulating security token format. Thus it is possible to leverage Kerberos-based authentication in an ID-WSF-based web services context, although at this time the limitations noted above with respect to the WS-Security Kerberos Token Profile will apply.<br />
<br />
<br />
==Security Technology Requirements==<br />
This section presents requirements that security technologies employed in the HTTP-based Web context ought to satisfy.<br />
<br />
===Security Protocol Overall Efficiency===<br />
<br />
Some small number of handshake exchanges in order to authenticate the principal with the IdP (i.e. KDC if Kerberos is being employed). Subsequent interactions with other websites, participating in the authentication domain, can be authenticated with a security token (e.g. a service ticket if Kerberos is being employed) accompanying HTTP messages from the user agent. <br />
<br />
The rationale here is that for any given web page, a user agent may make any number (not infrequently on the order of tens O(10) ) of requests to the server. This is due to the the user agent typically retrieving web page constituent components, e.g. images, frames, tables, etc., with an HTTP request per component. This is sometimes referred to as being "chatty". Since such requests are performed independently and asynchronously over separate TCP connections, each HTTP request will need to convey authentication information that the service provider can validate & verify without further interactions. <br />
<br />
===Security Token Size===<br />
<br />
Because of the "chatty" property of some web interactions noted above, and the necessity of each individual HTTP request being authenticated, the security token size will likely matter. <br />
<br />
Microsoft reports customer feedback to this effect: Active Directory et al encode principal group membership information -- Privilege Attribute Certificate (PAC) -- in the Kerberos service ticket. This can expand the ticket size to be over 12k bytes and noticeably slow down "chatty" web interactions. The same would likely be the case for attaching any other "large" chuck of information to service tickets and/or the HTTP requests themselves.<br />
<br />
===User Interaction===<br />
<br />
Some security technologies, e.g. Kerberos, are designed with the notion of signing the user on once, and then further interactions with participating entities (e.g. service provider websites) occurs in a transparently authenticated fashion. <br />
<br />
However, in some contexts -- especially those in which principal attributes beyond baseline principal name and secret are conveyed -- it may be required for there to be interaction with the principal at least whenever the user agent is being compelled to convey more information than some configurable baseline to the service provider (aka relying party). This, for example, is one of the features of [[Information Card]]s' "Identity Selector" user agent, and the underlying Identity [http://www.oasis-open.org/committees/download.php/29511/Identity_Selector_Interoperability_Profile_V1.5.pdf "Selector Interoperability Profile"] protocol.<br />
<br />
==Browsers==<br />
<br />
Most browsers support Negotiate by default, but most either disable the feature (requiring the user to enable it manually) or limit its use to "local" sites or sites explicitly trusted. It is unclear what the threat-model looks like and this should be investigated further.<br />
<br />
===Safari===<br />
<br />
Safari supports Negotiate with SPNEGO since Tiger. There is an information card identity selector for safari here: http://www.hccp.org/safari-plug-in.html.<br />
<br />
===Mozilla/Firefox===<br />
The Mozilla and Firefox browser family includes native support for Negotiate using the Kerberos GSS-API mechanism. This feature is not turned on by default though, and must be turned on manually by editing the "prefs.js" file. Credentials delegation is supported but must also be turned on manually. There are a few plugins implementing Information Card for Firefox/Mozilla. It is unclear if any of them support Kerberos authentication for Information Card-based IdPs.<br />
<br />
===Internet Explorer===<br />
<br />
Negotiate was invented by Microsoft and is widely deployed through the implementation in the Internet Explorer family of web browsers.<br />
<br />
===Konqueror===<br />
Konqueror is the browser included in the KDE desktop framework. Konqueror supports Negotiate and enables Negotiate for sites in the same domain as the client. There is no support for Information Card yet in Konqueror.<br />
<br />
==Application environments & Libraries==<br />
<br />
===IIS===<br />
IIS naturally has native support for Negotiate using the SPNEGO GSS-API mechanism. <br />
<br />
===.NET===<br />
The .NET framework supports the WS-Security Kerberos Token Profile as well as Negotiate natively.<br />
<br />
===Apache===<br />
Apache has add-on modules supporting Negotiate using both SPNEGO and Kerberos GSS-API including http://modauthkerb.sourceforge.net/.<br />
<br />
===Perl===<br />
The LPW::Authen::Negotiate module implements Negotiate using the GSSAPI perl module which in turn uses either Heimdal or MIT Kerberos libraries. This means that LPW::Authen::Negotiate can support both SPNEGO and Kerberos GSS-API.<br />
<br />
===Ruby===<br />
There is a GSS-API library for ruby which similar to the perl GSS-API library supports either MIT or Heimdal Kerberos. However the Ruby HTTP client library does not natively support Negotiate (it does support NTLM though). There have been working patches but they are not maintained. Ruby is one of the language of choice for "web 2.0" applications especially in combination with the Rails framework. These applications are known to prefer REST-style web services to more "enterprise"-style SOAP-based web services.<br />
<br />
===Java===<br />
Java has native support for the Kerberos GSS-API mechanism since JDK 1.4. A number of implementations of Negotiate exists for various application servers (e.g. Tomcat and JBoss). There are not free implementations of SPNEGO for JDK 1.5 and later although there are at least two commercial implementations. Since JDK 1.6 there is native support for SPNEGO.<br />
<br />
===WSS4j===<br />
WSS4J is the primary free implementation of XML security (from the apache project). It does not include an implementation of the Kerberos token profile.<br />
<br />
==Suggested Activities==<br />
<br />
[[Image:Kerberos-ArchAndProposedWorkItems-00.png|Figure 1]]<br />
<br />
* Back Channel (BC)<br />
*# Update the Kerberos Security Token Profile to support mutual authentication and channel bindings.<br />
*# Promote the implementation of the updated Kerberos Token Profile in common software frameworks (e.g. .NET, wss4j) and demonstrate interoperability.<br />
*# Update Kerberos cross-realm operation (in progress).<br />
*# Develop conventions or best-practices for integrating Kerberos into web-services governance solutions.<br />
<br />
* Front Channel (FC)<br />
*# Promote implementation and interoperability testing of Kerberos authentication for Information Card.<br />
*# Update Negotiate (in progress).<br />
*# Interoperability testing of Negotiate implementations.<br />
*# Investigate the role of Kerberos in OpenID.<br />
*# Define a discovery mechanism for SAML Web SSO deployments with many Identity Providers, enabling service providers to establish the Identity Provider that a customer is affiliated with.<br />
<br />
* Front and Back Channel (FB)<br />
*# Specify credentials-delegation for SAML-based SSO.<br />
*# Investigate the role of Kerberos in OAuth.<br />
*# Specify a SAML profile based on having the KDC sign a SAML authentication response/attribute assertion/authentication context. Also specify the relationship with GSS naming extensions.<br />
<br />
* Other (O)<br />
*# Document the ways in which Kerberos can be used in a web-context with current technology, to assist contemporary deployers seeking to address certain use-cases today.<br />
*# Develop best-practices and boilerplate covering governance of Kerberos-based web services.<br />
<br />
<br />
TODO: classify suggested activities by who needs to work on them, e.g. what SDOs / vendors / projects would need to be involved, skill set needed, SWAG wrt effort, etc. <br />
<br />
also recommendations wrt near- / intermediat- / long-term phasing.<br />
<br />
suggestion from SteveB:<br />
<br />
<pre><br />
One way to rank/organize these might be a table with the following <br />
columns:<br />
<br />
Activity Impact Effort Risks <br />
<br />
<br />
An example might be<br />
<br />
Activity Impact Effort Risks<br />
Investigate the role May solve large problem High, many years Technology neither implemented<br />
of Kerberos in OAuth. nor well understood<br />
</pre><br />
This documentation is made available under the [[MIT Kerberos License]]</div>Sbuckleyhttps://k5wiki.kerberos.org/wiki?title=KrbWeb_Outline_of_Work&diff=709KrbWeb Outline of Work2008-10-09T14:32:37Z<p>Sbuckley: </p>
<hr />
<div>'''<font size="5">Towards Kerberizing Web Identity and Services</font>'''<br />
<br />
<br />
<br />
<font size="5">Abstract</font><br />
<br />
Today, authentication and authorization are addressed in an incoherent, often site-specific fashion on the Internet overall and the Web specifically. This situation stems from many factors including the evolution, design, implementation, and deployment history of HTTP and HTTP-based systems in particular, and Internet protocols in general. Kerberos is a widely-implemented and widely-deployed authentication substrate with a long history in various communities and vendor products. Here we outline the history of "Web identity", "Web Single Sign-On", "Web Services" and "Web Services Stacks", and present how Kerberos fits into this picture today. Relevant "user stories" are then presented, as well as technological use cases along with a taxonomy of extant Web-relevant security technologies. From this we present an overall general architecture model and suggested activities for working towards more cohesive and widely deployed Kerberos-based Web authentication infrastructure. <br />
<br />
<br />
;Authors (alphabetical):<br />
:Jeff Hodges, Kings Mountain Systems<br />
:Josh Howlett, JANET<br />
:Leif Johansson, Stockholm University<br />
:RL "Bob" Morgan, Internet2 / University of Washington<br />
<br />
[[Category:Kerberos and web pages]]<br />
<br />
==Introduction==<br />
<br />
In this paper we attempt to provide a high-level overview of how authentication of end users, and to some extent their authorization, fits into the Web landscape -- and Kerberos' place in that picture along with its strengths and gaps. We follow with a brief presentation of "user stories" -- simple statements of what end users, deployers, and enterprises desire in terms of their security-related experiences when using the Web. Next, we discuss technological use cases, specific web-relevant security technologies, and some overall requirements such technologies should meet. Then we touch briefly on implementation and deployment technologies -- e.g. browsers and application development libraries, before closing the paper with a presentation of an architectural model, suggested activities, recommendations, and analysis. <br />
<br />
==Acknowledgments==<br />
<br />
The authors are grateful for the support of the [http://www.kerberos.org/ MIT Kerberos Consortium]. We also acknowledge and thank Love Hörnquist Åstrand, Steve Buckley, Michael Gettes, Ken Raeburn, Tom Yu, and Larry Zhu for their input and comments.<br />
<br />
==Related Pages==<br />
<br />
[[KrbWeb_Backlog|"Backlog" Page]] <br />
<br />
Steve's [[KrbWeb_Buckley-BoardMtgPresoAndNotes-2008-07-24|"slides and notes from the Consortium Board meeting"]] from 24-Jul-2008<br />
<br />
==Overview==<br />
<br />
===A Short History of Web Identity===<br />
<br />
For a system that was originally intended to facilitate collaboration between physicists, it is remarkable how ubiquitous Web technologies have become. It is no exaggeration to claim that the HTTP protocol defined in RFC 2616 is the ''de facto'' transport for applications operating between internetworked hosts. This is due, in part, to HTTP's success in meeting its authors' goal of defining a generic, stateless, protocol which can be used for many tasks beyond its use for hypertext transfer', but perhaps mainly to the convenience of using a common transport in an Internet composed of networks with diverse capabilities and policies.<br />
<br />
====The Primordial Identity Soup====<br />
<br />
HTTP's standard authentication capabilities, [http://en.wikipedia.org/wiki/Basic_access_authentication Basic] and [http://en.wikipedia.org/wiki/Digest_access_authentication Digest], are specified in RFC 2617. The most obvious deficiencies of these protocols, such as capture of credentials on-the-wire, were widely appreciated at the time, and the response was to remedy them using SSL (and subsequently TLS). However, the user experience provided by browsers implementing these methods was deemed by many as "poor" (for example, the bland username and password dialog) and also was effectively "unbrandable". So while these methods were deployed within the Enterprise (typically to protect Intranets and programmatic web services), they were largely ignored by the broader Web development community, where so-called [http://en.wikipedia.org/wiki/Form_based_authentication Form-based authentication] became dominant.<br />
<br />
Unlike Basic and Digest authentication, which are typically implemented in the web server -- at a system level -- Form-based authentication is typically implemented at the web application level. The application uses XHTML elements to construct a Form, typically consisting of username and password fields (and increasingly also a ''captcha'' dialog). The user enters his credentials into the Form, which is submitted to the application using the HTTP POST method.<br />
<br />
The paradigm of using TLS-protected Forms for user authentication and X.509-based server authentication became extremely common, and it remains the most common approach to authentication and establishing trust. However, this paradigm is not without drawbacks. The most significant problems include:<br />
<br />
* [http://en.wikipedia.org/wiki/Phishing Phishing] of credentials<br />
* Excessive numbers of credentials<br />
* Inconsistent and complex user experience<br />
* Privacy violations<br />
* Ad-hoc and unstandardized<br />
* not a system-level approach<br />
<br />
These drawbacks can be viewed as symptoms of this paradigm's failure to scale with the explosive growth of the Web. This confounded early attempts to improve HTTP authentication (for example, attempts to leverage [http://en.wikipedia.org/wiki/Simple_Authentication_and_Security_Layer SASL] (RFC 4422)) which might have permitted the use of a Kerberos mechanism) because the Web had not yet attained the scale and significance where the symptoms had developed to the chronic level that we observe today, and so consequently there was no obvious case for significant alterations to protocols or implementations.<br />
<br />
====Birth of Web Single Sign-On and Identity====<br />
<br />
The need for some notion of "Web [http://en.wikipedia.org/wiki/Single_sign-on single sign-on]" -- termed "Web SSO" -- was perceived by various disparate parties from the mid-1990s onwards. Often this occurred in a commercial, higher educational, or governmental enterprise setting. Many roughly similar solutions were concocted roughly in parallel, and the practice continues right to the present day. Some examples are the [http://www.stanford.edu/services/webauth/ WebAuth] system concocted and deployed at Stanford University (mid-to-late 1990s), [http://en.wikipedia.org/wiki/Pubcookie PubCookie] from University of Washington, and Yale's [http://www.ja-sig.org/products/cas/ Central Authentication System (CAS)].<br />
<br />
The first OS-vendor-driven effort to improve Web authentication, and provide users a cohesive notion of web-based "identity" as well as Web SSO, was [http://en.wikipedia.org/wiki/Windows_Live_ID Microsoft's Passport service]. However, Passport failed to gain any lasting traction, beyond Microsoft's own services, for reasons of trust. Technically, Microsoft's initial Passport SSO protocol was flawed, reducing confidence in this aspect of the system. More critically, Passport was perceived by potential consumers of the system - and others - as a vehicle that could hand Microsoft a monopoly in Internet identity. Passport's importance began to diminish in 2004 when Microsoft canceled the contracts with the most significant consumers of Passport, including eBay and Monster.com.<br />
<br />
In parallel with Passport, a Technical Committee (TC) within [http://www.oasis-open.org OASIS] -- the [http://www.oasis-open.org/committees/security Security Services TC (SSTC)] -- was established to define [http://en.wikipedia.org/wiki/Saml SAML], an open XML-based identity system derived from two earlier specifications, S2ML and AuthXML. SAML was the first, and is the most successful, technology for [http://en.wikipedia.org/wiki/Federated_identity federated identity]. The SAML specifications were quickly leveraged by the [http://en.wikipedia.org/wiki/Single_sign-on Liberty Alliance], a broad vendor and "deploying organizations" consortium initially reacting to the perceived threat from Passport, for their own [http://www.projectliberty.org/liberty/resource_center/specifications/specifications_archives/liberty_alliance_phase_i_1_0_specifications ID-FF (Identity Federation Framework)] specifications.<br />
<br />
In contrast to Passport, which was conceived as a wholly centralized identity system, federated identity is an approach in which a website (normally called the Service Provider, or SP) delegates responsibility for user authentication (and sometimes user authorization) to a trusted third party (normally called an Identity Provider, or IdP) with which the user is affiliated. The relationship between one or more IdP(s) and one or more SP(s) that have federated is often called a "federation" (the Liberty Alliance refers to this as a Circle of Trust).<br />
<br />
====Evolution Towards Federated Identity====<br />
<br />
However, Federated Identity does not replace Form-based authentication, nor was it ever intended to. Federated identity is independent of the authentication technique used by the IdP (although the authentication method may sometimes be a property of the authentication event about which the IdP informs the SP). Federated Identity can, however, be used to move the deployment of Form-based authentication from the SP to the IdP, alleviating the SP of the burden of authenticating user credentials and implementing the processes require to issue and manage those. It also means that, in general, a user only needs to maintain a single identity per federation.<br />
<br />
SAML, and the Liberty Alliance specifications in particular, are perceived to focus primarily on finding solutions for Enterprise and eCommerce use-cases. In the case of the Liberty Alliance framework, the federated identity technology is complemented by non-technological deliverables, such as federation governance models, security best practices, and deployment guidelines. While comprehensive, some within the Web development community viewed this approach to federated identity as unnecessarily complex for various use cases - and not scaleable to the Internet community at large (though these contentions are debatable). More philosophically, there was also opposition to what many (largely incorrectly) perceived as SAML's leanings towards "Enterprise-centric" identity, in which the user's identity is associated with some corporate entity issuing assertions on the user's behalf, than it is with the natural person represented by that identity.<br />
<br />
The [http://www.openid.net/ OpenID] protocol, and the "user-centric" movement that espouses it, is the clearest manifestation of this.<br />
<br />
Many argue that the claimed "user-centric" properties of OpenID are a distraction, and that SAML can be profiled equivalently such that it is no less "user-centric". While accurate, OpenID implementations, being optimized for abject simplicity, can be easier to deploy than some SAML implementations. For example, OpenID is not burdened by any notions of trust, whose subtleties add significantly to the SAML specification, and thus implementation and deployment complexity of SAML profiles reflecting and accommodating trust nuances. <br />
<br />
Relieved of these burdens, OpenID has seen significant deployments - but, almost invariably, only for applications where the consumer of the OpenID identity does not require a significant level of trust in the assertion (which, owing to the way in which the protocol operates, is equivalent to the level of trust that can be attributed to the DNS). Therefore, while OpenID is satisfactory for low-value applications it is perceived by many as typically not appropriate for higher-value applications.<br />
<br />
====From Identity Monopoly to Identity Metasystem====<br />
<br />
The recognition of the diversity of identity technologies, and the requirements of the applications consuming the identities, is a key feature of Kim Cameron's widely referenced ''Laws of Identity'' in which he proposes the need for (or perhaps the inevitable reality of) the ''Identity Metasystem''. Cameron was a vocal critic of Microsoft Passport and was subsequently recruited by Microsoft as its Chief Identity Architect. In the ''Laws of Identity'', Cameron proposes seven axiomatic properties of identity systems that, he claims, must be observed for any identity system to succeed. While the ''Laws of Identity'' have been subject to criticism, it is a nonetheless important document in that it expounds the philosophical underpinnings of the identity architecture being developed by Microsoft in the wake of Passport.<br />
<br />
====Emergence of Web Services====<br />
<br />
The notion of "Web Services" emerged in the late 1990s, becoming widely visible with IBM and Microsoft et al's submission of the ''Simple Object Access Protocol (SOAP) 1.1'' specification to the W3C (as a "W3C Note") in the spring of 2000. SOAP consists of highly tailorable XML-encoded protocol messages capable of encapsulating arbitrary data. They can be employed in either remote procedure call (RPC) or message passing styles. <br />
<br />
"Web Services" were felt by these practitioners to essentially exclusively consist of SOAP messages conveyed by HTTP, effectively excluding other extant protocols with well-defined URI schemes, e.g. FTP, LDAP, IMAP, etc., from the "web services party". <br />
<br />
A year later, IBM-Microsoft produced the ''Web Services Description Language (WSDL) 1.1'' W3C note in Spring 2001. It essentially defines an "interface description language" for SOAP-based protocols, which is purportedly an aid to developers. <br />
<br />
Security in the SOAP context -- authentication, confidentiality, and integrity protection -- was originally left as an afterthought, i.e. as an exercise for developers and deployers. Two years after SOAP's initial emergence, the WS-Security specification was publicly announced by IBM and Microsoft in Spring 2002. It specifies a framework for attaching essentially any type and/or number of "security tokens" (such as a Kerberos ticket) to SOAP messages, as well as cryptographically binding tokens to messages. This provides a means for data origin authentication on a per-message basis. This can be built upon to provide high-level security abstractions, e.g. for streams of messages.<br />
<br />
By then, 2002, it was clear that there was no industry-wide cohesive vision of what constituted "web services", other than a nominal agreement of them being SOAP-based, nor was there a single "home" for web services specification development. The lack of a home was, and still is, illustrated by the work on various aspects of the broad web services notion being spread across a plethora of fora: privately (e.g. the IBM-Microsoft "workshop process"), in the W3C, in the Web Services Interoperability (WS-I) organization, in OASIS, and in the Liberty Alliance Project.<br />
<br />
====Web Services Stacks and Identity====<br />
<br />
Given the fragmentation of the broader web services community noted above, it is not surprising that more than one "web services stack" has emerged. By "stack" we mean a full-featured specification suite addressing messaging and transport binding, interface description language, security framework, resource discovery, authentication and security token services, and web single sign-on. <br />
<br />
The two major extant SOAP-based web services stacks are the Liberty Alliance's ''Identity Web Services Framework'' (ID-WSF) and IBM-Microsoft-Et-Al's ''WS-*'' (dubya-ess star). Both meet the definition of "stack" given above. Both utilize SOAP-based messages and employ WS-Security as well as WSDL. However, they diverge as one goes further "up the stack". Yet, both stacks feature the key notion of federated identity being conveyed between the browser-accessible web-based "world" and back-end "web services"-based systems. <br />
<br />
ID-WSF specifies use of SAMLv2-based security tokens (though other token types may be profiled for use) and leverages SAMLv2's Web Browser SSO Profile for web single sign-on. The authentication service leverages a SASL-based authentication exchange thus supporting the plethora of extant SASL mechanisms, e.g. Kerberos. ID-WSF is designed with the notion of a user's identity being a first-order component of the context of interactions. For example, discovery service requests are implicitly made in the context of the identity of the user causing the request to be made, e.g. "'''I''' am asking for '''my''' service locations", as well as being able to express target identity contexts, e.g. "'''I''' am asking for '''her''' calendar service". While ID-WSF's specifications explicitly allow for extensions and profiling, where these are possible are carefully constrained. ID-WSF was designed to be concretely implementable and deployable directly from the original specification suite with no further profiling required.<br />
<br />
The composition of the WS-* stack is somewhat difficult to pin down in that IBM and Microsoft each have their own perspective on what constitutes the WS-* stack, and also because the specifications are strewn across a landscape including their private "workshop process", as well as OASIS, W3C, and WS-I. The WS-* specifications are designed to be freely "composable" -- one can pick and choose which ones to utilize in solving a particular use case. This is often cited as the rationale for the specifications' style of unconstrained XML element extensibility (in contrast to ID-WSF's constrained approach). In order to concretely implement WS-* to solve some given use case(s), one must leverage the WS-I "profile" specifications in concert with the WS-* protocol specifications. The notion of identity attained in the system will depend upon the selection of which aspects of WS-* are implemented as well as the profiling choices made.<br />
<br />
===Kerberizing Web Identity & Services===<br />
<br />
The use of Kerberos as an authentication mechanism for web applications has a long history in certain communities, notably Higher Education and Research as well as large-scale Enterprises. Extending Kerberos to address web authentication in these communities was typically driven by a desire to reuse technology which was well understood and widely deployed. This motivation has become even more pronounced with the wide deployment of [http://en.wikipedia.org/wiki/Active_directory Active Directory]. There is, therefore, a significant body of experience relating to the use of Kerberos for the Web and related technologies (Web services, XML, identity federations, and so forth) which can be used to formulate a strategy for future work in this field.<br />
<br />
This document tries to describe a number of missing pieces of the puzzle which when combined can help the Kerberos Consortium release the full potential of Kerberos as an authentication technology for the web.<br />
<br />
====Credentials Delegation====<br />
<br />
An important feature of Kerberos is the ability to forward tickets -- i.e the ability to delegate credentials to remote services where they can be used by that service to act on behalf of the user. When the services are simple traditional host-based services (e.g. ssh or telnet) the credentials-delegation picture is relatively uncomplicated: it just works. This picture changes dramatically with the advent of web-based applications needing access to user credentials in order to authenticate to kerberized backend services. This is sometimes referred to as "n-tier". The classical example is the web frontend to a kerberiezd IMAP server. As long as the authentication mechanism for the web application is basic access authentication or form-based authentication, i.e it has access to the user password, the web application can obtain a TGT -- but at the cost of compromising the secrecy of the user's Kerberos password. <br />
<br />
=====Enterprise Web SSO and Credentials Delegation=====<br />
<br />
Identity management in large-scale deployments of web applications has resulted in the deployment of governance solutions for web single sign-on (Web SSO). Open source products like [http://shibboleth.internet2.edu/ Shibboleth], [http://www.stanford.edu/services/webauth/ WebAuth], [http://www.ja-sig.org/products/cas/ CAS], and [http://en.wikipedia.org/wiki/Pubcookie PubCookie], as well as commercial products like [http://www.passlogix.com/ Passlogix], [http://www.actividentity.com/ ActivIdentity], [http://www.avencis.net/ Avencis SSOX], are often deployed as central points of authentication for multiple web applications in the enterprise. These systems are often seen as meeting several different requirements involving compliance (e.g. [http://en.wikipedia.org/wiki/Sarbanes_oxley Sarbanes-Oxley] (S-OX)) and auditing. However, the enterprise SSO makes Kerberos credentials delegation quite difficult. Some products (e.g. PubCookie) have the ability to forward TGTs from the point of authentication to the web application but these are exceptions rather than the rule.<br />
<br />
Combining enterprise SSO with kerberized backend services is often quite difficult if one wants to hang on to the "[http://www.cs.princeton.edu/~jrex/teaching/spring2005/reading/saltzer84.pdf end-to-end principle]" -- which in this context means to maintain a cryptographic connection between the ticket sent to the backend service and the end user credential used to originally authenticate with the IdP in the single sign-on environment. The success of Active Directory led to the introduction (by Microsoft) of a new way to do credentials delegation: [http://msdn.microsoft.com/en-us/library/aa480585.aspx s4u2self] (aka "constrained delegation"). In this model -- as opposed to the end-to-end end model -- the KDC delegates the right to a "service" principal to impersonate a user to a set of services. In our webmail example the service principal would be associated with the web application itself and the KDC would delegate to it the right to obtain IMAP service tickets for any user. The idea is that the web frontend is trusted to properly authenticate the user, by whatever means, allowing the KDC to delegate part of its responsibility to this service principal. This idea is sometimes called "air gap" security and while not as strong as end-to-end n-tier authentication it is nevertheless often good enough for many applications.<br />
<br />
=====User Driven Credentials Delegation=====<br />
<br />
The advent of "Web 2.0" web applications, notably social networking sites like Facebook, Linked-In and large scale software-as-a-service (SaaS) providers like Hotmail and gmail led to the creation of yet another type of credentials delegation paradigm: user driven credentials delegation whereby a user is asked to provide authorization for each time a service needs to be able to access another service with the rights of that user. The typical example is Facebook wanting access to the users Hotmail address book in order to setup relationships with "buddies" on Facebook. The OAuth protocol (cf below) has built-in support for this type of case-by-case credentials delegation. Although the Kerberos V5 specification, RFC 4120, has allowances for implementations to craft such "user driven" behavior, such behavior is not typically implemented and/or materialized to users. <br />
<!-- There is no correspondence to this model in Kerberos today. --><br />
<br />
However, credentials delegation in Kerberos <!-- , given its lack of support for user-driven credentials delegation and the gaps in the model that does exist, --> still remains one of its truly unique properties -- no other widely deployed security protocol has the ability to pass credentials between members of a multi-tiered architecture.<br />
<br />
====Efficiency Concerns====<br />
<br />
With Active Directory came the notion of the PAC - a data structure included in an extension to the ticket which includes what amounts to authorization data associated with the session. We will return to this notion below when discussing Level of Assurance (LoA) transport and SAML profiles for Kerberos. However it is worth noting that the inclusion of authorization information in the Kerberos protocol has adverse side-effects. When Kerberos is used as an HTTP authentication mechanism (cf Negotiate below) as opposed to being hidden behind an SSO abstraction layer such as the SAML Web Browser SSO Profile or a commercial Web SSO such as any of the products listed above - any extension to the ticket that adds significantly to the payload of the HTTP handshake may be noticeable by users in terms of overall system response time. <br />
<br />
Experiences with Active Directory in large-scale deployments (with many groups) shows that the PAC can often grow to ~20k which has a performance impact on HTTP especially when the browser needs to open and process several connections in order to render a single "page" to the user. Modern browsers are optimized for keeping multiple HTTP connections open in parallel and it is not uncommon for single user views ("pages") to result in 100s of connections to the server. In order to address this problem any protocol and/or authentication mechanism employing Kerberos will need a form of session identifier or other way of efficiently re-using the fact of initial authentication for multiple subsequent connections -- for example the "session resumption" feature of TLS (RFC 4346).<br />
<br />
===Summary===<br />
<br />
The Web authentication landscape is therefore highly complex and diverse, both in terms of technology and politics. The contrast with the Enterprise space, where Kerberos is virtually ubiquitous, could hardly be starker. The goal of this document is to explore how Kerberos might be used as a bridge over the "authentication gap" that separates these worlds.<br />
<br />
The document uses the following methodology :<br />
<br />
* First, a set of user stories are presented. A user story describes a particular outcome that a user wants.<br />
* Secondly, a set of use-cases are developed that bind the user stories into scenarios that can be generalized to address other similar problems.<br />
* Thirdly, there is a discussion of all existing technologies that might contribute.<br />
* Finally, a number of activities are proposed that are intended to supplement or extend these technologies in order to realize the use-cases.<br />
<br />
==User Stories==<br />
<br />
A user story is a statement describing a specific desire by a specific type of user in order to achieve a specific value. User stories often appear in agile development frameworks (e.g. SCRUM) and are used as a tool for evaluating the effectiveness of development activities. A user story often takes the form of a single sentence of the form "A wants to do B in order to achieve C".<br />
<br />
We have chosen to describe requirements as user-stories in an attempt to make the requirements easier to evaluate from the point of view of various stake-holders.<br />
<br />
===Notes===<br />
<br />
The term "web-based" is used to denote both "Internet-based" sites/services (connotes likelihood of "third-party"-ness in the overall interactions involved (e.g. ISPs, hosting providers, site/service-providing entity (e.g. bank, store, etc) may figure in the packets' path between user and the site/service process(es), and "enterprise-based" (aka "intranet-based") sites/services (connotes possibility of a range from "single-party"-ness to high "third-party"-ness, depending upon the characteristics of the "enterprise". <br />
<br />
The term "site/services" is simply used at this time to consciously acknowledge the range of web-based possibilities from simple static web pages, to wikis, to fancy full-featured sites offering a range of "services", e.g. Google, Yahoo, AOL, etc. <br />
<br />
A "site/service-providing entity" is also referred to as a "service provider (SP)".<br />
<br />
<br />
===General: Users===<br />
<br />
====Simplicity====<br />
<br />
<pre><br />
US1: Users want to reduce the number of sign-on technologies <br />
and credentials that they are required to use to access web-based <br />
sites/services.<br />
</pre><br />
<br />
====Transparency====<br />
<br />
<pre><br />
UT1: Users want to reduce the number of authentication steps taken <br />
when using online services.<br />
</pre><br />
<pre><br />
UT2: Users want to use mobile devices when authenticating to online <br />
services.<br />
</pre><br />
<br />
====Flexibility====<br />
<pre><br />
UF1: People want to assert different identity information in different <br />
contexts, e.g. to be able to "don" different roles when interacting with <br />
either the same or different site(s)/service(s). E.g. to be able to <br />
interact with a given bank in the role of either an individual consumer, <br />
or an officer of a company which is also the same bank's customer. <br />
</pre><br />
<br />
<pre><br />
UF2: Users want to use untrusted devices (e.g.. an airport Internet kiosk, <br />
a borrowed device) to access sites/services without compromising their <br />
credentials. <br />
</pre><br />
<br />
===General: Service Providers===<br />
<br />
<pre><br />
S1: Service providers that consume identities from third-party identity <br />
providers want to reduce and/or minimize the number of sign-on <br />
technologies that they are required to support.This applies to both <br />
Internet-based and enterprise-based SPs. <br />
</pre><br />
<br />
<pre><br />
S2: Service providers want to be able to manage and minimize the risks <br />
they assume when providing authenticated web-based sites/services. <br />
</pre><br />
<br />
===Financial Services===<br />
<br />
<pre><br />
FS1: Web-based financial services want to avoid phishing, and have their <br />
experience adhere to the "General: Service Providers" user-stories noted <br />
above. <br />
</pre><br />
<pre><br />
FS2: Customers of web-based financial services want to avoid phishing.<br />
</pre><br />
<pre><br />
FS3: Customers of web-based financial services want their experience of <br />
using the site/services to adhere to the "General: Users" user-stories <br />
noted above.<br />
</pre><br />
<br />
Note: essentially all web-based sites/services (and their users) are <br />
subject to phishing attacks. It would seem that the main reason to single <br />
out Financial Services SPs is that the attack results with them can be <br />
particularly devastating.<br />
<br />
===Federation===<br />
<pre><br />
F1: Deployers of web-based portal services with kerberized backend-services <br />
need to be able to use federated identity with N-tier authentication.<br />
</pre><br />
<br />
<pre><br />
F2: Grid services (in environments where PK-INIT is used) in the US Federal <br />
sector need to fulfill policy requirements that authentication be done <br />
using smartcards.<br />
</pre><br />
<br />
<pre><br />
F3: SAML service provider with a large number of affiliated Identity <br />
Providers requires a way to determine which Identity Provider a user is <br />
affiliated with, so that it knows where to request assertions for the user'. <br />
</pre><br />
<br />
<pre><br />
F4: The IT management at two or more federated partners need to define <br />
conventions, or an agreement, governing the use of a federated business <br />
process that is secured using Kerberos.<br />
</pre><br />
<br />
===Enterprise===<br />
<br />
<pre><br />
E1: Enterprise SOA architects want flexible life-cycle management for <br />
identities used for SOA.<br />
</pre><br />
<br />
<pre><br />
E2: Enterprise security officers want secure authentication for SOA.<br />
</pre><br />
<br />
<pre><br />
E3: Enterprise system integrators want interoperability between <br />
web service implementations from major vendors.<br />
</pre><br />
<br />
<pre><br />
E4: Enterprise identity architects want SSO-support in popular browsers <br />
with credential delegation capabilities turned on by default.<br />
</pre><br />
<br />
<pre><br />
E5: Enterprise identity architects want to be able to extend existing <br />
cookie-based SSO systems with support for Kerberos backchannel <br />
authentication and credentials delegation.<br />
</pre><br />
<br />
==Use Cases==<br />
<br />
TODO: complete mapping user-stories to use-cases (user story given as (N))<br />
<br />
The use-cases are divided between three categories<br />
<br />
* ''Back Channel'' - this describes transactions between service providers occur directly, without relying on user-wielded tools (typically, although not exclusively, a web browser) to act as an intermediary. E.g. an ecommerce site interacting directly with a user's banking site, without re-directing communications through the user's web browser. These transactions may either be invoked in response to an action performed by a user (for example, logging into a service provider) or be initiated automatically by software agents.<br />
* ''Front Channel'' - this describes interactions between service providers occurring indirectly via a user-wielded tool -- typically, although not exclusively, a web browser -- to mediate. These transactions are normally invoked in response to an action performed by a user (for example, logging into a service provider).<br />
* ''Front and Back Channel combined'' - this describes interactions that involve elements of Front and Back Channel activity (for example, a Back Channel transaction that is authorized using a token that was established previously in an earlier authentication event while the user was online).<br />
<br />
===Back channel===<br />
<br />
====Intra Enterprise====<br />
<br />
A large organization is deploying an increasing number of web services. Initial deployments, which were typically few in number, relied on the use of shared secrets for authentication and TLS for transport security. Although the web services are mainly SOAP-based, using HTTP for transport, the use of Negotiate or message-layer security is very uncommon.<br />
<br />
As the deployments of web services expands, the management of the shared secrets becomes an issue (E2). There is also increasing concern that certain properties of shared secret authentication, or the practices used to manage them, while acceptable during the initial deployments on low-value applications (such as hard-coding secrets into applications), are not appropriate for higher-value applications. The most common action taken is to move to the use of client certificates which, for an organization of this size and complexity, necessitates the acquisition of a web services governance solution. Such products are often based on an ESB (Enterprise Service Bus) and sometimes employ other transports besides HTTP (for example, various message-oriented protocols such as MQ or XMPP).<br />
<br />
The motivation for using Kerberos with these web services is to simplify the management of their security requirements (E1). However, the web services are perceived as distinct from the existing business infrastructure, and so consequently these services are often treated as a single administrative domain isolated from everything except those business systems which they connect. Therefore, the security properties of Kerberos are unlikely to be an important criterion in any evaluation against alternative mechanisms. It also means that Kerberos administration, in order to be a viable option, must integrate into the various web service governance solutions that exist.<br />
<br />
====Business-to-Business====<br />
<br />
A business needs to integrate with another business using a SOAP-based web service (E3). One or both of these businesses may already be in possession of an existing enterprise-wide SOAP-deployment similar to the one described in the previous use-case. The requirements of the security model are typically fairly simple (for example, there are no n-tier issues). As before, shared secrets are used authenticate endpoints, using either TLS or IPSec for transport security. The use of any transport for SOAP other than HTTP is very uncommon.<br />
<br />
The motivation for the use of Kerberos in this use-case may be to leverage each business' pre-existing Kerberos infrastructure, and possibly an existing cross-realm trust, in order to avoid establishing a special-purpose trust infrastructure (E2).<br />
<br />
The main difference between this use-case and the one that was described previously is that typically only a small number of web services are required for each pair of Business-to-Business relationships. Therefore, establishing and managing cross-realm trust must be perceived as a low barrier to the adoption of this trust-model.<br />
<br />
===Front channel===<br />
<br />
Business-to-employee and Business-to-customer use-cases typically involve front-channel exchanges through the user's (customer or employee) browser. Most technologies involved in front-channel authentication (for example, SAML Web SSO) currently use Form-based username and password authentication, even if other mechanisms are supported.<br />
<br />
The motivation to use Kerberos might be to provide a better user-experience. Information Card in combination with Kerberos could also be used to provide a consistent and simplified user experience for web-based authentication. The same is true (to a lesser extent) for Negotiate-based authentication.<br />
<br />
====Business-to-employee====<br />
<br />
In this use-case, the business issues credentials to the employee (E1). These could be used to provide access to both internal corporate resources, and resources offered by third-parties (such as SaaS providers).<br />
<br />
====Business-to-customer====<br />
<br />
In the case where the business issued credentials to customers, the primary challenge would be identity provisioning and management: a user would typically need to obtain and negotiate the use of credentials from multiple realms, obviating the single sign-on benefits of Kerberos.<br />
<br />
This could be mitigated through either the use of Kerberos cross-realm operation, or identity federation technologies (for example, the SAML Web SSO Profile) where Kerberos could be used to authenticate the user at an Identity Provider trusted by those businesses that the customer interacts with. If this were intended to solve the general problem (that is, for most users, for most service providers), there are a number of challenges; these include ''Identity Provider Discovery'' (how does a business determine which Identity Provider a customer is affiliated with, assuming a model involving multiple Identity Providers), technical trust model and governance.<br />
<br />
===Front and Back Channel Composition===<br />
<br />
====Credentials Delegation====<br />
<br />
A recently merged company wishes to provide the newly-united workforces with a single web portal providing access to various back-end services that, owing to delays in the re-organization of the respective IT functions, will remain administratively separate for some time. The provision of email is a core function of the web portal, which therefore needs to access a set of IMAP servers in these separate administrative domains. To avoid the need to issue new credentials to users, SAML-based Web SSO is used to provide federated authentication by the SAML Identity Providers operated by each IT function. These Identity Providers trusted could provide the web portal with delegate-able credentials for their own IMAP server(s) (E5).<br />
<br />
====Level-of-Assurance transport====<br />
<br />
Many services have policies attached to their use that stipulate which type(s) of credentials are acceptable (often called the ''level of assurance'') (E2). In scenarios where the service itself is authenticating the user's credentials, the policy is normally trivial to enforce using technical means because the service has visibility of the authentication event.<br />
<br />
However in a distributed environment the authentication of user credentials is often performed by a third party, out of the control of the service. There are several examples from within the US federal sector where services may require the use of smartcard technology and where there is also a desire to provide a federated web front-end (normally to extend access to users affiliated with trusted organizations).<br />
<br />
However, there is currently no way to communicate information about the authentication event (except in a few corner cases involving PK-INIT). Although SAML defines n element that enables an Identity Provider to express an ''Authentication Context'', it is unspecified how this should be used in a Kerberos deployment.<br />
<br />
==Security Technologies==<br />
<br />
The security technologies relevant to the HTTP-based Web can be divided into three overall categories:<br />
<br />
* ''Transport security'' is provided by the underlying transport protocol. The security service only acts at the socket or datagram layers between two hosts, and bindings to high-level security measures tend to be non-existent. Credentials are usually issued to hosts (if datagram-based) or services (if socket-based).<br />
* ''Application security'' is provided by the application protocol in combination with, or independent of, substrate transport security. Credentials are usually allocated to an application, and the users accessing those applications. Applications may, in some circumstances, leverage user credentials to act on a user's behalf. This is referred to as "impersonation" and/or "delegation" depending upon the detailed context.<br />
* ''Message security'' describes an approach where (application) protocol messages are individually cryptographically bound to security tokens they convey directly and/or indirectly (by reference). With such an approach, the protocol messages may be conveyed over different transports (e.g. HTTP, SMTP, TCP, etc), or stored on intermediate or endpoint systems, while retaining intact their originating security context (modulo any allowances for message modification in-transit). <br />
<br />
===Transport security===<br />
<br />
HTTP is the common transport in web-orientated architectures. Transport security is usually provided using TLS and X.509 PKI.<br />
<br />
Kerberos-based alternatives (existing and proposed) include:<br />
<br />
* Kerberos with IPSec.<br />
<br />
* Negotiate.<br />
<br />
* A specification describing a Kerberos-based cipher suite for TLS exists ([http://www.ietf.org/rfc/rfc2712.txt RFC2712]), and has seen at least two implementations ([http://www.openssl.org OpenSSL], [http://java.sun.com/javase/6/docs/technotes/guides/security/jgss/lab/part2.html JGSS]), but is widely regarded as flawed.<br />
<br />
* A recently-expired [http://tools.ietf.org/html/draft-santesson-tls-gssapi-03 draft] describes extensions to [http://tools.ietf.org/html/rfc4279 RFC4279] to enable dynamic key sharing in distributed environments using a GSS mechanism, and then import that shared key as the "Pre-Shared Key" to complete the TLS handshake. The TLS Working Group [http://www.ietf.org/mail-archive/web/tls/current/msg01887.html has argued] that user principal authentication is an application-level concern, and so this work appears to have stalled.<br />
<br />
Other transports, such as [http://www.xmpp.org XMPP], are available. However it is likely that architectures requiring the use of two or more transports would emphasize the use of message-based security, because the transports' respective security properties are not necessarily functionally equivalent. Where multiple web services are deployed from the same application server it is common to use a web service governance solution which abstracts the service business logic from the transports.<br />
<br />
In summary, HTTP is almost always used - but sometimes other transports are also used. In this case the logical way to provide security is to use message-based security.<br />
<br />
===Application security===<br />
<br />
====Negotiate====<br />
<br />
"Negotiate" is the collective name of a loosely defined set of HTTP authentication mechanisms that provide a simple 2-way [http://en.wikipedia.org/wiki/GSS-API GSS-API] handshake with the HTTP server. The most commonly deployed variant, "Simple And Protected Negotiate (SPNEGO)", defined in RFC 4559, uses the SPNEGO GSS-API mechanism, itself defined in RFC 4178. Other implementations use the Kerberos5 GSS-API mechanism (RFC 4121) instead. Updates to RFC 4559 have been discussed.<br />
<br />
It is worth noting that Negotiate authentication does not protect the HTTP request, because they are sent unprotected during the GSS-API handshake (which is itself encoded within an HTTP header). This authentication method is therefore not advised in some use-cases; in particular, REST-style web-services cannot in general be protected using Negotiate alone. Note that this is the case with all present authentication techniques that are conveyed within an HTTP message itself, e.g. in the HTTP message headers: Basic, Digest, and Negotiate. <br />
<br />
Negotiate suffers from a lack of mutual authentication and support for multiple-roundtrip GSS-API mechanisms. Earlier attempts (in the IETF) of introducing SASL-based authentication for HTTP showed that in order to gain wide acceptance any multiple-roundtrip HTTP authentication mechanism has to be able to deal with consecutive HTTP/1.1 connections being sent to different TCP endpoints (e.g. if a concentrator is deployed at the server). This implies that the authentication mechanism needs to support some form of state management. At least two different proposals have been put forward for solving this problem; one in http://tools.ietf.org/html/draft-johansson-http-gss where state management is done in the HTTP layer and one in http://tools.ietf.org/html/draft-zhu-negoex where state management is done in the GSS-API layer.<br />
<br />
====Information Card====<br />
<br />
;Introduction :<br />
<br />
"Information Card" is an identity technology based on the notion of a smart client, the identity selector (IS), under the control of a user, that can interact with a relying party(RP), and optionally an identity provider (IdP), to accomplish application signon and delivery of user information to the RP. Both IS-RP and IS-IdP interactions use the WS-Trust protocol (part of the WS-* suite). WS-Trust is intended to be a "meta" authentication protocol that can in theory permit a security token to be delivered to the RP in whatever format it requires, independent of the method the client uses to authenticate to the IdP. The identity selector has a user interface that presents the user's authentication options in the form of cards. A card can be "managed", meaning that it is issued by an IdP, and requires authentication to that IdP when used. Or, a card can be "self-issued", meaning it is generated within the identity selector, and uses a keypair managed by the selector to authenticate to the RP.<br />
<br />
Though Microsoft is the initial developer and evangelist of Information Card, many other companies and projects are developing compatible software and contributing to the technology specifications. The Information Card Foundation (http://www.informationcard.net/) was formed in 2008 to promote the technology. Microsoft's Information Card client (known generically as an "identity selector" or "identity agent") is called CardSpace. Since it is the most well-known implementation, many people (incorrectly) refer to the whole technology as CardSpace. The Information Card concept was originally developed by Kim Cameron of Microsoft as part of an "Identity Metasystem" concept, so this term is also used for this technology. The technology is now being standardized in an OASIS technical committee called the Identity Metasystem Interoperability TC (http://www.oasis-open.org/committees/imi/).<br />
<br />
The Information Card specifications define the authentication methods supported between identity selectors and IdPs (in the managed card case). Kerberos is one of these methods. The others are: X.509 cert, username/password, and self-issued card (technically a SAML token).<br />
<br />
;Kerberos authentication from Identity Selector to IdP :<br />
The Identity Selector (IS; an end-user client-side tool) can authenticate to an IdP using Kerberos. The WS-Security Kerberos Token Profile is used, underlying the WS-Trust protocol that does the security token request. An IdP supporting Kerberos authentication would be an application server from the Kerberos point of view. It doesn't appear that any of the existing Information Card IdP software supports Kerberos authentication however, so this is an opportunity for improvement. Microsoft's IdP (which probably won't be available until 2009) will support all four defined methods, including Kerberos.<br />
<br />
;Kerberos token delivery to the RP :<br />
WS-Trust operates by delivering security tokens to RPs to authenticate clients. WS-Trust is (or claims to be) token agnostic, meaning it can carry anything, but for a token format to be used interoperably its nature and handling by IdP and RP must be specified. Information Card defines the use of SAML tokens for self-issued cards and these have commonly been used as tokens in managed cards also. It would be possible to define a Kerberos token. Such a token (presumably a KRB_AP_REQ) would be generated by the IdP, carried by WS-Trust from IdP to IS and from IS to RP, and processed by Kerberos software at the RP. There is no such token defined at this time. Recent comments from Microsoft about supporting cross-technology delegation imply that it might be implementing delivery of Kerberos tokens via WS-Trust.<br />
<br />
;Identity Selector as standard authentication UI :<br />
Information Card technology has been introduced as an approach for browser authentication to web applications, since the web is obviously widely-used and urgently in need of better authentication solutions. The selector concept, however, can apply to any instance of user authentication. This might involve extending selectors to support other protocols, or adding the use of WS-Trust for authentication to existing systems. In particular the Identity Selector could be a user interface for Kerberos initial authentication in some scenarios.<br />
<br />
====OAuth====<br />
<br />
;Introduction :<br />
<br />
OAuth (http://oauth.net/) is a specification for interoperable support of delegated access to web-based resources. It is designed to support a particular common use case: a user of one web-based service (for example, a photo-sharing service, called the OAuth service provider) has protected resources (for example, photos) that the user would like to make accessible via another web-based service (for example, a social-networking service, called the OAuth consumer). This is often done today by the consumer service obtaining from the user their username and password on the service provider. The goal of OAuth is to avoid this practice. This done by defining service points to permit an access token to be produced by the service provider and delivered to the consumer via the browser. This token can then be used (after some transformation) to access the service provider via an OAuth-defined HTTP authentication method.<br />
<br />
OAuth was developed by an adhoc group, based on similar specs from a number of web technology companies (e.g. Google, Yahoo!). Its current version is 1.0. There are several implementations for different languages and platforms, and some initial deployments. Google in particular defines extensive support (http://code.google.com/apis/accounts/docs/OAuth.html).<br />
<br />
OAuth has no defined relationship to Kerberos or any other existing authentication technology at this time. Note that since the tokens are both issued and consumed by the service provider, their internal format and semantics can be whatever the service provider wants. For example, the validity period of the token is not defined in the spec or represented in the protocol; it is entirely up to the issuer.<br />
<br />
The standard OAuth scenario is referred to as "three-legged" since it involves the consumer, the provider, and the user who must indicate consent and transport the access token. There is interest in "two-legged" scenarios where the OAuth HTTP authentication method is used simply between consumer and provider, not on behalf of some user. In this case it would be an alternative to other HTTP authentication methods such as Basic or X.509/SSL. <br />
<br />
;Opportunities :<br />
<br />
There has been recent discussion about profiling OAuth with SAML in order to permit the encapsulation of SAML assertions (that might convey, for example, information about the user) in the OAuth protocol exchange, in conjunction with the otherwise OAuth-specific cryptographic credentials. As an alternative, Kerberos tickets could be sent either instead of or in conjunction with such SAML assertions. This could be appealing for a Kerberos-oriented OAuth service provider.<br />
<br />
OAuth defines an initial registration and key-exchange step betwen consumer and service provider. In a scenario where consumer and provider use Kerberos this step could be skipped if a method to bootstrap OAuth keys from Kerberos were defined.<br />
<br />
====OpenID====<br />
<br />
[https://spaces.internet2.edu/display/kerweb/OpenID] <font size="1">(reference material)</font><br />
<br />
OpenID Identity Providers (OPs) ''could'' employ Kerberos to authenticate their users and this approach for an OpenID OP would probably be quite useful as a means for an enterprise to stand up an OP in front of its existing authentication infrastructure. It is unclear how common this approach will be but it as been argued that enterprise passwords would become less exposed by something like this since users typically pick the same password for their blog/yammer/amazon account as the password used at work since it is easier to remember it. This practice exposes the enterprise credential to additional risk. There is very little an enterprise security officer could do about this except to provide an alternative and reasonably safe way to reuse the enterprise authentication.<br />
<br />
===Message security===<br />
<br />
====Security Strategies for Message-based architectures====<br />
<br />
Good message-based implementations understand that there are multiple SOAP transports and provide an interface for plugging in new ones, however in practice SOAP transports other than HTTP rarely occur when performance isn't an issue.<br />
<br />
SOAP method calls are either secured at the transport or message layer or both. The "official" way to secure SOAP is to use WS-Security but transport-layer security is much more common especially in the cross-domain cases. In this case it is not uncommon for IPSEC to be used to provide a tunnel between the client and the server and for the HTTP-based SOAP-calls to be unauthenticated in this tunnel. When tunnels are not practical it is common for HTTPS (TLS) to be used in combination with a username and clear-text password.<br />
<br />
The reason for using Kerberos may be any of:<br />
<br />
* Kerberos is easier to use once deployed and if the service endpoint is one of many published by "A" then maintaining username and passwords will be unpractical for the same reasons that maintaining lots of password-based user identities would be impractical. In this case Kerberos provides life-cycle management for the identities used to secure the web service.<br />
* Kerberos is the default security service used by the application framework used to develop and deploy the service endpoint.<br />
* Kerberos is chosen because security policy mandates the use of Kerberos for identities.<br />
<br />
There are (therefore) two ways to authenticate SOAP using Kerberos and if we ignore the possibility of using Kerberos with IPSEC for now:<br />
<br />
* by securing the transport.<br />
* by securing the SOAP messages.<br />
<br />
====The WS-* suite====<br />
[https://spaces.internet2.edu/display/kerweb/WS-*] <font size="1">(reference material)</font><br />
<br />
WS-* ("dubya ess star") denotes a suite of web services specifications promulgated by IBM, Microsoft and various collaborators. Unlike the SAML and ID-WSF specifications, only a few of the WS-* specifications have been subject to an open standardization process and subsequently their quality can be generously described as variable.<br />
<br />
Of these specifications, there are three that are central to WS-* security<br />
<br />
* WS-Security: this specification defines how security tokens are bound to messages. WS-* has defined security token profiles for SAML and Kerberos, amongst others, that can be leveraged by this specification. WS-* officially employs WS-Security-based ''messaging'' security techniques almost exclusively.<br />
* WS-Trust: this specification defines how to exchange (request, issue, renew, cancel) security tokens with web services. These tokens may be used in a variety of ways; for example, as evidence to authorize access to a web service.<br />
* WS-Federation: this specification is a specialization of WS-Trust that defines how to exchange security tokens in a federated context.<br />
<br />
In the Web and Kerberos context, the most important of these is WS-Trust as it provides the mechanisms for using tokens that might be a Kerberos ticket or a SAML assertion) to establish and leverage trust. WS-Trust also plays a key role in the Information Cards technology, another specialization of WS-Trust.<br />
<br />
=====WS-Security Kerberos Token Profile=====<br />
<br />
[https://spaces.internet2.edu/display/kerweb/WS-Security+Kerberos+Token+Profile] <font size="1">(reference material)</font> <br />
[''message security'']<br />
<br />
The WS-Security Kerberos Token Profile defines how to use Kerberos service tickets (specifically, the KRB-AP-REQ message) as a security token. The acquisition of the token is out-of-scope.<br />
<br />
The Kerberos message is attached to the SOAP message using the <wsse:BinarySecurityToken> element. Six different types are supported, including RFC 1510-style, RFC 4120-style and their equivalent GSS-API encapsulations. The octet sequence is encoded using the indicated method.<br />
<br />
This specification does not support the KRB-AP-REP message, and so consequently neither Kerberos mutual authentication, nor GSS-API channel bindings, are supported. In practice, therefore, this specification needs to be combined with transport layer security (e.g. TLS).<br />
<br />
====OASIS Security Assertion Mark-up Language (SAML)====<br />
<br />
[https://spaces.internet2.edu/display/kerweb/SAML] <font size="1">(reference material)</font><br />
<br />
SAML provides a suite of XML-based protocols that enables different security domains to exchange security data about user principals.<br />
<br />
Broadly, the SAML specifications define:<br />
<br />
* the ''assertion'', a security token that can express a user principal's authentication status, authorizations and other general attribute information.<br />
* ''protocols'', that are primarily used to request assertions about a user principal.<br />
* ''bindings'', that define how protocols are bound to certain transports (such as SOAP).<br />
* ''profiles'', that constrain the use of assertions, protocols and bindings to realize specific use-cases (such as the "Web SSO Profile").<br />
* ''federation metadata'', that allows security domains to express information (primarily configuration data, such as a public key) about themselves to other security domains.<br />
<br />
Although SAML focuses primarily on the passing of messages to federate identities in different security domains for Web SSO applications, the architecture of SAML allows discrete functional elements to be re-used in other contexts, allowing a broad range of potential applications. For example, the SAML assertion has been re-used in many other technologies - even technologies, such as WS-Federation implementations, which are competitive with SAML as a whole. Consequently it can be argued that the categorization of SAML as 'message security' is a generalization, depending on which particular ''SAML profile'' is being examined, and how it is specifically crafted in concert with the target protocol(s).<br />
<br />
SAML does not stipulate the use of any particular trust model(s), although X.509-based trust establishment and TLS is widely used in practice.<br />
<br />
There are several ways in which SAML, in terms of either SAML assertions themselves or the SAML profiles, can or could interface with Kerberos:<br />
<br />
;The SAML Identity Provider (IdP) uses Kerberos to validate usernames and passwords supplied by users on webpage forms<br />
:The main benefit offered by this configuration is that it allow users to use the same credentials to access resources protected by both SAML and Kerberos, offering users greater convenience. This is achievable with little or no modifications to the SAML IdP, and is a configuration that is likely to be used by IdP deployments today. <br />
<br />
;The IdP uses Kerberos authentication at the HTTP layer - e.g. Negotiate or NTLM<br />
:The main benefit offered by this configuration is that it permits the use of Kerberos-based SSO to authenticate to the SAML IdP, offering greater convenience to users. This is achievable with little or no modifications to the SAML IdP, and is a configuration that is known to be used by many IdP deployments today. <br />
<br />
;The IdP issues SAML assertions containing Kerberos tickets as an attribute<br />
:It would allow a SAML Relying Party to acquire a Kerberos ticket that it could use subsequently to authenticate, as another principal, against a Kerberos protected resource. The main benefit is that it could be used to support n-tier web-based use-cases (such as the webmail use-case), offering greater convenience to users and possibly reduce the abuse of user credentials by providing applications with delegable credentials. This would require modifications (possibly not too significant) to the SAML IdP. <br />
<br />
;The KDC includes a SAML assertion and/or authentication response message encapsulated in KDC-issued authorization data<br />
:It would allow the KDC to issue SAML assertions (or perhaps SAML messages in general) to Kerberos services. The main benefit is that this could be used to complement Kerberos-based authentication and/or provide richer authorization. This would probably require modification (probably reasonably significant) to the KDC. <br />
<br />
;The SP uses Negotiate to find the preferred IdP of the user (aka IdP discovery) based on the Kerberos-realm in the GSSAPI authentication request.<br />
:The benefit of this is that it reduces or eliminates the need to use GUI-based IdP Discovery (the commonest form of IdP discovery), which scales poorly and introduces UI considerations such as localization and accessibility. This is achievable with little modification to the SAML SP. It has already been implemented on SWITCH's "Where Are You From" service (but not used in their production federation). <br />
<br />
;A GSSAPI peer implementing the proposed GSSAPI naming extensions receives a SAML attribute assertion as part of a GSSAPI protocol exchange<br />
:While not strictly tied to Kerberos this may provide a way to tie in with other uses of the GSS-API naming extensions.<br />
<br />
====Liberty Alliance Identity Web Services Framework====<br />
[https://spaces.internet2.edu/display/kerweb/ID-WSF] <font size="1">(reference material)</font><br />
<br />
The Identity Web Services Framework (ID-WSF) is a set of specifications from the Liberty Alliance that builds on SAML to provide a full-featured web services stack that leverages WS-Security as its encapsulating security token format. Thus it is possible to leverage Kerberos-based authentication in an ID-WSF-based web services context, although at this time the limitations noted above with respect to the WS-Security Kerberos Token Profile will apply.<br />
<br />
<br />
==Security Technology Requirements==<br />
This section presents requirements that security technologies employed in the HTTP-based Web context ought to satisfy.<br />
<br />
===Security Protocol Overall Efficiency===<br />
<br />
Some small number of handshake exchanges in order to authenticate the principal with the IdP (i.e. KDC if Kerberos is being employed). Subsequent interactions with other websites, participating in the authentication domain, can be authenticated with a security token (e.g. a service ticket if Kerberos is being employed) accompanying HTTP messages from the user agent. <br />
<br />
The rationale here is that for any given web page, a user agent may make any number (not infrequently on the order of tens O(10) ) of requests to the server. This is due to the the user agent typically retrieving web page constituent components, e.g. images, frames, tables, etc., with an HTTP request per component. This is sometimes referred to as being "chatty". Since such requests are performed independently and asynchronously over separate TCP connections, each HTTP request will need to convey authentication information that the service provider can validate & verify without further interactions. <br />
<br />
===Security Token Size===<br />
<br />
Because of the "chatty" property of some web interactions noted above, and the necessity of each individual HTTP request being authenticated, the security token size will likely matter. <br />
<br />
Microsoft reports customer feedback to this effect: Active Directory et al encode principal group membership information -- Privilege Attribute Certificate (PAC) -- in the Kerberos service ticket. This can expand the ticket size to be over 12k bytes and noticeably slow down "chatty" web interactions. The same would likely be the case for attaching any other "large" chuck of information to service tickets and/or the HTTP requests themselves.<br />
<br />
===User Interaction===<br />
<br />
Some security technologies, e.g. Kerberos, are designed with the notion of signing the user on once, and then further interactions with participating entities (e.g. service provider websites) occurs in a transparently authenticated fashion. <br />
<br />
However, in some contexts -- especially those in which principal attributes beyond baseline principal name and secret are conveyed -- it may be required for there to be interaction with the principal at least whenever the user agent is being compelled to convey more information than some configurable baseline to the service provider (aka relying party). This, for example, is one of the features of [[Information Card]]s' "Identity Selector" user agent, and the underlying Identity [http://www.oasis-open.org/committees/download.php/29511/Identity_Selector_Interoperability_Profile_V1.5.pdf "Selector Interoperability Profile"] protocol.<br />
<br />
==Browsers==<br />
<br />
Most browsers support Negotiate by default, but most either disable the feature (requiring the user to enable it manually) or limit its use to "local" sites or sites explicitly trusted. It is unclear what the threat-model looks like and this should be investigated further.<br />
<br />
===Safari===<br />
<br />
Safari supports Negotiate with SPNEGO since Tiger. There is an information card identity selector for safari here: http://www.hccp.org/safari-plug-in.html.<br />
<br />
===Mozilla/Firefox===<br />
The Mozilla and Firefox browser family includes native support for Negotiate using the Kerberos GSS-API mechanism. This feature is not turned on by default though, and must be turned on manually by editing the "prefs.js" file. Credentials delegation is supported but must also be turned on manually. There are a few plugins implementing Information Card for Firefox/Mozilla. It is unclear if any of them support Kerberos authentication for Information Card-based IdPs.<br />
<br />
===Internet Explorer===<br />
<br />
Negotiate was invented by Microsoft and is widely deployed through the implementation in the Internet Explorer family of web browsers.<br />
<br />
===Konqueror===<br />
Konqueror is the browser included in the KDE desktop framework. Konqueror supports Negotiate and enables Negotiate for sites in the same domain as the client. There is no support for Information Card yet in Konqueror.<br />
<br />
==Application environments & Libraries==<br />
<br />
===IIS===<br />
IIS naturally has native support for Negotiate using the SPNEGO GSS-API mechanism. <br />
<br />
===.NET===<br />
The .NET framework supports the WS-Security Kerberos Token Profile as well as Negotiate natively.<br />
<br />
===Apache===<br />
Apache has add-on modules supporting Negotiate using both SPNEGO and Kerberos GSS-API including http://modauthkerb.sourceforge.net/.<br />
<br />
===Perl===<br />
The LPW::Authen::Negotiate module implements Negotiate using the GSSAPI perl module which in turn uses either Heimdal or MIT Kerberos libraries. This means that LPW::Authen::Negotiate can support both SPNEGO and Kerberos GSS-API.<br />
<br />
===Ruby===<br />
There is a GSS-API library for ruby which similar to the perl GSS-API library supports either MIT or Heimdal Kerberos. However the Ruby HTTP client library does not natively support Negotiate (it does support NTLM though). There have been working patches but they are not maintained. Ruby is one of the language of choice for "web 2.0" applications especially in combination with the Rails framework. These applications are known to prefer REST-style web services to more "enterprise"-style SOAP-based web services.<br />
<br />
===Java===<br />
Java has native support for the Kerberos GSS-API mechanism since JDK 1.4. A number of implementations of Negotiate exists for various application servers (e.g. Tomcat and JBoss). There are not free implementations of SPNEGO for JDK 1.5 and later although there are at least two commercial implementations. Since JDK 1.6 there is native support for SPNEGO.<br />
<br />
===WSS4j===<br />
WSS4J is the primary free implementation of XML security (from the apache project). It does not include an implementation of the Kerberos token profile.<br />
<br />
==Suggested Activities==<br />
<br />
[[Image:Kerberos-ArchAndProposedWorkItems-00.png|Figure 1]]<br />
<br />
* Back Channel (BC)<br />
*# Update the Kerberos Security Token Profile to support mutual authentication and channel bindings.<br />
*# Promote the implementation of the updated Kerberos Token Profile in common software frameworks (e.g. .NET, wss4j) and demonstrate interoperability.<br />
*# Update Kerberos cross-realm operation (in progress).<br />
*# Develop conventions or best-practices for integrating Kerberos into web-services governance solutions.<br />
<br />
* Front Channel (FC)<br />
*# Promote implementation and interoperability testing of Kerberos authentication for Information Card.<br />
*# Update Negotiate (in progress).<br />
*# Interoperability testing of Negotiate implementations.<br />
*# Investigate the role of Kerberos in OpenID.<br />
*# Define a discovery mechanism for SAML Web SSO deployments with many Identity Providers, enabling service providers to establish the Identity Provider that a customer is affiliated with.<br />
<br />
* Front and Back Channel (FB)<br />
*# Specify credentials-delegation for SAML-based SSO.<br />
*# Investigate the role of Kerberos in OAuth.<br />
*# Specify a SAML profile based on having the KDC sign a SAML authentication response/attribute assertion/authentication context. Also specify the relationship with GSS naming extensions.<br />
<br />
* Other (O)<br />
*# Document the ways in which Kerberos can be used in a web-context with current technology, to assist contemporary deployers seeking to address certain use-cases today.<br />
*# Develop best-practices and boilerplate covering governance of Kerberos-based web services.<br />
<br />
<br />
TODO: classify suggested activities by who needs to work on them, e.g. what SDOs / vendors / projects would need to be involved, skill set needed, SWAG wrt effort, etc. <br />
<br />
also recommendations wrt near- / intermediat- / long-term phasing.<br />
<br />
suggestion from SteveB:<br />
<br />
<pre><br />
One way to rank/organize these might be a table with the following <br />
columns:<br />
<br />
Activity Impact Effort Risks <br />
<br />
<br />
An example might be<br />
<br />
Activity Impact Effort Risks<br />
Investigate the role May solve large problem High, many years Technology neither implemented<br />
of Kerberos in OAuth. nor well understood<br />
</pre><br />
This documentation is made available under the MIT Kerberos License [[MIT_Kerberos_License]]</div>Sbuckleyhttps://k5wiki.kerberos.org/wiki?title=KrbWeb_Outline_of_Work&diff=706KrbWeb Outline of Work2008-10-09T07:56:53Z<p>Sbuckley: </p>
<hr />
<div>'''<font size="5">Towards Kerberizing Web Identity and Services</font>'''<br />
<br />
<br />
<br />
<font size="5">Abstract</font><br />
<br />
Today, authentication and authorization are addressed in an incoherent, often site-specific fashion on the Internet overall and the Web specifically. This situation stems from many factors including the evolution, design, implementation, and deployment history of HTTP and HTTP-based systems in particular, and Internet protocols in general. Kerberos is a widely-implemented and widely-deployed authentication substrate with a long history in various communities and vendor products. Here we outline the history of "Web identity", "Web Single Sign-On", "Web Services" and "Web Services Stacks", and present how Kerberos fits into this picture today. Relevant "user stories" are then presented, as well as technological use cases along with a taxonomy of extant Web-relevant security technologies. From this we present an overall general architecture model and suggested activities for working towards more cohesive and widely deployed Kerberos-based Web authentication infrastructure. <br />
<br />
<br />
;Authors (alphabetical):<br />
:Jeff Hodges, Kings Mountain Systems<br />
:Josh Howlett, JANET<br />
:Leif Johansson, Stockholm University<br />
:RL "Bob" Morgan, Internet2 / University of Washington<br />
<br />
[[Category:Kerberos and web pages]]<br />
<br />
==Introduction==<br />
<br />
In this paper we attempt to provide a high-level overview of how authentication of end users, and to some extent their authorization, fits into the Web landscape -- and Kerberos' place in that picture along with its strengths and gaps. We follow with a brief presentation of "user stories" -- simple statements of what end users, deployers, and enterprises desire in terms of their security-related experiences when using the Web. Next, we discuss technological use cases, specific web-relevant security technologies, and some overall requirements such technologies should meet. Then we touch briefly on implementation and deployment technologies -- e.g. browsers and application development libraries, before closing the paper with a presentation of an architectural model, suggested activities, recommendations, and analysis. <br />
<br />
==Acknowledgments==<br />
<br />
This work is gratefully supported by the [http://www.kerberos.org/ MIT Kerberos Consortium]. We acknowledge and thank Love Hörnquist Åstrand, Steve Buckley, Michael Gettes, Ken Raeburn, Tom Yu, and Larry Zhu for their input and comments. <br />
<br />
==Related Pages==<br />
<br />
[[KrbWeb_Backlog|"Backlog" Page]] <br />
<br />
Steve's [[KrbWeb_Buckley-BoardMtgPresoAndNotes-2008-07-24|"slides and notes from the Consortium Board meeting"]] from 24-Jul-2008<br />
<br />
==Overview==<br />
<br />
===A Short History of Web Identity===<br />
<br />
For a system that was originally intended to facilitate collaboration between physicists, it is remarkable how ubiquitous Web technologies have become. It is no exaggeration to claim that the HTTP protocol defined in RFC 2616 is the ''de facto'' transport for applications operating between internetworked hosts. This is due, in part, to HTTP's success in meeting its authors' goal of defining a generic, stateless, protocol which can be used for many tasks beyond its use for hypertext transfer', but perhaps mainly to the convenience of using a common transport in an Internet composed of networks with diverse capabilities and policies.<br />
<br />
====The Primordial Identity Soup====<br />
<br />
HTTP's standard authentication capabilities, [http://en.wikipedia.org/wiki/Basic_access_authentication Basic] and [http://en.wikipedia.org/wiki/Digest_access_authentication Digest], are specified in RFC 2617. The most obvious deficiencies of these protocols, such as capture of credentials on-the-wire, were widely appreciated at the time, and the response was to remedy them using SSL (and subsequently TLS). However, the user experience provided by browsers implementing these methods was deemed by many as "poor" (for example, the bland username and password dialog) and also was effectively "unbrandable". So while these methods were deployed within the Enterprise (typically to protect Intranets and programmatic web services), they were largely ignored by the broader Web development community, where so-called [http://en.wikipedia.org/wiki/Form_based_authentication Form-based authentication] became dominant.<br />
<br />
Unlike Basic and Digest authentication, which are typically implemented in the web server -- at a system level -- Form-based authentication is typically implemented at the web application level. The application uses XHTML elements to construct a Form, typically consisting of username and password fields (and increasingly also a ''captcha'' dialog). The user enters his credentials into the Form, which is submitted to the application using the HTTP POST method.<br />
<br />
The paradigm of using TLS-protected Forms for user authentication and X.509-based server authentication became extremely common, and it remains the most common approach to authentication and establishing trust. However, this paradigm is not without drawbacks. The most significant problems include:<br />
<br />
* [http://en.wikipedia.org/wiki/Phishing Phishing] of credentials<br />
* Excessive numbers of credentials<br />
* Inconsistent and complex user experience<br />
* Privacy violations<br />
* Ad-hoc and unstandardized<br />
* not a system-level approach<br />
<br />
These drawbacks can be viewed as symptoms of this paradigm's failure to scale with the explosive growth of the Web. This confounded early attempts to improve HTTP authentication (for example, attempts to leverage [http://en.wikipedia.org/wiki/Simple_Authentication_and_Security_Layer SASL] (RFC 4422)) which might have permitted the use of a Kerberos mechanism) because the Web had not yet attained the scale and significance where the symptoms had developed to the chronic level that we observe today, and so consequently there was no obvious case for significant alterations to protocols or implementations.<br />
<br />
====Birth of Web Single Sign-On and Identity====<br />
<br />
The need for some notion of "Web [http://en.wikipedia.org/wiki/Single_sign-on single sign-on]" -- termed "Web SSO" -- was perceived by various disparate parties from the mid-1990s onwards. Often this occurred in a commercial, higher educational, or governmental enterprise setting. Many roughly similar solutions were concocted roughly in parallel, and the practice continues right to the present day. Some examples are the [http://www.stanford.edu/services/webauth/ WebAuth] system concocted and deployed at Stanford University (mid-to-late 1990s), [http://en.wikipedia.org/wiki/Pubcookie PubCookie] from University of Washington, and Yale's [http://www.ja-sig.org/products/cas/ Central Authentication System (CAS)].<br />
<br />
The first OS-vendor-driven effort to improve Web authentication, and provide users a cohesive notion of web-based "identity" as well as Web SSO, was [http://en.wikipedia.org/wiki/Windows_Live_ID Microsoft's Passport service]. However, Passport failed to gain any lasting traction, beyond Microsoft's own services, for reasons of trust. Technically, Microsoft's initial Passport SSO protocol was flawed, reducing confidence in this aspect of the system. More critically, Passport was perceived by potential consumers of the system - and others - as a vehicle that could hand Microsoft a monopoly in Internet identity. Passport's importance began to diminish in 2004 when Microsoft canceled the contracts with the most significant consumers of Passport, including eBay and Monster.com.<br />
<br />
In parallel with Passport, a Technical Committee (TC) within [http://www.oasis-open.org OASIS] -- the [http://www.oasis-open.org/committees/security Security Services TC (SSTC)] -- was established to define [http://en.wikipedia.org/wiki/Saml SAML], an open XML-based identity system derived from two earlier specifications, S2ML and AuthXML. SAML was the first, and is the most successful, technology for [http://en.wikipedia.org/wiki/Federated_identity federated identity]. The SAML specifications were quickly leveraged by the [http://en.wikipedia.org/wiki/Single_sign-on Liberty Alliance], a broad vendor and "deploying organizations" consortium initially reacting to the perceived threat from Passport, for their own [http://www.projectliberty.org/liberty/resource_center/specifications/specifications_archives/liberty_alliance_phase_i_1_0_specifications ID-FF (Identity Federation Framework)] specifications.<br />
<br />
In contrast to Passport, which was conceived as a wholly centralized identity system, federated identity is an approach in which a website (normally called the Service Provider, or SP) delegates responsibility for user authentication (and sometimes user authorization) to a trusted third party (normally called an Identity Provider, or IdP) with which the user is affiliated. The relationship between one or more IdP(s) and one or more SP(s) that have federated is often called a "federation" (the Liberty Alliance refers to this as a Circle of Trust).<br />
<br />
====Evolution Towards Federated Identity====<br />
<br />
However, Federated Identity does not replace Form-based authentication, nor was it ever intended to. Federated identity is independent of the authentication technique used by the IdP (although the authentication method may sometimes be a property of the authentication event about which the IdP informs the SP). Federated Identity can, however, be used to move the deployment of Form-based authentication from the SP to the IdP, alleviating the SP of the burden of authenticating user credentials and implementing the processes require to issue and manage those. It also means that, in general, a user only needs to maintain a single identity per federation.<br />
<br />
SAML, and the Liberty Alliance specifications in particular, are perceived to focus primarily on finding solutions for Enterprise and eCommerce use-cases. In the case of the Liberty Alliance framework, the federated identity technology is complemented by non-technological deliverables, such as federation governance models, security best practices, and deployment guidelines. While comprehensive, some within the Web development community viewed this approach to federated identity as unnecessarily complex for various use cases - and not scaleable to the Internet community at large (though these contentions are debatable). More philosophically, there was also opposition to what many (largely incorrectly) perceived as SAML's leanings towards "Enterprise-centric" identity, in which the user's identity is associated with some corporate entity issuing assertions on the user's behalf, than it is with the natural person represented by that identity.<br />
<br />
The [http://www.openid.net/ OpenID] protocol, and the "user-centric" movement that espouses it, is the clearest manifestation of this.<br />
<br />
Many argue that the claimed "user-centric" properties of OpenID are a distraction, and that SAML can be profiled equivalently such that it is no less "user-centric". While accurate, OpenID implementations, being optimized for abject simplicity, can be easier to deploy than some SAML implementations. For example, OpenID is not burdened by any notions of trust, whose subtleties add significantly to the SAML specification, and thus implementation and deployment complexity of SAML profiles reflecting and accommodating trust nuances. <br />
<br />
Relieved of these burdens, OpenID has seen significant deployments - but, almost invariably, only for applications where the consumer of the OpenID identity does not require a significant level of trust in the assertion (which, owing to the way in which the protocol operates, is equivalent to the level of trust that can be attributed to the DNS). Therefore, while OpenID is satisfactory for low-value applications it is perceived by many as typically not appropriate for higher-value applications.<br />
<br />
====From Identity Monopoly to Identity Metasystem====<br />
<br />
The recognition of the diversity of identity technologies, and the requirements of the applications consuming the identities, is a key feature of Kim Cameron's widely referenced ''Laws of Identity'' in which he proposes the need for (or perhaps the inevitable reality of) the ''Identity Metasystem''. Cameron was a vocal critic of Microsoft Passport and was subsequently recruited by Microsoft as its Chief Identity Architect. In the ''Laws of Identity'', Cameron proposes seven axiomatic properties of identity systems that, he claims, must be observed for any identity system to succeed. While the ''Laws of Identity'' have been subject to criticism, it is a nonetheless important document in that it expounds the philosophical underpinnings of the identity architecture being developed by Microsoft in the wake of Passport.<br />
<br />
====Emergence of Web Services====<br />
<br />
The notion of "Web Services" emerged in the late 1990s, becoming widely visible with IBM and Microsoft et al's submission of the ''Simple Object Access Protocol (SOAP) 1.1'' specification to the W3C (as a "W3C Note") in the spring of 2000. SOAP consists of highly tailorable XML-encoded protocol messages capable of encapsulating arbitrary data. They can be employed in either remote procedure call (RPC) or message passing styles. <br />
<br />
"Web Services" were felt by these practitioners to essentially exclusively consist of SOAP messages conveyed by HTTP, effectively excluding other extant protocols with well-defined URI schemes, e.g. FTP, LDAP, IMAP, etc., from the "web services party". <br />
<br />
A year later, IBM-Microsoft produced the ''Web Services Description Language (WSDL) 1.1'' W3C note in Spring 2001. It essentially defines an "interface description language" for SOAP-based protocols, which is purportedly an aid to developers. <br />
<br />
Security in the SOAP context -- authentication, confidentiality, and integrity protection -- was originally left as an afterthought, i.e. as an exercise for developers and deployers. Two years after SOAP's initial emergence, the WS-Security specification was publicly announced by IBM and Microsoft in Spring 2002. It specifies a framework for attaching essentially any type and/or number of "security tokens" (such as a Kerberos ticket) to SOAP messages, as well as cryptographically binding tokens to messages. This provides a means for data origin authentication on a per-message basis. This can be built upon to provide high-level security abstractions, e.g. for streams of messages.<br />
<br />
By then, 2002, it was clear that there was no industry-wide cohesive vision of what constituted "web services", other than a nominal agreement of them being SOAP-based, nor was there a single "home" for web services specification development. The lack of a home was, and still is, illustrated by the work on various aspects of the broad web services notion being spread across a plethora of fora: privately (e.g. the IBM-Microsoft "workshop process"), in the W3C, in the Web Services Interoperability (WS-I) organization, in OASIS, and in the Liberty Alliance Project.<br />
<br />
====Web Services Stacks and Identity====<br />
<br />
Given the fragmentation of the broader web services community noted above, it is not surprising that more than one "web services stack" has emerged. By "stack" we mean a full-featured specification suite addressing messaging and transport binding, interface description language, security framework, resource discovery, authentication and security token services, and web single sign-on. <br />
<br />
The two major extant SOAP-based web services stacks are the Liberty Alliance's ''Identity Web Services Framework'' (ID-WSF) and IBM-Microsoft-Et-Al's ''WS-*'' (dubya-ess star). Both meet the definition of "stack" given above. Both utilize SOAP-based messages and employ WS-Security as well as WSDL. However, they diverge as one goes further "up the stack". Yet, both stacks feature the key notion of federated identity being conveyed between the browser-accessible web-based "world" and back-end "web services"-based systems. <br />
<br />
ID-WSF specifies use of SAMLv2-based security tokens (though other token types may be profiled for use) and leverages SAMLv2's Web Browser SSO Profile for web single sign-on. The authentication service leverages a SASL-based authentication exchange thus supporting the plethora of extant SASL mechanisms, e.g. Kerberos. ID-WSF is designed with the notion of a user's identity being a first-order component of the context of interactions. For example, discovery service requests are implicitly made in the context of the identity of the user causing the request to be made, e.g. "'''I''' am asking for '''my''' service locations", as well as being able to express target identity contexts, e.g. "'''I''' am asking for '''her''' calendar service". While ID-WSF's specifications explicitly allow for extensions and profiling, where these are possible are carefully constrained. ID-WSF was designed to be concretely implementable and deployable directly from the original specification suite with no further profiling required.<br />
<br />
The composition of the WS-* stack is somewhat difficult to pin down in that IBM and Microsoft each have their own perspective on what constitutes the WS-* stack, and also because the specifications are strewn across a landscape including their private "workshop process", as well as OASIS, W3C, and WS-I. The WS-* specifications are designed to be freely "composable" -- one can pick and choose which ones to utilize in solving a particular use case. This is often cited as the rationale for the specifications' style of unconstrained XML element extensibility (in contrast to ID-WSF's constrained approach). In order to concretely implement WS-* to solve some given use case(s), one must leverage the WS-I "profile" specifications in concert with the WS-* protocol specifications. The notion of identity attained in the system will depend upon the selection of which aspects of WS-* are implemented as well as the profiling choices made.<br />
<br />
===Kerberizing Web Identity & Services===<br />
<br />
The use of Kerberos as an authentication mechanism for web applications has a long history in certain communities, notably Higher Education and Research as well as large-scale Enterprises. Extending Kerberos to address web authentication in these communities was typically driven by a desire to reuse technology which was well understood and widely deployed. This motivation has become even more pronounced with the wide deployment of [http://en.wikipedia.org/wiki/Active_directory Active Directory]. There is, therefore, a significant body of experience relating to the use of Kerberos for the Web and related technologies (Web services, XML, identity federations, and so forth) which can be used to formulate a strategy for future work in this field.<br />
<br />
This document tries to describe a number of missing pieces of the puzzle which when combined can help the Kerberos Consortium release the full potential of Kerberos as an authentication technology for the web.<br />
<br />
====Credentials Delegation====<br />
<br />
An important feature of Kerberos is the ability to forward tickets -- i.e the ability to delegate credentials to remote services where they can be used by that service to act on behalf of the user. When the services are simple traditional host-based services (e.g. ssh or telnet) the credentials-delegation picture is relatively uncomplicated: it just works. This picture changes dramatically with the advent of web-based applications needing access to user credentials in order to authenticate to kerberized backend services. This is sometimes referred to as "n-tier". The classical example is the web frontend to a kerberiezd IMAP server. As long as the authentication mechanism for the web application is basic access authentication or form-based authentication, i.e it has access to the user password, the web application can obtain a TGT -- but at the cost of compromising the secrecy of the user's Kerberos password. <br />
<br />
=====Enterprise Web SSO and Credentials Delegation=====<br />
<br />
Identity management in large-scale deployments of web applications has resulted in the deployment of governance solutions for web single sign-on (Web SSO). Open source products like [http://shibboleth.internet2.edu/ Shibboleth], [http://www.stanford.edu/services/webauth/ WebAuth], [http://www.ja-sig.org/products/cas/ CAS], and [http://en.wikipedia.org/wiki/Pubcookie PubCookie], as well as commercial products like [http://www.passlogix.com/ Passlogix], [http://www.actividentity.com/ ActivIdentity], [http://www.avencis.net/ Avencis SSOX], are often deployed as central points of authentication for multiple web applications in the enterprise. These systems are often seen as meeting several different requirements involving compliance (e.g. [http://en.wikipedia.org/wiki/Sarbanes_oxley Sarbanes-Oxley] (S-OX)) and auditing. However, the enterprise SSO makes Kerberos credentials delegation quite difficult. Some products (e.g. PubCookie) have the ability to forward TGTs from the point of authentication to the web application but these are exceptions rather than the rule.<br />
<br />
Combining enterprise SSO with kerberized backend services is often quite difficult if one wants to hang on to the "[http://www.cs.princeton.edu/~jrex/teaching/spring2005/reading/saltzer84.pdf end-to-end principle]" -- which in this context means to maintain a cryptographic connection between the ticket sent to the backend service and the end user credential used to originally authenticate with the IdP in the single sign-on environment. The success of Active Directory led to the introduction (by Microsoft) of a new way to do credentials delegation: [http://msdn.microsoft.com/en-us/library/aa480585.aspx s4u2self] (aka "constrained delegation"). In this model -- as opposed to the end-to-end end model -- the KDC delegates the right to a "service" principal to impersonate a user to a set of services. In our webmail example the service principal would be associated with the web application itself and the KDC would delegate to it the right to obtain IMAP service tickets for any user. The idea is that the web frontend is trusted to properly authenticate the user, by whatever means, allowing the KDC to delegate part of its responsibility to this service principal. This idea is sometimes called "air gap" security and while not as strong as end-to-end n-tier authentication it is nevertheless often good enough for many applications.<br />
<br />
=====User Driven Credentials Delegation=====<br />
<br />
The advent of "Web 2.0" web applications, notably social networking sites like Facebook, Linked-In and large scale software-as-a-service (SaaS) providers like Hotmail and gmail led to the creation of yet another type of credentials delegation paradigm: user driven credentials delegation whereby a user is asked to provide authorization for each time a service needs to be able to access another service with the rights of that user. The typical example is Facebook wanting access to the users Hotmail address book in order to setup relationships with "buddies" on Facebook. The OAuth protocol (cf below) has built-in support for this type of case-by-case credentials delegation. Although the Kerberos V5 specification, RFC 4120, has allowances for implementations to craft such "user driven" behavior, such behavior is not typically implemented and/or materialized to users. <br />
<!-- There is no correspondence to this model in Kerberos today. --><br />
<br />
However, credentials delegation in Kerberos <!-- , given its lack of support for user-driven credentials delegation and the gaps in the model that does exist, --> still remains one of its truly unique properties -- no other widely deployed security protocol has the ability to pass credentials between members of a multi-tiered architecture.<br />
<br />
====Efficiency Concerns====<br />
<br />
With Active Directory came the notion of the PAC - a data structure included in an extension to the ticket which includes what amounts to authorization data associated with the session. We will return to this notion below when discussing Level of Assurance (LoA) transport and SAML profiles for Kerberos. However it is worth noting that the inclusion of authorization information in the Kerberos protocol has adverse side-effects. When Kerberos is used as an HTTP authentication mechanism (cf Negotiate below) as opposed to being hidden behind an SSO abstraction layer such as the SAML Web Browser SSO Profile or a commercial Web SSO such as any of the products listed above - any extension to the ticket that adds significantly to the payload of the HTTP handshake may be noticeable by users in terms of overall system response time. <br />
<br />
Experiences with Active Directory in large-scale deployments (with many groups) shows that the PAC can often grow to ~20k which has a performance impact on HTTP especially when the browser needs to open and process several connections in order to render a single "page" to the user. Modern browsers are optimized for keeping multiple HTTP connections open in parallel and it is not uncommon for single user views ("pages") to result in 100s of connections to the server. In order to address this problem any protocol and/or authentication mechanism employing Kerberos will need a form of session identifier or other way of efficiently re-using the fact of initial authentication for multiple subsequent connections -- for example the "session resumption" feature of TLS (RFC 4346).<br />
<br />
===Summary===<br />
<br />
The Web authentication landscape is therefore highly complex and diverse, both in terms of technology and politics. The contrast with the Enterprise space, where Kerberos is virtually ubiquitous, could hardly be starker. The goal of this document is to explore how Kerberos might be used as a bridge over the "authentication gap" that separates these worlds.<br />
<br />
The document uses the following methodology :<br />
<br />
* First, a set of user stories are presented. A user story describes a particular outcome that a user wants.<br />
* Secondly, a set of use-cases are developed that bind the user stories into scenarios that can be generalized to address other similar problems.<br />
* Thirdly, there is a discussion of all existing technologies that might contribute.<br />
* Finally, a number of activities are proposed that are intended to supplement or extend these technologies in order to realize the use-cases.<br />
<br />
==User Stories==<br />
<br />
A user story is a statement describing a specific desire by a specific type of user in order to achieve a specific value. User stories often appear in agile development frameworks (e.g. SCRUM) and are used as a tool for evaluating the effectiveness of development activities. A user story often takes the form of a single sentence of the form "A wants to do B in order to achieve C".<br />
<br />
We have chosen to describe requirements as user-stories in an attempt to make the requirements easier to evaluate from the point of view of various stake-holders.<br />
<br />
===Notes===<br />
<br />
The term "web-based" is used to denote both "Internet-based" sites/services (connotes likelihood of "third-party"-ness in the overall interactions involved (e.g. ISPs, hosting providers, site/service-providing entity (e.g. bank, store, etc) may figure in the packets' path between user and the site/service process(es), and "enterprise-based" (aka "intranet-based") sites/services (connotes possibility of a range from "single-party"-ness to high "third-party"-ness, depending upon the characteristics of the "enterprise". <br />
<br />
The term "site/services" is simply used at this time to consciously acknowledge the range of web-based possibilities from simple static web pages, to wikis, to fancy full-featured sites offering a range of "services", e.g. Google, Yahoo, AOL, etc. <br />
<br />
A "site/service-providing entity" is also referred to as a "service provider (SP)".<br />
<br />
<br />
===General: Users===<br />
<br />
====Simplicity====<br />
<br />
<pre><br />
US1: Users want to reduce the number of sign-on technologies <br />
and credentials that they are required to use to access web-based <br />
sites/services.<br />
</pre><br />
<br />
====Transparency====<br />
<br />
<pre><br />
UT1: Users want to reduce the number of authentication steps taken <br />
when using online services.<br />
</pre><br />
<pre><br />
UT2: Users want to use mobile devices when authenticating to online <br />
services.<br />
</pre><br />
<br />
====Flexibility====<br />
<pre><br />
UF1: People want to assert different identity information in different <br />
contexts, e.g. to be able to "don" different roles when interacting with <br />
either the same or different site(s)/service(s). E.g. to be able to <br />
interact with a given bank in the role of either an individual consumer, <br />
or an officer of a company which is also the same bank's customer. <br />
</pre><br />
<br />
<pre><br />
UF2: Users want to use untrusted devices (e.g.. an airport Internet kiosk, <br />
a borrowed device) to access sites/services without compromising their <br />
credentials. <br />
</pre><br />
<br />
===General: Service Providers===<br />
<br />
<pre><br />
S1: Service providers that consume identities from third-party identity <br />
providers want to reduce and/or minimize the number of sign-on <br />
technologies that they are required to support.This applies to both <br />
Internet-based and enterprise-based SPs. <br />
</pre><br />
<br />
<pre><br />
S2: Service providers want to be able to manage and minimize the risks <br />
they assume when providing authenticated web-based sites/services. <br />
</pre><br />
<br />
===Financial Services===<br />
<br />
<pre><br />
FS1: Web-based financial services want to avoid phishing, and have their <br />
experience adhere to the "General: Service Providers" user-stories noted <br />
above. <br />
</pre><br />
<pre><br />
FS2: Customers of web-based financial services want to avoid phishing.<br />
</pre><br />
<pre><br />
FS3: Customers of web-based financial services want their experience of <br />
using the site/services to adhere to the "General: Users" user-stories <br />
noted above.<br />
</pre><br />
<br />
Note: essentially all web-based sites/services (and their users) are <br />
subject to phishing attacks. It would seem that the main reason to single <br />
out Financial Services SPs is that the attack results with them can be <br />
particularly devastating.<br />
<br />
===Federation===<br />
<pre><br />
F1: Deployers of web-based portal services with kerberized backend-services <br />
need to be able to use federated identity with N-tier authentication.<br />
</pre><br />
<br />
<pre><br />
F2: Grid services (in environments where PK-INIT is used) in the US Federal <br />
sector need to fulfill policy requirements that authentication be done <br />
using smartcards.<br />
</pre><br />
<br />
<pre><br />
F3: SAML service provider with a large number of affiliated Identity <br />
Providers requires a way to determine which Identity Provider a user is <br />
affiliated with, so that it knows where to request assertions for the user'. <br />
</pre><br />
<br />
<pre><br />
F4: The IT management at two or more federated partners need to define <br />
conventions, or an agreement, governing the use of a federated business <br />
process that is secured using Kerberos.<br />
</pre><br />
<br />
===Enterprise===<br />
<br />
<pre><br />
E1: Enterprise SOA architects want flexible life-cycle management for <br />
identities used for SOA.<br />
</pre><br />
<br />
<pre><br />
E2: Enterprise security officers want secure authentication for SOA.<br />
</pre><br />
<br />
<pre><br />
E3: Enterprise system integrators want interoperability between <br />
web service implementations from major vendors.<br />
</pre><br />
<br />
<pre><br />
E4: Enterprise identity architects want SSO-support in popular browsers <br />
with credential delegation capabilities turned on by default.<br />
</pre><br />
<br />
<pre><br />
E5: Enterprise identity architects want to be able to extend existing <br />
cookie-based SSO systems with support for Kerberos backchannel <br />
authentication and credentials delegation.<br />
</pre><br />
<br />
==Use Cases==<br />
<br />
TODO: complete mapping user-stories to use-cases (user story given as (N))<br />
<br />
The use-cases are divided between three categories<br />
<br />
* ''Back Channel'' - this describes transactions between service providers occur directly, without relying on user-wielded tools (typically, although not exclusively, a web browser) to act as an intermediary. E.g. an ecommerce site interacting directly with a user's banking site, without re-directing communications through the user's web browser. These transactions may either be invoked in response to an action performed by a user (for example, logging into a service provider) or be initiated automatically by software agents.<br />
* ''Front Channel'' - this describes interactions between service providers occurring indirectly via a user-wielded tool -- typically, although not exclusively, a web browser -- to mediate. These transactions are normally invoked in response to an action performed by a user (for example, logging into a service provider).<br />
* ''Front and Back Channel combined'' - this describes interactions that involve elements of Front and Back Channel activity (for example, a Back Channel transaction that is authorized using a token that was established previously in an earlier authentication event while the user was online).<br />
<br />
===Back channel===<br />
<br />
====Intra Enterprise====<br />
<br />
A large organization is deploying an increasing number of web services. Initial deployments, which were typically few in number, relied on the use of shared secrets for authentication and TLS for transport security. Although the web services are mainly SOAP-based, using HTTP for transport, the use of Negotiate or message-layer security is very uncommon.<br />
<br />
As the deployments of web services expands, the management of the shared secrets becomes an issue (E2). There is also increasing concern that certain properties of shared secret authentication, or the practices used to manage them, while acceptable during the initial deployments on low-value applications (such as hard-coding secrets into applications), are not appropriate for higher-value applications. The most common action taken is to move to the use of client certificates which, for an organization of this size and complexity, necessitates the acquisition of a web services governance solution. Such products are often based on an ESB (Enterprise Service Bus) and sometimes employ other transports besides HTTP (for example, various message-oriented protocols such as MQ or XMPP).<br />
<br />
The motivation for using Kerberos with these web services is to simplify the management of their security requirements (E1). However, the web services are perceived as distinct from the existing business infrastructure, and so consequently these services are often treated as a single administrative domain isolated from everything except those business systems which they connect. Therefore, the security properties of Kerberos are unlikely to be an important criterion in any evaluation against alternative mechanisms. It also means that Kerberos administration, in order to be a viable option, must integrate into the various web service governance solutions that exist.<br />
<br />
====Business-to-Business====<br />
<br />
A business needs to integrate with another business using a SOAP-based web service (E3). One or both of these businesses may already be in possession of an existing enterprise-wide SOAP-deployment similar to the one described in the previous use-case. The requirements of the security model are typically fairly simple (for example, there are no n-tier issues). As before, shared secrets are used authenticate endpoints, using either TLS or IPSec for transport security. The use of any transport for SOAP other than HTTP is very uncommon.<br />
<br />
The motivation for the use of Kerberos in this use-case may be to leverage each business' pre-existing Kerberos infrastructure, and possibly an existing cross-realm trust, in order to avoid establishing a special-purpose trust infrastructure (E2).<br />
<br />
The main difference between this use-case and the one that was described previously is that typically only a small number of web services are required for each pair of Business-to-Business relationships. Therefore, establishing and managing cross-realm trust must be perceived as a low barrier to the adoption of this trust-model.<br />
<br />
===Front channel===<br />
<br />
Business-to-employee and Business-to-customer use-cases typically involve front-channel exchanges through the user's (customer or employee) browser. Most technologies involved in front-channel authentication (for example, SAML Web SSO) currently use Form-based username and password authentication, even if other mechanisms are supported.<br />
<br />
The motivation to use Kerberos might be to provide a better user-experience. Information Card in combination with Kerberos could also be used to provide a consistent and simplified user experience for web-based authentication. The same is true (to a lesser extent) for Negotiate-based authentication.<br />
<br />
====Business-to-employee====<br />
<br />
In this use-case, the business issues credentials to the employee (E1). These could be used to provide access to both internal corporate resources, and resources offered by third-parties (such as SaaS providers).<br />
<br />
====Business-to-customer====<br />
<br />
In the case where the business issued credentials to customers, the primary challenge would be identity provisioning and management: a user would typically need to obtain and negotiate the use of credentials from multiple realms, obviating the single sign-on benefits of Kerberos.<br />
<br />
This could be mitigated through either the use of Kerberos cross-realm operation, or identity federation technologies (for example, the SAML Web SSO Profile) where Kerberos could be used to authenticate the user at an Identity Provider trusted by those businesses that the customer interacts with. If this were intended to solve the general problem (that is, for most users, for most service providers), there are a number of challenges; these include ''Identity Provider Discovery'' (how does a business determine which Identity Provider a customer is affiliated with, assuming a model involving multiple Identity Providers), technical trust model and governance.<br />
<br />
===Front and Back Channel Composition===<br />
<br />
====Credentials Delegation====<br />
<br />
A recently merged company wishes to provide the newly-united workforces with a single web portal providing access to various back-end services that, owing to delays in the re-organization of the respective IT functions, will remain administratively separate for some time. The provision of email is a core function of the web portal, which therefore needs to access a set of IMAP servers in these separate administrative domains. To avoid the need to issue new credentials to users, SAML-based Web SSO is used to provide federated authentication by the SAML Identity Providers operated by each IT function. These Identity Providers trusted could provide the web portal with delegate-able credentials for their own IMAP server(s) (E5).<br />
<br />
====Level-of-Assurance transport====<br />
<br />
Many services have policies attached to their use that stipulate which type(s) of credentials are acceptable (often called the ''level of assurance'') (E2). In scenarios where the service itself is authenticating the user's credentials, the policy is normally trivial to enforce using technical means because the service has visibility of the authentication event.<br />
<br />
However in a distributed environment the authentication of user credentials is often performed by a third party, out of the control of the service. There are several examples from within the US federal sector where services may require the use of smartcard technology and where there is also a desire to provide a federated web front-end (normally to extend access to users affiliated with trusted organizations).<br />
<br />
However, there is currently no way to communicate information about the authentication event (except in a few corner cases involving PK-INIT). Although SAML defines n element that enables an Identity Provider to express an ''Authentication Context'', it is unspecified how this should be used in a Kerberos deployment.<br />
<br />
==Security Technologies==<br />
<br />
The security technologies relevant to the HTTP-based Web can be divided into three overall categories:<br />
<br />
* ''Transport security'' is provided by the underlying transport protocol. The security service only acts at the socket or datagram layers between two hosts, and bindings to high-level security measures tend to be non-existent. Credentials are usually issued to hosts (if datagram-based) or services (if socket-based).<br />
* ''Application security'' is provided by the application protocol in combination with, or independent of, substrate transport security. Credentials are usually allocated to an application, and the users accessing those applications. Applications may, in some circumstances, leverage user credentials to act on a user's behalf. This is referred to as "impersonation" and/or "delegation" depending upon the detailed context.<br />
* ''Message security'' describes an approach where (application) protocol messages are individually cryptographically bound to security tokens they convey directly and/or indirectly (by reference). With such an approach, the protocol messages may be conveyed over different transports (e.g. HTTP, SMTP, TCP, etc), or stored on intermediate or endpoint systems, while retaining intact their originating security context (modulo any allowances for message modification in-transit). <br />
<br />
===Transport security===<br />
<br />
HTTP is the common transport in web-orientated architectures. Transport security is usually provided using TLS and X.509 PKI.<br />
<br />
Kerberos-based alternatives (existing and proposed) include:<br />
<br />
* Kerberos with IPSec.<br />
<br />
* Negotiate.<br />
<br />
* A specification describing a Kerberos-based cipher suite for TLS exists ([http://www.ietf.org/rfc/rfc2712.txt RFC2712]), and has seen at least two implementations ([http://www.openssl.org OpenSSL], [http://java.sun.com/javase/6/docs/technotes/guides/security/jgss/lab/part2.html JGSS]), but is widely regarded as flawed.<br />
<br />
* A recently-expired [http://tools.ietf.org/html/draft-santesson-tls-gssapi-03 draft] describes extensions to [http://tools.ietf.org/html/rfc4279 RFC4279] to enable dynamic key sharing in distributed environments using a GSS mechanism, and then import that shared key as the "Pre-Shared Key" to complete the TLS handshake. The TLS Working Group [http://www.ietf.org/mail-archive/web/tls/current/msg01887.html has argued] that user principal authentication is an application-level concern, and so this work appears to have stalled.<br />
<br />
Other transports, such as [http://www.xmpp.org XMPP], are available. However it is likely that architectures requiring the use of two or more transports would emphasize the use of message-based security, because the transports' respective security properties are not necessarily functionally equivalent. Where multiple web services are deployed from the same application server it is common to use a web service governance solution which abstracts the service business logic from the transports.<br />
<br />
In summary, HTTP is almost always used - but sometimes other transports are also used. In this case the logical way to provide security is to use message-based security.<br />
<br />
===Application security===<br />
<br />
====Negotiate====<br />
<br />
"Negotiate" is the collective name of a loosely defined set of HTTP authentication mechanisms that provide a simple 2-way [http://en.wikipedia.org/wiki/GSS-API GSS-API] handshake with the HTTP server. The most commonly deployed variant, "Simple And Protected Negotiate (SPNEGO)", defined in RFC 4559, uses the SPNEGO GSS-API mechanism, itself defined in RFC 4178. Other implementations use the Kerberos5 GSS-API mechanism (RFC 4121) instead. Updates to RFC 4559 have been discussed.<br />
<br />
It is worth noting that Negotiate authentication does not protect the HTTP request, because they are sent unprotected during the GSS-API handshake (which is itself encoded within an HTTP header). This authentication method is therefore not advised in some use-cases; in particular, REST-style web-services cannot in general be protected using Negotiate alone. Note that this is the case with all present authentication techniques that are conveyed within an HTTP message itself, e.g. in the HTTP message headers: Basic, Digest, and Negotiate. <br />
<br />
Negotiate suffers from a lack of mutual authentication and support for multiple-roundtrip GSS-API mechanisms. Earlier attempts (in the IETF) of introducing SASL-based authentication for HTTP showed that in order to gain wide acceptance any multiple-roundtrip HTTP authentication mechanism has to be able to deal with consecutive HTTP/1.1 connections being sent to different TCP endpoints (e.g. if a concentrator is deployed at the server). This implies that the authentication mechanism needs to support some form of state management. At least two different proposals have been put forward for solving this problem; one in http://tools.ietf.org/html/draft-johansson-http-gss where state management is done in the HTTP layer and one in http://tools.ietf.org/html/draft-zhu-negoex where state management is done in the GSS-API layer.<br />
<br />
====Information Card====<br />
<br />
;Introduction :<br />
<br />
"Information Card" is an identity technology based on the notion of a smart client, the identity selector (IS), under the control of a user, that can interact with a relying party(RP), and optionally an identity provider (IdP), to accomplish application signon and delivery of user information to the RP. Both IS-RP and IS-IdP interactions use the WS-Trust protocol (part of the WS-* suite). WS-Trust is intended to be a "meta" authentication protocol that can in theory permit a security token to be delivered to the RP in whatever format it requires, independent of the method the client uses to authenticate to the IdP. The identity selector has a user interface that presents the user's authentication options in the form of cards. A card can be "managed", meaning that it is issued by an IdP, and requires authentication to that IdP when used. Or, a card can be "self-issued", meaning it is generated within the identity selector, and uses a keypair managed by the selector to authenticate to the RP.<br />
<br />
Though Microsoft is the initial developer and evangelist of Information Card, many other companies and projects are developing compatible software and contributing to the technology specifications. The Information Card Foundation (http://www.informationcard.net/) was formed in 2008 to promote the technology. Microsoft's Information Card client (known generically as an "identity selector" or "identity agent") is called CardSpace. Since it is the most well-known implementation, many people (incorrectly) refer to the whole technology as CardSpace. The Information Card concept was originally developed by Kim Cameron of Microsoft as part of an "Identity Metasystem" concept, so this term is also used for this technology. The technology is now being standardized in an OASIS technical committee called the Identity Metasystem Interoperability TC (http://www.oasis-open.org/committees/imi/).<br />
<br />
The Information Card specifications define the authentication methods supported between identity selectors and IdPs (in the managed card case). Kerberos is one of these methods. The others are: X.509 cert, username/password, and self-issued card (technically a SAML token).<br />
<br />
;Kerberos authentication from Identity Selector to IdP :<br />
The Identity Selector (IS; an end-user client-side tool) can authenticate to an IdP using Kerberos. The WS-Security Kerberos Token Profile is used, underlying the WS-Trust protocol that does the security token request. An IdP supporting Kerberos authentication would be an application server from the Kerberos point of view. It doesn't appear that any of the existing Information Card IdP software supports Kerberos authentication however, so this is an opportunity for improvement. Microsoft's IdP (which probably won't be available until 2009) will support all four defined methods, including Kerberos.<br />
<br />
;Kerberos token delivery to the RP :<br />
WS-Trust operates by delivering security tokens to RPs to authenticate clients. WS-Trust is (or claims to be) token agnostic, meaning it can carry anything, but for a token format to be used interoperably its nature and handling by IdP and RP must be specified. Information Card defines the use of SAML tokens for self-issued cards and these have commonly been used as tokens in managed cards also. It would be possible to define a Kerberos token. Such a token (presumably a KRB_AP_REQ) would be generated by the IdP, carried by WS-Trust from IdP to IS and from IS to RP, and processed by Kerberos software at the RP. There is no such token defined at this time. Recent comments from Microsoft about supporting cross-technology delegation imply that it might be implementing delivery of Kerberos tokens via WS-Trust.<br />
<br />
;Identity Selector as standard authentication UI :<br />
Information Card technology has been introduced as an approach for browser authentication to web applications, since the web is obviously widely-used and urgently in need of better authentication solutions. The selector concept, however, can apply to any instance of user authentication. This might involve extending selectors to support other protocols, or adding the use of WS-Trust for authentication to existing systems. In particular the Identity Selector could be a user interface for Kerberos initial authentication in some scenarios.<br />
<br />
====OAuth====<br />
<br />
;Introduction :<br />
<br />
OAuth (http://oauth.net/) is a specification for interoperable support of delegated access to web-based resources. It is designed to support a particular common use case: a user of one web-based service (for example, a photo-sharing service, called the OAuth service provider) has protected resources (for example, photos) that the user would like to make accessible via another web-based service (for example, a social-networking service, called the OAuth consumer). This is often done today by the consumer service obtaining from the user their username and password on the service provider. The goal of OAuth is to avoid this practice. This done by defining service points to permit an access token to be produced by the service provider and delivered to the consumer via the browser. This token can then be used (after some transformation) to access the service provider via an OAuth-defined HTTP authentication method.<br />
<br />
OAuth was developed by an adhoc group, based on similar specs from a number of web technology companies (e.g. Google, Yahoo!). Its current version is 1.0. There are several implementations for different languages and platforms, and some initial deployments. Google in particular defines extensive support (http://code.google.com/apis/accounts/docs/OAuth.html).<br />
<br />
OAuth has no defined relationship to Kerberos or any other existing authentication technology at this time. Note that since the tokens are both issued and consumed by the service provider, their internal format and semantics can be whatever the service provider wants. For example, the validity period of the token is not defined in the spec or represented in the protocol; it is entirely up to the issuer.<br />
<br />
The standard OAuth scenario is referred to as "three-legged" since it involves the consumer, the provider, and the user who must indicate consent and transport the access token. There is interest in "two-legged" scenarios where the OAuth HTTP authentication method is used simply between consumer and provider, not on behalf of some user. In this case it would be an alternative to other HTTP authentication methods such as Basic or X.509/SSL. <br />
<br />
;Opportunities :<br />
<br />
There has been recent discussion about profiling OAuth with SAML in order to permit the encapsulation of SAML assertions (that might convey, for example, information about the user) in the OAuth protocol exchange, in conjunction with the otherwise OAuth-specific cryptographic credentials. As an alternative, Kerberos tickets could be sent either instead of or in conjunction with such SAML assertions. This could be appealing for a Kerberos-oriented OAuth service provider.<br />
<br />
OAuth defines an initial registration and key-exchange step betwen consumer and service provider. In a scenario where consumer and provider use Kerberos this step could be skipped if a method to bootstrap OAuth keys from Kerberos were defined.<br />
<br />
====OpenID====<br />
<br />
[https://spaces.internet2.edu/display/kerweb/OpenID] <font size="1">(reference material)</font><br />
<br />
OpenID Identity Providers (OPs) ''could'' employ Kerberos to authenticate their users and this approach for an OpenID OP would probably be quite useful as a means for an enterprise to stand up an OP in front of its existing authentication infrastructure. It is unclear how common this approach will be but it as been argued that enterprise passwords would become less exposed by something like this since users typically pick the same password for their blog/yammer/amazon account as the password used at work since it is easier to remember it. This practice exposes the enterprise credential to additional risk. There is very little an enterprise security officer could do about this except to provide an alternative and reasonably safe way to reuse the enterprise authentication.<br />
<br />
===Message security===<br />
<br />
====Security Strategies for Message-based architectures====<br />
<br />
Good message-based implementations understand that there are multiple SOAP transports and provide an interface for plugging in new ones, however in practice SOAP transports other than HTTP rarely occur when performance isn't an issue.<br />
<br />
SOAP method calls are either secured at the transport or message layer or both. The "official" way to secure SOAP is to use WS-Security but transport-layer security is much more common especially in the cross-domain cases. In this case it is not uncommon for IPSEC to be used to provide a tunnel between the client and the server and for the HTTP-based SOAP-calls to be unauthenticated in this tunnel. When tunnels are not practical it is common for HTTPS (TLS) to be used in combination with a username and clear-text password.<br />
<br />
The reason for using Kerberos may be any of:<br />
<br />
* Kerberos is easier to use once deployed and if the service endpoint is one of many published by "A" then maintaining username and passwords will be unpractical for the same reasons that maintaining lots of password-based user identities would be impractical. In this case Kerberos provides life-cycle management for the identities used to secure the web service.<br />
* Kerberos is the default security service used by the application framework used to develop and deploy the service endpoint.<br />
* Kerberos is chosen because security policy mandates the use of Kerberos for identities.<br />
<br />
There are (therefore) two ways to authenticate SOAP using Kerberos and if we ignore the possibility of using Kerberos with IPSEC for now:<br />
<br />
* by securing the transport.<br />
* by securing the SOAP messages.<br />
<br />
====The WS-* suite====<br />
[https://spaces.internet2.edu/display/kerweb/WS-*] <font size="1">(reference material)</font><br />
<br />
WS-* ("dubya ess star") denotes a suite of web services specifications promulgated by IBM, Microsoft and various collaborators. Unlike the SAML and ID-WSF specifications, only a few of the WS-* specifications have been subject to an open standardization process and subsequently their quality can be generously described as variable.<br />
<br />
Of these specifications, there are three that are central to WS-* security<br />
<br />
* WS-Security: this specification defines how security tokens are bound to messages. WS-* has defined security token profiles for SAML and Kerberos, amongst others, that can be leveraged by this specification. WS-* officially employs WS-Security-based ''messaging'' security techniques almost exclusively.<br />
* WS-Trust: this specification defines how to exchange (request, issue, renew, cancel) security tokens with web services. These tokens may be used in a variety of ways; for example, as evidence to authorize access to a web service.<br />
* WS-Federation: this specification is a specialization of WS-Trust that defines how to exchange security tokens in a federated context.<br />
<br />
In the Web and Kerberos context, the most important of these is WS-Trust as it provides the mechanisms for using tokens that might be a Kerberos ticket or a SAML assertion) to establish and leverage trust. WS-Trust also plays a key role in the Information Cards technology, another specialization of WS-Trust.<br />
<br />
=====WS-Security Kerberos Token Profile=====<br />
<br />
[https://spaces.internet2.edu/display/kerweb/WS-Security+Kerberos+Token+Profile] <font size="1">(reference material)</font> <br />
[''message security'']<br />
<br />
The WS-Security Kerberos Token Profile defines how to use Kerberos service tickets (specifically, the KRB-AP-REQ message) as a security token. The acquisition of the token is out-of-scope.<br />
<br />
The Kerberos message is attached to the SOAP message using the <wsse:BinarySecurityToken> element. Six different types are supported, including RFC 1510-style, RFC 4120-style and their equivalent GSS-API encapsulations. The octet sequence is encoded using the indicated method.<br />
<br />
This specification does not support the KRB-AP-REP message, and so consequently neither Kerberos mutual authentication, nor GSS-API channel bindings, are supported. In practice, therefore, this specification needs to be combined with transport layer security (e.g. TLS).<br />
<br />
====OASIS Security Assertion Mark-up Language (SAML)====<br />
<br />
[https://spaces.internet2.edu/display/kerweb/SAML] <font size="1">(reference material)</font><br />
<br />
SAML provides a suite of XML-based protocols that enables different security domains to exchange security data about user principals.<br />
<br />
Broadly, the SAML specifications define:<br />
<br />
* the ''assertion'', a security token that can express a user principal's authentication status, authorizations and other general attribute information.<br />
* ''protocols'', that are primarily used to request assertions about a user principal.<br />
* ''bindings'', that define how protocols are bound to certain transports (such as SOAP).<br />
* ''profiles'', that constrain the use of assertions, protocols and bindings to realize specific use-cases (such as the "Web SSO Profile").<br />
* ''federation metadata'', that allows security domains to express information (primarily configuration data, such as a public key) about themselves to other security domains.<br />
<br />
Although SAML focuses primarily on the passing of messages to federate identities in different security domains for Web SSO applications, the architecture of SAML allows discrete functional elements to be re-used in other contexts, allowing a broad range of potential applications. For example, the SAML assertion has been re-used in many other technologies - even technologies, such as WS-Federation implementations, which are competitive with SAML as a whole. Consequently it can be argued that the categorization of SAML as 'message security' is a generalization, depending on which particular ''SAML profile'' is being examined, and how it is specifically crafted in concert with the target protocol(s).<br />
<br />
SAML does not stipulate the use of any particular trust model(s), although X.509-based trust establishment and TLS is widely used in practice.<br />
<br />
There are several ways in which SAML, in terms of either SAML assertions themselves or the SAML profiles, can or could interface with Kerberos:<br />
<br />
;The SAML Identity Provider (IdP) uses Kerberos to validate usernames and passwords supplied by users on webpage forms<br />
:The main benefit offered by this configuration is that it allow users to use the same credentials to access resources protected by both SAML and Kerberos, offering users greater convenience. This is achievable with little or no modifications to the SAML IdP, and is a configuration that is likely to be used by IdP deployments today. <br />
<br />
;The IdP uses Kerberos authentication at the HTTP layer - e.g. Negotiate or NTLM<br />
:The main benefit offered by this configuration is that it permits the use of Kerberos-based SSO to authenticate to the SAML IdP, offering greater convenience to users. This is achievable with little or no modifications to the SAML IdP, and is a configuration that is known to be used by many IdP deployments today. <br />
<br />
;The IdP issues SAML assertions containing Kerberos tickets as an attribute<br />
:It would allow a SAML Relying Party to acquire a Kerberos ticket that it could use subsequently to authenticate, as another principal, against a Kerberos protected resource. The main benefit is that it could be used to support n-tier web-based use-cases (such as the webmail use-case), offering greater convenience to users and possibly reduce the abuse of user credentials by providing applications with delegable credentials. This would require modifications (possibly not too significant) to the SAML IdP. <br />
<br />
;The KDC includes a SAML assertion and/or authentication response message encapsulated in KDC-issued authorization data<br />
:It would allow the KDC to issue SAML assertions (or perhaps SAML messages in general) to Kerberos services. The main benefit is that this could be used to complement Kerberos-based authentication and/or provide richer authorization. This would probably require modification (probably reasonably significant) to the KDC. <br />
<br />
;The SP uses Negotiate to find the preferred IdP of the user (aka IdP discovery) based on the Kerberos-realm in the GSSAPI authentication request.<br />
:The benefit of this is that it reduces or eliminates the need to use GUI-based IdP Discovery (the commonest form of IdP discovery), which scales poorly and introduces UI considerations such as localization and accessibility. This is achievable with little modification to the SAML SP. It has already been implemented on SWITCH's "Where Are You From" service (but not used in their production federation). <br />
<br />
;A GSSAPI peer implementing the proposed GSSAPI naming extensions receives a SAML attribute assertion as part of a GSSAPI protocol exchange<br />
:While not strictly tied to Kerberos this may provide a way to tie in with other uses of the GSS-API naming extensions.<br />
<br />
====Liberty Alliance Identity Web Services Framework====<br />
[https://spaces.internet2.edu/display/kerweb/ID-WSF] <font size="1">(reference material)</font><br />
<br />
The Identity Web Services Framework (ID-WSF) is a set of specifications from the Liberty Alliance that builds on SAML to provide a full-featured web services stack that leverages WS-Security as its encapsulating security token format. Thus it is possible to leverage Kerberos-based authentication in an ID-WSF-based web services context, although at this time the limitations noted above with respect to the WS-Security Kerberos Token Profile will apply.<br />
<br />
<br />
==Security Technology Requirements==<br />
This section presents requirements that security technologies employed in the HTTP-based Web context ought to satisfy.<br />
<br />
===Security Protocol Overall Efficiency===<br />
<br />
Some small number of handshake exchanges in order to authenticate the principal with the IdP (i.e. KDC if Kerberos is being employed). Subsequent interactions with other websites, participating in the authentication domain, can be authenticated with a security token (e.g. a service ticket if Kerberos is being employed) accompanying HTTP messages from the user agent. <br />
<br />
The rationale here is that for any given web page, a user agent may make any number (not infrequently on the order of tens O(10) ) of requests to the server. This is due to the the user agent typically retrieving web page constituent components, e.g. images, frames, tables, etc., with an HTTP request per component. This is sometimes referred to as being "chatty". Since such requests are performed independently and asynchronously over separate TCP connections, each HTTP request will need to convey authentication information that the service provider can validate & verify without further interactions. <br />
<br />
===Security Token Size===<br />
<br />
Because of the "chatty" property of some web interactions noted above, and the necessity of each individual HTTP request being authenticated, the security token size will likely matter. <br />
<br />
Microsoft reports customer feedback to this effect: Active Directory et al encode principal group membership information -- Privilege Attribute Certificate (PAC) -- in the Kerberos service ticket. This can expand the ticket size to be over 12k bytes and noticeably slow down "chatty" web interactions. The same would likely be the case for attaching any other "large" chuck of information to service tickets and/or the HTTP requests themselves.<br />
<br />
===User Interaction===<br />
<br />
Some security technologies, e.g. Kerberos, are designed with the notion of signing the user on once, and then further interactions with participating entities (e.g. service provider websites) occurs in a transparently authenticated fashion. <br />
<br />
However, in some contexts -- especially those in which principal attributes beyond baseline principal name and secret are conveyed -- it may be required for there to be interaction with the principal at least whenever the user agent is being compelled to convey more information than some configurable baseline to the service provider (aka relying party). This, for example, is one of the features of [[Information Card]]s' "Identity Selector" user agent, and the underlying Identity [http://www.oasis-open.org/committees/download.php/29511/Identity_Selector_Interoperability_Profile_V1.5.pdf "Selector Interoperability Profile"] protocol.<br />
<br />
==Browsers==<br />
<br />
Most browsers support Negotiate by default, but most either disable the feature (requiring the user to enable it manually) or limit its use to "local" sites or sites explicitly trusted. It is unclear what the threat-model looks like and this should be investigated further.<br />
<br />
===Safari===<br />
<br />
Safari supports Negotiate with SPNEGO since Tiger. There is an information card identity selector for safari here: http://www.hccp.org/safari-plug-in.html.<br />
<br />
===Mozilla/Firefox===<br />
The Mozilla and Firefox browser family includes native support for Negotiate using the Kerberos GSS-API mechanism. This feature is not turned on by default though, and must be turned on manually by editing the "prefs.js" file. Credentials delegation is supported but must also be turned on manually. There are a few plugins implementing Information Card for Firefox/Mozilla. It is unclear if any of them support Kerberos authentication for Information Card-based IdPs.<br />
<br />
===Internet Explorer===<br />
<br />
Negotiate was invented by Microsoft and is widely deployed through the implementation in the Internet Explorer family of web browsers.<br />
<br />
===Konqueror===<br />
Konqueror is the browser included in the KDE desktop framework. Konqueror supports Negotiate and enables Negotiate for sites in the same domain as the client. There is no support for Information Card yet in Konqueror.<br />
<br />
==Application environments & Libraries==<br />
<br />
===IIS===<br />
IIS naturally has native support for Negotiate using the SPNEGO GSS-API mechanism. <br />
<br />
===.NET===<br />
The .NET framework supports the WS-Security Kerberos Token Profile as well as Negotiate natively.<br />
<br />
===Apache===<br />
Apache has add-on modules supporting Negotiate using both SPNEGO and Kerberos GSS-API including http://modauthkerb.sourceforge.net/.<br />
<br />
===Perl===<br />
The LPW::Authen::Negotiate module implements Negotiate using the GSSAPI perl module which in turn uses either Heimdal or MIT Kerberos libraries. This means that LPW::Authen::Negotiate can support both SPNEGO and Kerberos GSS-API.<br />
<br />
===Ruby===<br />
There is a GSS-API library for ruby which similar to the perl GSS-API library supports either MIT or Heimdal Kerberos. However the Ruby HTTP client library does not natively support Negotiate (it does support NTLM though). There have been working patches but they are not maintained. Ruby is one of the language of choice for "web 2.0" applications especially in combination with the Rails framework. These applications are known to prefer REST-style web services to more "enterprise"-style SOAP-based web services.<br />
<br />
===Java===<br />
Java has native support for the Kerberos GSS-API mechanism since JDK 1.4. A number of implementations of Negotiate exists for various application servers (e.g. Tomcat and JBoss). There are not free implementations of SPNEGO for JDK 1.5 and later although there are at least two commercial implementations. Since JDK 1.6 there is native support for SPNEGO.<br />
<br />
===WSS4j===<br />
WSS4J is the primary free implementation of XML security (from the apache project). It does not include an implementation of the Kerberos token profile.<br />
<br />
==Suggested Activities==<br />
<br />
[[Image:Kerberos-ArchAndProposedWorkItems-00.png|Figure 1]]<br />
<br />
* Back Channel (BC)<br />
*# Update the Kerberos Security Token Profile to support mutual authentication and channel bindings.<br />
*# Promote the implementation of the updated Kerberos Token Profile in common software frameworks (e.g. .NET, wss4j) and demonstrate interoperability.<br />
*# Update Kerberos cross-realm operation (in progress).<br />
*# Develop conventions or best-practices for integrating Kerberos into web-services governance solutions.<br />
<br />
* Front Channel (FC)<br />
*# Promote implementation and interoperability testing of Kerberos authentication for Information Card.<br />
*# Update Negotiate (in progress).<br />
*# Interoperability testing of Negotiate implementations.<br />
*# Investigate the role of Kerberos in OpenID.<br />
*# Define a discovery mechanism for SAML Web SSO deployments with many Identity Providers, enabling service providers to establish the Identity Provider that a customer is affiliated with.<br />
<br />
* Front and Back Channel (FB)<br />
*# Specify credentials-delegation for SAML-based SSO.<br />
*# Investigate the role of Kerberos in OAuth.<br />
*# Specify a SAML profile based on having the KDC sign a SAML authentication response/attribute assertion/authentication context. Also specify the relationship with GSS naming extensions.<br />
<br />
* Other (O)<br />
*# Document the ways in which Kerberos can be used in a web-context with current technology, to assist contemporary deployers seeking to address certain use-cases today.<br />
*# Develop best-practices and boilerplate covering governance of Kerberos-based web services.<br />
<br />
<br />
TODO: classify suggested activities by who needs to work on them, e.g. what SDOs / vendors / projects would need to be involved, skill set needed, SWAG wrt effort, etc. <br />
<br />
also recommendations wrt near- / intermediat- / long-term phasing.<br />
<br />
suggestion from SteveB:<br />
<br />
<pre><br />
One way to rank/organize these might be a table with the following <br />
columns:<br />
<br />
Activity Impact Effort Risks <br />
<br />
<br />
An example might be<br />
<br />
Activity Impact Effort Risks<br />
Investigate the role May solve large problem High, many years Technology neither implemented<br />
of Kerberos in OAuth. nor well understood<br />
</pre></div>Sbuckleyhttps://k5wiki.kerberos.org/wiki?title=Main_Page&diff=129Main Page2008-01-16T16:55:23Z<p>Sbuckley: </p>
<hr />
<div>'''K5Wiki''' is a wiki for the development of [[MIT Kerberos]], a reference implementation of [[wp:Kerberos (protocol)|the Kerberos network authentication protocol]]. MIT Kerberos is a project of the [http://www.kerberos.org/ MIT Kerberos Consortium].<br />
<br />
Here are some starting points:<br />
* [[How to contribute]]<br />
* [[:Category:Policies|Policies for development]]<br />
* [[:Category:projects|Ongoing projects ]]<br />
* [[K5Wiki:Todo|A todo list for work needing doing on this wiki]]<br />
<br />
We look forward to your contributions to K5Wiki and MIT Kerberos.</div>Sbuckley