eAuthentication Forum Notes
November 21, 2002
Owen Ambur, U.S. Fish & Wildlife Service
The forum was hosted by GSA with several hundred participants in the audience. The E-Authentication site is at http://www.cio.gov/eauthentication/ and the presentations from the forum are at http://www.cio.gov/eauthentication/presentations.htm Links to 17 vendors who sponsored the forum are also provided there. Here are the key points that I noted.
Jeanette Thornton, e-Authentication Portfolio Manager, OMB
Introduction
● eGov is the linchpin for all five of the President’s Management Agenda initiatives
● Uncle Sam has 33 million Web pages
● Under the Paperwork Reduction Act (PRA) and Government Paperwork Elimination Act (GPEA), we are reengineering how government conducts business
● Uncle Sam conducts about 5,600 different kinds of transactions
● With respect to the four eGov portfolios, the objectives include:
○ G2C – Improve cycle time
○ G2B – Use XML & streamline
○ G2G – Vertical as well as horizontal integration of data
○ IEE – Streamline & integrate (e.g., eTravel, payroll, recruitment)
● eGov successes thus far include:
○ recreation.gov
○ gov benefits portal (150 programs)
○ EZTax filing
○ eTraining
● eGrants will be coming out with some new things soon
● Most eGov applications require eAuthentication
Steve Timchak, e-Authentication Program Manager, GSA
e-Authentication: Where We Are, How We Arrived
http://www.cio.gov/eauthentication/presentations/forum_timchak.ppt
● President’s Management Agenda calls for citizen-centered services
● President has personally inquired about status of eGov initiative
● Goals of e-Auth include:
○ Enable mutual trust
○ Minimize burden on public when obtaining services across all levels of gov (single sign on)
○ Common, interoperable authentication services
● DoEd has already issued 20,000 credentials for students
● Gateway simplifies & unifies interoperability
● e-Auth is not PKI only; is a broad array of credentials
● The Gateway:
○ Is NOT
- An issuer of credentials or repository of personal information
- The Federal PKI bridge authority
- eSecurity, which will be determined by each application for itself
○ IS a validation service
● Funding was only received in May 2002 but have accomplished a lot:
○ Collaborative effort with many agencies
○ MitreTek Lab is testing state of the art technology
○ Conducted facilitated meetings with 6 of the eGov projects; will do the rest soon
● The National Finance Center considered e-Auth in the Time & Attendance application to be a competitive advantage for them in the competition for Governmentwide payroll services
● The production gateway will be operational by September 30, 2003
● In meantime, the prototype will be maintained in the lab
● 54 responses to the request for information (RFI) were received
○ Want industry to solve the problem for us
● Electronic authentication is currently:
○ Focused on the enterprise rather than interenterprise
○ Centrally managed rather than distributed
● Industry is moving toward Security Assurance Markup Language (SAML)
○ We will not consider proprietary solutions
[Note: The XML Working Group was briefed on SAML in December 2001 and will receive an update at our December 17, 2002, meeting. http://xml.gov/agenda/20021217.htm]
● The Federal Government has applied to join the Liberty Alliance
[Note: The Liberty Alliance was unable to present at the December 2001 meeting of the XML Working Group, but I arranged for them to brief the CIO Council’s Architecture and Infrastructure Committee (AIC). Their Web site is at http://www.projectliberty.org/]
● The e-Authentication gateway will provide service to the 24 eGov projects but also others
○ Come to us with requests
○ Other applications include homeland security and pay.gov
David Temoshok, Director, Identity Policy/Management, GSA
● ACES was intended to issue trusted credentials
○ Previously nothing was available to enable compliance with GPEA
○ Two dozen or more agencies using
○ But have not seen large-scale implementation
● e-Auth is not just a PKI solution
○ Want to leverage other credentials too, e.g., user IDs & passwords
○ But must be able to assess the quality of the credentials
● Scope is not just 24 eGov projects but all of government and perhaps beyond
○ States are very interested
○ Exploring interest in commercial sector too
● Working with Industry Advisory Council (IAC) on three focus issues:
○ Business rules – reliability & liability
○ Business case – need to understand
○ Insight into potential credential providers – obtain feedback from
● While principal target is Federal requirements, want to understand non-federal requirements and add value in the private sector as well
Jeanette Thornton, OMB
Determining Authentication Levels
http://www.cio.gov/eauthentication/presentations/forum_thornton.ppt
● e-Auth policy will be issued soon by OMB
○ Can be used by agencies & by industry too, not just by e-Auth project
○ Draft will be issued for 30-60 days of public review & comment
● Needs include:
○ Consistency across government
○ Framework for future guidance on:
- E-credential providers
- Credentialing
- Technology solutions
● Goals include:
○ Allow policymakers & process stewards to select levels of authentication
○ Establish authentication levels based upon need for certainty
● Proposed process steps include:
○ Identify business processes that require authentication
○ Assess the risk
○ Identify suitable technology solutions, using NIST guidance, etc.
[Note: The new eGov Act requires NIST to establish minimum requirements for information security. http://xml.gov/draft/eGovXML.htm]
● OMB is watching the privacy issues
● Emphatic yes to question about coordination with the Federal Enterprise Architecture, particularly the Component-Based Architecture
David Temoshok, GSA
● e-Auth:
○ Is not authorization (i.e., rights, permissions, or priviledges)
○ Is just verification of ID
● Our interests in the Liberty Alliance include:
○ How can we use the specification for the gateway & agency applications
○ Mediation of business rules through the gateway
● The gateway will be funded with appropriated dollars and/or in partnership with industry
● The level of authentication will map to the requirements of the application and the gateway will do that
Roopangi Kadakia, Director of Systems, Security & New Technology, GSA
Getting an Application on the Gateway
http://www.cio.gov/eauthentication/presentations/forum_kadakia.ppt
● FirstGov is expanding to become a transaction-based portal
○ Becoming front door to Federal Government
○ Goal is to enable citizens to interact more easily with government
● The integrated future of the Office of Citizen Services includes:
○ Shared-service infrastructure
- Contact center
- Content management
- Knowledge management
- etc.
● Phase I, e-Auth & FirstGov, includes:
○ Risk assessment for interoperability
○ Security
○ Links to all applications using e-Auth gateway
○ Guidance on how to be authenticated
● Phase II will address:
○ Privacy
○ Evaluation of options, e.g., strong Customer Relationship Management (CRM)
○ Opt-in strategy so that citizens aren’t forced to go through gateway to get info
● Cited USA Services in response to a question on the authorization (as opposed to authentication) component
David Tomoshok interjected that convenience for citizens will require data covered by the Privacy Act, and GSA wants to proceed slowly and cautiously in that regard. A followup questioner noted that most commercial applications combine authentication with authorization. David responded that the gateway envisions distributed authorization so as to proceed quickly with authentication. That will require agency applications to control authorizations, but in the future agencies may request for the gateway to address roles and privileges.
Mark Liegey, National Finance Center, USDA
e-Authentication Initiative
http://www.cio.gov/eauthentication/presentations/forum_nfc.ppt
● Need to understand the applications that are out there – not just eGov apps but all authentication requirements
● User IDs & passwords are expensive to maintain & can be cumbersome for users
● Can existing credentials be reused?
○ If not, ensure that new ones can be
● Vision: One UID & map appropriate credentials to applications
● Don’t have to be an eGov initiative to use e-Auth
○ If have authentication requirement, let us know
● Share knowledge
○ Help each other avoid mistakes already made
● e-Auth will work with agency applications to:
○ Determine appropriate authentication levels
- Conduct e-Auth Risk Analysis (E-RA)
○ Link appropriate credentials to apps
● Can also help to determine how to maintain user authorization, access control, and privilege management for protected resources
● Can enter agreement with e-Auth gateway and activate link on FirstGov
Rich Corelli, Software Engineering Institute
e-Authorization Risk Analysis
http://www.cio.gov/eauthentication/presentations/forum_carnmellon.ppt
● E-RA approach:
○ Risk-based requirements definition
○ Uses transactions as primary driver (i.e., protection of data)
- Map transactions to e-Auth levels
● Risks are context driven
● Have already worked with four eGov projects:
○ eTravel
○ eGrants
○ Business Compliance One-Stop
○ Gov benefits
● Have initiated contact with:
○ Integrated acquisition
○ eTraining
● Many folks don’t think they need e-Auth but we challenge them to look at the data set
● Application risks can be assessed in about six hours in a facilitated workshop
Tice de Young, NASA
● Trying to reach beyond the 24 eGov projects
● Hired Mitretek to give unbiased advice
Monette Respress, Principle Engineer, Mitretek Systems, Inc.
e-Authentication Gateway
http://www.cio.gov/eauthentication/presentations/forum_respress.ppt
● Conducted rapid prototyping
○ Using whatever was available
● Technical side is easier than policy side
● Looking for open standards, e.g., SAML, LDAP, etc.
● Demo’ed System for Time & Attendance Reporting (STAR)
● Current intent is to include no privacy data in gateway
○ But for prototype had to work with what was available
Judith Spencer, Chair, Federal PKI Steering Committee
The Need for Trustworthy Credentials
http://www.cio.gov/eauthentication/presentations/forum_spencer.ppt
● Four levels of trust
○ No confidence
○ Balance of probabilities
○ Substantial assurance (evidence)
○ Beyond reasonable doubt
● Five types of evidence
○ Personal statement
○ Documentary evidence
○ Third-party corroboration
○ Biometrics
○ Existing relationships
● Someone suggested sixth type – reputation
[Note: In terms of eCommerce, all of these types actually involve comparing E-records provided at the time of the transaction to another set that is already available and, hopefully, which has the attributes set forth in ISO 15489, the international standard for records management.]
● There is no such thing as “Security”!
○ There are risks & there are countermeasures
[Neither is there any such thing as a “trusted network” – only records of varying degrees of quality. http://xml.gov/documents/completed/eRegCOP/sld005.htm]
● Should adopt the minimum degree of e-Auth assurance that meets your requirements
○ Higher assurance entails higher costs
[That is questionable – since lower levels of assurance inevitably lead to waste, fraud, abuse and, in extreme circumstances like 9/11, catastrophe! Low levels of assurance may no longer be as “affordable” as they were in the past. Moreover, distributing the costs of certainty among stovepipe applications does not eliminate or even reduce those costs. It merely hides them, thereby resulting in “tragedy of the commons.” http://members.aol.com/trajcom/private/trajcom.htm It is anything but citizen-centered. Nor is it consistent with the intent of the FEA. http://www.feapmo.gov/fea.htm]
David Temoshok, GSA
The Intersection of the Gateway and ECPs
http://www.cio.gov/eauthentication/presentations/forum_temoshok.ppt
● In past applications agencies haven’t taken citizen-centered approach
● Need balance of centralized and distributed management
● Half of the respondents to the RFI said don’t know how can separate authentication from authorization
○ May need to provide more in the gateway, i.e., roles and privileges
● Most responses to RFI suggested federated approach, e.g., the Liberty Alliance
● Technical aspects are important but so too are the policies (business rules)
○ Need to normalize business rules across communities of interest
○ Discussing with Liberty Alliance & IAC
● Federal PKI bridge entails more than 180 requirements
● Need classification scheme for different degrees of trust
● Transactions in the e-Auth gateway are yes or no
○ The credentials are valid or not
● Estimated that 20% of State-issued credentials are fraudulent
● Sign on to internal agency network will probably not be covered
○ But intent is to provide single sign on across agencies
In the concluding Q&A, Steve Timchak said the 300 Exhibit identifies two potential ways to fund the gateway: 1) pass the hat, or 2) dedicated appropriated funds. When asked if agencies have requested funding for their shares of the cost, he said such funds have been requested for the five eGov projects that GSA manages. In response to a question about an authorization component, David Temoshok reiterated that the gateway will not address ID management or authorization management, but that doing so is part of the Federal Enterprise Architecture initiative. Finally, regarding nonrepudiation, David indicated the responsibility lies with the agency application (relying party) to record and maintain the necessary data for nonrepudiation, as well as for validation of digital signatures if PKI is used.
[In other words, there’s no such thing as a free lunch when it comes to the need to create and maintain the appropriate business-quality records to support our business processes. However, hopefully, at some point, as required by the new eGov Act, NIST, NARA, GSA and OMB will provide sufficient guidance and tools to save us all from having to reinvent the wheel in that regard. http://xml.gov/documents/completed/eGovXML.htm]