[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[atlarge-discuss] Spcl Attn. VR committee - Verification and Authentication NIST standards and president's directive



All fellow members and VR committee members,

  The following is a email received via the DOC's NIST:

============== Copy of contents in part follows=========

Jeff,

  Thank you and your members of your organization for aiding
in the development and furtherance of the developing standard
required by the presidents directive of September 2000 for
Authentication and Verification standards.  You may also
wish to, and it would be advised for you to forward the
most important element along to the At-large organization
you are involved with and attempting to shepherd.

Kindly,
B.  Burr NIST
Manager, Security Technology Group

===========  End of copy ==============

Here is the information attached as relevant.

" Information Sharing and the Privacy Act

    When developing authentication processes, agencies must consider
the requirements for managing security in the collection and storage
of information associated with the process of validating a user's
identity. As required by the E-Government Act of 2002 (Public Law
107-347), section 208, 44 U.S.C. Sec.  3604, agencies are required
to conduct privacy impact assessments for electronic information
systems and collections, which includes when authentication
technology is newly applied to an electronic information system.
    The following information is captured in most e-authentication
processes:
    [sbull] Information regarding the individuals/ businesses/
governments using the E-Gov service.
    [sbull] Electronic user credentials (i.e., some combination of
public key certificates, user identifiers, passwords, and Personal
Identification Numbers).
    [sbull] Transaction information associated with user
authentication, including credential validation method.
    [sbull] Audit Log/Security information.
    Some of this information includes personal information as
defined by the Privacy Act and, systems that use the information are
considered systems of records that must meet all requirements of the
Privacy Act and the E-Government Act.
    Data collected and stored during the authentication process
should only be accessible routinely to systems administrators and to
auditors. As required by the Privacy Act, access to the system of

[[Page 41374]]

records must be provided to registered users to allow them to see
and/or change personal information about them maintained in the
system of records. Information from the system of records should not
be shared routinely outside of legitimate needs as permitted or
required by law for the administration and control of the
authentication process.
    In order to authenticate a user, it may be necessary for an
agency providing an E-Gov service to obtain additional information
about that user through the CSP that issued the user his/her
credential. In such a case, the CSP must ask the user for permission
and be granted that permission by the user to provide the specified
information to the e-gov service provider. Disclosure of the
additional information by the CSP to the e-gov application or
service may also be established prior to the time of the
transaction, if it is outlined in the terms of the relationship
between the user and the CSP.

4.4. Cost Considerations

    In most cases, higher levels of assurance require more costly
credentials; however minimizing the number of credentials can create
cost savings. Section 3 of the GPEA guidance provides additional
information on assessing risks, costs, and benefits. In-person
proofing is most likely more expensive. The e-authentication
technical guidance will provide alternatives for addressing some of
the authentication levels that may help agencies to better manage
the costs of authentication.

4.5. Relationship to Other Guidance

4.5.1. Federal Bridge Certification Authority


    Federal Bridge levels will be mapped to the assurance levels
described in this document. Since these assurance levels take into
account a wide range of authentication solutions, the levels
described in this guidance differ from the levels established by the
Federal Bridge Certification Authority (FBCA) Certificate Policy.
For example, levels 1 and 2 in this e-authentication policy are
primarily reserved for non-cryptographic authentication solutions
not covered by the FBCA. However, it is likely that some public key
infrastructure (PKI) solutions and the FBCA Rudimentary Certificate
Policy will map to level 1 or level 2. The FBCA Basic Certificate
Policies and the FBCA Medium Certificate Policies will fall in level
3, while FBCA High Certificate Policy will fall into level 4.

4.5.2. Federal Information Processing Standards Publication 199

    While this E-Authentication Guidance addresses the consequential
risk in making an authentication error, NIST is in the process of
developing much broader risk levels for Federal information and
Information Systems. NIST is in the process of developing a Federal
Information Processing Standards Publication (FIPS) 199, ``Standards
for Security Categorization of Federal Information and Information
Systems'' promulgated under the E-Government Act of 2002 (Public Law
107-347). The standards establish three levels of risk (low,
moderate, and high) for each of the stated security objectives
(confidentiality, integrity, and availability) relevant to securing
Federal information and information systems.
    It is expected that these levels established in FIPS 199 will
map to the levels in the e-authentication guidance. When an
authentication error might cause a loss of confidentiality,
integrity or availability, then--
    [sbull] If the risk as defined in FIPS 199 is low,
authentication assurance levels 1 through 4 are sufficient;
    [sbull] If the risk as defined in FIPS 199 is moderate,
authentication assurance level 3 or 4 should be used; and
    [sbull] If the risk as defined in FIPS 199 is high,
authentication assurance level 4 should be used.

5. Effective Dates of This Guidance

    The Effective Dates for this guidance is 30 days after issuance
as final policy. Additional information can be found in the
supplemental information above."

Further information can be found on the federal Registry
noted in the following format.

[FR Doc. 03-17634 Filed 7-10-03; 8:45 am]

Regards,

--
Jeffrey A. Williams
Spokesman for INEGroup LLA. - (Over 131k members/stakeholders strong!)
"Be precise in the use of words and expect precision from others" -
    Pierre Abelard
===============================================================
CEO/DIR. Internet Network Eng. SR. Eng. Network data security
Information Network Eng. Group. INEG. INC.
E-Mail jwkckid1@ix.netcom.com
Contact Number: 214-244-4827 or 214-244-3801

---------------------------------------------------------------------
To unsubscribe, e-mail: atlarge-discuss-unsubscribe@lists.fitug.de
For additional commands, e-mail: atlarge-discuss-help@lists.fitug.de