On The Other Hand - Kerberos - 2008-04-07-BoardMeeting

Kerberos Consortium Board Meeting Notes for 2008-04-07

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:
- Carnegie Mellon
- Cornell
- Microsoft
- Michigan State
Hot Prospects
- widely used in financial services industry
- have been cagey about joining the consortium
- needs of financials are very different from academics, more disciplined
FY09 (July 1 2008 - June 30 2009)
- $1.15M in commitments
- $1.57M budget
- short $400,000 so need to bring on 3 big sponsors in the next 3 months
- Would like board members to try and get hold of contacts in other companies
Open Positions
- Strategic Advisor (evangelist in the plan). Marketing who understands Kerberos and business needs
- Programmer/Analyst. Would like to increase this req by 2. Don't currently have a pipeline of CS grads.
- Development Manager. Sam Hartman is moving on.
Board priority: huge doc push
- Full time tech writer has been hired until end of fiscal year. Been on board for 6 weeks now.
- 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
- MIT and Google recruiting summer interns
- Kerberos auth to MySQL
- 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
- Needs better problem description
- Contacting with Bob Morgan, Leif Johansen, Josh Howlett and Jeff Hodges
  - Lots of OASIS folks
- First meeting next week

Update on Priorities - Hartman http://kerberos.org/events/Board-4-7-08/2-Hartman.pdf

Priorities
- Standardized admin interfaces
- coding practices and static analysis
- Simplification of host configuration
Standardized Admin Interfaces
- Not a lot of interest from other vendors in putting a lot of work into a standardized admin protocol
- Everyone has an open administrative protocol (links to MS docs are online so is Heimdal)
- Many interested in understanding customer use cases
- Sun and MIT have similar admin protocol and would like to sync up the incompatibilities
- Sun has donated incremental propagation code
Coding practices and static analysis
- Paying someone for full audit beyond financial needs but there are great tools for this
- Significant progress in style and process (opened up on Kerberos wiki)
- 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
- 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
- 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)

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

Lots of finance customers, who are frequent drivers

Second biggest is internal IT ops

Trying to roll out Kerberos across the enterprise

PKINIT

Resync with MIT 1.6.3

Update pre-auth plugin to use KMF APIs for keystore flexibilities

KMF is abstract APIs for manipulating keys

Allows for applying system wide policy

Update pam_krb5 to use PKINIT (separate project)

Recently started, no estimate of completion date yet

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

enhancements to existing kclient script

kclient == script for configuring and enrolling a host into an existing KRB5 realm

Ease administrative burden

Addresses some scalability concerns

New features

**enroll in AD

- - enrolling in non-Solaris /non-AD realms
  - adding dynamic (DHCP) clients
KDC Master Key migration
- make it possible to migrate to stronger keys without destroying current DB
- Many clients moving from Solaris 8 (DES only) to Solaris 10 (AES) but can't currently migrate keys without re-keying
- MIT has a proposal for this in design review.
Post dated ticket management
- credential management for long running automated processes and cron/ at jobs
- SQLlite KDC backend
- ksu support
  - Solaris historically has not included the ksu utility, but many customers asked for it.
    - Historically pointed people at RBAC
Top requests
- Easier integration and interop with AD
  - simple domain joining and enrollment processes
- referrals
  - client and server side
- 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
- Kerberos work in opensolaris.org/os/projects/kerberos
- Public mailing lists
- 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
- prepare kerberos to meet future challenges
- continue to lead the technology
Strategic pillars
- kerberos on the web
- Kerberos for mobile devices
- Maintaining and Securing Kerberos
- Vendor Independence
How we'll work
- report progress on each pillar at board meetings
- requirements analysis on future stages at the same time as work on earlier stages
  - tackle each pillar in parallel, need prioritization
- Lots of both standardization and implementation
- 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
- understand and analyze web services
  - WS-

web services

Examine and analyze

Protocols

How Kerberos is implemented today?

Implementation quality

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

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

Used alongside SAML/OpenID etc

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

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

tools.ietf.org/id/dtraft-zhu-ws-kerb-04 may be part of the answer

Authentication in Enterprise

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

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

Kerberos identity management (which id to use)

Other ID frameworks have a variety of privacy mechanisms; can we take these mechanisms or something similar and use them in Kerberos

How do you make this usable?

Need to understand user use cases for privacy and how that fits into KRB

Broader authentication
- Understand tech challenges, but not use cases.
  - 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
        
        Would like to see a capability based model
        
        in ACL model, only thing you have is the principal name, so fewer interesting things to do
        
        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
        
        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"
- 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
- limited memory and CPU (although this is relative)
- 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
- Problems:
  - lots of DNS
  - multiple round trips with the KDC
  - Basically unusable with GPRS, kind of usable on EDGE
- 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
- 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)
- 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
        
        Power is something we're eating more of every year, going up slower than CPU and memory (battery tech not keeping up)
Embedded development
- Need to reach out to embedded developers
Credential management for mobiles
- typing passwords on mobiles is hard
- storing passwords on mobiles is a problem due to theft
- 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
- improve security and flexibility
- Need protocol maintenance
- finish FAST
- implement anonymous PKINIT
- implement mechanism glue layer
- implement PKU2U
FAST Pre-auth
anonymous pkinit
- used when one side doesn't have a key
PKU2U and mech glue
- major win for Microsoft (SSPI)
- low on priority list, but high on implementation list (lots of work done already)
- there are people who want this today for projects they're engaging in.
- part of implementation from Sun
- valuable but a fair bit of work
Vendor independence
- Extensions add value, but there are areas where the community should have concern
- Consortium needs to be a neutral party, convince vendors to do things that are in the communities interest
- Encourage vendors to document what they've done
- 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
- what we shouldn't do is re-implement all vendor extensions in an open manner
  - expensive
  - interop problems
- important to understand when an extension is causing a problem
- 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
- 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
- consortium is risky, if get too blue sky/ivory tower then can cause death of the consortium
- 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
- Consortium plays a good role for some in industry as come talk to consortium instead of individual to vendors
- Should we set a criteria that limits where we go (e.g. extreme engineering but not doing research)?
- 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
- Lots of people have heard of Kerberos but don't understand it
- Why should I use it, I have LDAP?
- Many people only know about it when it doesn't work
- Reaching out to the developers is crucial, lots of ignorance about Kerberos
Engineering distance markers
- develop use cases, analysis of requirements
- MRD is also a marker
AS-REQ armoring
- Covered by FAST
- Priority 1 already
- Finish in the IETF and consortium should implement
Role of IETF and consortium
- standards except for internal APIs
- standard IETF process ('go solve this problem through IETF consensus process')
- 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
- 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
- hearing lots of things about code quality
- is the code base ready for mobiles and the web?
  - scalability is a problem
    - understand performance map of kerberos
    - .mac uses kerberos
- does code quality produce an impediment to going forward?
- 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)
- 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
- would like to become less of a specific platform and more of a general UNIX target
- deprecating carbon so compat with it can be dropped
KFW
- Not used by Microsoft
Should we support KFW/KFM any more?
- As add new features, provides a way of experimenting and a testing UI for that
- Platforms should integrate Kerberos and deal with the platform specific bits
- KFM has KLL which should move into the standard UNIX base
- Kerberos.App as have a way to view tickets
- CCAPI is in cross platform stuff
- Possibly need APIs for UI
- Push back about shipping a UI rather than just pointing people at a separate project that deals with the UI
- 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?
- Soonest would be September
- 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.

Version 1.3 last modified by Paul Armstrong on 2008-05-23 at 16:55

Comments: 0

No comments for this document

Attachments: 0

No attachments for this document

Kerberos Consortium Board Meeting Notes for 2008-04-07

Top Menu

Kerberos Consortium Board Meeting Notes for 2008-04-07

Document data

Comments: 0

Attachments: 0

Search

QuickLinks