PKI Unlocked

Deploying PKI to End Users in Higher Education: Workshop Findings

Dartmouth College, Hanover, NH

July 15, 2004

 

Here are the findings from our workshop.  My apologies if I misinterpreted comments – please feel free to send corrections and/or elaborations to: Mark.J.Franklin@Dartmouth.EDU .

 

 

Opportunities

  • What are good applications for PKI in higher education?
  • What are short term opportunities?
  • Long term opportunities?
  • How can we use PKI to better secure the increasingly valuable network transactions we are all implementing?

 

  1. All seemed to agree that the best PKI is close to invisible to users. 
  2. To succeed, we must make PKI easier than its alternative. 
  3. Make the additional security benefits of PKI apparent, but don’t expect to “sell” PKI on this alone. 
  4. PKI is a cost-effective way to deploy 2-factor authentication.
  5. Digital signatures show promise.
    • Signatures on:

                                                    i.     Forms

                                                  ii.     Contracts

                                                iii.     Documents for distribution

                                                iv.     Code

    • Rely on existing paper signature laws and federal and state regulations pertaining to digital signatures.  Should be sufficient.
    • Must mesh well with your institution’s document retention process.
    • Specific ideas include: payroll authorization, expense reports, transcripts requests, HR transactions, QA transactions seem likely applications of digital signatures.  A generalization here appears to be transaction type documents that have a short time span in which they are actually used and require authentication.  Then they can be archived.
    • Need a validation service to attest to signature’s validity at the time of the transaction and record the timestamp in a trustworthy fashion.  This can sometimes be part of an archival process.
    • Longer term should apply to external business relations.
  1. Encryption:
    • FERPA documents exchange between faculty and students.
    • HR transactions.
    • Classified research.
  2. Institutions are succeeding with simple S/MIME “send a signed and perhaps encrypted email with the following information” transactions as a way to get started with digital signatures for electronic transactions.
  3. PKI is emerging as a way to authenticate for password changes (they may have lost their password to a system, but they still have their PKI authentication).

 

Obstacles

  • What are obstacles to higher education institutions adopting PKI?
  • How have schools addressed these obstacles?
  • What obstacles still need addressing?

 

  1. End users don’t care about PKI.
  2. Username and password is highly ingrained into people’s thinking and habits (both users and administrators).
  3. Forgotten token or software keystore password.
  4. Long time to ROI.  How to justify short term expense for long term benefits.
  5. Lack of PKI support in applications, or PKI support that isn’t fully baked.
  6. Interoperability issues.
  7. Funding resources, finding PKI knowledgeable administrators – general lack of knowledge about PKI.
  8. Cost of managing the PKI infrastructure.
  9. CPs and CPSs – some felt strongly that these are highly negative to PKI deployment because people get bogged down in the legalese and policies.  What other solutions do we hold to such high standards?  Why do we throw this extra overhead on PKI in particular?
  10. Getting application and function owner buy-in.  Deployment requires coordination with these people and organizations.
  11. Not knowing what kind of support load to expect from a PKI infrastructure and deployment.

 

Working Together

  • How can we band together to address obstacles and seize opportunities?
  • How can we help our colleagues at other schools with PKI?
  1. Rejuvenate one of the existing email lists for PKI deployment traffic.
    1. Join EDUCAUSE’s PKI mailing list by signing up at the Net@EDU working group page: http://www.educause.edu/netatedu/groups.asp .
  2. Continue to promote inter-institutional trust solutions
    1. HEBCA
    2. Encourage I2 to do USHER (but consider letting Canada and other foreigners participate).  Get USHER root certificate in Mozilla trusted store and in IE trusted store.  Get Microsoft to fund the necessary auditing costs in the name of making IE have more value in higher education.
  3. Participate in PUG and HEPKI-TAG calls.
  4. Share documentation.  Examples:
    1. www.dartmouth.edu/~deploypki
    2. calnetpki.berkeley.edu
    3. calnetad.berkeley.edu
  5. Educate administrators and help desk personnel first.
  6. Ask vendors to improve their existing PKI products and make appropriate new ones.
    1. Browsers need improvements.
    2. Cooperate to use “insider” contacts to get more of our requests to the right people within vendors:

                                                    i.     Apple contact: Mark

                                                  ii.     Mozilla contact: Heikki

                                                iii.     Sun contact: Steve

  1. Encourage openssh to implement X.509 certificates in ssh.

 

Themes

  1. Some schools are finding that in practice CRLs provide little if any value.  Some of the longest running PKIs in higher education have revoked very few certificates.  Several eloquently argued that we don’t need to revoke certificates.  One can view a certificate as a way to identify the user (whether they are still affiliated with the institution and/or authorized to use its systems).  This reduces the functionality of revocation to only when a certificate was issued in error or when control of a private key is lost by an end user.  These events are rarely reported, so why bother with CRLs?
  2. PKI lite is working well as a way to get started without huge CPS overhead.
  3. A study of user behaviors with respect to security generated quite a bit of interest in the group.  The fact is that users take the path of least resistance and will circumvent our fancy security systems if they impose too much extra work or are difficult to understand. The lesson here is that we need to consider what users will actually do with your PKI as we design and deploy it.

 

Last modified 8/2/04