Today was the first
board meeting of the
Kerberos Consortium. The meeting consisted of the three initial board members from
Google,
Sun and
MIT as well as the Kerberos Consortium staff, team leads and lead programmers.
Overview - Stephen Buckley
Aiming for 2009 budget of $1.57M
Microsoft coming on board, supplying developer and small amount of money (small Kerberos budget).
- Attend interoperability workshops
- provide gssMonger suite and allow modification and redistribution
- will sign eternal commitment (i.e. renews every year automatically)
- Slava Kavsan assigned to board (ex RSA CTO)
GSS Monger
- test suite
- test most aspects of GSSAPI
- test daemon will accept basic GSS requests
- version for Heimdal, MIT, SSPI
- master runs on Windows, being ported to UNIX
- multi-level delegation and the like (e.g. Heimdal talks to MIT through Microsoft)
- been the heart of almost all their interop tests
State of Technology - Sam Hartman
Kerberos 1.7
- public release planning process 6 - 18 months ago
- Sun involved
- other open source contributors
- if have donated code, will try to integrate where possible (create vibrant open source project)
Transparency
- has historically been MIT focussed, want to get more non-MIT developers involved
- more transparency so others can see what's being worked on and comment on it
- develop policies and procedures for adding developers and code
- initial notes sent to development community
Kerberos on the web
Kerberos on mobile devices
Initial plans
- API and admin docs (not updated since 2002/2003)
- Never really had API documentation, HP has donated their documentation
- lots of time spent on tools and infrastructure, planning on getting others in to take this load
- looking to build pool of consultants for future work
Stability
- anything that doesn't require KRB5_PRIVATE is a committed stable interface
- not publicly stated, but should be
- want a middle ground as well for things that shouldn't be private but may change
Infrastructure
- old version of RT, don't want to lose ticket numbers so weary of integrating with central MIT RT instance
- SVN run by central group
Opportunities
- FAST proposal (improved security and internationalization)
- OTP (interest from RSA)
Mobile devices
- Apple (extremely important priority for them)
- network performance, ease of use, code size
- issues with entering passwords but need a way to ensure authentication to the device
- latency makes KRB difficult/painful to use on mobile networks
- 15 seconds to get initial tickets on cell phone
- particularly bad on cross-realm case
- CPU not an issue on mobile, but is on sensor networks
- memory footprint a problem on mobile devices
- No known plans for Android, but we should try to get a Kerberos client integrated
On the web
- Kerberos tokens for SOAP
- little support, possibly too much complexity
- may be important to be able to delegate into SAML or the like (IETF driving some work on this)
- Microsoft negotiate is state of the art for HTTP KRB negotiation
- doesn't quite follow HTTP spec
- acceptable user experience on corporate, but not good for public internet
- needs Kerberos and PKI (note, I can't find a reference for this assertion)
- trivial MITM attacks as doesn't tie to page
- substantial community of people interested in web authentication in browsers
- no resources for implementation (little experience with appropriate technologies)
- potential sponsors who have indicated that this would be very high priority
- need channel binding between GSS and TLS layers
- present at Financial Services Technology Consortium (FSTC) later this week
FAST
- MIT/Microsoft joint
- make more secure, more difficult to do password guessing
- make easier to integrate things like PKINIT and OTP
- Microsoft not as far ahead of implementation curve as thought
- Microsoft co-authored draft so deeply interested in technology
- recommend: finish draft, investigate resources
- could be used to fix some internationalization problems
- if combine internationalization, would make that a lot easier but make whole project a lot harder
- no sponsors prioritizing internationalization
OTP
- approached by RSA
- take advantage of FAST
- integrate OTP and Secure ID
- tokens heavily used by Government, Finance and places like MIT
- previous attempts have has standardization and security problems
- if valuable to market, someone should be willing to sponsor it
- already support smart cards today
- create more standardized two factor option, still supply one factor
- would also link into FAST
- consortium writing generic part of OTP support
- RSA would need to write support for RSA
- integration costs can be significant (see LDAP backend)
- We should ask RSA if they're willing to co-sponsor FAST as well given it's tightly coupled with OTP
Project specific supporters
- how do we want to deal with supporters who are concerned about having a specific agenda and being voted down by board
Kerberos 1.7 - Tom Yu
Release types
- Full: krb5-x.y
- Patch: krb5-x.y.z
- have testing releases
Planning process
- this is the one used in the past, may change with consortium priorities
- community input and ranking for goals
- run estimates of work on ranked goals
- assign based on resources available and work estimates for highest ranked goals
Development
- SVN
- trunk has most of development
- attempt to keep relatively stable
- branches to isolate intensive development or for stability in releases
Branching
- release branches
- forked off trunk, /branches/krb5-x-y
- no new features after beta
- keep as stable as possible
- changes only be release engineer or delegate
- must have ticket in RT and pullup request
- change located on trunk and then pulled into stable
- temp branches for heavy development
Release branch
- for those wanting to aggressively test latest code
- testing releases
- alpha - bugs expected
- beta - expect minimal changes before release
Release
- no code changes from final beta
- minor docs changes
Patch releases
- pulled up to existing release branch
- usually go through beta testing
- only not done for security fixes that are extremely minor fixes
** rare to do patch release without at least one beta
- named krb5-x.y.z
- allow: bug fixes, minor enhancements, security fixes
- maintenance releases: prior release, security only
Features in 1.7
- Kerberos identity management (KIM) API
- GSSAPI enhanced error strings
- Unified credentials cache API (CCAPI) on Mac OS and Windows
- Support for GSSAPI mechanism glue (mechglue) plug-in modules
Status
- August 2008 release
- 2 month allocated for testing
- Daptiv PPM for project tracking
- on schedule
- completed:
- CCAPI for Mac OS X
- GSSAPI enhanced error messages
- March board meeting may add things and slip dates
- engineering estimate revisions may slip dates
- Glue layer taken a long time ago but dlopen support not done
- propose SSPI and GSSAPI become the same
- Take Luke Howards enhancements and make work on Windows
- Want to get rid of UMich NFSv4 glue layer (UMich are interested in fixing this too)
Kerberos Identity Management - Sam Hartman
What is an identity?
- multiple credential problems
- MacOS: For all peer to peer things, each machine becomes it's own KDC
- identity selection issue
- KRB5CCNAME on UNIX, default credential in Windows/MacOS
- proposing KIM API
- selection hints, tell API information such as what hostname and what Kerberos service
- initially ask the user, this is somewhat necessary but required as not enough information to know what service to use
- prompt and cache
- allow rules for making decisions for you
- cross platform design and implementation
- API makes use of multiple identities by a single application possible.
- Wish for feedback http://mit.edu/macdev/kim.html
Kerberos for Windows - Kevin Koch
What is KRB for Windows
- Identity management GUI client
- easier to use than command line tools
- development going on at "secure endpoints"
- Was funded by MIT, but no longer funded
- Kevin does build and packaging, bug fixes
- Porting credential cache code to Windows
- Kevin is new to Kerberos so is capturing and creating documentation for new Kerberos users
Today
- only 32 bit Windows client
- manually switch between identities
- Network Identity Manager 1 (NIM1)
- written to win32 API which has caused completeness of implementation and details problems
- credentials cache code is Windows specific and has symptoms of "my first C++ program"
- throw away and use common credential cache code
- color coded credential expiration times
- advanced view shows tree view with all tickets and expiration times
- fair amount of flexibility in controlling appearance
Directions
- Remove KRB4 support and make into separate library
- 64 bit support
- cross platform credential cache (CCAPI) code
- windows specific code is per-user local server
- NIM2
Shipping KfW with Windows
- discussions of shipping on Windows resource CD
KfW
- much better experience if using KRB and not on domain on Vista
- Vista it's fully integrated and things like IE will pickup tickets
- XP doesn't have a full integration like that
- insert into MS-LSA cache
- write to GSSAPI rather than SSPI
- write using raw Kerberos APIs if need to
- If have Kerberos services not part of domain or on Windows, may find using KfW a lot easier
- Picks up tickets allocated by Active Directory
Proposed Priorities - Ken Raeburn
Proposed work
- 37 tasks in proposal
- 10 proposed by board members
- Need to refine what we mean by each priorities
Standardized admin interfaces
- better admin in mixed environments
- data model, LDAP schema work at IETF for administration of Kerberos realms
- MIT and Heimdal currently used different protocols and similar data and operations - may be difficult to bring into single protocol
- Sun based on MIT - easy to bring into a single protocol
- Microsoft?
- No known interest from them in getting single admin protocol
- IETF set/change key/password protocol
Propagation
- requires coordination with Heimdal
- looks doable
- need to get Heimdal interested
- May need minor database changes
- A lot of differences can probably be translated
- Heimdal has the ability to read MIT dump file
- RFC of protocol
- call for vendor interest when LDAP schema was proposed
- MS indicated dis-interest
- No current talks with Heimdal
Database formats
- changes cause Sun and customers problems
- been a while since changes made
- tools can translate
- old glitch involving policy database
Incremental Propagation
- have code from Sun
- top of "small projects" queue to spin up consultants with
- standardize wire protocol and database formats
- Stanford has two way synchronization plugin interface between Active Directory, check it out
- hoping to create feedback mechanism
- Sun model doesn't line up well with Heimdal model so moving between them difficult
Error messages
- some work done on improving local error messages
- complicating issues such as internationalization
- customized policies would mean customized messages
- standardized error messages would mean casting in stone and may mean issues with being difficult to improve
- more feasible to standardize codes and leave messages to implementer
- set/change password has some of this implementation and is a good starting point, in IETF now
Security audit
- real and perceived code quality issues
- PR plus
- 20 security advisories in last 5 years
- Mostly code inspection, not exploits
- Some possibly not exploitable, but couldn't prove weren't
- getting lots of vulnerability reports due to reader being unable to understand code
- difficult code means that others write code that has security issues due to lack of understanding
- PR issue with all advisories being listed as critical
- last few have been updated phrasing wise
- demonstrate pro-activeness in fixing, even though not exploitable or no active exploits
- started library code audit several years ago, not finished
- didn't change procedures at that time to prevent requirement for future audit
- find and identify current problems
- fix current practices
- deploy some tools to do things like static analysis
- suspect audit is not the best way to spend money, but we should price it out anyway
- price options of
- 3rd party audit
- static code analysis
- changing practices
- Sun evaluated various groups, got lots of false positives and extra work
- Coverity will cover for free and have just said they will do checks on the Kerberos code
- no-brainer is getting free tools over it
- Sun wants it to be lint-clean
- Made changes to Sun lint to check for buffer overflows
- negotiations as header files can get incredibly difficult to get warning free on all architectures
- (missed the name) ASN.1 automatic checker (but it's in C# and generates C)
- may be able to move away from C#
- If do audit, do it ourselves or hire other party. Each has benefits and drawbacks.
- Planning to decommission KRB4
- Apple, Sun and Microsoft all don't support it
- Already mostly not supported
- Moving towards Doxygen
- Have some LaTeX and TeXInfo
- Going to use Opengrok
- multiple areas that need to be investigated: code, architecture and the protocol
- code: buffer overflows (9 of 22)
- architecture: e.g. reliance on DNS
- protocol: talk to IETF
Zero Configuration
- useful for new install, browser apps, reducing end-user hassle
- issues with determining clients local realm
- DNS security issues, how serious an issue that is depends
- pop up first time and then save it after confirmation would improve security
- may already fall into work for KIM
- Sun, Apple and RH all have a tools to simplify client initialization
- server referrals and determining realm based on host name
- offload from client to KDC
- Microsoft already ship a version of this protocol
- implemented client side of Microsoft protocol
- Stanford is developing a technology called Wallet for solving this problem
Interop test suite
- some work based on Microsoft GSS Monger
- Mainly GSSAPI testing, not full protocol
- Dumps and XML table, no easy list of issues
- Not yet integrated in regular testing
- Would like to add extensions for things like kadmin protocol, anonymity, internationalization etc
- driver program only works on Windows as part of a domain
- porting to UNIX, fails in same way as Windows outside a domain
- Believe it's necessary and doable to port to non-Windows
- Microsoft willing to give MIT team commit access for this
Database support
- Comes up on occasion, on to-do list but no traction yet
- levels:
- offer to help with design
- offer to help with code
User docs
- last touched 5+ years ago
- Sun have admin docs so might be able to integrate
Web browser and email client support
- Sun thinks this is a big one
- For things that have it, UI issues
- Should "just work" out of the box
- have a box that's checked by default
- More difficult in multi-mechanism GSSAPI world
- goes back to issue with bootstrapping clients
- some clients have bad failure modes (like Thunderbird) and will fail completely if GSSAPI not available
- Need options for "Allow" vs "Require"
Common credential cache implementation
- CCAPI and UNIX file caches
- Kerberos for Windows only support LSA for Vista
- Sun has many customers that have issues with cron
- Would love "LSA for UNIX"
- have support for Linux Keyrings
- Considering port of CCAPI to UNIX
- suspend to disk and root privileges make this still a difficult problem
Standardized developer API
- GSSAPI but needs better docs
- Admin protocol - needs standardization
- basic Kerberos protocol
- Apple, Sun, MIT are converging
- MIT/Heimdal issues
- First step probably to document current API
- Very little on guidance of how to use stuff
Propagation management
- query if slaves up to date
- control
- force propagation
- simplify slave propagation management
Prioritization
- higher
- Sysadmin and user docs
- browser and email support
- lower
- standardized admin interfaces lead to more tools and making things more scalable
- Sam noted interest in administering Kerberos from Java
- should get Java team involved
- writing Java administration applications
- first step is go to all the players, see what's possible and report back
Final Priority List
- Standardization - Admin interfaces - e.g. incremental propagation
- MSFT, Heimdal, Java
- huge doc push, white papers best practices
- client side config - make easier
- engineering estimates
- changing coding practices - culture shift
- good test suite - GSS Monger for UNIX
- Web Services - SAML
- needs better problem description
- Common Credential Cache - away from file based
- Common UNIX security authority
- Google and Sun to discuss
- Database support - enable connection with MySQL
- conversation with MySQL - Google and MIT, Google to start
Next meeting
