The Kerberos Consortium Events

The Consortium will hold interoperability, testing and other knowledge sharing events throughout each year.

Massachusetts Institute of Technology

Kerberos Consortium Board Meeting Notes
APril 7, 2008
1600 Amphitheater Parkway
Mountain View, CA 94043


* Slava Kavsan - microsoft
* Stephen Buckley - MIT
* Sam Hartman - MIT
* Tom Yu - MIT
* Matt Alexander - Google
* Matt Johnson - Google
* Wilson D'Souza - MIT
* Wyllys Ingersoll - Sun Microsystems
* Jordan Hubbard - Apple
* Jeff Schiller - MIT
* Marshall Vale - MIT

Start of the Consortium, introduction and updates - Buckley

* Re-iterate goals of the consortium
* goals: report back and chart new roadmap
* New sponsors since last:
o Carnegie Mellon
o Cornell
o Microsoft
o Michigan State
* Hot Prospects
o widely used in financial services industry
o have been cagey about joining the consortium
o needs of financials are very different from academics, more disciplined
* FY09 (July 1 2008 - June 30 2009)
o $1.15M in commitments
o $1.57M budget
o short $400,000 so need to bring on 3 big sponsors in the next 3 months
o Would like board members to try and get hold of contacts in other companies
* Open Positions
o Strategic Advisor (evangelist in the plan). Marketing who understands Kerberos and business needs
o Programmer/Analyst. Would like to increase this req by 2. Don't currently have a pipeline of CS grads.
o Development Manager. Sam Hartman is moving on.
* Board priority: huge doc push
o Full time tech writer has been hired until end of fiscal year. Been on board for 6 weeks now.
o Full time "Best Practices" writer on contract. Been in financial services industry. Chuck Wade. Contract until end of June
+ Working on 3 classes of white papers
# Why use Kerberos
# Best Practices for Deployment
# Best Practices for Integrating Kerberos
* Board Priority: Database Support
o MIT and Google recruiting summer interns
o Kerberos auth to MySQL
o Sam recommends getting someone familiar with Kerberos to do a design review. Postgres did it a few years ago but go it very wrong.
* Board Priority: Web Services/SAML
o Needs better problem description
o Contacting with Bob Morgan, Leif Johansen, Josh Howlett and Jeff Hodges
+ Lots of OASIS folks
o First meeting next week

Update on Priorities - Hartman

* Priorities
o Standardized admin interfaces
o coding practices and static analysis
o Simplification of host configuration
* Standardized Admin Interfaces
o Not a lot of interest from other vendors in putting a lot of work into a standardized admin protocol
o Everyone has an open administrative protocol (links to MS docs are online so is Heimdal)
o Many interested in understanding customer use cases
o Sun and MIT have similar admin protocol and would like to sync up the incompatibilities
o Sun has donated incremental propagation code
* Coding practices and static analysis
o Paying someone for full audit beyond financial needs but there are great tools for this
o Significant progress in style and process (opened up on Kerberos wiki)
o Initial evaluations of covarity, Solaris lint, KlocWork and Fortify
+ Tools have a non-overlapping set of problems they detect.
+ Get lots more from running many of the tools, there's a point of diminishing returns
+ Coverity and Solaris Lint very interesting
+ Coverity has the best way of managing false positives
+ Unlikely, especially in cross-platform environment to be lint clean
+ Report in June with specific recommendations
+ Coverity and Lint are the only free ones
# Only one that's definitely going ahead is the open source version of Coverity. MIT is evaluating cost version.
+ Initial review shows bug, but none of them particularly frightening
o Would like Paul and Wyllys to bootstrap code review process to try and run
+ What you want to do
+ What you expect to get out of it
+ Sam thinks right place to start process is where people think it's useful so can test process, find where it's valuable and then establish criteria where it can be used.
+ Currently do external code
+ Do not review _all_ commits
+ Review all design proposals
* Host configuration
o Stanford has a product called Wallet
+ Would like to recommend people use this
+ Work with Stanford Document it's use
+ Would it be bundled?
# Talked to Russ (on core team) who's definitely interested in working with us
# Sensitive to the issue of making it easy to use

*Implement KDC side of realm referrals mapping (client in 1.6)

o Anonymous Pkinit
+ Combined with extensions to Wallet, would allow keying machines without prior trust relationships

Sun's Priorities, Based on Demand - Ingersoll

* Project Priorities
* Customer Needs
o Lots of finance customers, who are frequent drivers
o Second biggest is internal IT ops
+ Trying to roll out Kerberos across the enterprise
o Resync with MIT 1.6.3
o Update pre-auth plugin to use KMF APIs for keystore flexibilities
+ KMF is abstract APIs for manipulating keys
+ Allows for applying system wide policy
o Update pam_krb5 to use PKINIT (separate project)
o Recently started, no estimate of completion date yet
o Request from MIT to get issues documented with their PKINIT proposal. Lots of customers have feedback on this. Design requirement to swap out various parts.
* kclient2
o enhancements to existing kclient script
o kclient == script for configuring and enrolling a host into an existing KRB5 realm
+ Ease administrative burden
+ Addresses some scalability concerns
o New features

**enroll in AD

+ enrolling in non-Solaris /non-AD realms
+ adding dynamic (DHCP) clients
* KDC Master Key migration
o make it possible to migrate to stronger keys without destroying current DB
o Many clients moving from Solaris 8 (DES only) to Solaris 10 (AES) but can't currently migrate keys without re-keying
o MIT has a proposal for this in design review.
* Post dated ticket management
o credential management for long running automated processes and cron/ at jobs
o SQLlite KDC backend
o ksu support
+ Solaris historically has not included the ksu utility, but many customers asked for it.
# Historically pointed people at RBAC
* Top requests
o Easier integration and interop with AD
+ simple domain joining and enrollment processes
o referrals
+ client and server side
o admin interface enhancement
+ encryption discovery
+ set password feature
# IETF in working group last call
+ service principal naming consistency
+ policy enforcement
# n-strikes and you are out, revocation
* OpenSolaris
o Kerberos work in
o Public mailing lists
+ category: solaris subcategory:kerberosv5_bundled

Kerberos Development Roadmap - Hartman

* Goals of the roadmap
o prepare kerberos to meet future challenges
o continue to lead the technology
* Strategic pillars
o kerberos on the web
o Kerberos for mobile devices
o Maintaining and Securing Kerberos
o Vendor Independence
* How we'll work
o report progress on each pillar at board meetings
o requirements analysis on future stages at the same time as work on earlier stages
+ tackle each pillar in parallel, need prioritization
o Lots of both standardization and implementation
o Consortium and IETF?
+ IETF is standards body for most of Kerberos technologies
+ Would want to go to IETF for anything other than APIs
+ If consortium wants to go to IETF, would commit staff to IETF as individuals
+ Some members already participate directly in IETF process
* Kerberos on the web
o understand and analyze web services
+ WS-
+ Soap
+ XML DSIG/encryption
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 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
* Mobile devices
o limited memory and CPU (although this is relative)
o Network is high latency and low bandwidth (also being improved)
+ Worse of a problem for Kerberos than CPU and memory
+ Want to facilitate development on mobiles
* Mobile network performance
o Problems:
+ lots of DNS
+ multiple round trips with the KDC
+ Basically unusable with GPRS, kind of usable on EDGE
o What we can do
+ examine caching to reduce DNS traffic and store realm capabilities
# Many issues with a lack of caching SRV records and the like
+ Advance proposals to have local KDC's perform cross-realm authentication
# To offload most of this, KDC has to have your keys. There's always one
o Assertion that CPU and memory are worse
+ caching and the like by the vendor can mitigate much of the networking issues
+ everything kerberos team has seen points to network (lots of ports to very constrained platforms that we can talk to)
o CPU and Memory
+ suspected targets:
# compile time options to strip unneeded options (e.g. use local functionality instead of self supplied)
# use native crypto library
# compile out unneeded cache implementations etc
+ Not sure how big CPU problem on the client
# Core library versus UI
# CPU = power (battery and the like)
* This also goes back to network as more packets is more power
* Power should be number one item
o Power is something we're eating more of every year, going up slower than CPU and memory (battery tech not keeping up)
* Embedded development
o Need to reach out to embedded developers
* Credential management for mobiles
o typing passwords on mobiles is hard
o storing passwords on mobiles is a problem due to theft
o What we can do:
+ encourage PKINIT or single use tokens to avoid dependence on passwords
+ work with mobile device vendors to see what they're doing and work with it
+ There are UI issues (particularly with things like smart cards)
# user authenticates to device, device authenticates to the network on behalf of the user
# one thing to lose with this model is the ability to go to a random device and authenticate
+ Very low priority, it's a _hard_ problem
+ A lot of this is probably up to the device manufacturers
* Maintaining and security
o improve security and flexibility
o Need protocol maintenance
o finish FAST
o implement anonymous PKINIT
o implement mechanism glue layer
o implement PKU2U
* FAST Pre-auth
* anonymous pkinit
o used when one side doesn't have a key
* PKU2U and mech glue
o major win for Microsoft (SSPI)
o low on priority list, but high on implementation list (lots of work done already)
o there are people who want this today for projects they're engaging in.
o part of implementation from Sun
o valuable but a fair bit of work
* Vendor independence
o Extensions add value, but there are areas where the community should have concern
o Consortium needs to be a neutral party, convince vendors to do things that are in the communities interest
o Encourage vendors to document what they've done
o Consider issues when everyone depends on a vendor extension
+ If get into situation where one party is blocking others innovation, consortium should intervene
* Encouraging documentation
* Preserving open evolution
o what we shouldn't do is re-implement all vendor extensions in an open manner
+ expensive
+ interop problems
o important to understand when an extension is causing a problem
o goal is interop and evolution of kerberos
+ try to build it in a constructive way such as asking the next evolution of an extension being a standard
o Collaboration and communication are critical here
+ Example of PKINIT implementation not being as well done as it could have been
+ Good process should solve these problems

Roadmap Discussion

* Dreaming issue
o consortium is risky, if get too blue sky/ivory tower then can cause death of the consortium
o Lots of work, little power
+ cleaning house should be the first goal
# Be merciless in jettisoning old baggage (old protocol so there's a fair amount of it)
# Financials institutions will provide more pragmatism
+ dreaming should be after that to set direction
o Consortium plays a good role for some in industry as come talk to consortium instead of individual to vendors
o Should we set a criteria that limits where we go (e.g. extreme engineering but not doing research)?
o Get vendors involved directly with code base where not already
+ internships for vendors hiring kerberos developers
+ Chase:
# RedHat for this (lunch with Karl happening tomorrow)
# Intel
# Lack of international representation....
# Nokia?
# BT don't currently see the vision, explain why the problems are hard and how we can fix it.
# Many large companies are motivated by a compelling vision of how it fits into the future
* This roadmap should be consistent with that commitment
* Documentation
o Lots of people have heard of Kerberos but don't understand it
o Why should I use it, I have LDAP?
o Many people only know about it when it doesn't work
o Reaching out to the developers is crucial, lots of ignorance about Kerberos
* Engineering distance markers
o develop use cases, analysis of requirements
o MRD is also a marker
* AS-REQ armoring
o Covered by FAST
o Priority 1 already
o Finish in the IETF and consortium should implement
* Role of IETF and consortium
o standards except for internal APIs
o standard IETF process ('go solve this problem through IETF consensus process')
o There's some skepticism as to the value of the IETF by some members
+ prior bad engagements
+ Kerberos consortium, has so far had good relations with the IETF
# Kerberos chairs are process experts and believe in moving things forward
# Well established, functioning community
o Making standards?
+ By defacto. Build an implementation, if everyone buys into it, then we can standardize it.
+ Who will write the spec?
# lots of investment in writing such things
* Tom will take over from Sam next week
o hearing lots of things about code quality
o is the code base ready for mobiles and the web?
+ scalability is a problem
# understand performance map of kerberos
# .mac uses kerberos
o does code quality produce an impediment to going forward?
o At what point to be burn it down and start again?
+ More a core team than a board issue
+ How quickly can you build a new one?
+ Wary of completely re-writing
+ What would be our goals in doing such a thing?
+ Better to take the gradual approach (replace individual functions)
# don't want second system syndrome
# too much feature creep
# open new security issues
+ Target performance for fixing
# check out dtrace
* dtrace toolkit
* instruments in leopard (part of developer tools)
o Kerberos 4
+ Yanking code?
# Gone in Mac
# KFW 4.0
# 1.7 is going to make it very difficult
+ lots of people will be stuck on 1.6
# they're unlikely to upgrade anyway
# lots of noise for about the first 90 days, very noisy and painful to go through the transition, but over very quickly
# Kerberos core team seeing very little push back in KRB4 removal
o would like to become less of a specific platform and more of a general UNIX target
o deprecating carbon so compat with it can be dropped
o Not used by Microsoft
* Should we support KFW/KFM any more?
o As add new features, provides a way of experimenting and a testing UI for that
o Platforms should integrate Kerberos and deal with the platform specific bits
o KFM has KLL which should move into the standard UNIX base
o Kerberos.App as have a way to view tickets
o CCAPI is in cross platform stuff
o Possibly need APIs for UI
o Push back about shipping a UI rather than just pointing people at a separate project that deals with the UI
o Used to focus on people getting their Kerberos from vendors, may need to move back from that a bit
+ Kerberos consortium is a vendor interface point
+ People expect different things from consortium and a small MIT team
+ Feedback from some sources about building their own Kerberos to replace vendor Kerberos

Wrap up and Next Steps

Action items:

* Paul and Wyllys to bootstrap code review process and follow up on credential cache
* Jordan to request stats from .mac admins
* Better problem statement from Tom on cleaning up code base (less power consumption)
* For next meeting: Getting back on track with interop testing
* Annual conference with wider group than the board
* combine a board meeting with a conference?
o Soonest would be September
o Meeting after September/October at MIT, the following board meeting will be in the Winter of 2009 at Microsoft's Redmond campus

Side discussions: MIT and Heimdal working closely

* common for MIT to copy API proposals to Heimdal lists
* API now for "I'd like a credentials cache no one else is using please" replaced Heimdal and MIT implementations with a better, shared, version
* Had a different API for PKINIT. Have now got a glue layer.