=JeffH: Created.

2008-08-22T21:37:30Z

Created.

New page

{{krbweb-page}}

==Context==

Below are (reformatted) "..slides and notes from the Consortium Board meeting.." sent by Steve [http://mailman.mit.edu/mailman/private/mitkc-krbweb/2008-July/000039.html in this message] on 24-Jul-2008 to mitkc-krbweb@.

They appear to be taken from Sam Hartman's [http://www.kerberos.org/events/Board-4-7-08/3-hartman.pdf "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==

<pre>

* 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

</pre>

KrbWeb Buckley-BoardMtgPresoAndNotes-2008-07-24 - Revision history

=JeffH: Created.