This is the accessible text file for GAO report number GAO-03-952 
entitled 'Electronic Government: Planned e-Authentication Gateway 
Faces Formidable Development Challenges' which was released on October 
16, 2003.

This text file was formatted by the U.S. General Accounting Office 
(GAO) to be accessible to users with visual impairments, as part of a 
longer term project to improve GAO products' accessibility. Every 
attempt has been made to maintain the structural and data integrity of 
the original printed product. Accessibility features, such as text 
descriptions of tables, consecutively numbered footnotes placed at the 
end of the file, and the text of agency comment letters, are provided 
but may not exactly duplicate the presentation or format of the printed 
version. The portable document format (PDF) file is an exact electronic 
replica of the printed version. We welcome your feedback. Please E-mail 
your comments regarding the contents or accessibility features of this 
document to Webmaster@gao.gov.

This is a work of the U.S. government and is not subject to copyright 
protection in the United States. It may be reproduced and distributed 
in its entirety without further permission from GAO. Because this work 
may contain copyrighted images or other material, permission from the 
copyright holder may be necessary if you wish to reproduce this 
material separately.

Report to the Committee on Government Reform and the Subcommittee on 
Technology, Information Policy, Intergovernmental Relations, and the 
Census, House of Representatives:

September 2003:

ELECTRONIC GOVERNMENT:

Planned e-Authentication Gateway Faces Formidable Development 
Challenges:

GAO-03-952:

GAO Highlights:

Highlights of GAO-03-952, a report to the Committee on Government 
Reform and the Subcommittee on Technology, Information Policy, 
Intergovernmental Relations, and the Census, House of Representatives 

Why GAO Did This Study:

For on-line government services that involve sensitive information, 
such as financial or personal information, it is important to be able 
to confirm the identity of potential users. This confirmation process, 
known as authentication, is crucial for security and user confidence. 
The General Services Administration (GSA) is developing an “e-
Authentication gateway,” which is to provide a consolidated electronic 
authentication service to support the e-government initiatives 
sponsored by the Office of Management and Budget (OMB). The figure 
depicts schematically how the gateway process would work. GAO was 
asked to (1) assess GSA’s progress in implementing the proposed 
initiative and (2) identify the challenges associated with 
implementing the gateway.

What GAO Found:

Although the original goal was for the e-Authentication gateway to be 
operational by September 2003, GSA has achieved few of its project 
objectives and recently extended the milestone for completing a fully 
operational system to March 2004. GSA has completed several important 
tasks, such as issuing a request for information and fielding a 
demonstration prototype of the gateway. However, other essential 
activities, such as developing authentication profiles—requirements 
summaries that address the needs of the other 24 OMB e-government 
initiatives—have not yet been fully addressed. Further, to meet the 
new milestone, GSA plans to compress the acquisition process for the 
operational gateway by awarding a contract by December 2003 for 
delivery of an operational gateway by March 2004. This accelerated 
schedule may be difficult to achieve. The modest progress achieved to 
date calls into question the likelihood that the project can 
successfully field an operational gateway, even within the revised 
schedule.

The challenges facing the e-Authentication gateway project make it 
difficult for GSA to achieve the kind of rapid results envisioned for 
the initiative. For example, procedures and guidance have not yet been 
completed defining the specific technologies to support different 
authentication requirements. In addition, technical standards have not 
yet been agreed upon to provide a basis for ensuring interoperability 
among different authentication products and systems. Further, GSA has 
not taken full measures to ensure that the gateway system is 
adequately secured and that privacy information is adequately 
protected. Addressing these and other challenges is essential to the 
successful deployment of a gateway that can effectively support the 
authentication requirements of OMB’s e-government initiatives. 

What GAO Recommends:

GAO recommends that the Administrator of GSA, in conjunction with OMB, 
take steps to ensure that e-Authentication gateway implementation 
challenges are fully addressed, including, among other things, 
revising the schedule for deploying a fully operational version of the 
gateway and working to define key technical interfaces to promote 
interoperability with commercial products.

In commenting on a draft of this report, agency officials requested 
that we include updated information, which has been incorporated in 
this report.

www.gao.gov/cgi-bin/getrpt?GAO-03-952.

To view the full product, including the scope and methodology, click 
on the link above. For more information, contact Linda Koontz at (202) 
512-6240 or koontzl@gao.gov.

[End of section]

Contents:

Letter: 

Results in Brief: 

Background: 

Objectives, Scope, and Methodology: 

Important Objectives and Milestones Have Not Been Fully Met: 

Formidable Challenges Hinder Speedy Deployment of an Operational 
Gateway: 

Conclusions: 

Recommendations for Executive Action: 

Agency Comments and Our Evaluation: 

Appendixes:

Appendix I: Comments from the General Services Administration: 

Appendix II: Comments from the Department of Commerce: 

Glossary:

Figure:

Figure 1: Using the e-Authentication Gateway: 

Abbreviations: 

API: application-programming interface: 

CIO: chief information officer:

e-RA: e-Authentication requirements and risk analysis: 

ECP: electronic credential provider:

FBCA: Federal Bridge Certification Authority: 

GPEA: Government Paperwork Elimination Act: 

GSA: General Services Administration: 

MOU: memorandum of understanding: 

NIST: National Institute of Standards and Technology:

OMB: Office of Management and Budget: 

PIN: personal identification number: 

PKI: public-key infrastructure: 

RFI: request for information: 

RFP: request for proposal:


Letter September 12, 2003:

The Honorable Tom Davis 
Chairman, 
Committee on Government Reform 
House of Representatives:

The Honorable Adam H. Putnam 
Chairman, Subcommittee on Technology, Information Policy, 
Intergovernmental Relations, and the Census 
Committee on Government Reform 
House of Representatives:

Many government services depend on transactions that exchange sensitive 
information, such as financial or personal information. As the federal 
government strives to deliver more services on-line, it increases the 
need to safeguard electronic transactions involving such information. 
Both the electronic system and the user need assurance that the user's 
identity can be confirmed: the system needs to know that the user is 
authorized to exchange the information, which in turn allows the user 
to have some confidence that the system will not release sensitive 
information to unauthorized users. This confirmation of user identity 
is known as authentication.

Systems perform authentication by examining electronic 
credentials[Footnote 1] provided by users and determining their 
trustworthiness. Such credentials can be generated through a variety of 
technologies and provide differing levels of assurance, depending on 
the type of technology used and whether the system is properly 
implemented and maintained. Establishing an on-line environment of 
systems with the capability to verify a wide range of credentials is 
essential to maintaining public confidence in the government's ability 
to conduct business over the Internet and protect confidential 
information from unauthorized access.

This report responds to your request that we assess the progress of the 
General Services Administration (GSA) in implementing its e-
Authentication initiative and the challenges associated with developing 
the e-Authentication gateway, which is the centerpiece of the 
initiative. The e-Authentication gateway is being developed to provide 
a consolidated electronic authentication service to support 24 major 
electronic government (e-government)[Footnote 2] initiatives sponsored 
by the Office of Management and Budget (OMB). All these initiatives, 
including e-Authentication, were originally chosen by OMB in part 
because of the likelihood of their being deployed within 18 to 24 
months. In this regard, we agreed to (1) assess GSA's progress in 
implementing the proposed initiative and (2) identify the challenges 
associated with implementing the gateway.

Results in Brief:

OMB originally set a goal for the e-Authentication gateway to be 
operational by September 2003, but GSA has thus far achieved few of its 
project objectives, and OMB recently extended the milestone for 
completing a fully operational system to March 2004. While important 
tasks--such as issuing a request for information (RFI) and fielding a 
demonstration prototype of the gateway--were completed, other 
activities essential to the successful deployment of an operational 
gateway, such as establishing authentication profiles for the 24 e-
government initiatives, have not yet been fully addressed. Further, to 
meet the new milestone, GSA plans to compress the acquisition process 
for the operational gateway by awarding a contract by December 2003 for 
delivery of an operational gateway by March 2004. This accelerated 
schedule may be difficult to achieve. Fielding a fully operational 
gateway without a full consideration of technical options increases the 
risk that the gateway will not work as intended, support user 
requirements, or receive financial support from partner agencies. The 
modest progress achieved to date calls into question the likelihood 
that the project can successfully field an operational gateway, even 
within the revised schedule.

While the gateway has the potential to provide multiple benefits to the 
other 24 e-government initiatives and the public, several formidable 
challenges will make it difficult for GSA to achieve the kind of rapid 
results envisioned by OMB for the initiative. These challenges include 
the following:

* Establishing comprehensive policies and guidance. Comprehensive 
policies and procedures to promote consistency and interoperability 
among disparate authentication systems operating across the federal 
government have not yet been completed, making it difficult for federal 
agencies developing the 24 e-government initiatives to make decisions 
on what types of authentication technologies and systems to implement.

* Defining user authentication requirements. User requirements have not 
yet been fully defined, and as of August 2003, assessments had been 
conducted for 12 of the 24 e-government initiatives to determine their 
authentication needs and appropriate assurance levels. GSA has not been 
considering the results of these risk assessments in designing the 
gateway.

* Achieving interoperability[Footnote 3] among available 
authentication products. Technical standards have not yet been agreed 
upon to provide a basis for ensuring interoperability among different 
authentication products and systems.

* Fully addressing funding, security, and privacy issues. GSA has not 
developed an effective investment strategy to support full-scale 
development of the gateway or taken full measures to ensure that the 
gateway system is adequately secured and that privacy information is 
adequately protected.

Addressing these challenges is essential to the successful deployment 
of a gateway that can effectively support the authentication 
requirements of the 24 e-government initiatives. In light of these 
challenges, we are making recommendations to the Administrator of GSA 
aimed at improving planning and systems development activities now 
under way and at coordinating activities with other federal agencies to 
better ensure that the gateway provides robust support for multiple 
authentication requirements based on a range of commercial products. We 
also are making recommendations that OMB work with GSA, in conjunction 
with the National Institute of Standards and Technology (NIST) and the 
federal Chief Information Officers (CIO) Council, to expand and improve 
e-Authentication policies and guidance to meet the needs of an 
operational gateway.

We received written comments on a draft of this report from the 
Administrator of GSA and from the Secretary of Commerce. We also 
received oral comments from staff of OMB's Office of General Counsel. 
GSA generally agreed with our discussion of the challenges hindering 
speedy deployment of the e-Authentication gateway, as well as our 
recommendations aimed at addressing these challenges. The agency 
requested that we include more information on recent developments, 
which we have incorporated in this report. OMB staff said the agency 
agreed with GSA's comments. NIST officials generally agreed with the 
content of information and recommendations in the draft report and 
requested that we update information on recently drafted authentication 
guidance. We updated this report accordingly.

Background:

To deliver complete on-line services to citizens, business partners, 
employees, and other entities, the government needs to authenticate the 
identity of users who wish to conduct transactions involving sensitive 
information, such as financial or personal information. A variety of 
authentication technologies are in use, providing differing levels of 
assurance, depending on the type of technology and whether the system 
is properly implemented and maintained. Establishing an electronic 
gateway with the capability to verify a wide range of credentials is a 
critical element in the federal government's strategy for maintaining 
public confidence in the conduct of public business over the Internet 
and protecting confidential information from unauthorized access. It is 
also consistent with the government's effort to integrate information 
technology investments across agencies and to streamline services.

A Variety of Techniques Are Used to Perform Authentication:

The electronic authentication process can involve a range of different 
technologies and electronic credentials, each with varying strengths 
and weaknesses in ensuring that parties are who they claim to be when 
conducting electronic transactions. The types of identifying factors 
used by these different technologies can generally be grouped into 
three basic categories: (1) "something you know," such as a password; 
(2) "something you have," such as a smart card or other token; and 
(3) "something you are," including biometric identifiers such as 
fingerprints or retina scans.

* Something you know: An authentication process based on "something you 
know" relies on information known by both the user and the system--a 
"shared secret"--and offers some advantages and disadvantages. The most 
common types of shared secrets are passwords and personal 
identification numbers (PIN), which are used by systems to confirm the 
identity of individuals accessing computers. Users wishing to access 
such a system are required to enter a password when they first turn on 
and log into the system, confirming the shared secret. Systems that 
support password-based authentication processes are relatively easy to 
implement, because they do not require external products or specialized 
devices. However, they provide only relatively limited confidence in 
the identity of users, because users often share their secret codes 
with others or select common phrases and dates that others can easily 
identify or guess.

* Something you have: An authentication system based on "something you 
have" relies on physical devices--such as smart cards or other physical 
tokens--or tamper-resistant electronic credentials, such as digital 
certificates. Physical devices are encoded with information that can 
verify the identity of the device's owner. To initiate the 
authentication process, a user inserts a token or smart card into an 
electronic reader, and the system verifies information stored on the 
device. Electronic credentials, such as digital certificates, can be 
either stored on a smart card or token and accessed through a reader or 
stored in a user's computer. Digital certificates are small electronic 
files containing identifying information that is encrypted to be 
tamper-resistant. Public-key infrastructure (PKI) is a prominent 
security technology that makes use of digital certificates for 
authentication and may also involve the use of a physical device or 
token.[Footnote 4]

* Something you are: Authentication systems based on "something you 
are" use biometric technologies to capture measurements of personal 
characteristics--such as fingerprints, hands, or facial features--to 
authenticate users. Characteristics from individuals are measured and 
averaged to create unique digital representations of these 
characteristics, called templates, that are stored centrally in a 
database or locally in a user's token, such as a smart card. The user 
must present the characteristic, such as a finger or hand, to the 
authentication device to gain access to the system. The device then 
compares the stored template to the live characteristic of the 
individual for verification. If the characteristics match, the user is 
authenticated and allowed to access the system. Biometric technologies 
have the advantage of not requiring that an individual remember a 
shared secret or keep track of a physical authentication device, 
although biometrics are often used in combination with at least one of 
the other factors.[Footnote 5]

The technologies used to exploit these three authentication factors can 
be combined and implemented in many different ways to provide different 
levels of assurance. For example, a Web site that requires users to 
enter a password provides only very limited assurance of the identity 
of individuals who successfully log on with a correct password. A more 
sophisticated system that requires users to insert a smart card and 
also enter a PIN likely will provide a greater level of assurance, 
because it would be much harder for an imposter to gain access to both 
the smart card and the PIN required to successfully impersonate a 
legitimate user. A system requiring users to provide a biometric 
identifier in addition to a smart card and PIN would arguably offer an 
even higher level of assurance that users were indeed who they claimed 
to be.[Footnote 6]

More sophisticated authentication techniques can have some drawbacks. 
For example, biometric devices tend to be expensive and must be 
deployed at all locations where users need to access systems. Further, 
as we reported previously,[Footnote 7] users tend to resist having to 
present physical characteristics for authentication. As a result, care 
must be taken to choose an appropriate level of authentication for any 
given system, based on an examination of the costs of the systems and 
the risks of information being compromised. Federal government systems 
can be expected to include a broad range of applications requiring a 
variety of assurance levels.

Gateway Established to Provide Common, Governmentwide Authentication 
Services:

In October 2001, the President's Management Council, working with OMB, 
endorsed the development of 24 e-government initiatives[Footnote 8] to 
significantly improve the delivery of services to citizens across 
government. OMB set a goal for initial capabilities to be achieved for 
each of the initiatives by September 2003. The objective of the e-
Authentication initiative was to provide a centralized gateway to 
verify the identity of users, based on multiple types of credentials, 
in support of the other e-government initiatives. By accommodating 
different and multiple authentication mechanisms--such as passwords, 
tokens, digital certificates, and biometrics--the gateway was intended 
to support the different levels of assurance that are likely to be 
required for conducting personal or financially sensitive government 
transactions. In October 2001, OMB tasked GSA to be the managing 
partner for the e-Authentication initiative. As managing partner, GSA 
was given responsibility for spearheading the e-Authentication 
initiative, identifying the authentication requirements of the other 24 
e-government initiatives, and completing an operational gateway by 
September 30, 2003. GSA also was tasked with working with NIST, which 
is responsible for setting technical standards for the federal 
government, to develop authentication assurance policies and 
guidelines, as well as with the federal CIO Council on issues related 
to the Federal Bridge Certification Authority.[Footnote 9]As 
envisioned, the gateway offers multiple benefits to citizens and 
federal agencies conducting on-line transactions, including simplified 
access to government applications and services and cost savings to 
agencies through the deployment of common authentication technologies 
and services.

One of the primary goals of the gateway is to promote secure, easy-to-
use methods for users to prove their identity to federal agencies and 
obtain personal or financially sensitive on-line information and 
services from these agencies. Other goals include establishing uniform 
standards for accessing government services while protecting against 
fraud as much as possible and reducing the need to maintain duplicate 
credentials and user registration information for multiple government 
applications and services. In support of these goals, the gateway is to 
provide what is known as "single sign-on" capability: that is, using 
one authentication method to verify the identity of a user while 
granting access to multiple applications and services. Providing single 
sign-on capability simplifies the authentication process by using the 
same identification method to verify the identity of users from 
application to application. Further, the intention is to extend this 
benefit beyond the 24 e-government initiatives: although the gateway 
was established to support these initiatives, upon completion, it is 
intended to be used to support other applications and services across 
government.

As envisioned, the gateway will provide authentication services through 
a governmentwide portal and links to agency-level applications. The 
plan is for users to rely on a governmentwide portal--such as the 
FirstGov.gov site--to direct them to authentication services offered by 
the gateway. Users would then be able to present credentials for 
authentication. Alternatively, users could be directed to the gateway 
from within specific agency applications to verify their identities 
before they can access information or services. Once a user's 
credential has been successfully authenticated, the user will then be 
granted appropriate access to the application. After being authorized 
to use a specific application, a user may request access to another 
application that is also linked to the gateway. If the second 
application accepts credentials from the user and the first 
application, no additional authentication will be required. If the 
second application requires a credential with a higher level of 
security, the user will have to provide new credentials. Figure 1 
provides a schematic diagram of the gateway's planned authentication 
services.

Figure 1: Using the e-Authentication Gateway:

[See PDF for image]

[End of figure]

Although the gateway will serve as a central point for authentication, 
it will not issue, maintain, or store credentials. Instead, the gateway 
will rely on a network of electronic credential providers (ECP), which 
are to include both government agencies and private sector companies. 
ECPs will issue credentials after verifying the identities of users 
based on traditional means--such as the presentation of passports, 
drivers' licenses, and other identification documents--or by checking 
standardized databases, such as credit history databases. Users seeking 
authentication from the gateway will be directed to appropriate ECPs to 
obtain credentials if they do not already have them. Delegating the 
issuing of credentials to ECPs allows the gateway to support a range of 
credentials and eliminates the need for the gateway to maintain a 
repository of identification information for all credentialed users. 
ECPs are to be responsible for all aspects of managing user 
credentials, including replacing lost or expired credentials and 
maintaining the identification information associated with the 
credentials. Agency applications will retain the responsibility to 
authorize users to conduct specific transactions, such as creating or 
approving information, based on authenticated credentials.

The gateway has the potential to provide multiple benefits to the other 
24 e-government initiatives and to the public. Some of these benefits 
include standardizing credentials and authentication technologies 
across government, improving cost savings by eliminating redundant 
purchases and authentication services, and simplifying public access to 
multiple government applications and services. The cost savings could 
be substantial. In its fiscal year 2004 budget plan, GSA estimated that 
over a 5-year period, gateway costs would total about $73 million, 
while over the same period, costs for separate authentication systems 
at individual agencies are estimated to total approximately $460 
million. Much of the cost savings from centralizing authentication 
would also come from reducing the number of passwords that need to be 
administered from agency to agency and application to application. An 
official with Gartner,[Footnote 10] a market research company, provided 
an indication of the costs associated with resetting lost passwords: in 
a privately funded study, these were found to total about $50 per 
event. Finally, the federal government could enhance the willingness of 
citizens to conduct business electronically by providing centralized 
authentication services that reduce the burden on citizens of 
negotiating multiple credentials and authentication systems to access 
disparate government electronic services.

Objectives, Scope, and Methodology:

Our objectives were to (1) assess the progress GSA has made in 
implementing the e-Authentication gateway and (2) identify key 
challenges associated with implementing the gateway. To assess GSA's 
progress in implementing the gateway, we reviewed project plans, cost 
estimates, funding strategies, contracting activities, testing 
results, performance metrics, and other project documentation, 
including studies completed by GSA, OMB, NIST, and other federal 
agencies on related authentication and security issues. We also 
interviewed GSA project managers and officials from other agencies 
involved in the initiative, such as Agriculture, the Treasury, and the 
National Aeronautics and Space Administration. Contract employees 
involved in developing and testing the prototype were also interviewed.

To assess key challenges associated with implementing the proposed e-
Authentication gateway, we reviewed and analyzed relevant technical 
reports and evaluations of authentication technologies and services 
completed by industry experts and research groups to identify key 
management and technology issues. We also held discussions with 
officials responsible for managing the project within GSA, as well as 
other agency officials involved in development of the prototype. We 
conducted these discussions with officials from Agriculture's National 
Finance Center and two large federal agencies--the Departments of 
Defense and Commerce--to obtain information on funding and technical 
issues related to the gateway.

We performed our review in accordance with generally accepted 
government auditing standards, working from November 2002 through July 
2003, at various locations, including GSA Headquarters in Washington, 
D.C; NIST Headquarters in Gaithersburg, Maryland; and the National 
Finance Center in New Orleans, Louisiana.

Important Objectives and Milestones Have Not Been Fully Met:

GSA's drive to make the e-Authentication gateway operational quickly 
has resulted in few objectives being achieved and changes to planned 
tasks that have increased project risks. While GSA has completed 
several important tasks--such as issuing an RFI and fielding a 
demonstration prototype of the gateway--it has not yet fully addressed 
objectives essential to the successful deployment of an operational 
gateway, and it has extended the milestone for making the gateway fully 
operational from September 2003 to March 2004. To meet the new 
milestone, GSA plans to compress the acquisition process for making the 
gateway fully operational by issuing a request for proposal (RFP) and 
awarding a contract in December 2003. According to the project manager, 
the contractor will be expected to have a fully operational gateway up 
and running by the March 2004 milestone. However, this accelerated 
schedule may be difficult to achieve because it is based on an 
extremely short time frame, which allows the selected contractor only 3 
months to develop, test, and deploy a fully operational gateway.

In December 2001, GSA developed its original plan for implementing a 
fully operational e-Authentication gateway. Major tasks included:

1. developing and issuing an RFI and RFP to obtain industry input on 
technical approaches to authentication for potential incorporation into 
the e-Authentication gateway,

2. assisting e-government initiatives and other federal agencies in 
identifying their authentication requirements,

3. developing authentication profiles that address the needs of the 
other 24 e-government initiatives by linking their requirements to a 
set of standard authentication technologies,

4. enabling three multiuse applications to interoperate with the 
gateway, and:

5. revising existing governmentwide contracting mechanisms for PKI-
related services to promote broader use by federal agencies.

To date, GSA has partially addressed four of these five tasks. The 
first major task--to develop and issue an RFI and RFP--was partially 
completed in July 2002 with the issuance of an RFI. GSA obtained input 
from 54 industry representatives on potential technical approaches to 
implementing e-Authentication in response to the RFI. This information 
was used to help design the prototype gateway and a framework for 
delivering authentication services. However, in April 2003, GSA decided 
to use its existing contractor--builder of the prototype version of the 
gateway--to continue work aimed at deploying an "interim" operational 
version of the gateway, and to delay the milestone for the fully 
operational version of the gateway from September 2003 to March 2004. 
According to an April 2003 letter from GSA's Chief Information Officer 
to OMB, the anticipated delay was due to the lack of receipt of funds 
from federal agency partners. In commenting on a draft of this report, 
GSA officials further stated that the delay was due to a lack of demand 
for authentication services from the 24 other e-government initiatives, 
as well as industry's lack of readiness to provide interoperable 
gateway services. The e-Authentication project manager told us in July 
2003 that GSA planned to compress the acquisition process for the 
operational gateway by issuing an RFP, selecting a contractor, and 
awarding a contract by December 2003. According to the project manager, 
the contractor would be expected to deploy a fully operational gateway 
by the March 2004 milestone. (Originally GSA had planned to issue an 
RFP in September 2002 to have an operational gateway in place a full 
year later.) Awarding a competitively selected contract is important 
because it allows a range of alternatives to be considered before a 
final technical approach is selected. However, the accelerated schedule 
contemplated by GSA may be difficult to achieve because it is based on 
an extremely short time frame, which allows the selected contractor 
only 3 months to develop and deploy a fully operational gateway. In 
addition, GSA will need time to complete the required certification and 
accreditation process in order to obtain full authority to operate the 
gateway.

GSA also partially completed the second task of assisting e-government 
initiatives and other federal agencies in identifying their 
authentication requirements. Identifying requirements is important 
because they represent the blueprint that system developers and program 
managers use to design, develop, and acquire a system. GSA worked with 
the Software Engineering Institute[Footnote 11] to develop an 
assessment tool to identify authentication requirements by helping 
agencies determine appropriate assurance levels for their planned 
electronic transactions. However, the process of identifying 
requirements is still under way. Thus far, only 12 of the 24 e-
government initiatives have completed assessments and shared this 
information with GSA. Officials plan to conduct assessments for 5 of 
the other initiatives. According to GSA officials, assessments are not 
planned for the other 7 initiatives, because those initiatives have no 
requirements for electronic authentication at this time. Without fully 
defined requirements, the gateway project faces the risk that extensive 
or costly changes may be needed before it will meet the needs of all 
the e-government initiatives.

GSA has also taken steps to address its fourth major task, enabling 
three e-government applications to interoperate through the gateway. A 
prototype version of the gateway was fielded on schedule in September 
2002. However, the prototype gateway accommodated just one 
demonstration version of a multiuse application managed by the 
Department of Agriculture's National Finance Center. It did not support 
any of the 24 e-government initiatives. The gateway's project manager 
said that as of June 30, 2003, the gateway had achieved initial 
operational capability and was supporting vital records transactions 
from state and local governments to the Social Security Administration. 
Approximately 400 transactions had been supported as of July 25, 2003. 
However, these transactions were also not associated with any of the 
OMB-sponsored e-government initiatives. Officials said that work was 
under way to develop a link for the Disaster Management initiative, 
although no milestone had been set for making that link operational.

According to GSA officials, action has also been taken to address the 
fifth task--to revise mechanisms for governmentwide contracting for 
PKI-related services, as a means to promote broader use by federal 
agencies. Specifically, GSA officials reported that policy for use of 
its Access Certificates for Electronic Services program had been 
modified in June 2003 to provide for broader use.

The remaining task (task 3), establishing authentication profiles for 
the 24 e-government initiatives, has not been addressed, because not 
all e-government initiatives have yet identified their authentication 
requirements and because technical guidance for linking those 
requirements to specific technologies has not yet been finalized by 
NIST.

In its updated e-government strategy plan, released in April 
2003,[Footnote 12] OMB set milestones for several ongoing gateway-
related tasks. These interim milestones included issuing governmentwide 
authentication guidance by April 2003, deploying the first applications 
linked to the gateway by May 2003, and establishing a list of 
credential providers by August 2003. However, these interim tasks have 
not yet been fully addressed. For example, governmentwide 
authentication guidance was not issued as planned in April 2003, 
although OMB partially addressed this objective by issuing a draft 
version of the guidance for comment in March. No revised time frame has 
been established for finalizing this guidance. Nor were applications 
deployed and linked to the gateway in May 2003. The project's 
milestones were extended because of funding limitations and technical 
problems, according to the gateway program manager. GSA, which was 
tasked by OMB to lead the gateway implementation effort, now plans to 
link the first of the 24 e-government initiatives to the gateway in 
July 2003 rather than May 2003. In addition, GSA now plans to complete 
the remaining tasks to make the gateway fully operational by March 
2004, rather than September 2003.

Formidable Challenges Hinder Speedy Deployment of an Operational 
Gateway:

Developing the e-Authentication gateway has been a challenging 
undertaking. A variety of technical and management challenges have 
hindered GSA's progress in developing and deploying the gateway as 
originally planned. These challenges include establishing 
comprehensive policies and guidance, fully defining user requirements, 
achieving interoperability among commercial authentication products, 
and addressing resource, security, and privacy issues. Addressing these 
challenges will require the cooperation of federal agencies developing 
the 24 e-government initiatives, as well as commitment by GSA to making 
the gateway a fully operational cross-agency resource.

Policies and Guidance Are Not Yet Complete:

While GSA has drafted guidance to assist federal agencies in deciding 
on what types of authentication technologies and systems to implement, 
policies and procedures to promote consistency and interoperability 
among disparate authentication systems operating across the federal 
government have not yet been completed. Policies and procedures are 
needed to specify such things as the range of standard assurance levels 
to be supported; the types of authentication technologies appropriate 
for each of those levels; processes for issuing, maintaining, and 
revoking electronic credentials; and procedures for ensuring that 
individual agencies and credential providers are meeting security 
standards in operating and maintaining their separate systems. Without 
such standard policies and procedures, agencies are unlikely to develop 
systems that provide consistent levels of security, which would make it 
difficult to achieve interoperability across agencies and could lead to 
security vulnerabilities if authentication systems are not properly 
designed and implemented.

OMB is responsible for establishing policies, standards, and guidelines 
for information management, including e-government. In March 2003, OMB 
published draft guidance on electronic authentication to promote 
consistent authentication processes across government.[Footnote 13] 
The draft guidance proposes four standard assurance levels for 
authentication, termed "minimal," "low," "substantial," and "high." 
Examples were provided that were intended to assist agencies in 
identifying the levels of assurance that would be appropriate for 
specific applications, based on an assessment of the risks and 
consequences if transactions were completed in error. According to OMB, 
the purpose of the guidance, when finalized, is to help federal 
agencies make consistent decisions about authentication risks, reduce 
authentication system development and acquisition costs, and minimize 
the number and type of electronic credentials that federal employees, 
citizens, and businesses need to conduct electronic transactions with 
the government. No date has yet been set for completing the draft 
guidance.[Footnote 14]

Further, guidance has not been provided to agencies on how to identify 
appropriate technologies to address their authentication requirements. 
According to OMB, agencies must first identify the assurance levels 
associated with their planned e-government transactions and then refer 
to additional technical guidance to identify appropriate technical 
implementations. NIST has been tasked with developing this guidance, 
which would specify the types of technologies that could be used to 
conduct transactions at each of the OMB-defined assurance levels. A 
NIST official indicated that an initial draft of this guidance would be 
available for comment by September 2003. However, until the NIST 
guidance is completed, technical requirements for the gateway may be 
difficult to identify, and agencies will be at risk of choosing 
authentication systems that may need to be changed at a later date to 
conform to NIST's guidance.

In addition to OMB and NIST guidance setting standard authentication 
levels and associated technology alternatives, additional policy and 
procedures covering other aspects of administering e-Authentication 
consistently across the government have not been completed. In July 
2003, GSA issued a draft framework for evaluating the processes used by 
ECPs to issue credentials to users for conducting transactions at each 
of the four assurance levels. Agencies need to be able to assess 
compliance with standard policies and procedures in order to be able to 
determine whether the credentials issued and managed by specific ECPs 
have an adequate degree of trustworthiness. GSA also drafted guidance 
in July 2003 for the use of passwords, PINs, and PKI. However, no 
milestones have been set for finalizing this guidance. In other areas, 
no guidance has been developed. Guidance concerning authorization--the 
process of granting appropriate access privileges to authenticated 
users--is an example. A GSA official indicated that such guidance could 
help ensure that agencies perform authorization consistently across 
government. However, GSA officials said they had no plans to develop 
authorization guidance, because they considered authorization to be the 
responsibility of the agencies that control the software applications 
being supported.

User Authentication Requirements Have Not Been Fully Defined:

In addition to the lack of complete policies and procedures, 
implementation of the e-Authentication gateway is also impeded by the 
lack of defined authentication requirements from the other 24 e-
government initiatives and agencies expected to use the gateway. 
Improperly defined or incomplete requirements have often been 
identified as a root cause of the failure of systems to meet their 
cost, schedule, or performance goals.[Footnote 15] Key stakeholders and 
other federal agencies responsible for e-government initiatives and for 
contributing funding for the gateway have not been involved in 
assessing the prototype and determining whether it is suitable for 
operational deployment.[Footnote 16] According to a GSA project 
official, the 24 e-government initiatives have played a limited role in 
the gateway project by completing risk assessments and identifying 
technical approaches to authentication for their individual projects; 
they have not been involved in determining the technologies to be 
incorporated in the gateway. Although the gateway is intended to 
deliver common, interoperable authentication services in support of the 
other e-government initiatives, it will be difficult to develop and 
operate such a system until user requirements are better defined.

Identifying authentication requirements for the other 24 e-government 
initiatives has been slow because deployment phases for the projects 
vary widely, and many are still in their early phases--making it 
difficult to define robust information assurance and authentication 
requirements. In May 2002, GSA and the Software Engineering Institute 
established a joint project to develop and apply a risk-based process 
to identify the authentication requirements for transactions associated 
with the other 24 e-government initiatives. Project objectives were to 
(1) document and characterize the transactions and data associated with 
each of the e-government initiatives; (2) identify the risks associated 
with conducting these transactions and authenticating users involved in 
them; (3) define associated authentication requirements; and 
(4) analyze the identified authentication requirements in aggregate to 
help define standard levels of authentication for the gateway. The 
result of this project was the development of a standardized e-
Authentication requirements and risk analysis (e-RA) process. 
Subsequently, the Software Engineering Institute developed a self-
directed tool, based on the e-RA process, for the agency officials to 
use in assessing the requirements of their own initiatives.

Because authentication requirements have been identified through the e-
RA process for only 12 of the e-government initiatives (as of August 
2003), the gateway risks not being able to address the wider 
authentication requirements that may be identified in the future for 
the other e-government initiatives. After participating in pilot risk 
assessments for four of the initiatives, the Software Engineering 
Institute reported that the transactions assessed in these pilot 
efforts were not representative of other e-government initiatives, and 
that no conclusion could be drawn about the extent to which the 
identified authentication requirements were representative of the other 
e-government initiatives. Altogether, as of August 2003, risk 
assessments had been completed for 12 e-government initiatives, 
including the 4 pilot risk assessments that the Software Engineering 
Institute participated in conducting. However, the results of these 
assessments were not used as input into the design of the prototype and 
interim gateways, and they have not been used to establish functional 
requirements for the gateway. Despite the Software Engineering 
Institute's conclusion to the contrary, project officials said they 
believed the results of the four pilot risk assessments validated the 
assurance levels proposed by OMB and thus were sufficient as the basis 
for designing the gateway. GSA project officials further stated that 
the risk assessments were to be used to identify assurance levels for 
transactions, not functional requirements for the gateway. Officials 
indicated that functional requirements have not yet been identified, 
though the gateway achieved initial operating capability in June 2003.

Commercial Authentication Products Generally Are Not Interoperable:

Agencies generally use commercial off-the-shelf products to implement 
authentication for their individual applications, and many of these 
products are based on unique proprietary approaches, making it 
difficult for them to interoperate. In January 2003, GSA analyzed data 
that it received from over 50 vendors in response to the RFI it issued 
in 2002. Vendors indicated that a wide variety of standards and 
protocols were being used to design and develop authentication products 
and services, including the Security Assertions Markup Language, the 
Simple Object Access Protocol, the Secure Sockets Layer protocol, the 
X.509 digital certificates standard, the Lightweight Directory Access 
Protocol, and others. Because so many different and incompatible 
approaches had been used to design authentication products and 
services, GSA officials stated that, at that time, they were unable to 
identify a single standard or small number of standards that would be 
suitable for the gateway, which must interoperate with many agency 
systems.

Many vendors suggested that the government develop a common methodology 
to link divergent applications and authentication products to the 
gateway. One approach to doing this would be to develop an application-
programming interface (API) based on open, nonproprietary standards 
that would serve to connect agency applications to gateway services. 
Using a standard API to connect applications to use the gateway could 
eliminate the need to define unique interfaces for each application, 
and reduce development costs and implementation time frames. However, a 
common methodology or API to link authentication products and 
applications to the gateway would likely take considerable time to 
develop--too long to meet the gateway's planned operational milestone-
-and would be difficult, given that the gateway's user requirements are 
not yet fully defined. A technical specialist working with Mitretek, 
the contractor GSA hired to assist in prototype development, stated 
that custom software interfaces would have to be developed for each 
authentication product intended to interoperate with the gateway, 
including customized software links between agency applications, 
electronic credential providers, and the gateway. According to this 
official, a considerable amount of time likely would be needed to 
develop customized APIs for each of the 24 e-government initiatives. 
This official further noted that the gateway prototype was tailored 
specifically to interoperate with two authentication systems managed by 
the Department of Agriculture's National Finance Center and that it 
took several months to develop the software interfaces for these two 
systems. In its attempt to reduce the number of software custom 
interfaces needed to link e-government initiatives to the gateway, in 
April 2003, GSA drafted technical guidance that encourages the use of 
the Security Assertions Markup Language as a standard way to interface 
with the gateway. However, this guidance has not yet been issued.

Further, because currently available commercial authentication 
products are not designed to interoperate with other products across 
multiple systems, developing a stable and reliable system that depends 
on interconnecting these technologies may prove difficult. Several 
commercial vendors stated that the technologies needed to support 
single sign-on capabilities across multiple platforms, applications, 
and databases have not yet been developed. A Mitretek official further 
indicated that commercial authentication products generally are 
designed to combine authorization and authentication services, because 
most existing systems treat both functions as one. The gateway, 
however, is intended to provide only authentication services, leaving 
agency applications the responsibility to grant access authorizations 
based on the authentication results. To support this requirement, 
vendors will need to make programming changes to "turn off" 
authorization services in their existing products. These changes could 
affect product performance and reliability. According to a NIST 
official, the gateway is a large and challenging project that is trying 
to cover a broad range of applications with different assurance 
requirements, in an area where technologies and business models are 
still evolving. These factors add to the development risk and argue for 
an extended period of testing before the gateway is made operational.

Finally, GSA has not yet addressed how the gateway's software will 
interoperate with systems maintained by nongovernment organizations and 
individual citizens. According to a NIST official, GSA's concept for 
delivering gateway services to citizens is heavily dependent on the 
relationships established between citizens and nongovernment 
organizations, such as financial institutions, airlines, and 
telecommunications carriers. Under this concept, nongovernment 
organizations will play a key role in issuing authentication 
credentials to customers. Integrating the gateway with systems managed 
by nongovernment organizations as well as validating credentials 
provided to customers will be challenging, according to this NIST 
official. GSA officials agreed that it would be a challenge to 
establish relationships with nongovernment credential service 
providers and to ensure that credentials are issued and correctly 
validated. GSA is attempting to establish a consortium of industry and 
government ECPs to promote information sharing and develop a "trust 
list" to facilitate the exchange of credentials across organizations. 
In addition, the consortium would like to adopt processes used by 
nongovernment organizations to issue credentials and adapt those 
processes to validate credentials for government transactions. 
Officials indicated that collaborative partnerships would be needed to 
ensure that authentication systems and electronic credentials 
interoperate successfully. As of July 2003, GSA was working with the 
Liberty Alliance Project and other national organizations, such as the 
National Automated Clearing House Association, to discuss potential 
solutions for authentication interoperability problems.

Resource, Security, and Privacy Issues Have Not Been Fully Addressed:

Addressing funding, security, and privacy issues will be critical to 
the deployment of the e-Authentication gateway and to maintaining 
public confidence in the government's ability to provide on-line 
services. While GSA has developed general strategies to address 
funding, security, and privacy issues related to deployment of the 
gateway, certain issues remain outstanding.

In December 2001, GSA established a multiagency investment strategy for 
the gateway initiative that called for financial and personnel resource 
commitments from 14 different federal agencies, not all of which are 
responsible for leading e-government initiatives. The agencies were 
asked to contribute about $30 million (50 percent) of the nearly $60 
million needed to implement and maintain the gateway through 2006. 
About $32 million was to be provided during 2002. In August 2002, GSA 
revised the funding strategy for the gateway and increased its cost 
projections for linking all 24 e-government initiatives to the gateway 
to about $73 million through 2008. Under the revised funding plan, 13 
of the 14 federal agencies were expected to provide about $25 million 
beginning in 2003.

GSA's funding strategy for the gateway initiative has depended on 
contributions that have been less than expected and provided late in 
the fiscal year. In May 2003, only five agencies had agreed to fund the 
gateway as proposed, contributing about $4.1 million of the nearly $25 
million required. GSA drafted memorandums of understanding (MOU) to 
obtain funding and personnel resource commitments from other agencies 
on an annual basis, beginning in 2003, and as part of the original 
funding strategy. The MOUs identified gateway priorities, milestones, 
partner responsibilities, and the contributions expected from each 
agency. As of August 2003, GSA had discussed the proposed MOUs with 11 
of the 14 agencies (80 percent) included in the initial funding 
strategy for the gateway and 2 additional agencies. GSA's project 
manager stated that 16 agencies are now part of the e-Authentication 
Steering Committee, and 13 agencies provided a total of $13.5 million 
to GSA for the gateway as of August 18, 2003, with another $3 million 
expected from another agency by the end of fiscal year 2003. However, 
GSA still needed to secure about $5.1 million for the gateway as of 
August 18, 2003. According to GSA's project manager, all 16 agencies 
serving on the Steering Committee pledged individual contributions of 
$337,000 and $393,000 for 2004 and 2005, respectively. Eight new 
members may also be added to the Steering Committee, and contributions 
from agencies may be reduced accordingly. GSA's project manager further 
stated that the estimated costs for completing the gateway were reduced 
to about $55 million through 2008 as part of the fiscal year 2004 
budgeting process.

Because resources have not been ensured and were provided late in the 
fiscal year, the funding strategy poses significant risks for the 
gateway. According to GSA's project manager, difficulty in obtaining 
funds for the initiative has contributed to milestone delays and other 
problems. The project experienced a funding shortfall in 2003 and had 
to change the acquisition strategy for the initiative and reduce 
contracting support, according to the project manager. The GSA official 
added that the project might face similar funding shortfalls beyond 
2003, and that GSA planned to charge subscription or service fees to 
agencies that use the gateway to cover operations and maintenance costs 
after 2004. However, GSA has not yet determined what these fees would 
be, and additional funding may be needed to operate and maintain the 
gateway if agencies do not use it as much as is expected, and service 
fees fall short of projections.

In addition, maintaining adequate security for the e-Authentication 
gateway may be difficult, because it is intended to connect with so 
many other systems. As more and more agency applications and ECPs are 
linked to the gateway, an effective configuration management program 
will be vital to maintain minimal levels of security for the system. 
GSA intends to adhere to the National Information Assurance 
Certification and Accreditation Process, which establishes minimum 
national standards for certifying and accrediting national security 
systems. In April 2003, the interim gateway was granted authority to 
operate as part of the certification and accreditation process.

The gateway's use of personal information for identity verification 
also raises the potential for privacy issues. The E-Government Act of 
2002 requires agencies to conduct privacy impact assessments for 
systems such as the gateway.[Footnote 17] A privacy impact assessment 
is a process that helps departments and agencies determine whether new 
technologies, information systems, and initiatives meet privacy 
requirements. GSA officials stated that they are designing the gateway 
so that privacy information is not retained within the gateway itself, 
thus hoping to avoid the potential problems associated with having to 
adequately protect stored privacy information. However, such a strategy 
does not provide assurance that all aspects of privacy have been 
adequately identified and addressed--conducting a privacy impact 
assessment could provide a more comprehensive view. According to GSA 
officials, a privacy impact assessment has not yet been completed.

In addition, concerns have been raised about the privacy implications 
of aggregating information collected from multiple sources and the loss 
of personal privacy if records are shared across government. A recent 
National Research Council report[Footnote 18] suggests that 
authentication systems obtain only necessary information from users and 
for well-defined purposes. According to the report, this information 
should be retained for a minimal period of time, and a clear policy 
should be established to articulate what entities will have access to 
collected data and for what defined purposes. Further, the system 
should be reviewed and periodically audited to ensure compliance with 
these policies, and individuals should have the right to check on and 
correct any personal information collected by the system. OMB 
recommends that agencies develop measures for ensuring compliance with 
the Privacy Act and other government security standards.[Footnote 19] 
Accordingly, agencies need to assess and plan for appropriate privacy 
measures when implementing systems, including authentication 
technologies.

Conclusions:

Developing an e-Authentication gateway capable of supporting the 
authentication requirements of the OMB-sponsored e-government 
initiatives is important in ensuring that citizens can safely and 
securely conduct electronic business with the government. Developing 
such a system is an ambitious task, involving the interconnection of 
authentication technologies on a scale that has not been attempted 
before within government or private industry. In attempting to meet 
near-term milestones--such as the initial September 2003 deadline--GSA 
did not adequately address several important implementation objectives. 
For example, GSA has only partially completed its task of assisting e-
government initiatives and other federal agencies in identifying their 
authentication requirements, and it has not yet enabled any of the e-
government initiatives to interoperate with the interim gateway. Nor 
has it developed authentication profiles that address the needs of the 
other 24 e-government initiatives or made needed changes to its 
governmentwide PKI-related services contract. GSA's modest progress can 
be understood in light of the significant challenges that the agency 
faces in attempting to build the e-Authentication gateway. These 
challenges include a lack of comprehensive administrative polices and 
guidance, inadequately defined user requirements, a dearth of 
interoperable commercial authentication products, and important 
resource, security, and privacy issues. Without addressing these 
challenges, GSA runs the risk of deploying a system that does not 
address user needs or operate as required.

Recommendations for Executive Action:

To address the issues associated with GSA's attempts to meet near-term 
milestones for implementing the e-Authentication gateway, we recommend 
that the Administrator of GSA:

* revise the schedule for deploying a fully operational version of the 
gateway, based on realistic milestones for development of the gateway 
using a competitively awarded contract, development of authentication 
profiles for each of the other 24 e-government initiatives, and 
completion of revisions to GSA's governmentwide PKI-related services 
contract.

To ensure that e-Authentication gateway implementation challenges are 
fully addressed, we recommend that the Administrator of GSA, in 
conjunction with the Director of OMB,

* ensure that a comprehensive framework of authentication policies and 
procedures related to gateway operations is developed and implemented, 
in conjunction with NIST, the CIO Council, and other federal agencies 
(the framework should include policies and standards for auditing 
agencies and nongovernment organizations that will be linked to the 
gateway for compliance with applicable security, privacy, and 
credential requirements);

* establish a process to complete risk assessments for the OMB e-
government initiatives that require authentication services and define 
associated authentication requirements to ensure that the gateway's 
design can support the range of authentication technologies that will 
be needed by the e-government initiatives;

* define key technical interfaces to promote interoperability with 
commercial products and facilitate interconnection with ECPs;

* enhance the effectiveness of the gateway's funding strategy by 
defining specific contributions from federal agencies and obtaining 
their commitment to support the initiative, based on the project's 
implementation and maintenance schedule, which addresses costs through 
2008; and:

* establish and implement security and privacy policies for the 
gateway, based on input from stakeholders and potential users, to 
ensure that all privacy requirements are considered and addressed--
including the development and completion of a privacy impact assessment 
that involves key stakeholders.

Agency Comments and Our Evaluation:

We received written comments on a draft of this report from the 
Administrator of GSA and from the Secretary of Commerce. Letters from 
these two agencies are reprinted in appendixes I and II. We also 
received oral comments from staff of OMB's Office of General Counsel. 
GSA generally agreed with our discussion of the challenges hindering 
speedy deployment of the e-Authentication gateway, as well as our 
recommendations aimed at addressing these challenges. Regarding the 
agency's progress in developing the gateway, GSA requested that we 
include more information on recent developments. In response to this 
concern, we added information to the report to acknowledge these recent 
developments, as outlined by GSA in an attachment to its comments. OMB 
staff said the agency agreed with GSA's comments.

Regarding comments from NIST, officials generally agreed with the 
content of information and recommendations in the draft report. 
Officials requested that we update information on recently drafted 
authentication guidance. We updated this report accordingly.

:

Unless you publicly announce the contents of this report earlier, we 
plan no further distribution until 30 days from the report date. At 
that time, we will send copies of this report to the Ranking Minority 
Member, House Committee on Government Reform; to the Ranking Minority 
Member, Subcommittee on Technology, Information Policy, 
Intergovernmental Relations and the Census, Committee on Government 
Reform; and to other interested congressional committees. We will also 
send copies to the Director of OMB and the Administrator of GSA. Copies 
will be made available to others upon request. In addition, this report 
will be available at no charge on the GAO Web site at www.gao.gov.

Signed by:

If you have any questions concerning this report, please call me at 
(202) 512-6240 or send E-mail to koontzl@gao.gov. Other major 
contributors to this report included Barbara Collier, John de Ferrari, 
Vijay D'Souza, Steven Law, and Yvonne Vigil.


Signed by:

Linda D. Koontz Director, Information Management Issues:

[End of section]

Appendixes: 

[End of section]

Appendix I: Comments from the General Services Administration:

GSA Administrator:

August 11, 2003:

The Honorable David M. Walker Comptroller General of the United States 
The General Accounting Office:

441 G Street NW., 7Th Floor Washington DC 20548:

Dear Mr. Walker:

Thank you for the opportunity to respond to the General Accounting 
Office's (GAO) recent draft report regarding the General Services 
Administration's (GSA's) progress in implementing E-Authentication. In 
the September 2003 Draft Report entitled Planned E -Authentication 
Gateway Faces Formidable Challenges, the GAO offered a number of 
recommendations for the GSA Administrator and the Office of Management 
and Budget, in order that near-term milestones are met and that 
implementation challenges are fully met.

Because E-Authentication was tasked with serving all of the President's 
Management Agenda E-Gov initiatives, GSA considers the effort vital to 
the national interest. It is therefore important that the report 
accurately portray the progress made in the implementation as well as 
the challenges facing it. Continuing progress has been made so we ask 
that you accept recent developments for inclusion in your published 
report. For example, policies, frameworks, processes and procedures are 
under development simultaneously with system development and are at a 
more mature level than depicted in the draft report. We welcome GAO's 
recommendations to address the challenges that still lie before us.

The E-Authentication effort is a complex and difficult challenge, and 
is at the forefront of driving technical interoperability based on 
emerging industry standards. Despite this complexity, the E-
Authentication gateway was operational as of June 30, 2003, providing 
authentication services to five applications for the Social Security 
Administration, and it stands ready to interface to the Department of 
Homeland Security's Disaster Management Initiative. GSA is pleased with 
this progress but realizes there is still a long way to go to achieve 
the vision that the President's Management Council approved for this 
initiative.

Please find the enclosed GSA specific comments to the draft report 
findings and recommendations.

If you have any additional questions or need further assistance, please 
have a member of your staff contact Mary J. Mitchell, Associate Deputy 
Administrator, Office of Electronic Government and Technology, at (202) 
501-0202.

Sincerely,

Stephen A. Perry: 

Administrator: 

Signed by Stephen A. Perry: 

Enclosure:


[End of section]

Appendix II: Comments from the Department of Commerce:

THE SECRETARY OF COMMERCE 
Washington. D.C. 20230:

August 14, 2003:

Mr. Joel C. Willemssen:

Managing Director, Information Technology Issues United States General 
Accounting Office Washington, D.C. 20548:

Dear Mr. Willemssen:

Thank you for the opportunity to review and comment on the General 
Accounting Office (GAO) Draft Report GAO-03-952, Electronic Government: 
Planned E-Authentication Gateway Faces Formidable Development 
Challenges.

The Department of Commerce is pleased to offer comments that we believe 
will strengthen the report. We value the opportunity to contribute to 
the development of this technology and to help increase security for 
the Federal Government's many physical and information assets.

We look forward to your final report and will continue our efforts in 
support of the e-Authentication gateway throughout the Federal 
Government.

Sincerely,

Donald L. Evans: 

Signed by Donald L. Evans: 

Enclosure:

DEPARTMENT OF COMMERCE COMMENTS ON GAO DRAFT REPORT:

"Electronic Government: Planned E-Authentication Gateway Faces 
Formidable Development Challenges (GAO-03-952)":

We have the following comments:

1) To ensure that e -Authentication gateway implementation challenges 
are fully addressed, we recommend that the Administrator of GSA, in 
conjunction with the Director of OMB,

* Ensure that a comprehensive framework of authentication policies and 
procedures related to gateway operation is developed and implemented, 
in conjunction with NIST, the CIO Council and other federal agencies. 
The framework should include policies for auditing agencies and 
nongovernment organizations that will be linked to the gateway for 
compliance with applicable security, privacy, and credential 
requirements.

In our interview with GAO, NIST stressed the challenges of the guidance 
NIST is being asked to develop, and we want to reiterate that point. If 
a large company were implementing a corporate e-Authentication policy, 
they would be free to select a few specific, relatively mature 
authentication technologies and make their technical polices and 
standards specific to those specific technologies. It would be 
sufficient to tailor the selected approach to one solution of many. But 
in this effort and other security efforts NIST is constantly enjoined, 
often in legislation, to be technology independent, to develop 
performance standards and guidance that express performance 
requirements rather than design requirements, and that do not unduly 
constrain solutions, even new, immature solutions.

This is much more difficult. There is a wide range of authentication 
technologies available in the literature and the marketplace and it is 
not easy to compare and rank them all. These include:

* Symmetric key cryptography:

* Public key infrastructure:

* Smartcards and many other kinds of hardware identification tokens * 
PINs and passwords:

* Pass faces:

* "Knowledge-based" authentication * Biometrics:

Each of these has many variations. It is not terribly hard to select 
specific variants of these technologies and develop specific technical 
guidance that will ensure security in 
particular cases. It is much more challenging to develop technical 
guidance that encompasses the broad range of alternatives, and ideally 
accommodates future innovation. Passwords are widely used but 
problematic, and not well understood in some fundamental ways. On the 
other hand there is an urgent need to have guidance available soon. The 
NIST e-Authentication guidance may have to be iterative and probably 
developed piecemeal, with first attention given to the most widely used 
technologies. Any comprehensive framework of authentication policies 
will be evolutionary and may take some time to encompass the full range 
of technical possibilities. Passwords, PKI, and smartcards are the 
relatively common and mature technologies that we can build on first. 
There is a strong business case for using knowledge-based 
authentication, but in security terms it is much harder to evaluate, 
and we may have to address it in a second phase of the effort.

2) According to OMB, agencies must first identify the assurance levels 
associated with their planned e-government transactions and then refer 
to additional technical guidance to identify appropriate technical 
solutions. NIST has been tasked with developing this guidance, which 
would specify the types of technologies that could be used to conduct 
transactions at each of the OMB-defined assurance levels. A NIST 
official indicated that a working draft of this guidance likely would 
take several months to develop, and no specific milestone has yet been 
established for issuing the guidance.

NIST is working very closely and intensively with GSA in the e-
Authentication effort and on a Credential Assessment Framework GSA is 
developing to make an initial gateway capability available in the fall 
of 2003. This capability will not encompass the full range of e-
Authentication technologies, but will facilitate early implementation 
of e-Government applications. NIST expects to circulate a first draft 
of the overall NIST e-Authentication guidance in September 2003 for 
comment. Undoubtedly, both the guidance and the design of the gateway 
will continue to evolve for some time. This is inevitable in the 
rapidly evolving area of Web services and electronic service delivery.

[End of section]

Glossary:

[End of section]

Authentication:

The process of confirming an asserted identity with a specified or 
understood level of confidence.

Authorization:

The granting of appropriate access privileges to authenticated users.

Application Programming Interface:

An interface between the application software and the application 
platform (i.e., operating system), across which all services are 
provided.

Assurance level:

In the context of authentication, the level of confidence that the 
relying party has that an electronic identity credential is being 
presented by the person whose identity is asserted by the credential.

Biometrics:

Measures of an individual's unique physical characteristics or the 
unique ways that an individual performs an activity. Physical 
biometrics include fingerprints, hand geometry, facial patterns, and 
iris and retinal scans. Behavioral biometrics include voice patterns, 
written signatures, and keyboard typing techniques.

Certificate:

A digital representation of information that (1) identifies the 
certification authority issuing it; (2) names or identifies the person, 
process, or equipment that is the user of the certificate; (3) contains 
the user's public key; (4) identifies its operational period; and 
(5) is digitally signed by the certification authority issuing it. A 
certificate is the means by which a user is linked--"bound"--to a 
public key.

Certification Authority:

An authority trusted by one or more users to issue and manage digital 
certificates.

Confidentiality:

The assurance that information is not disclosed to unauthorized 
entities or processes.

Digital signature:

A special encrypted code, attached to an electronic message, that can 
be used to prove to a third party that the message was, in fact, signed 
by the originator. Digital signatures may also be attached to other 
electronic information and programs so that the integrity of the 
information and programs may be verified at a later time.

Electronic credentials:

The electronic equivalent of traditional paper-based credentials--
documents that vouch for an individual's identity.

Electronic credential providers:

Organizations, both governmental and nongovernmental, that issue and, 
in some cases, maintain electronic credentials.

Electronic government:

Government's use of technology, particularly Web-based applications, to 
enhance the access to and delivery of government information and 
services to citizens, business partners, employees, and other entities.

Federal Bridge Certification Authority:

A system of certification authorities, directories, certificate 
policies, and certification practice statements designed to provide 
interoperability among federal agency certification authorities.

Identification:

The process of determining to what identity a particular individual 
corresponds.

Interoperability:

The ability of two or more systems or components to exchange 
information and to use the information that has been exchanged.

Privacy:

The ability of an individual to decide when and on what terms elements 
of his or her personal information should be revealed.

Privacy Impact Assessment:

A process that helps departments and agencies determine whether new 
technologies, information systems, and initiatives meet basic privacy 
requirements.

Public key infrastructure (PKI):

A system of hardware, software, policies, and people that, when fully 
and properly implemented, can provide a suite of information security 
assurances--including confidentiality, data integrity, authentication, 
and nonrepudiation--that are important in protecting sensitive 
communications and transactions.

Risk:

The expectation of loss expressed as the probability that a particular 
threat will exploit a particular vulnerability with a particular 
harmful result.

Smart card:

A tamper-resistant security device--about the size of a credit card--
that relies on an integrated circuit chip for information storage and 
processing.

(310354):

FOOTNOTES

[1] Electronic credentials are the electronic equivalent of traditional 
paper-based credentials--documents that vouch for an individual's 
identity.

[2] E-government refers to the use of technology, particularly Web-
based Internet applications, to enhance the access to and delivery of 
government information and services to citizens, business partners, 
employees, and other entities. 

[3] Interoperability is the ability of two or more systems or 
components to exchange information and to use the information that has 
been exchanged.

[4] A PKI is a system of hardware, software, policies, and people that 
can provide a set of information assurances, including authentication, 
that are important in conducting electronic transactions. For more 
information on PKI, see U.S. General Accounting Office, Information 
Security: Advances and Remaining Challenges to Adoption of Public Key 
Infrastructure Technology, GAO-01-277 (Washington, D.C.: Feb. 26, 
2001).

[5] For more information on biometrics, see U.S. General Accounting 
Office, Technology Assessment: Using Biometrics for Border Security, 
GAO-03-174 (Washington, D.C.: Nov. 15, 2002).

[6] This discussion assumes that each of these hypothetical systems has 
been properly implemented and maintained. The level of assurance 
provided by any specific system is dependent on how well the system has 
been implemented and maintained. Further, a system's ability to 
successfully authenticate a given user does not provide direct 
assurance that the user's data are secure and reliable, because the 
user's system could have security weaknesses unrelated to user 
authentication.

[7] U.S. General Accounting Office, Technology Assessment: Using 
Biometrics for Border Security, GAO-03-174 (Washington, D.C.: Nov. 15, 
2002), p. 68.

[8] The OMB-sponsored e-government initiatives now number 25. In 2002, 
a decision was made to separate the e-Clearance initiative from the 
Integrated Human Resources initiative, resulting in an increase in the 
number of initiatives from 24 to 25.

[9] The Federal Bridge Certification Authority, which became 
operational in June 2001, facilitates PKI-based transactions across 
agencies.

[10] Gartner, Inc., is a research and advisory firm that provides 
technology-related consulting, research, and other services.

[11] The Software Engineering Institute at Carnegie Mellon University 
is a federally funded research and development center that provides 
services intended to improve the quality of automated systems and 
software development and maintenance practices.

[12] Office of Management and Budget, Implementing the President's 
Management Agenda for E-Government--E-Government Strategy (April 
2003).

[13] Office of Management and Budget, Procedures and Guidance on 
Implementing E-Authentication for Federal Agencies, Draft Version 15 
(Washington, D.C.: Mar. 28, 2003).

[14] For electronic authentication based on PKI technology, in 2000, 
OMB issued implementation guidance for the Government Paperwork 
Elimination Act, Public Law 105-277, Div. C, tit. XVII, directing 
agencies to consider using PKI for (1) transactions in which parties 
commit to actions or contracts that may give rise to financial or legal 
liability and (2) transactions that involve the transfer of funds. See 
Office of Management and Budget, Procedures and Guidance on 
Implementing the Government Paperwork Elimination Act, Memorandum M-00-
10 (Apr. 25, 2000), pp. 19-20.

[15] See U.S. General Accounting Office, D.C. Courts: Disciplined 
Processes Critical to Successful System Acquisition, GAO-02-316 
(Washington, D.C.: Feb. 28, 2002), p. 10.

[16] Leading companies use a disciplined review process during 
prototyping to assess design maturity and stability, as well as to 
ensure that user requirements are addressed. Stakeholder agreements are 
used to document user involvement in designing and evaluating 
prototypes and to better ensure that products work as intended. For 
more information, see U.S. General Accounting Office, Best Practices: 
Capturing Design and Manufacturing Knowledge Early Improves Acquisition 
Outcomes, GAO-02-701 (Washington, D.C.: July 15, 2002).

[17] E-Government Act of 2002, Public Law 107-347 (Dec. 17, 2002).	

[18] National Research Council of the National Academies, Committee on 
Authentication Technologies and Their Privacy Implications, Who Goes 
There? Authentication Through the Lens of Privacy, prepublication 
version (Washington, D.C.: Apr. 8, 2003).

[19] Office of Management and Budget, Memorandum--Procedures and 
Guidance on Implementing the Government Paperwork Elimination Act, M-
00-10 (Washington, D.C.: Apr. 25, 2000).