This document is a draft concerning Kerberos and the Web.
Below are (reformatted) "..slides and notes from the Consortium Board meeting.." sent by Steve in this message on 24-Jul-2008 to mitkc-krbweb@.
They appear to be taken from Sam Hartman's "Kerberos Road Map" board preso of 7-Apr-2008, specifically the "Kerberos on the Web" major section, and have been slightly edited along with apparent questions/comments inserted, especially towards the end after the "Broader Authentication" topic header.
Kerberos on the Web Preso & Notes
* Kerberos on the web - Contents: o understand and analyze web services + WS- + Soap + XML DSIG/encryption + REST + SAML o Gateways between Kerberos, SAML and other federation technologies o Kerberos through firewalls o Authentication within the enterprise o Managing identity o Broader authentication * web services o Examine and analyze + Protocols + How Kerberos is implemented today? + Implementation quality o Gap analysis + Can kerberos be used to secure all parts of a web services infrastructure # Should only need one security system. Deploying them is hard and costly. + Will extensions to kerberos break kerberos integration into web services # Has had issues with using raw cert instead of AP-REQ + Are implementations and standards sufficiently avilable to meet customer needs + Sufficient documentation o What we can do? + improve standards and docs + add necessary support for kerb implementation + Identify gaps, but not write web services ourselves * Gateways to federation o Used alongside SAML/OpenID etc o Several challenges: + Authority to convert from one tech to another + Translating information such as entitlements from one format to another + Determining trust to assign to an authentication that has crossed mech boundaries # If you have a chain like KRB -> SAML -> OpenID -> KRB should I trust it? + Policies are an important property of Federation # What policies should we look at? Where do we go? * Firewalls o Several companies developed solutions to deliver Kerberos over the same port as web traffic + Firewalls near client and server + Kerberos needs to follow same path as application o tools.ietf.org/id/dtraft-zhu-ws-kerb-03 may be part of the answer * Authentication in Enterprise o Both Kerb and certs today + Required for security today + If either has a problem, you're in trouble + Kerb for privacy instead of certs? # easier to make arbitrary (self-singed) certs # Would have to re-implement a lot of the stack # Strongest argument is TLS problems that might not exist in KRB # Provided only have to do one deployment, most problems go away o Could improve user experience and config + web browsers all support KRB but tend to turn it off by default. # Why? # Work on user experience. + Make it easier to use Kerberos and other mech on the server side + Work on client config issues * Managing identity o Kerberos identity management (which id to use) o Other ID frameworks have a variety of privacy mechanisms; can we take these mechanisms or something similar and use them in Kerberos o How do you make this usable? o Need to understand user use cases for privacy and how that fits into KRB * Broader authentication o finish requirements work for web authentication o participate in discussion of web authentication in standards organizations o Understand tech challenges, but not use cases. + Where will this benefit people? + Working with IETF and financial services industry. # workshop to bring together major web sites with security community and find out where they would use other authentication technologies (not just kerberos) # KRB community should be in place to...(?) + only current web services for kerberos is WS- where kerberos is a profile # business to business is difficult * no way to send claims * No way of sending policy * Kerberos has everything you need in protocol, but no standardized implementation * No facility to acquire and then act on policy, communicates all attributes to services * Strong connection to ACL based authorization today o Would like to see a capability based model o in ACL model, only thing you have is the principal name, so fewer interesting things to do o Don't try to be OpenID as it's messy and complicated? + If we don't make sure we can interact with technologies in that space, then people will find they can't use it + Our goal is not to be competitive but complementary (at least in marketing) # We probably need to solve most of the problems they're solving anyway. # OpenID is wonderful for web browsers but bad for most other things * For going after the blogging identity market, would need to understand where we would provide benefit * For business, need to have some of the properties of OpenID such as lower infrastructure costs o Prefer to keep Kerberos as the foundation and let the vendors deal with the higher level stuff? + This is a fundamental disagreement with basis of the presentation + One of the assumptions is that consortium should be doing the "dreaming" o Basic message: understand tech, but need to know what use case we're trying to solve and why we have a better solution than others