ISO/IEC 9798-3:2019

INTERNATIONAL ISO/IEC
STANDARD 9798-3
Third edition
2019-01
IT Security techniques — Entity
authentication —
Part 3:
Mechanisms using digital signature
techniques
Techniques de sécurité IT — Authentification d'entité —
Partie 3: Mécanismes utilisant des techniques de signature
numériques
Reference number
©
ISO/IEC 2019
© ISO/IEC 2019
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may
be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting
on the internet or an intranet, without prior written permission. Permission can be requested from either ISO at the address
below or ISO’s member body in the country of the requester.
ISO copyright office
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: +41 22 749 01 11
Fax: +41 22 749 09 47
Email: copyright@iso.org
Website: www.iso.org
Published in Switzerland
ii © ISO/IEC 2019 – All rights reserved

Contents Page
Foreword .iv
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Symbols and abbreviated terms . 2
5 General . 3
5.1 Time variant parameters . 3
5.2 Tokens . 3
5.3 Use of text fields . 4
6 Requirements . 4
7 Mechanisms without an on-line trusted third party . 5
7.1 Unilateral authentication . 5
7.1.1 General. 5
7.1.2 Mechanism UNI.TS — One-pass authentication . 5
7.1.3 Mechanism UNI.CR — Two-pass authentication . 6
7.2 Mutual authentication . 6
7.2.1 General. 6
7.2.2 Mechanism MUT.TS — Two-pass authentication . 7
7.2.3 Mechanism MUT.CR — Three-pass authentication . 8
7.2.4 Mechanism MUT.CR.par — Two-pass parallel authentication . 9
8 Mechanisms involving an on-line trusted third party .10
8.1 General .10
8.2 Unilateral authentication .11
8.2.1 General.11
8.2.2 Mechanism TP.UNI.1 — Four-pass authentication (initiated by A) .11
8.2.3 Mechanism TP.UNI.2 — Four-pass authentication (initiated by B) .12
8.3 Mutual authentication .13
8.3.1 General.13
8.3.2 Mechanism TP.MUT.1 — Five-pass authentication (initiated by A) .13
8.3.3 Mechanism TP.MUT.2 — Five-pass authentication (initiated by B) .15
8.3.4 Mechanism TP.MUT.3 — Seven-pass authentication (initiated by B) .17
Annex A (normative) Object Identifiers .20
Annex B (informative) Usage guidance .21
Annex C (informative) Use of text fields .24
Bibliography .25
© ISO/IEC 2019 – All rights reserved iii

Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical
Commission) form the specialized system for worldwide standardization. National bodies that are
members of ISO or IEC participate in the development of International Standards through technical
committees established by the respective organization to deal with particular fields of technical
activity. ISO and IEC technical committees collaborate in fields of mutual interest. Other international
organizations, governmental and non-governmental, in liaison with ISO and IEC, also take part in the
work. In the field of information technology, ISO and IEC have established a joint technical committee,
ISO/IEC JTC 1.
The procedures used to develop this document and those intended for its further maintenance are
described in the ISO/IEC Directives, Part 1. In particular, the different approval criteria needed for
the different types of document should be noted. This document was drafted in accordance with the
editorial rules of the ISO/IEC Directives, Part 2 (see www .iso .org/directives).
Attention is drawn to the possibility that some of the elements of this document may be the subject
of patent rights. ISO and IEC shall not be held responsible for identifying any or all such patent
rights. Details of any patent rights identified during the development of the document will be in the
Introduction and/or on the ISO list of patent declarations received (see www .iso .org/patents).
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and
expressions related to conformity assessment, as well as information about ISO's adherence to the
World Trade Organization (WTO) principles in the Technical Barriers to Trade (TBT) see www .iso
.org/iso/foreword .html.
This document was prepared by Joint Technical Committee JTC 1, Information Technology, Subcommittee
SC 27, IT Security techniques.
This third edition cancels and replaces the second edition (ISO/IEC 9798–3:1998), which has been
technically revised. It also incorporates the amendment ISO/IEC 9798–3:1998/Amd 1:2010, and
corrigenda ISO/IEC 9798–3:1998/Cor 1:2009 and ISO/IEC 9798–3:1998/Cor 2:2012. The main changes
compared to the previous edition are as follows:
— all mechanisms have been technically revised to resolve security issues and make the mechanism
secure by default;
— all mechanisms have been renamed and editorially improved to represent them more clearly;
— three additional mechanisms have been included using an on-line trusted third party;
— guidance to explain the security properties of the mechanisms and guide users in selecting the
appropriate mechanism for their use case has been added (Annex B).
A list of all parts in the ISO/IEC 9798 series can be found on the ISO website.
Any feedback or questions on this document should be directed to the user’s national standards body. A
complete listing of these bodies can be found at www .iso .org/members .html.
iv © ISO/IEC 2019 – All rights reserved

INTERNATIONAL STANDARD ISO/IEC 9798-3:2019(E)
IT Security techniques — Entity authentication —
Part 3:
Mechanisms using digital signature techniques
1 Scope
This document specifies entity authentication mechanisms using digital signatures based on
asymmetric techniques. A digital signature is used to verify the identity of an entity.
Ten mechanisms are specified in this document. The first five mechanisms do not involve an on-line
trusted third party and the last five make use of on-line trusted third parties. In both of these two
categories, two mechanisms achieve unilateral authentication and the remaining three achieve mutual
authentication.
Annex A defines the object identifiers assigned to the entity authentication mechanisms specified in
this document.
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content
constitutes requirements of this document. For dated references, only the edition cited applies. For
undated references, the latest edition of the referenced document (including any amendments) applies.
ISO/IEC 9798-1, Information technology — Security techniques — Entity authentication — Part 1: General
ISO/IEC 14888 (all parts), Information technology — Security techniques — Digital signatures with
appendix
ISO/IEC 9796 (all parts), Information technology — Security techniques — Digital signature schemes
giving message recovery.
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
ISO and IEC maintain terminological databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https: //www .iso .org/obp
— IEC Electropedia: available at http: //www .electropedia .org/
3.1
atomic transaction
transaction which cannot be split into multiple smaller transactions
3.2
claimant
entity which is or represents a principal for the purposes of authentication
[SOURCE: ISO/IEC 9798–1:2010, 3.6, modified — The Note to entry has been removed.]
© ISO/IEC 2019 – All rights reserved 1

3.3
digital signature
signature
data appended to, or a cryptographic transformation of, a data unit that allows the recipient of the data
unit to verify the source and integrity of the data unit
3.4
entity authentication
corroboration that an entity is the one claimed
[SOURCE: ISO/IEC 9798–1:2010, 3.14]
3.5
mutual authentication
entity authentication (3.4) which provides both entities with assurance of each other’s identity
[SOURCE: ISO/IEC 9798–1:2010, 3.18]
3.6
token
message consisting of data fields that are the output of a cryptographic function
3.7
trusted third party
security authority or its agent, trusted by other entities with respect to security related activities
[SOURCE: ISO/IEC 9798–1:2010, 3.38, modified — The Note to entry has been removed.]
3.8
unilateral authentication
entity authentication which provides one entity with assurance of the other’s identity but not vice versa
[SOURCE: ISO/IEC 9798–1:2010, 3.39]
3.9
verifier
entity that requires to verify the identity of another entity
4 Symbols and abbreviated terms
The symbols and abbreviated terms given in ISO/IEC 9798–1 and the following shall apply.
Cert certificate for entity X
X
I representation of the identity of entity X, which is either i or Cert
X X X
i string identifying entity X
X
M data string that is input to a digital signature algorithm
P public verification key associated with X
X
Res result of verifying entity X’s public key or public key certificate
X
i
SID constant uniquely identifying the mechanism m and the signed string (number i) within
m
the mechanism
sS (M) signature on data string M with the private signing key of entity X. The signature shall be
X
such that M can be recovered
2 © ISO/IEC 2019 – All rights reserved

time variant parameter used by entity X, either a sequence number N or a time stamp T
X X
T
X
N
X
X ‖ Y result of the concatenation of data items X and Y in the order specified. In cases where
the result of concatenating two or more data items is signed as part of one of the mecha-
nisms specified in this document, this result should be composed so that it can be uniquely
resolved into its constituent data strings, i.e. so that there is no possibility of ambiguity in
interpretation
NOTE  Unique parsing of concatenated strings can be achieved in a variety of different ways,
depending on the application. For example, it can be guaranteed by a) fixing the length of
each of the substrings throughout the domain of use of the mechanism, or b) encoding the
sequence of concatenated strings using a method that guarantees unique decoding, e.g., using
[3]
the distinguished encoding rules defined in ISO/IEC 8825–1 .
5 General
5.1 Time variant parameters
The mechanisms specified in this document use digital signatures to achieve unilateral or mutual
entity authentication. Annex B provides guidance to explain the security properties of the mechanisms
and guide users in selecting the appropriate mechanism for their use case.
To prevent valid authentication information from being accepted at a later time, time variant
parameters such as time stamps, sequence numbers, or random numbers are used (see ISO/IEC 9798-
1:2010, Annex B and the Note below).
If a time stamp or a sequence number is used, one pass is needed for unilateral authentication, while
two passes are needed to achieve mutual authentication. If a challenge and response method employing
random numbers is used, two passes are needed for unilateral authentication, while three or four
passes (depending on the mechanism employed) are required to achieve mutual authentication.
NOTE The signing by one entity of a data block which has been manipulated by a second entity can be
prevented by the first entity including its own random number in the data block which it signs. In this case, it is
the unpredictability which prevents the signing of pre-defined data.
5.2 Tokens
Throughout this document, tokens are defined as:
Token = X ‖ ··· ‖ X ‖ sS (Y ‖ ··· ‖ Y ).
1 i A 1 j
In this document, the term “signed data” refers to the data string “Y ‖ ··· ‖ Y ” used as input to the
1 j
signature scheme and the term “unsigned data” refers to the data string “X ‖ ··· ‖ X ”.
1 i
Information contained in the unsigned data is, in general, not authenticated by the mechanisms in this
document.
If information contained in the signed data of the token can be recovered from the signature [as is
the case for signature schemes with message recovery, as specified in ISO/IEC 9796 (all parts)] or is
already known to the verifier, then it does not need to be contained in the unsigned data of the token
sent by the claimant.
When a signature scheme without message recovery is used, the signed data, M, should be inserted
in the unsigned data right before the corresponding signature, i.e. sS (M) is replaced by M ‖ sS (M).
X X
© ISO/IEC 2019 – All rights reserved 3

Parts of the signed data M that are already available to the recipient can be excluded from the unsigned
version of M.
5.3 Use of text fields
All text fields specified in the following mechanisms are available for use in applications outside the
scope of this document (they may be empty). Their relationship and contents depend on the specific
application. See Annex C for information on the use of text fields.
6 Requirements
In the authentication mechanisms specified in this document, an entity to be authenticated corroborates
its identity by demonstrating its knowledge of its private signature key. This is achieved by the entity
using its private signature key to sign specific data. The signature can be verified by anyone using the
entity’s public verification key.
The authentication mechanisms have the following requirements:
a) A verifier shall possess the valid public key of the claimant, i.e. of the entity that the claimant
claims to be.
One way of obtaining a valid public key is by means of a certificate (see ISO/IEC 9798-1:2010,
Annex C). The generation, distribution, and revocation of certificates are outside the scope of
this document. Depending on the mechanism, a trusted third party may be used to distribute an
authentic copy of the public key and its certificate. Another way of obtaining a valid public key is by
a trusted courier.
As the distribution of certificates is outside the scope of this document, the sending of certificates
is optional in all mechanisms.
b) A claimant shall have a private signature key known and used only by the claimant.
c) The private signature key used in an implementation of one of the mechanisms specified in this
document shall be distinct from keys used for any other purposes.
d) The data strings signed at various points in an authentication mechanism shall be composed so
that they cannot be interchanged.
i
To help achieve requirement d), the mechanisms in this document include constants SID in the
m
signed data.
i
NOTE The form of the constants, SID , is not specified in this document. However, in order to meet
m
requirement d), they can be defined to include the following data elements:
— The object identifier as specified in Annex A, in particular identifying the ISO/IEC standard, the part number,
and the authentication mechanism;
— A constant that uniquely identifies the signed string within the mechanism. This constant can be omitted in
mechanisms that include only one signed string.
i
The recipient of a signature shall verify that the constant SID in the signed data is as expected.
m
If any of the above requirements is not satisfied, then the authentication process can be compromised
or fail to complete successfully.
Annex A defines the object identifiers which shall be used to identify the entity authentication
mechanisms specified in this document.
4 © ISO/IEC 2019 – All rights reserved

7 Mechanisms without an on-line trusted third party
7.1 Unilateral authentication
7.1.1 General
Unilateral authentication means that only one of the two entities is authenticated by use of the
mechanism.
7.1.2 Mechanism UNI.TS — One-pass authentication
In this authentication mechanism, the claimant A initiates the process and is authenticated by the
verifier B. Uniqueness and timeliness is controlled by generating and checking a time stamp or a
sequence number (see ISO/IEC 9798-1:2010, Annex B).
The authentication mechanism is illustrated in Figure 1.
Figure 1 — One-pass unilateral authentication
The form of the token (TokenAB), sent by the claimant A to the verifier B is:
 
T
A
TokenTAB = extT21sS SID i ext ,
 
A UNIT. S B
N
 A 
where the claimant, A, uses either a sequence number, N , or a time stamp, T , as the time variant
A A
parameter. The choice depends on the technical capabilities of the claimant and the verifier as well as
on the environment.
NOTE 1 The inclusion of the identifier i in the signed data of TokenAB is necessary to prevent the token from
B
being accepted by anyone other than the intended verifier.
NOTE 2 One application of this mechanism can be public key or certificate distribution (see ISO/IEC 9798-
1:2010, Annex A).
a) A sends TokenAB and, optionally, its identity, I , to B.
A
b) On receipt of the message containing TokenAB, B performs the following steps:
1) It checks the received identity, I , and determines whether this is trusted by verifying the
A
certificate of A, matching it with a stored list of trusted entities or by some other means.
NOTE 3 It can also check whether the received identity is equal to its own identity. In many
applications, authenticating an entity against itself is considered a security issue.
2) It ensures that it is in possession of a valid public key of A.
3) It verifies TokenAB by verifying the signature of A contained in the token, by checking the SID,
by checking the time stamp or the sequence number, and by checking that the value of the
identifier field, (i ), in the signed data of TokenAB is equal to entity B’s distinguishing identifier.
B
© ISO/IEC 2019 – All rights reserved 5

7.1.3 Mechanism UNI.CR — Two-pass authentication
In this authentication mechanism, the claimant, A, is authenticated by the verifier, B, who initiates the
process. Uniqueness and timeliness is controlled by generating and checking a random number, R (see
B
ISO/IEC 9798-1:2010, Annex B).
The authentication mechanism is illustrated in Figure 2.
Figure 2 — Two-pass unilateral authentication
The form of the token (TokenAB), sent by the claimant, A, to the verifier, B, is:
TokenAB = Text3 ‖ sS (SID ‖ R ‖ R ‖ i ‖ Text2).
A UNI.CR A B B
NOTE 1 The inclusion of the identifier, i , in the signed data of TokenAB prevents the token from being accepted
B
by anyone other than the intended verifier (e.g., in a person-in-the-middle attack).
NOTE 2 The inclusion of the random number, R , in the signed part of TokenAB prevents B from obtaining the
A
signature of A on data chosen by B prior to the start of the authentication mechanism.
a) B sends a random number, R , and, optionally, a text field, Text1, to A.
B
b) A sends TokenAB and, optionally, its identity, I , to B.
A
c) On receipt of the message containing TokenAB, B performs the following steps:
1) It checks the received identity, I , and determines whether this is trusted either by verifying
A
the certificate of A, matching it with a stored list of trusted entities or by some other means.
NOTE 3 It can also check whether the received identity is equal to its own identity. In many
applications, authenticating an entity against itself is considered a security issue.
2) It ensures that it is in possession of a valid public key of A.
3) It verifies TokenAB by checking the signature of A contained in the token, by checking the SID,
by checking that the random number, R , sent to A in step a), agrees with the random number
B
contained in the signed data of TokenAB, and by checking that the value of the identifier field,
(i ), in the signed data of TokenAB is equal to B’s distinguishing identifier.
B
7.2 Mutual authentication
7.2.1 General
Mutual authentication means that the two communicating entities are authenticated to each other.
The two mechanisms described in 7.1.2 and 7.1.3 are extended in 7.2.2 and 7.2.3, respectively, to
achieve mutual authentication. This is achieved by transmitting one further message resulting in two
additional steps.
The mechanism specified in 7.2.4 uses four messages which do not need to be all sent consecutively. In
this way, the authentication process can be speeded up.
6 © ISO/IEC 2019 – All rights reserved

7.2.2 Mechanism MUT.TS — Two-pass authentication
In this authentication mechanism, uniqueness and timeliness is controlled by generating and checking
time stamps or sequence numbers (see ISO/IEC 9798-1:2010, Annex B).
The authentication mechanism is illustrated in Figure 3.
Figure 3 — Two-pass mutual authentication
The form of the token (TokenAB), sent by A to B, is analogous to that specified in 7.1.2:
 T 
1 A
TokenTAB = extT21sS SID i ext .
 
A MUTT. S B
N
 A 
The form of the token (TokenBA), sent by B to A, is:
 T T 
2 B A
TokenTBA= extT43sS SID i  ext .
 
B MUTT. S A
N N
B A
 
The choice of using either time stamps or sequence numbers in this mechanism depends on the technical
capabilities of the claimant and the verifier as well as on the environment.
NOTE 1 The inclusion of identifiers, i and i , in the signed data of TokenBA and TokenAB, respectively, is
A B
necessary to prevent the tokens from being accepted by anyone other than the intended verifier.
T
A
NOTE 2 If were to be omitted in TokenBA, the two messages of this mechanism are not bound together in
N
A
any way, other than implicitly by timeliness; the mechanism involves independent use of mechanism 7.1.2 twice.
The mechanism no longer achieves mutual authentication.
a) A sends TokenAB and, optionally, its identity, I , to B.
A
b) On receipt of the message containing TokenAB, B performs the following steps:
1) It checks the received identity, I , and determines whether this is trusted either by verifying
A
the certificate of A, matching it with a stored list of trusted entities or by some other means.
NOTE 3 It can also check whether the received identity is equal to its own identity. In many
applications, authenticating an entity against itself is considered a security issue.
2) It ensures that it is in possession of a valid public key of A.
3) It verifies TokenAB by verifying the signature of A contained in the token, by checking the SID,
by checking the time stamp or the sequence number, and by checking that the value of the
identifier field, (i ), in the signed data of TokenAB is equal to entity B’s distinguishing identifier.
B
c) B sends TokenBA and, optionally, its identity, I , to A.
B
d) On receipt of the message containing TokenBA, A performs the following steps:
1) It checks the received identity, I , and determines whether this is trusted either by verifying
B
the certificate of B, matching it with a stored list of trusted entities or by some other means.
NOTE 4 It can also check whether the received identity is equal to its own identity. In many
applications, authenticating an entity against itself is considered a security issue.
© ISO/IEC 2019 – All rights reserved 7

2) It ensures that the received identity, I , corresponds to i included in TokenAB.
B B
3) It ensures that it is in possession of a valid public key of B.
4) It verifies TokenBA by verifying the signature of B contained in the token, by checking the SID,
by checking the time stamp or the sequence number, and by checking that the value of the
identifier field, (i ), in the signed data of TokenBA is equal to entity A’s distinguishing identifier.
A
T
A
5) A verifies that the received in TokenBA is identical to the one sent in TokenAB in step a).
N
A
7.2.3 Mechanism MUT.CR — Three-pass authentication
In this authentication mechanism, uniqueness and timeliness is controlled by generating and checking
random numbers (see ISO/IEC 9798-1:2010, Annex B).
The authentication mechanism is illustrated in Figure 4.
Figure 4 — Three-pass mutual authentication
The tokens are of the following form:
TokenTAB = extT32sS SIDRRi  ext ;
AA()MUTC. R BB
′
TokenTBA= extT54sS SIDRRi  ext .
()
BBMUTC. R AA
NOTE 1 When i or i are omitted from TokenAB or TokenBA, respectively, A cannot conclude B is intending to
B A
authenticate to A (and vice versa). Additionally, agreement on Text2 and Text4 cannot be guaranteed.
NOTE 2 The inclusion of the random number, R , in the signed part of TokenAB prevents B from obtaining the
A
signature of A on data chosen by B prior to the start of the authentication mechanism. The same holds for the
random number, R′ , in the signed part of TokenBA. R′ can be set to R , but, in this case, A can obtain a signature
B B B
from B on data chosen prior to sending TokenAB.
a) B sends a random number, R , and, optionally, a text field, Text1, to A.
B
b) A sends TokenAB and, optionally, its identity, I , to B.
A
c) On receipt of the message containing TokenAB, B performs the following steps:
1) It checks the received identity, I , and determines whether this is trusted either by verifying
A
the certificate of A, matching it with a stored list of trusted entities or by some other means.
NOTE 3 It can also check whether the received identity is equal to its own identity. In many
applications, authenticating an entity against itself is considered a security issue.
2) It ensures that it is in possession of a valid public key of A.
3) It verifies TokenAB by checking the signature of A contained in the token, by checking the SID,
by checking that the random number, R , sent to A in step a), agrees with the random number
B
contained in the signed data of TokenAB, and by checking that the value of the identifier field,
(i ), in the signed data of TokenAB is equal to B’s distinguishing identifier.
B
d) B sends TokenBA and, optionally, its identity, I , to A.
B
8 © ISO/IEC 2019 – All rights reserved

e) On receipt of the message containing TokenBA, A performs the following steps:
1) It checks the received identity, I , and determines whether this is trusted either by verifying
B
the certificate of B, matching it with a stored list of trusted entities or by some other means.
NOTE 4 It can also check whether the received identity is equal to its own identity. In many
applications, authenticating an entity against itself is considered a security issue.
2) It ensures that the received identity, I , corresponds to i included in TokenAB.
B B
3) It ensures that it is in possession of a valid public key of B.
4) It verifies TokenBA by checking the signature of B contained in the token, by checking the SID,
by checking that the random number, R , sent to B in step b), agrees with the random number
A
contained in the signed data of TokenBA, and by checking that the value of the identifier field,
(i ), in the signed data of TokenBA is equal to A’s distinguishing identifier.
A
7.2.4 Mechanism MUT.CR.par — Two-pass parallel authentication
In this mechanism, authentication is carried out in parallel. Uniqueness and timeliness is controlled by
generating and checking random numbers (see ISO/IEC 9798-1:2010, Annex B).
The authentication mechanism is illustrated in Figure 5.
Figure 5 — Two-pass parallel authentication
The tokens are similar to those of 7.1.3:
TokenTAB = extT43sS SIDRRi  ext ,
AA()MUTC.Rpar BB
TokenTBA= extT65sS SIDRRi  ext .
()
BBMUTC.Rpar AA
NOTE 1 The random number, R , is present in TokenAB to prevent B from obtaining the signature of A on data
A
chosen by B prior to the start of the authentication mechanism. For similar reasons, the random number, R , is
B
present in TokenBA. Depending on the relative time of receipt of the messages sent in steps (1) and (1)’, one of the
parties can know the random number of the other party when choosing its random number. If this is undesirable,
both parties can insert an additional random number, R′ and R′ , in the text fields Text3 of TokenAB and Text5 of
A B
TokenBA, respectively.
NOTE 2 Both signatures in the mechanism have the same identifier, SID , since the order of messages
MUT.CR.par
is not fixed.
a) A sends a random number, R , and, optionally, its identity, I , and optionally a text field, Text1, to B.
A A
a’) B sends a random number, R , and, optionally, its identity, I , and optionally a text field, Text2, to A.
B B
b) A and B each perform the following steps:
1) Each of them checks the received identity, I , and determines whether this is trusted either by
X
verifying the certificate of the other entity, matching it with a stored list of trusted entities or
by some other means.
© ISO/IEC 2019 – All rights reserved 9

NOTE 3 Each of them can also check whether the received identity is equal to its own identity. In
many applications, authenticating an entity against itself is considered a security issue.
2) Each of them ensures that it is in possession of a valid public key of the other entity.
c) A sends TokenAB to B, where TokenAB contains, i , corresponding to the identity of the entity that
B
is considered trusted by A in step b).
c’) B sends TokenBA to A, where TokenBA contains, i , corresponding to the identity of the entity that
A
is considered trusted by B in step b).
d) A and B each perform the following steps:
1) Each of them verifies the received token by checking the signature contained in the token [by
using the public key from step b)] and by checking the SID.
2) Each of them checks that the random number, which it previously sent to the other entity,
agrees with the first random number contained in the signed data of the token received.
3) Each of them checks that the random number it previously received from the other entity
[n step a)] agrees with second the random number contained in the signed data of the token
received.
4) Each of them checks that the value of the identity field, (i ), contained in the signed data of the
X
received token corresponds to its own identity.
8 Mechanisms involving an on-line trusted third party
8.1 General
Implementations of the mechanisms in this clause shall use one of the signature schemes specified in
ISO/IEC 14888 (all parts) or ISO/IEC 9796 (all parts).
In the specification of the mechanisms in this clause, the form of tokens and text fields follows the
description given in Clauses 4 and 5. In addition, the values of the fields Res , Res , Status and Failure in
A B
the mechanisms specified in this clause shall have the following forms:
— Res = (Cert ‖ Status), (i ‖P ) or Failure;
A A A A
— Res = (Cert ‖ Status), (i ‖P ) or Failure;
B B B B
— Status = True or False. The value of the field shall be set to False if the certificate validation (e.g.
[4] [7]
according to ISO/IEC 9594-8, ITU-T X.509 or the security policy of the domain in which the TP
is residing) fails. Otherwise it shall be set to True.
— Failure:Re s (where X ∈ {A,B}) will be set to Failure if neither a public key nor a certificate of entity
X
X can be found by TP.
In the mechanisms of this clause, if TP knows the mapping between identity X and P (where X ∈ {A,B}),
X
then it shall set I = i ; otherwise, it shall set I = Cert , and X shall be set equal to the collection of
X X X X
distinguished identity fields in Cert . If either X or Cert is permitted to be used as an identity, then
X X
there should be a pre-arranged means to allow TP to distinguish the two types of identity indications.
The value of Res (where X = {A,B}) shall be determined according to Table 1.
X
Table 1 — Value of Res
X
Field Choice 1 Choice 2
I i Cert
X X X
Res (i ‖ P ) or Failure (Cert ‖ Status) or Failure
X X X X
10 © ISO/IEC 2019 – All rights reserved

8.2 Unilateral authentication
8.2.1 General
The authentication mechanisms in this subclause require the two entities A (or B) to validate the other's
public key using an on-line trusted third party (with distinguishing identifier TP). This trusted third
party shall have the capability to verify the authenticity of the public key of A (or B). The entities A (or
B) shall possess a reliable copy of the public key of TP.
This subclause specifies two four-pass authentication mechanisms, both of which achieve unilateral
authentication between entities A and B. Furthermore, the mechanisms in this subclause provide entity
authentication of the TP as well as origin authentication and non-replay of the verification results. The
four-pass authentication is an atomic transaction.
Implementations of the mechanisms shall use one of the signature schemes specified in ISO/IEC 14888
(all parts) or ISO/IEC 9796 (all parts).
8.2.2 Mechanism TP.UNI.1 — Four-pass authentication (initiated by A)
In this authentication mechanism, the claimant B is authenticated by the verifier A who initiates the
process, using an on-line trusted third party (with distinguishing identifier TP). TP shall have the
capability to verify the authenticity of the public key of B. The entity A shall possess a reliable copy of
the public key of TP.
This authentication mechanism is illustrated in Figure 6.
Figure 6 — Four-pass authentication (initiated by A)
The tokens shall be created as follows:
TokenTBA= ext2sS SIDRRi Text3 ;
()
BBTP.UNI.1 AA
′
TokenTTA= ext5sS SIDR Res Text6 .
TB()TP.UNI.1 A
The mechanism is performed as follows:
a) A sends a random number, R and, optionally, a text field, Text1, to B.
A,
b) B sends the token TokenBA to A.
c) A sends a random number, R′ , I . and, optionally, a text field, Text4, to TP.
A B
d) On receipt of the message in step c) from A, TP performs the following steps. If I = i , TP retrieves
B B
P . If I = Cert , TP checks the validity of Cert . The process of certificate verification by TP can
B B B B
© ISO/IEC 2019 – All rights reserved 11

require protection from denial-of-service attacks. The specification of mechanisms to be used to
provide such protection is outside of the scope of this document.
e) TP sends TokenTA to A. The fields Res in TokenTA shall be: the certificate of B and its status, the
B
distinguishing identifier of B and its public key, or an indication of Failure.
f) On receipt of the message in step e) from TP, A performs the following steps:
1) Verify TokenTA by checking the signature of TP contained in the token, by checking the SID,
and by checking that the random number R′ , sent to TP in Step c), is the same as the random
A
number, R′ , contained in the signed data of TokenTA, and by checking Res is not Failure.
A B
NOTE It can also check whether the received identity is equal to its own identity. In many
applications, authenticating an entity against itself is considered a security issue.
2) Retrieve the public key of B from the message, verify TokenBA received in step b) by checking
the signature of B contained in the token, by checking the SID and checking that the value of
identifier field, (i ), in the signed data of TokenBA is equal to A's distinguishing identifier, and
A
then check that the random number, R , sent to B in step a), is the same as the random number,
A
R , contained in TokenBA.
A
8.2.3 Mechanism TP.UNI.2 — Four-pass authentication (initiated by B)
In this authentication mechanism, the claimant A is authenticated by the verifier B who initiates the
process, using an on-line trusted third party (with distinguishing identifier TP). TP shall have the
capability to verify the authenticity of the public key of A. The entity B shall possess a reliable copy of
the public key of TP.
This authentication mechanism is illustrated in Figure 7.
Figure 7 — Four-pass authentication (initiated by B)
The tokens shall be created as follows:
TokenTTA= ext3sS SIDR Res Text4 ;
()
TBTP.UNI.2 A
TokenTAB = ext5TokenTTA sS SIDRRi  ext6 .
AA()TP.UNI.2 BB
The mechanism is performed as follows:
a) B sends a random number, R and, optionally, a text field, Text1, to A.
B,
b) A sends, R , I and, optionally, a text field, Text2, to TP.
B A,
c) On receipt of the message in Step b) from A, TP performs the following steps: If I = i , TP retrieves
A A
P . If I = Cert , TP checks the validity of Cert . The process of certificate verification by TP can
A A A A
12 © ISO/IEC 2019 – All rights reserved

require protection from denial-of-service attacks. The specification of mechanisms to be used to
provide such protection is outside of the scope of this document.
d) TP sends TokenTA to A. The fields Res in TokenTA shall be: the certificate of A and its status, the
A
distinguishing identifier of A and its public key, or an indication of Failure.
e) A sends the token TokenAB to B.
f) On receipt of the message in step e) from A, B performs the following steps:
1) Verify the signature of TP in TokenTA by checking the signature of TP contained in the token, by
checking the SID and by checking that the random number, R , sent to A in step a), is the same
B
as the random number, R , contained in the signed data of TP of TokenTA, and by checking
B B
ResA is not Failure.
NOTE It can also check whether the received identity is equal to its own identity. In many
applications, authenticating an entity against itself is considered a security issue.
2) Retrieve the public key of A from the message, verify TokenAB by checking the signature of A
contained in the token, by checking SID, and checking that the value of identifier field, (i ), in
B
the signed data of TokenAB is equal to B's distinguishing identifier, and then check that the
random number, R , sent to A in step a), is the same as the random number, R , contained in the
B B
signed data of A of TokenAB.
8.3 Mutual authentication
8.3.1 General
The authentication mechanisms in this subclause require the two entities A and B to validate each
other's public keys using one or two on-line trusted third parties.
If only a single on-line trusted third party is used, it has a distinguishing identifier denoted by TP.
If two on-line trusted third parties are used, their distinguishing identifiers are denoted by TP and
A
TP respectively. The authenticity of the public key of A is verified only by TP , and the authenticity of
B A
the public key of B is verified only by TP . Entity A trusts TP (A accepts any assertion signed by TP
B A A
as valid) and shall possess a reliable copy of the public key of corresponding TP . Entity B trusts TP
A B
(B accepts any assertion signed by TP as valid) and shall possess a reliable copy of the public key of
B
corresponding TP . TP and TP trust each other. TP has a reliable copy of TP 's public key and TP has
B A B A B B
a reliable copy of TP 's public key.
A
This subclause specifies two five-pass and one seven-pass authentication mechanisms, all of which
achieve mutual authentication between entities A and B. Furthermore, these mechanisms provide entity
authentication of the TP, TP , or TP as well as origin authentication and non-replay of the verification
A B
results. The five-pass and seven-pass authenticat
...