KrbWeb Buckley-BoardMtgPresoAndNotes-2008-07-24

This document is a draft concerning Kerberos and the Web.

Context

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