Last Modified: 2004-11-02
|
EasyCert BOF
IETF 61 Notes combined from Paul Hoffman and Lakshminath Dondeti Unlike many BOF sessions, this one is not intended to result in an IETF working group. Rather, this is an educational session. The hope is that everyone can learn from the people who have had successful PKI deployments. We have prepared presentations from two organizations that have successfully deployed PKI: MIT and Johnson & Johnson. We also we have some informal comments from a third organization: the US Department of Defense. ------ Jeff Schiller, MIT The MIT CA Experience Notes are matched to slides (approximately), and are meant to be read at the same time as looking at the slides. See easycertjis.pdf. (Intro) Built in 1996 About 40,000 people Issued 1.6 million certs issued since inception Started with v1 certs, now doing v3 Major app: web authentication LDAP is not an authentication mechanism Allows MIT to let non-MIT systems use MIT's authentication (Buy vs. Build) MIT didn't like the $-per-cert model Notion of charge per certificate: skews the value Built their own system Fixed cost of development Allows many certificates per user with the same name (Technology Requirements) Easy to use; cost effective; incrementally deployable (Easy to Use) MIT is slave to the browser vendors Biggest problem: exporting certificate and associated keys to import into another system Cannot expect users to have just one cert Exporting/importing is just too hard Why not just give people one cert Doesn't use smart cards due to cost Works only because web authentication is used (Cost Effective) Have 1000 new people each year About 10-20 support calls Web form wording is very important The problem is reduced to getting it from a website (Incremental Deployment) 99.9% of students have certificates Students must have a client certificate to get registered 66% faculty have certificates Java and cryptix Version 1: servlet Version 2: jsp Version 3: about to be deployed (MIT CA Implementation) Now on version 3 Version 1 and 2 were in Java Now using Python; glue will be available later Acts as a front end to Openssl (Registration Procedure) Certs obtained by authenticating to CA website with Kerberos name, password and MIT ID number Hand out coupon with six-word SKEY phrase for initial creation Can only be used once Can get another coupon if they lose it Bootstrapped with a shared secret to get a Kerberos identity Uses the Kerberos identity and password to get more certs (Tips) Revocation is rarely asked for, so they have never implemented it Big challenge is getting the CRLs out (Certificate Lifetimes) All certs expire in the middle of summer Good for an academic environment Can specify a shorter lifetime A "0-day" cert is good for 1-hour :-) Valid date is actually a day in the past due problems with UTC Certs issued to freshmen from off-campus expire on Sept 1 Some hacks around UTC to get things to work Their Python code is available (Services Offered) Web authentication Student registration Employee HR "self service" Have a separate CA for server certs Jeff issues these by hand after doing human verification Has to rewrite the DN to correct spelling and so on before issuing (What We Do Not Have) A cert practice statement A cert policy statement In "practice" no one seems to care (they are not the government) (Future) S/MIME Problem: have to have one cert only What about key escrow? Implementations store encrypted messages encrypted Encrypted mail is more important than signed mail Funny stories about signed mail (Questions from the floor) Perry Metzger notes that this in "ideal mode" No revocation, with only simple authentication At some point, a cert might be stolen Revocation might be an issue Jeff answers that the real-world has many checks and balances Have a CRL, but it's empty Don't have a CRLDP, but they add that later Bob Morgan mentioned KX509 that does similar things Code is available from University of Michigan Stefan Santesson brought up systems that work by having a central authority Need to have Kerberos as a central layer in order to allow people to get multiple certificates over time Steve Bellovin asks if all web based applications for this, right? Does this works because of the Kerberos database at MIT? Jeff answers that if they didn't have Kerberos, it could still work, but details would have to be worked out Anything that could be used as a PSK might be used for the same purpose Jeff's closing: Nothing in PKIX makes his life hard Subject Alt name is a problem, but Kerberos subject alt name is finally being defined ------ Bob Stahl, Johnson & Johnson Johnson & Johnson's Public Key Infrastructure Notes are matched to slides (approximately), and are meant to be read at the same time as looking at the slides. See JJEDS.IETF.ppt. (Johnson & Johnson) Big, big manufacturing company Has 200 operating companies 109K employees 175 countries (Baseline PKI Architecture) Have an offline root and an online root Have an enterprise directory, feed by all 100+ HR groups CRL is bigger than 2.2 megabytes: yikes! HR feeds the employee status into the directory (JJEDS PKI Principles) Directory-driven, no passwords Built and operated themselves Use only open standards Web-based self-service model Strong identity proofing Issue separate signing and encryption keys Use USB tokens, not smartcards Smartcards don't work: not many laptop models have smartcard readers They escrow the private encryption keys (Standards Based) Use LDAP load-balanced around the world Nine instances In operation for two years Have a cert policy and cert practice statement Have a CRL of the online root generated once per year for the root CA (for the subordinate CAs) Online CRL generates once a day (24-hours) (Self-Service Registration) See the diagram in the slides! Branding this as "digital identity" Each person as a world-wide ID Send a message to new employee and to the boss Has to get the second part from the boss When names changes or leaves, must revoke Boss can revoke Alice's certs are generated on her client and provide only her ID not her access privileges Alice's certs are publishes to the Enterprise directory and from there to the email directory Alice's signature key is never duplicated her decryption key is escrowed for contingencies Michael Richardson notes that one-time codes emailed to Alice and her supervisor in the clear Bob answers: there is a "in the clear" and "a secret" portion that the supervisor delivers (Security Vision) A very major issue is regulation Want to issue certificates to machines to allow internal net access JJEDS is going the PKI way to get rid of passwords Legal and regulatory compliant SOX, HIPAA in the US European privacy requirements Paul Hoffman asks if the different countries' laws are impacting things differently Bob says, not yet! (Applications) Directory became popular by itself More than 150k active entries WWID-based login Workflow routing Phonebook replacement Online org charts Compliance tracking/training Email lookups for apps Working on a guaranteed-to-be-unique identifier (PKI Applications) Killer app: remote access More than 60K users Seeing an increase in request for secure email Many industry-competitive parts use encryption now Within a few years, most applications will go to certificate-only New CRL every day with a lifetime of 7 days Big apps are SAP, Oracle, and Windows Logon No problems enabling in the web space with cert format Use eCertify for CA now, will switch to Microsoft next year The big CRL is not a problem for them Major reason for CRL size is people locking or losing their tokens Users take up to seven days to realize their cert has expired Certs have five-year lifetime Rich Graveman asks if there are any instances of certs that work for one app that don't work for others Bob answer that they carry fields that work with all sorts of apps Marcus Leech said that one of the problems that caused Nortel to drop certs is interoperability. Some apps required weird fields that other apps didn't like. Bob says they are using Windows on desktops everywhere Switching to the Microsoft CA sometime soon Microsoft IE has some problems with the CRL Flushing the cache fixed it Separation between the encryption and signature key helps in revocation (sign key) vs. recovery (encr key) when something is lost Nicolas Williams asked whether OCSP would help for revocation Bob says the problem with OCSP is you have to be online (Next Leap - SAFE) Mostly used for authentication SAFE - industry consortium for facilitating e-transactions Cute acronym for "secure access for everyone" Mostly for digital signatures Run by big biopharma companies Biopharma industry consortium aimed at facilitating e-transactions through SAFE-wide digital credentials Will have a bridge model for signing credentials (SAFE Value Potential) Identity management high for clinical trial researchers Moving towards "digital originals" for documents Less paper Digital signatures Clinical testers have multiple laptops from each company they work Must include OCSP response when things are signed Separate company from SAFE will issue credentials to researchers (Questions from the floor) Steve Bellovin notes the reliance on existing authentication database Bob says they created that database Hardest problem was getting the internal HR folks to agree to doing this Also hard to describe this to everyone in the company to get their buy-in For enrollment, have an ActiveX widget to ship certificate requests over SSL Must use FIPS-validated tokens Gregory M Lebovitz asks what is the mechanism between the desktop and CA Bob says it is ActiveX based CP and CPS were created by a consultant Built with the federal bridge in mind Send out roots with software update, initially loaded in standard desktop loads ----- Sandi Roddy, US Department of Defense DOD PKI started as part of the defense travel service Now an identity management system (IDMS) There is a directory that serves as the authoritative source for their bootstrapping. Now has 23 million DOD in the database Have a strong need for portable private keys Cannot have private keys stored on people's workstations They have to be mobile - something that people can carry Big challenges are political issues Different services already had different PKIs in place Convergence was a big problem Using smartcards Workstations for creating ID cards are custom-built the whole way Has a logistics system to keep cards flowing to RA systems Registration kiosks; some cases mobile on a tractor-trailer Legal: relied on PKIX CP and CPS On version 9 of their CP Big challenge: new personnel given signing and encrypting key but didn't get email keys CRL is about 40 megabytes; hoping for reduction Contains every registration mistake Users forgetting their passwords is common 3-year certs Rolling out OCSP now, has problems with some of the current apps About 20 subordinate CAs, mostly custom code Root CA is mostly offline Global directory service that they rely on is not functional enough LDAP replication hasn't worked as well as they hoped PKIX work is wonderful, wish some of it came out sooner Next big challenge is devices with PKI Really, really want better, fuller standards Using PKCS7 ----- Open Mic Eric Rescorla The stories today are about systems where the user is forced How do we get people to do this voluntarily? Russ Housley ISPs could issue certs with a new email mailbox AOL is issuing a hardware device, but you need to pay money for it Michael Richardson PKI scales up, but not down This doesn't work for small (50-person) organizations Small orgs cannot afford full-time support to handle lost passwords Bob Moskowitz IETF maybe can use PGP to request and validate PKIX certificates Steve Bellovin replies that here is not enough there in PGP to issue certificates based on that. Stefan Santesson Big problem is that IETF creates protocols not applications In-field problems are interop and getting enrollment to work IETF should try not to require anything heavy-weight Thinks PKIX scales down OK We need servers to help clients pick the right certificate if given multiple keys Love Åstrand Big problem is having several roots with no bridge The problem is access Jeff Schiller Would the IESG be interested in issuing a cert to anyone who can read at an address Also has a version of Mailman that uses PKIX certs Hannes Tschofenig If we had more apps using them, it will help bootstrap We have ways to bootstrap symmetric keys, why not asymm keys? David Nelson Layer 8: the problem is getting an ROI and showing it Need to think about costs of issuing and revocation Steve Bellovin Maybe phishing is the driving force for this Sam Hartman Why is the web access problem a PKI and not a PK problem? Marcus Leech Biggest problem is lack of interop between big vendors Operational issues such as storage of all keys on a single smartcard Uri Blumenthal We have all we need in protocol and application suites Whenever there was the power of force, it pretty much worked What is lacking is force |