US Federal E-Authentication and Higher Education
March 28, 2007 | Leave a Comment
The United States federal government has been working on an E-Authentication project actively since 2003 in response to the E-Government Act of 2002. Movement has been slow, but there are many federal agencies now leveraging this infrastructure in a federated manner. For more details about the initiative, there is the publicly available Burton Group Report on the Federal E-Authentication Initiative. For an updated view see the GCN article, E-Authentication maps out its future.
Since then, there has been work to bridge both Liberty Alliance and Shibboleth-based federations with the e-Government services. Involvement also extends to the Post Secondary Electronic Standards Council (PESC) who is working with all these organizations to assure higher education is appropriately represented. Certainly NSF Fastlane and Federal Student Aid (FAFSA) seem like the most obvious first candidates to work with higher education institutions.
With all the activity surrounding the federal government deploying these services in a federated method, institutions should definitely be getting their internal infrastructure in place to support and interoperate with one of the major federations (InCommon, eGovernment, etc).
Tags: "liberty alliance", act, authentication, burton group, e-authentication, eauth, eauthentication, egovernment, fafsa, fastlane, federal, federated, federation, financial aid, gcn, government, higher education, identity, identity management, idm, incommon, initiative, liberty, pesc, pki, shibboleth
Establishing and Securing Identity in a Distributed World
September 2, 2005 | 11 Comments
We have found ourselves in an interesting position. We need to establish, ensure, and maintain identity with remote users without ever exchanging SSN or other highly confidential identifiers or information. Popular solutions include security questions, requiring initial email address, authoritative remote identity providers (ex. notary), or physical presence. First let me debunk all of these in our environment.
Security questions:
- limiting questions to predetermined ones, simplifies ability to automatically guess answers.
- with increased personal information becoming available online, personal questions may have answers easily found.
- open questions often lead to simple question/answer combinations (ex. what color is the sky? blue.)
Initial email address:
- we provide email accounts as a service, requiring an email account to get an email account is laughable
- expired or abandoned accounts are a dead end for ongoing use
Remote identity providers:
- time consuming and cumbersome for the user
- costly for the user
- much manual work
- difficult globally
Physical presence:
- could be time consuming
- online education implies never needing to come to campus
- difficult globally
- not remote, if they have to come here
One potential solution in this space is Faces. This is also potentially cumbersome and the cost is unknown.
Now let me present our solution.
Upon account creation at the institution (student, faculty, guest, alumni, etc), we generate a 32 character password change authorization code, or PCAC, (ex. KLAS-DFHL-KASD-FKLJ-KKL3-243I-HF34-POI2) and a unique username. The account is initially locked. The user receives the username and code through the postal service to a known address, in person, or it is presented to them online if they are able to establish an account-creating relationship online.
Once they have the PCAC, they are instructed to keep it in a safe permanent location (ex. with birth certificate or social security card). They are also intructed to use this code to activate their account and set their password online. From anywhere in the world they can enter the PCAC and username into a secure web form, to set their password.
Once the user has a known username and password combination they use this to access all their services.
This same procedure can be used in the future to instantly reset their password if they have lost or forgotten it. Of course if they know their password they will always be allowed to use that to change it to something else.
At this point they have established identity, received credentials, and with their PCAC can always recover from lost or forgotten passwords. All these steps can be performed online, self-service. The security of their account is primarily in their hands. No one at the institution ever knows their password, and their is no formulaic way of figuring it out. There are no guessable hints.
All of this explains the situation where the user has their PCAC or password. In the contingency where they have lost or misplaced their PCAC, they can have a new one created immediately in person, or request a new one to be mailed to them via an online form.
I have posted this with hopes that people will review this and comment on their opinion of its viability. Please leave comments if you see problems or advantages in this we have not.
This solution is not useful for schools with a PKI solution, but could be used very easily as a cheap intermediary solution while that area matures.
Flowchart of this process (PDF)
PCAC Example (PDF)
Jon Emmons’ article on this same topic: Password Management in an Identity-Theft World
(This proposal authored by Jon Emmons and Zachary Tirrell - 2005)
Tags: faces, identity, identity management, information technology, it, Jon Emmons, password, password management, passwords, PCAC, pki, pooch, security, Zach Tirrell, Zachary Tirrell
Emerging PKI
July 28, 2005 | 2 Comments
This week four of us attended the 2005 EDUCAUSE/Dartmouth PKI Deployment Summit. Our intention was to get a feel for the status of client-side PKI.
Before I get into that, here is a definition of PKI from the UK Department of Health: (just happened to be the clearest, most concise one I could find.)
“A public-key infrastructure (PKI) is the set of policies, people, processes, technology and services that make it possible to deploy and manage the use of public-key cryptography and digital certificates on a wide-scale.”
What about the client-side part? I can’t find a clean definition of this alone, but here’s my summary. Client-side PKI is the assignment of digital certificates to end users for the purpose of authentication without the need for usernames and passwords. An end user could then present their personal certificate as either a soft-copy or on a hardware token to gain access to systems and services they are authorized for. In general deployment of client-side PKI gives a much greater level of assurance (LOA) that the user is in fact who they claim to be.
With the vast number and variety of integrated and disparate systems in most higher education institutions, coupled with a need to be sure only appropriate users are gaining access to them, client-side PKI becomes an attractive technology.
One of the more interesting presentations was from Peter Alterman on behalf of the Federal Public Key Infrastructure Authority. He spoke at great length about LOA and what levels would allow you to map to other levels of access to federal services through the Federal Bridge. I assume there will eventually be a great number of services provided through the bride which will be of interest to higher ed, so institutions need to be aware of the hoops you may need to jump through to get certified. Keep in mind that usernames and passwords will only qualify you for minimal connectivity and services.
So why not roll out client-side PKI at your institutions as quickly as possible? Well… it is complex, the road is mostly unpaved, and it is hugely expensive. Each user needs to have a certificate assigned to them and renewed annually. The outright cost of these are usually $8-$15. Under the newly formed EDUCAUSE Identity Management Services Program (IMSP) a reduced price has been negotiated with VeriSign dropping the price to about $4 (or less depending on volume). Looking at a basic higher education institute with say 7000 users, that gives an annual price tag of $28,000. Put alumni in the same mix and that price gets worse. Then there is a cost associated with hardware tokens if you decide to use those. My understanding is that these run about $30 ($210,000 for 7000). The only way this could actually be funded would be to pass this cost along to the students in their technology fee and have departments budgets handle it for faulty and staff.
Many institutions are avoiding all of this by signing their own certificates. Of course this then prompts users about unknown signing authority which might cause calls to the help desk with confused users. This is the solution MIT, USC, and others have adopted.
There is another solution nearing availability, USHER, the US Higher Education Root. According to Neal McBurnett of Internet2, USHER will:
provide a basis for campuses to deploy signed documents, secure email, and other applications. Serving as both an infrastructure and an initiative, it will include a root (AKA trust anchor or certification authority) to identify campus roots [CA’s], and recommended applications, tools and metadata. It will coordinate with the InCommon federation.
Assuming the USHER CA finds its way into the major browsers as an accepted signing authority, it will provide higher education with an affordable solution for digital certificates. USHER is a key player in multiple Internet2 initiatives including the InCommon Federation and Shibboleth. USHER does not yet seem to have its own web site, but is being coordinated by HEPKI-TAG. I believe USHER is the lynch pin for general deployment of PKI in higher education.
Tags: authentication, certificates, digital certificates, educause, federal bridge, federated identity management, federations, HEPKI-TAG, higher education, identity management, incommon, internet2, loa, middleware, pki, public key infrastructure, SSL, USHER, verisign