Jim Dray

NIST

February 9, 1996

Jim Dray, National Institute of Standards and Technology
Computer Security Division, Bldg 820, Rm 411
820 West Diamond St, Gaithersburg, MD 20899
jdray@nist.gov, 301-975-3356, fax 301-948-1233

	       SPECIFICATION FOR THE PROPOSED NIST

	     AUTHENTICATION MODULE INTERFACE STANDARD





		 *****  PRELIMINARY DRAFT  *****



			February 9, 1996







			TABLE OF CONTENTS





1.      INTRODUCTION ....................................... aa



2.      CONFORMANCE ........................................ bb



3.      DESIGN GOALS ....................................... cc



4.      SYSTEM MODEL ....................................... dd



	4.1     Data Objects ............................... ee

		4.1.1   Client Credentials Object Class .... ff

		4.1.2   Client Session Object Class ........ gg

	4.2     Multiple Authentication Sessions ........... hh

	4.3     Security Administration Issues ............. ii



5.      FUNCTIONAL SPECIFICATION ........................... jj



	5.1     Function Index ............................. kk

	5.2     Notation ................................... ll

	5.3     Functional Specification ................... mm



APPENDIX A - Example Authentication Sequences .............. nn



APPENDIX B - Example ASN.1 Encoding of AMI Message Set ..... oo



1.      INTRODUCTION



This standard provides the specification for a general purpose

interface between an authentication module and any entity

communicating with the module.  An authentication module may

consist of software, hardware, or a combination of both.  The

primary functions of an authentication module are to collect

authentication data from a human user or other claimant in a

distributed computing environment, verify the identity of the

claimant based on this data, and convey this decision to other

entities in a secure manner.  In some cases, the authentication

module may act as both claimant and verifier on behalf of locally

authenticated entities in mutual authentication exchanges.  Some

example authentication modules include the software component of

an operating system which retrieves and verifies passwords, a

portable authentication token, and a biometric authentication

device.





2.      CONFORMANCE



Conformance to the standard does not require implementation of

all specified functions; authentication module designers may add

functions which extend the core specification in a manner

consistent with the conventions of the standard, or choose a subset

thereof to match the capabilities of a particular technology.

Authorization and access control issues are outside the scope of

this standard.





3.      DESIGN GOALS



Two primary criteria were used in the design of the

Authentication Module Interface (AMI).  First, the functionality

provided by the interface supports a general set of

authentication processes which are applicable to as broad a range

of authentication modules as possible.  These processes include

support for multiple concurrent authentication sessions, entity

authentication based on the exchange of static or dynamic

authentication data, symmetric, asymmetric or hash based

cryptographic authentication techniques, unilateral and bilateral

exchanges.  Support for device specific system administration and

maintenance functions is not included in the AMI since these

functions are implementation dependent.



Placement of the AMI at a specific layer within a multilayer

architecture is the second design criterion.  The AMI resides

immediately above the highest level communications layer of the

interface stack between application level programs and

authentication modules, allowing applications to communicate with

these modules with minimal concern for communications protocols

and hardware differences.  Conceptually, the AMI is the dividing

line between layers involved in the security context of messages

and lower level layers that perform communications functions.



FIGURE - Layered Interface Model





4.      SYSTEM MODEL



The scope of this standard is restricted to specification of the

interface between an authentication module and other entities.

However, the primary purpose of the functions which comprise the

AMI is to instruct an authentication module to perform operations

which involve data objects stored within the module.  It is

therefore necessary to provide a logical description of these

data objects from the perspective of the interface.  The low

level format and details of the internal manipulation of these

objects are not relevant to the interface specification and are

beyond the scope of this standard.



4.1     Data Objects



FIGURE - User -- Host -- AM [CSO - CCO]



The AMI specification is based on a conceptual model of the

authentication process with three primary object classes.  These

include Module Information, Client Credentials, and Client

Session classes. There is generally one instance of the Module

Information object for a given authentication module, which

contains information about the configuration and current

operational status of the module.  The Module Information object

is not directly related to authentication processes and will not

be discussed in detail.



Client Credentials objects are created for each client that

registers with a given module, and these objects exist for the

life of the module or until explicitly terminated.  Client

Session objects are created when a registered client

authenticates successfully to the module, and terminate when the

client's authentication session ends or the module is reset.

Authentication modules must be able to distinguish between

security administrators and other clients, since security

administrators will have a unique set of privleges in most

implementations.



4.1.1   Client Credentials Object Class



Authentication modules will contain one Client Credentials

object for each registered client identity.  The AMI places no

restriction on the number of unique identities that can be

assigned to one client, since the number of identities that a

client can assume is a policy issue that will vary from system to

system.  The Client Credentials class allows for the binding of

static authentication data (i.e. passwords and cryptographic

keys) to the identity of one client. Client Credentials objects

are created by a security administrator through a registration

process that associates labeled static authentication data with a

client name.  The identity of the security administrator who created a

Client Credentials object is contained in the object, so that the

authentication module can enforce appropriate controls for

subsequent security administration procedures involving the

object.  A Client Credentials object is therefore owned by both

the client and the security administrator who initially created the

object.



4.1.2   Client Session Object Class



A client may authenticate to the module through a variety of

mechanisms involving passwords and/or cryptographic keys, as

determined by the capabilities of a given implementation.

Successful authentication of a client shall result in the

creation of a Client Session object linked to that client's

identity and logically separate from all other Client Session

objects.  Likewise, an authentication module may prove the

identity of a client with a valid authentication session to

another entity through a variety of mechanisms.  It is expected

that not all module implementations will support all

authentication mechanisms; entities can determine which

mechanisms a given module implements from the output of the

Status function.  Client Session objects shall exist for the time

period specified in the Lifetime (L) field or until explicitly

terminated.



Once a Client Session object is created, the mechanism used to

prove the client's identity to another entity depends on the

degree of coupling between the authentication module and the

other entity.  For example, a software module which uses static

passwords for authentication may be an integral component of the

operating system on a workstation.  Because the authentication

module is tightly integrated with other components of the

operating system, these components can access the Client Session

objects directly to determine the authentication status of

various clients.  No further effort beyond the creation and

termination of Client Session objects is required of the

authentication module to communicate authentication status.



In a loosely coupled authentication system, more sophisticated

methods are used to communicate authentication status.  As an

example, some authentication modules are physical tokens

containing a microprocessor and memory.  Clients first

authenticate to the token through submission of a password and

physical possession of the token, and then use the token to prove

identity to other entities.  In these situations, entities

outside the boundaries of the token do not have direct access to

Client Session objects within the token.  The token must

communicate the existence of a valid Client Session object to

outside entites upon request in a secure manner.  This process

requires a formal exchange between the token and the outside

entity through the AMI, which may also involve authentication of

the entity to the token to assure the client of the entity's

identity (bidirectional authentication).



4.2     Multiple Authentication Sessions



The AMI supports multiple concurrent authentication sessions

through the use of an optional client label and digital signature

included in each message as subfields of the CMDx field.  These

fields are optional because single session authentication modules

do not need to differentiate between users.  However,

multisession modules must have a mechanism for associating

messages with the appropriate session. The client label

identifies the source of the message, and the digital signature

proves this identity and provides message integrity.  This

process is equivalent to continuous re-authentication on a per

message basis.  If used, the signature value will be calculated

on the entire message excluding the signature itself.



This standard does not specify the internal mechanisms that a

multi-session authentication module will use to isolate client

session objects from each other; these mechanisms will generally

be provided by a multitasking operating system or equivalent.



FIGURE - Multi-Session Authentication Modules





4.3     Security Administration Issues



Security models which differentiate between the roles of security

administrator and other clients imply the presence of mechanisms

to enforce this distinction.  The initial registration of a

security administrator is a potential problem because most

security systems do not have knowledge that would allow them to

distinguish between a legitimate security administrator and any

other entity prior to installation and use.  These systems are

generally installed in an uninitialized state, and information

which allows the system to identify the security administrator(s)

is loaded as one of the first steps after the system becomes

operational.  The system is therefore in a vulnerable state for

some period of time before a valid security administrator's

credentials are loaded, since anyone with physical access to the

system could in fact become the security administrator by loading

security administrator credentials into the authentication

module.  The AMI cannot protect against such attacks;

organizational policies which restrict access to the system prior

to the registration of a valid system security administrator must

be enforced.





5.      FUNCTIONAL SPECIFICATION



5.1     Function Index



	5.2.1   Reset           General device reset.

	5.2.2   Reset_CS        Reset a specific Client session.

	5.2.3   Status          Return current device status.

	5.2.4   Bind_EF         Set execution sequence for a

				    client.

	5.2.5   Bind_LF         Bind message mnemonic.

	5.2.6   Bind_ADS        Bind static authentication data

				    to a client identity.

	5.2.7   Generate_ADS    Generate static authentication

				    data.

	5.2.8   Verify_ADS      Compare static authentication

				    data to previously stored

				    value.

	5.2.9   Return_ADS      Return static authentication

				    data.

	5.2.10  Delete_ADS      Delete previously stored static

				    authentication data.

	5.2.11  Accept_ADD      Receive dynamic authentication

				    data for processing.

	5.2.12  Generate_ADD    Generate dynamic authentication

				    data.



5.2     Notation



The notation used to specify data elements for each function is

an extension of the notation used in the current draft of FIPS

standard JJJ for public key cryptographic entity authentication

mechanisms.  The vertical bar symbol "|" represents concatenation

of data fields to form a message string.  Functions within an

authentication module are invoked through the interface by

passing a message string to the module. CMDx (i.e. CMD1,

CMD2,...) is a compound field containing the function name,

client name, and signature value.  The client name and signature

values are optional fields because they are not relevant to

single user modules.  In the interest of generality, message

formats are not specified at the bit level.



The module's response to a message consists of a positive (+) or

negative (-) acknowledgement with an optional error code field

ECODE.  In come cases a data field RDATA is included in the response.



Abbreviations for field names:



	CMDx:   Message field containing the function label,

		  optional client name and digital signature



	ADD:    Dynamic authentication data



	ADDL:   Dynamic authentication data label



	ADS:    Static authentication data



	ADSL:   Static authentication data label



	ADT:    Authentication data type (password, key, etc.)



	L:      Lifetime for a Client Session object



	ECODE:  Optional error code response field



	RDATA:  Response data field



	+/-:    Positive/negative response



5.3     Functional Specification



5.3.1   Reset



Format : CMD1



Objects : Client Session (all instances)



Return : +/- [| ECODE]



Reset the module to a power-on state, clearing all temporary

data.  This message terminates all active Client Session objects.

The session identifier component of the CMD1 string is present

but has no meaning since this message affects all sessions.



5.3.2   Reset_CS



Format : CMD2



Objects : Client Session



Return : +/- [| ECODE]



Terminate authentication session for specific client.



5.3.3   Status



Format : CMD3



Objects : Module Configuration



Return : +/- [| ECODE] | RDATA



Return information about the current status of all authentication

sessions and type of the device in RDATA.  The session identifier

component of the CMD1 string is present but has no meaning since

this message does not affect individual sessions.



For the Status message, RDATA contains two subfields:

Implementation-Dependent Data (IID) and

Implementation-Independent Data (IDD).  The content of the IDD

subfield is not defined by this standard. The IID subfield

contains the following information:



	1.  Client identifier for each existing Client Session

	      Object



	2.  Logical machine state for the authentication module



	3.  Authentication mechanisms supported





5.3.4   Bind_EF



Format : CMD4 | CMDA | CMDB [| CMDC | CMDE ...]



Objects : Client Credentials, Client Session



Return : +/- [| ECODE]



Set the execution sequence of functions for a client.  The

function of highest precedence is CMDA in the list.  Once this

sequence has been set, the client cannot execute a specified

function until the required preceeding function(s) in the list

have been executed successfully.



5.3.5   Bind_LF



Format : CMD5 | CMDA | CMDB



Objects : Function Labels



Return : +/- [| ECODE]



Bind the function currently labeled CMDA to the new label CMDB.

Some implementations will use a static command label binding,

whereby the label format is predetermined and cannot be changed.

In these cases, this function will return an error code

indicating that the attempted label binding failed because the

authentication module supports only static binding.



For implementations that use dynamic command label binding, it is

recommended that functions should be initially referenced by

ordinal value (1-13) as defined in this standard for reasons of

interoperability.  Although mnemonic function labels are used in

the standard for convenience, they are not mandatory. The session

identifier component of the CMD1 string is present but has no

meaning since this message affects all sessions.  This message

requires an active Client Session Object for the security

administrator.



NOTE:  This function may be removed in future revisions of the

AMI specification, since an implementation is free to use any

command labeling convention it chooses.  Dynamic labeling would

only be of use in situations where labels need to be loaded as

part of the authentication module initialization process, or when

it is anticipated that the label format might change during the

lifetime of the module.  This might be necessary if, for example,

an authentication module were used with multiple host systems

having different label conventions.



5.3.6   Bind_ADS



Format : CMD6 | ADSL | ADS | ADT



Objects : Client Credentials



Return : +/- [| ECODE]



Associate static authentication data ADS of type ADT

with specified client.  The ADSL field contains the name

that will be used to index the authentication data.  The

type specified by ADT shall be associated with the authentication

data ADS within a Client Credentials Object.  The authentication

module will use the authentication data type to determine which

comparison algorithm to use in subsequent authentications.  For

example, the ADT field might contain the ASCII string

"Biometric:Voiceprint:AlgorithmXY".  The authentication module

would then know that ADS contains voiceprint data that will be

compared against live scan data using AlgorithmXY as requested.

Static data marked as cryptographic keys shall only be used as

such.



5.3.7   Generate_ADS



Format : CMD7 | ADSL | ADT [| L]



Objects : Client Credentials



Return : +/- [| ECODE]



Generate static authentication data of type ADT (password, crypto

key) and associate with specified client.  ADSL contains the name

used to index the static authentication data.  Generation of

static authentication data shall be in accordance with applicable

Federal Standards for password and key generation, and the static

authentication data shall exist for the lifetime specified in the

optional L field if present.



5.3.8   Load_ADS



Format : CMD7B | ADSL | ADS | ADT | E [| ADSL2] [| L]



Objects : Client Credentials



Return : +/- [| ECODE]



Receive static authentication data ADSL | ADS of type ADT

(password, crypto key) and associate with specified client.  ADSL

contains the name used to index the static authentication data.

If cryptographic protection is indicated by the E field, the

optional ADSL2 field contains the name of the cryptographic key

to be used.  This function may create a Client Credentials

object, in which case a security administrator Client Session object

must exist.  If created, the Client Session object shall exist

for the lifetime specified in the optional L field if present.



5.3.9   Verify_ADS



Format : CMD8 | ADSL | ADS | L | E [| ADSL2] [| L]



Objects : Client Session



Return : +/- [| ECODE]



Receive static authentication data ADSL | ADS for specified

client. Perform appropriate comparison of static authentication

data with value stored by Bind_ADS and initiate a session object

for the client if the comparison succeeds.  The Client Session

object shall exist for the time period contained in the L field.

Static authentication data may be ciphertext or plaintext as

indicated by the E field. If ciphertext, the authentication

module shall decrypt the encrypted authentication data using the

cryptographic key stored in the client credentials under the

label ADL2.



The comparison algorithm for static authentication data is

selected by the authentication module based on the authentication

data type associated with original static authentication data

stored in the client credentials object by a prior Bind_ADS or

Generate_ADS message.



5.3.10  Return_ADS



Format : CMD9 | ADSL | E [| ADSL2]



Objects : Client Credentials



Return : +/- [| ECODE] | RDATA



Return static authentication data ADSL associated with specified

client in RDATA.  Option E allows cryptographic protection for

confidentiality through encryption under the key specified by

optional field ADSL2.



5.3.11  Delete_ADS



Format : CMD10 | ADSL



Objects : Client Credentials



Return : +/- [| ECODE]



Remove static authentication data ADSL associated with specified

client.  Passwords and cryptographic keys may be deleted

individually but deletion of the last static authentication data

element shall automatically delete the Client Credentials object.

This function requires an active Client Session object for the

module security administrator or the client who owns the client

credentials object.



5.3.12  Accept_ADD



Format : CMD11 | ADD | ADT | L | CRYPT [| ADSL] [| L]



Return : +/- [| ECODE] [| RDATA]



This function supports several authentication mechanisms based on

dynamic (time-variant) data.  The dynamic authentication data is

received in the ADD field, and processed according to the values

of the ADT and CRYPT fields.  If the CRYPT field indicates a

cryptographic operation, the optional ADSL field contains the

name of the symmetric or asymmetric key to be used.

Authentication mechanisms include synchronized passwords and

random challenge protocols using symmetric, asymmetric or hash

based techniques.  Both unilateral and bilateral authentication

are available.  Resulting Client Session objects shall exist for

the time period specified in the L field or until explicitly

terminated.  Processing of the ADD field proceeds as follows:



ADT     CRYPT   ACTION

------  ------  -------------------------------------------------

SYNC    X       Authentication of Client to Module via

		synchronized authentication data.  The Module

		compares ADD against a synchronized internal

		value, and initiates a client session if the

		values match.



RC_O    SYM     Response verification step of a challenge

		response protocol using symmetric key

		cryptography.  ADD contains the encrypted

		response to a challenge originated by the Module

		in a previous Generate_ADD message.  The module

		decrypts the ADD value using a secret key shared

		with claimant and compares the plaintext to the

		original stored value.  If the values match, a

		session is created for the Client or the Client

		is notified of the verification of a host

		identity.



RC_I    SYM     Generate encrypted response to a random challenge

		contained in the ADD field to prove the identity

		of a Client to a host.  The Module encrypts

		the random challenge using a symmetric key

		obtained from the Client Object, which is shared

		with the target system.  Return the encrypted

		response in RDATA.



RC_O    ASYM    Equivalent to RC_O/SYM process, except the ADD

		field contains a signature value on a challenge

		previously generated by the Module.  The Module

		verifies the signature using the public key of

		the Client and initiates a session if one does

		not already exist.



RC_I    ASYM    Equivalent to the RC_I/SYM process, except the

		ADD field contains a random value which will be

		signed by the Module using the Client's private

		key.  The signature is returned in RDATA.



5.3.13   Generate_ADD



Format: CMD12 | ADD | ADT | E



Objects : Client Session



Return : +/- [| ECODE] | RDATA



Generate dynamic authentication data and store generated value in

a temporary area associated with the Client Session object for

use in future verification.  Return in plaintext or encrypted

(signed) form in RDATA.  This function can be used as the first

step in a random challenge-response authentication protocol, in

which case a call would be made to the Accept_ADD function to

complete the protocol.  Generate_ADD can also be used to generate

random numbers for other purposes.

	  APPENDIX A:  EXAMPLE AUTHENTICATION SEQUENCES





A1.     OVERVIEW



Sections A2 through A5 describe example message sequences for

module initialization, user to module authentication, module to

module authentication, and client session termination.  The module

used for this example is initialized for security administrator

authentication via a password.  In addition, a client credentials

object containing a password, a secret key, and a public/private

key pair is created for one user.  In this example, the host

system inserts the string "NoSig" in the optional signature

subfield to indicate that signatures are not calculated on each

message.  Some implementations may choose to eliminate the

signature subfield entirely in this situation.





A2.     MODULE INITIALIZATION



The authentication module is assumed to be in an uninitialized

state prior to this series of exchanges.  The module is reset,

and then client credentials objects are created for a security

administrator "Security_Administrator" and a user "User1".  A

cryptographic key is not installed for the security

administrator, because he/she will authenticate to the module

using a password.  The user's client credentials object contains

three forms of static authentication data: a password, a secret

cryptographic key, and a public/private key pair.  A client

session object can be created using any of the three forms of

static authentication data.  The {public/private key pair} field

contains the data for User1's public and private keys, in an

implementation-dependent format.



1.      CMD1 = "Reset | NoClient | NoSig"

	Message to module = CMD1

	Response from module = "+"



2.      CMD6 = "Bind_ADS | Security_Administrator | NoSig"

	Message to module = CMD6 | "SA_Password1" | "R)1%a7" | "Password"

	Response from module = "+"



3.      CMD8 = "Verify_ADS | Security_Administrator | NoSig"

	Message to module = CMD8 | "SA_Password1" | "R)1%a7" |

			      "Plaintext"

	Response from module = "+"



4.      CMD6 = "Bind_ADS | User1 | NoSig"

	Message to module = CMD6 | "User1_Password1" |  "zxmcov" | "Password"

	Response from module = "+"



5.      CMD6 = "Bind_ADS | User1 | NoSig"

	Message to module = CMD6 | "User1_Key1" | "f0335c75a981cca1" |

			    "Secret_Key"

	Response from module = "+"



6.      CMD6 = "Bind_ADS | User1 | NoSig"

	Message to module = CMD6 | "User1_Key2" | {public/private key pair} |

			    "Public/Private_Keys"

	Response from module = "+"





A3.     USER TO MODULE AUTHENTICATION



The module is reset by a host computer system, and then "User1"

authenticates to the module by submitting the password "zxmcov".

A client session object now exists for "User1" until explicitly

terminated.



1.      CMD1 = "Reset | NoClient | NoSig"

	Message to module = CMD1

	Response from module = "+"



2.      CMD8 = "Verify_ADS | User1 | NoSig"

	Message to module = CMD8 | "User1_Password1" | "zxmcov" |

			    "Plaintext"

	Response from module = "+"





A4.     MODULE TO MODULE AUTHENTICATION



The existence of "User1"'s client session object within module 1

is communicated to a second module, module 2, through a signature

based authentication scheme.  Module 2 is instructed to generate

a random challenge represented by the string "Time_Variant_Data".

The random challenge is conveyed to module 1 in the Accept_ADD

message.  The Module retrieves the private component of the

public/private key pair for "User1" and generates a digital

signature on the random challenge, as indicated by the

values of the ADT and CRYPT fields.  The signature is returned to

the host in the RDATA field of the message response, and conveyed

to module 2 in another Accept_ADD command.  Module 2 then

verifies the signature with "User1"'s public key.  If the

signature is valid, module 1 has successfully proven "User1"'s

identity to module 2.  Module 2 creates its own client session

object for "User1".



1.      CMD13 = "Generate_ADD | User1 | NoSig"

	Message to module 2 = CMD11

	Response from module 2 = "+" | "Time_Variant_Data"



2.      CMD11 = "Accept_ADD | User1 | NoSig"

	Message to module 1 = CMD11 | "Time_Variant_Data" | "RC_I" | "ASYM"

			    | "User1_Key2"

	Response from module 1 = "+" | "{Signature Value}"



3.      CMD11 = "Accept_ADD | User1 | NoSig"

	Message to module 2 = CMD11 | {Signature Value} | "RC_O" | "ASYM"

				| "User1_Key2"

	Response from module 2 = "+"





A5.     SESSION TERMINATION



User1's client session object is terminated at the appropriate

time through a Reset_CS message.



1.      CMD2 = "Reset_CS | User1 | NoSig"

	Message to module = CMD2

	Response from module = "+"

      APPENDIX B:  EXAMPLE ASN.1 ENCODING OF AMI MESSAGE SET







In progress.