Kerberos Consortium Board Meeting Notes
APril 7, 2008
Google
1600 Amphitheater Parkway
Mountain View, CA 94043
Attendees:
* 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 http://kerberos.org/events/Board-4-7-08/1-Buckley.pdf
* 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 http://kerberos.org/events/Board-4-7-08/2-Hartman.pdf
* 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 http://kerberos.org/events/Board-4-7-08/ingersoll.pdf
* 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
* PKINIT
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
*
o
+ 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 opensolaris.org/os/projects/kerberos
o Public mailing lists
o bugs.opensolaris.org
+ category: solaris subcategory:kerberosv5_bundled
Kerberos Development Roadmap - Hartman http://kerberos.org/events/Board-4-7-08/3-hartman.pdf
* 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
+ 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-04 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
* dtracescripts.org
* 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
* KFM
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
* KFW
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.
