ASTM E1985-98(2005)
(Guide)Standard Guide for User Authentication and Authorization
Standard Guide for User Authentication and Authorization
SIGNIFICANCE AND USE
This guide has three purposes:
4.1.1 To serve as a guide for developers of computer software that provides or makes use of authentication and authorization processes,
4.1.2 To serve as a guide to healthcare providers who are implementing authentication and authorization mechanisms, and
4.1.3 To be a consensus standard on the design, implementation, and use of authentication and authorization mechanisms.
Additional standards will define interoperable protocols and message formats that can be used to implement these mechanisms in a distributed environment, using specific commercial technologies such as digital signatures.
SCOPE
1.1 This guide covers mechanisms that may be used to authenticate healthcare information (both administrative and clinical) users to computer systems, as well as mechanisms to authorize particular actions by users. These actions may include access to healthcare information documents, as well as, specific operations on those documents (for example, review by a physician).
1.2 This guide addresses both centralized and distributed environments, by defining the requirements that a single system shall meet and the kinds of information which shall be transmitted between systems to provide distributed authentication and authorization services.
1.3 This guide addresses the technical specifications for how to perform user authentication and authorization. The actual definition of who can access what is based on organizational policy.
General Information
Relations
Standards Content (Sample)
NOTICE: This standard has either been superseded and replaced by a new version or withdrawn.
Contact ASTM International (www.astm.org) for the latest information
Designation: E1985 − 98(Reapproved 2005) An American National Standard
Standard Guide for
User Authentication and Authorization
This standard is issued under the fixed designation E1985; the number immediately following the designation indicates the year of
original adoption or, in the case of revision, the year of last revision. A number in parentheses indicates the year of last reapproval. A
superscript epsilon (´) indicates an editorial change since the last revision or reapproval.
1. Scope FIPS PUB 112 Password Usage
1.1 This guide covers mechanisms that may be used to
3. Terminology
authenticate healthcare information (both administrative and
3.1 Definitions:
clinical) users to computer systems, as well as mechanisms to
3.1.1 access control list—a piece of access control
authorize particular actions by users. These actions may
information, associated with a target, that specifies the initia-
include access to healthcare information documents, as well as
tors who may access the target.
specific operations on those documents (for example, review
3.1.2 capability—a piece of access control information,
by a physician).
associated with an initiator, which authorizes the holder to
1.2 This guide addresses both centralized and distributed
access some target.
environments, by defining the requirements that a single
3.1.3 claimant—party requesting authentication; may be a
system shall meet and the kinds of information which shall be
person or a device.
transmitted between systems to provide distributed authentica-
tion and authorization services. 3.1.4 initiator—an entity (for example, a user) who requests
access to some object.
1.3 This guide addresses the technical specifications for
3.1.5 principal—legitimate owner of an identity.
how to perform user authentication and authorization. The
actual definition of who can access what is based on organi-
3.1.6 security label—access control information bound to
zational policy.
initiators and targets. The initiator and target labels are com-
pared to determine if access is allowed.
2. Referenced Documents
3.1.7 target—anentity(forexample,afileordocument)that
2.1 ASTM Standards:
may be accessed by an initiator.
E1762 Guide for Electronic Authentication of Health Care
3.1.8 verifier—another party seeking to authenticate princi-
Information
pal.
PS100 Provisional Specification for Authentication of
3.2 Acronyms:
Healthcare Information Using Digital Signatures
3.2.1 ACI—Access Control Information
2.2 ANSI Standard:
3.2.2 ACL—Access Control List
X9.45 Enhanced Management Controls Using Digital Sig-
natures and Attribute Certificates
3.2.3 ADF—Access Control Decision Function
2.3 Other Standards:
3.2.4 ADI—Access Control Decision Information
ECMA1-219 AuthenticationandPrivilegeAttributeSecurity
3.2.5 AEF—Access Control Enforcement Function
Applications with Related Key Distribution Functions
3.2.6 PIN—Personal Identification Number
4. Significance and Use
This guide is under the jurisdiction of ASTM Committee E31 on Healthcare
4.1 This guide has three purposes:
Informatics and is the direct responsibility of Subcommittee E31.25 on Healthcare
4.1.1 To serve as a guide for developers of computer
Data Management, Security, Confidentiality, and Privacy.
Current edition approved July 17, 2006. Published January 2006. Originally
software that provides or makes use of authentication and
approved in 1998. Last previous edition approved in 1998 as E1985 – 98. DOI:
authorization processes,
10.1520/E1985-98R05.
4.1.2 To serve as a guide to healthcare providers who are
For referenced ASTM standards, visit the ASTM website, www.astm.org, or
implementing authentication and authorization mechanisms,
contact ASTM Customer Service at service@astm.org. For Annual Book of ASTM
Standards volume information, refer to the standard’s Document Summary page on
and
the ASTM website.
Available from American National Standards Institute, 11 W. 42nd St., 13th
Floor, New York, NY 10036. Available from National Technical Information Service, U.S. Department of
Available from ECMA International, Rue du Rhone 114, CH, 1204, Geneva. Commerce, Springfield, VA. http://csrc.nist.gov or www.ntis.gov.
Copyright © ASTM International, 100 Barr Harbor Drive, PO Box C700, West Conshohocken, PA 19428-2959. United States
E1985 − 98 (2005)
4.1.3 To be a consensus standard on the design, implemen- claimant. The token shall contain information unique to the
tation, and use of authentication and authorization mecha- principal or claimant. The claimant shall present the token as
nisms. proof of identity. A password or PIN may be used to access
informationontoken.Theverifiershallthenverifythetokenof
4.2 Additional standards will define interoperable protocols
the claimant.
and message formats that can be used to implement these
5.4.2 The information shall be protected against duplication
mechanisms in a distributed environment, using specific com-
or theft.
mercial technologies such as digital signatures.
5.4.3 Determination of which type of form factor may be
used is based on risk assessment and organizational policy.
5. User Authentication
5.4.4 Theformfactorsmayincludebutarenotlimitedtothe
5.1 Authentication ensures the identity of a user. The
following:
legitimate owner of an identity is known as a principal.
5.4.4.1 Smart Card,
Authentication occurs when a claimant has presented a prin-
5.4.4.2 PCMCIA,
cipal’s identity and claims to be that principal. Authentication
5.4.4.3 Diskettes, and
allows the other party (verifier) to verify that the claim is
5.4.4.4 Hand held password or challenge response genera-
legitimate.
tors.
5.4.5 The form factors may also be used for cryptographic
5.2 Requirements:
5.2.1 Users shall be authenticated for access to health techniques.
information.
5.5 Physical Characteristic:
5.2.2 Users may be authenticated at the system, subsystem,
5.5.1 Certain physical features of the human body are
application, or medical record level.
relatively unique to an individual. These features are called
5.2.3 Users shall be authenticated by one or more of the
biometrics. Biometric authentication is the measurement of a
following methods based on organizational policy:
uniquebiologicalfeaturesusedtoverifytheclaimedidentityof
5.2.3.1 Claimant demonstrates knowledge of a password, or
aprincipal.Theclaimantshallpresentthebiometricasproofof
the like,
identity. The biometric may be stored on a token. A password
5.2.3.2 Claimant demonstrates possession of a token, or
or PIN may be used to access the biometric. The verifier shall
something similar,
then verify the biometric of the claimant.
5.2.3.3 Claimant exhibits some physical characteristic, like
5.5.2 Thebiometricshallbeprotectedagainstduplicationor
a fingerprint, and
theft.
5.2.3.4 Cryptographic techniques.
5.5.3 Determinationofwhichtypeofbiometricmaybeused
5.2.4 Remote access to health information shall be mutually
is based on risk assessment and organizational policy.
authenticated.
5.5.4 These biometrics include but are not limited to the
5.2.5 Determination of which method or methods to use for
following:
authentication shall be based on a risk assessment and organi-
5.5.4.1 Fingerprints,
zational policy.
5.5.4.2 Voice recognition,
5.2.6 For accountability purposes, authentication shall be
5.5.4.3 Retinal scan,
based upon an individual principal rather than upon a role.
5.5.4.4 Hand geometry,
5.3 Knowledge: 5.5.4.5 Signature dynamics or recognition, and
5.3.1 Password or Personal Identification Number:
5.5.4.6 Facial characteristics.
5.3.1.1 In any environment, a user can be authenticated
5.6 Cryptographic Techniques:
using a password or a personal identification number (PIN).
5.6.1 Authentication using cryptographic techniques are
The claimant shall enter a password or PIN for authentication
based on the principle of convincing a verifier that because a
purposes. The verifier shall then verify the password or PIN of
claimant possesses some secret key, the claimant is the
the claimant.
principal claimed. Symmetric or public key techniques may be
5.3.1.2 The password or PIN shall be protected against
used.
disclosure. For guidelines on password generation and usage
5.6.2 Symmetric Key— The principal and the verifier shall
see FIPS PUB 112.
shareasymmetrickey.Theclaimantshalleitherencryptorseal
5.3.1.3 In a multiple system environment, a single password
the information using that key. If the verifier can successfully
or PIN may be used for authentication.
decryptorverifythatthesealiscorrect,thentheclaimantisthe
5.3.2 Challenge-Response—Password or PIN-based
principal claimed to be. A non-repeating value may also be
schemes may be augmented by the challenge-response mecha-
used as part of the information encrypted.
nism. In challenge-response, as part of the authentication
5.6.3 Public Key—The principal shall have a public/private
protocol, the verifier sends the claimant a non-repeating value
key pair. The claimant digitally signs a challenge using his
(challenge) in advance. The claimant sends a response to the
private key. The verifier checks the digital signature, using the
verifier based on the challenge.
public key of the principal. If the signature checks correctly,
5.4 Possession: then the claimant is the principal that he claimed to be. A
5.4.1 The user or claimant shows possession by presenting non-repeatingvaluemayalsobeusedaspartoftheinformation
a physical object or token that is unique to the principal or signed. See also 5.3.2.
E1985 − 98 (2005)
5.6.4 A trusted on-line server may be used for authentica- example, user identities or roles) may be required. Although
tion. One of the following methods may be used: this guide does not dictate where each entity resides, it may be
5.6.4.1 The claimant shall encrypt or seal the health infor- possible to make use of existing operating system access
mation with his or her key. A separate exchange with the control mechanisms if the AEF and ADF reside on the same
authentication server shall be used for verification. The verifier system as the target.
and the authentication server shall use a shared key.
6.2.2 A variety of access control mechanisms have been
5.6.4.2 The claimant shall first conduct an exchange with
defined, each of which is appropriate for particular environ-
the authentication server to obtain a ticket which is then passed
ments. These include:
to the verifier. The exchange between the claimant and authen-
6.2.2.1 Access control lists (ACLs) are associated with a
tication server shall be protected using a shared key. The ticket
target and list the initiators which may access the target.ACLs
shall be constructed in such a way that will be acceptable only
might list individual user identities, as well as names of groups
to an entity knowing the shared key between the verifier and
of users, and roles. Using groups and roles can minimize the
the authentication server. An example of this is the Kerberos
size of the ACL. Many operating systems support ACLs. In a
system.
distributed environment, some method for verifying the iden-
5.6.5 When using the public key cryptography, an off-line
tity of a remote initiator (for example, a public key certificate)
server may be used for authentication. Verifiers shall need to
is needed in order to provide remote access. ACLs are
obtain the certified public keys of principals and certificate
particularly appropriate when the number of targets is very
revocation lists.
large compared to the number of initiators.
6.2.2.2 Capabilities are associated with an initiator and
6. Authorization
specify the targets that may be accessed. Targets might be
combined into groups in order to minimize the size of
6.1 Requirements:
capabilities. In some cases (for example, a patient record),
6.1.1 Three types of authorization are required based on
targets are hierarchically structured so that a capability might
organizational policy:
grant access to the “root” object and all subordinates. In other
6.1.1.1 Users shall be authorized to access (read or write)
cases, independent targets (for example, all patients on a ward)
healthcare information documents;
can be combined into a group, as discussed below. Few
6.1.1.2 Users shall be authorized to perform application-
operating systems implement capabilities. However, in a dis-
specific actions on a document (for example, physician re-
tributed environment, there is a great deal of work using
view); and
certificates to bind access control and other information to a
6.1.1.3 Users shall be able to determine whether all neces-
user’s identity (see, for example, ANSI X9.45). Such certifi-
sary actions have been performed on the document, and
cates can be used to specify such capabilities.
whether the users performing these actions were allowed to do
so, according to any rules and limits agreed to by the parties
6.2.2.3 Security labels are associated with both the initiator
involved.Forexample,itmaybearequirementthatdocuments and the target and are compared by the ADF to determine if
shall be reviewed by a physician prior to inclusion in the
access is allowed. Labels were developed for the military
medical record. environment and typically contain a security classification.An
6.1.2 A user’s application-specific action on a document
initiator may, then, read a target if the initiator’s classification
will be indicated using an electronic signature, as defined in dominates (is greater than) that of the target. Labels are useful
Guide E1762. Particular actions are indicated using signature if there are many initiators and targets, but only a coarse
purposes. Thus, signatures are applied in 6.1.1.2, and verified granularity of access (that is, a classification) is needed.
in 6.1.1.3. Generic access as described in 6.1.1.1 may be
6.2.2.4 The mechanisms in 6.2.2.1-6.2.2.3 may, of course,
indicated using signatures, but this is not a requirement. This
be combined, so that, for example, a user shall have an
type of access may be needed to perform the specific actions of
appropriate classification, and be on anACL, in order to access
6.1.1.2.
a file.
6.2.3 Access control policies may be rule-based, in which
6.2 Access Control:
case the policy is specified and enforced by the authority
6.2.1 In a distributed environment, the following entities
responsible for a security domain, or identity-based, in which
canbeidentified:theinitiatorwishestoaccesssomeobject:the
case individual users control access to their own information.
target. Access is mediated by an access control enforcement
Rule-based policies may be automatically enforced; one ex-
function (AEF), that uses an access control decision function
ample is a multi-level security policy using classifications.
(ADF) to determine whether access is to be gr
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.