ASTM E1985-98
(Guide)Standard Guide for User Authentication and Authorization
Standard Guide for User Authentication and Authorization
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
An American National Standard
Designation:E1985–98
Standard Guide for
User Authentication and Authorization
This standard is issued under the fixed designation E 1985; 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 (e) indicates an editorial change since the last revision or reapproval.
1. Scope FIPS PUB 112 Password Usage
FIPS PUB 181 Automated Password Generator
1.1 This guide covers mechanisms that may be used to
FIPS PUB 190 Guideline for Use of Advanced Authentica-
authenticate healthcare information (both administrative and
tion Technology Alternatives
clinical) users to computer systems, as well as mechanisms to
authorize particular actions by users. These actions may
3. Terminology
include access to healthcare information documents, as well as
3.1 Definitions:
specific operations on those documents (for example, review
3.1.1 access control list—a piece of access control informa-
by a physician).
tion, associated with a target, that specifies the initiators who
1.2 This guide addresses both centralized and distributed
may access the target.
environments, by defining the requirements that a single
3.1.2 capability—a piece of access control information,
system shall meet and the kinds of information which shall be
associated with an initiator, which authorizes the holder to
transmitted between systems to provide distributed authentica-
access some target.
tion and authorization services.
3.1.3 claimant—party requesting authentication; may be a
1.3 This guide addresses the technical specifications for
person or a device.
how to perform user authentication and authorization. The
3.1.4 initiator—an entity (for example, a user) who requests
actual definition of who can access what is based on organi-
access to some object.
zational policy.
3.1.5 principal—legitimate owner of an identity.
2. Referenced Documents 3.1.6 security label—access control information bound to
initiators and targets. The initiator and target labels are com-
2.1 ASTM Standards:
pared to determine if access is allowed.
E 1762 Guide for Electronic Authentication of Healthcare
3.1.7 target—an entity (for example, a file or document)
Information
that may be accessed by an initiator.
PS 100 Provisional Specification for Authentication of
2 3.1.8 verifier—another party seeking to authenticate princi-
Healthcare Information Using Digital Signatures
pal.
2.2 ANSI Standard:
3.2 Acronyms:
X9.45 Enhanced Management Controls Using Digital Sig-
3.2.1 ACI—Access Control Information
natures and Attribute Certificates
3.2.2 ACL—Access Control List
2.3 ISO Standard:
3.2.3 ADF—Access Control Decision Function
ISO 10181-3 1994: Security Frameworks in Open
4 3.2.4 ADI—Access Control Decision Information
Systems—Access Control Framework
3.2.5 AEF—Access Control Enforcement Function
2.4 Other Standards:
3.2.6 PIN—Personal Identification Number
ECMA1-219 Authentication and Privilege Attribute Secu-
rity Applications with Related Key Distribution Func-
4. Significance and Use
tions
4.1 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
This guide is under the jurisdiction of ASTM Committee E-31 on Healthcare
authorization processes,
Informatics and is the direct responsibility of Subcommittee E31.20 on Data System
4.1.2 To serve as a guide to healthcare providers who are
Security for Health Information.
implementing authentication and authorization mechanisms,
Current edition approved Oct. 10, 1998. Published November 1998.
and
Annual Book of ASTM Standards, Vol 14.01.
Available from American National Standards Institute, 11 W. 42nd St., 13th
Floor, New York, NY 10036.
Available from ISO, 1 Rue de Varembe, Case Postale 56, CH 1211, Geneve,
Switzerland. Available from National Technical Information Service, U.S. Department of
Available from ECMA. 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
4.1.3 To be a consensus standard on the design, implemen- proof of identity. A password or PIN may be used to access
tation, and use of authentication and authorization mecha- informationontoken.Theverifiershallthenverifythetokenof
nisms. the claimant.
4.2 Additional standards will define interoperable protocols 5.4.2 The information shall be protected against duplication
and message formats that can be used to implement these
or theft.
mechanisms in a distributed environment, using specific com-
5.4.3 Determination of which type of form factor may be
mercial technologies such as digital signatures.
used is based on risk assessment and organizational policy.
5.4.4 Theformfactorsmayincludebutarenotlimitedtothe
5. User Authentication
following:
5.1 Authentication ensures the identity of a user. The
5.4.4.1 Smart Card,
legitimate owner of an identity is known as a principal.
5.4.4.2 PCMCIA,
Authentication occurs when a claimant has presented a prin-
5.4.4.3 Diskettes, and
cipal’s identity and claims to be that principal. Authentication
5.4.4.4 Hand held password or challenge response genera-
allows the other party (verifier) to verify that the claim is
tors.
legitimate.
5.4.5 The form factors may also be used for cryptographic
5.2 Requirements:
techniques.
5.2.1 Users shall be authenticated for access to health
5.5 Physical Characteristic:
information.
5.5.1 Certain physical features of the human body are
5.2.2 Users may be authenticated at the system, subsystem,
relatively unique to an individual. These features are called
application, or medical record level.
biometrics. Biometric authentication is the measurement of a
5.2.3 Users shall be authenticated by one or more of the
uniquebiologicalfeaturesusedtoverifytheclaimedidentityof
following methods based on organizational policy:
aprincipal.Theclaimantshallpresentthebiometricasproofof
5.2.3.1 Claimant demonstrates knowledge of a password, or
identity. The biometric may be stored on a token. A password
the like,
or PIN may be used to access the biometric. The verifier shall
5.2.3.2 Claimant demonstrates possession of a token, or
then verify the biometric of the claimant.
something similar,
5.5.2 Thebiometricshallbeprotectedagainstduplicationor
5.2.3.3 Claimant exhibits some physical characteristic, like
theft.
a fingerprint, and
5.5.3 Determinationofwhichtypeofbiometricmaybeused
5.2.3.4 Cryptographic techniques.
is based on risk assessment and organizational policy.
5.2.4 Remote access to health information shall be mutually
5.5.4 These biometrics include but are not limited to the
authenticated.
following:
5.2.5 Determination of which method or methods to use for
5.5.4.1 Fingerprints,
authentication shall be based on a risk assessment and organi-
5.5.4.2 Voice recognition,
zational policy.
5.5.4.3 Retinal scan,
5.2.6 For accountability purposes, authentication shall be
5.5.4.4 Hand geometry,
based upon an individual principal rather than upon a role.
5.5.4.5 Signature dynamics or recognition, and
5.3 Knowledge:
5.5.4.6 Facial characteristics.
5.3.1 Password or Personal Identification Number:
5.6 Cryptographic Techniques:
5.3.1.1 In any environment, a user can be authenticated
5.6.1 Authentication using cryptographic techniques are
using a password or a personal identification number (PIN).
based on the principle of convincing a verifier that because a
The claimant shall enter a password or PIN for authentication
claimant possesses some secret key, the claimant is the
purposes. The verifier shall then verify the password or PIN of
principal claimed. Symmetric or public key techniques may be
the claimant.
used.
5.3.1.2 The password or PIN shall be protected against
5.6.2 Symmetric Key— The principal and the verifier shall
disclosure. For guidelines on password generation and usage
shareasymmetrickey.Theclaimantshalleitherencryptorseal
see FIPS PUB 112.
the information using that key. If the verifier can successfully
5.3.1.3 In a multiple system environment, a single password
decryptorverifythatthesealiscorrect,thentheclaimantisthe
or PIN may be used for authentication.
principal claimed to be. A non-repeating value may also be
5.3.2 Challenge-Response—Password or PIN-based
used as part of the information encrypted.
schemes may be augmented by the challenge-response mecha-
nism. In challenge-response, as part of the authentication 5.6.3 Public Key—The principal shall have a public/private
key pair. The claimant digitally signs a challenge using his
protocol, the verifier sends the claimant a non-repeating value
(challenge) in advance. The claimant sends a response to the private key. The verifier checks the digital signature, using the
public key of the principal. If the signature checks correctly,
verifier based on the challenge.
5.4 Possession: then the claimant is the principal that he claimed to be. A
non-repeatingvaluemayalsobeusedaspartoftheinformation
5.4.1 The user or claimant shows possession by presenting
a physical object or token that is unique to the principal or signed. See also 5.3.2.
claimant. The token shall contain information unique to the 5.6.4 A trusted on-line server may be used for authentica-
principal or claimant. The claimant shall present the token as tion. One of the following methods may be used:
E1985–98
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
6.2.2.3 Security labels are associated with both the initiator
so, according to any rules and limits agreed to by the parties
and the target and are compared by the ADF to determine if
involved.Forexample,itmaybearequirementthatdocuments
access is allowed. Labels were developed for the military
shall be reviewed by a physician prior to inclusion in the
environment and typically contain a security classification.An
medical record.
initiator may, then, read a target if the initiator’s classification
6.1.2 A user’s application-specific action on a document
dominates (is greater than) that of the target. Labels are useful
will be indicated using an electronic signature, as defined in
if there are many initiators and targets, but only a coarse
Guide E 1762. Particular actions are indicated using signature
granularity of access (that is, a classification) is needed.
purposes. Thus, signatures are applied in 6.1.1.2, and verified
6.2.2.4 The mechanisms in 6.2.2.1-6.2.2.3 may, of course,
in 6.1.1.3. Generic access as described in 6.1.1.1 may be
be combined, so that, for example, a user shall have an
indicated using signatures, but this is not a requirement. This
appropriate classification, and be on anACL, in order to access
type of access may be needed to perform the specific actions of
a file.
6.1.1.2.
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 granted. This
Non-hierarchical policies may be constructed by assigning
decision is based on access control decision information (ADI)
initiators and targets to compartments. Note that in either case,
associate
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.