ISO/IEC 9798-4:1995
(Main)Information technology — Security techniques — Entity authentication — Part 4: Mechanisms using a cryptographic check function
Information technology — Security techniques — Entity authentication — Part 4: Mechanisms using a cryptographic check function
Technologies de l'information — Techniques de sécurité — Mécanismes d'authentification d'entité — Partie 4: Mécanismes utilisant une fonction cryptographique de vérification
General Information
Relations
Standards Content (Sample)
INTERNATIONAL ISO/IEC
STANDARD
First edition
1995-03-I 5
Information technology - Security
- Entity authentication -
techniques
Part 4:
Mechanisms using a cryptographic check
function
Technologies de /‘information - Techniques de s&wit6 - Mbcanismes
d’authentification d’entitt? -
Partie 4: Mkanismes utilisant une fonction cryptographique de Wification
Reference number
lSO/IEC 9798-43 995(E)
---------------------- Page: 1 ----------------------
ISO/IEC 9798-4: 1995 (E)
Foreword
IS0 (the International Organization for Standardization) and IEC (the International Elec-
trotechnical Commission) form the specialized system for worldwide standardization. Na-
tional bodies that are members of IS0 or IEC participate in the development of Interna-
tional Standards through technical committees established by the respective organization
to deal with particular fields of technical activity. IS0 and IEC technical committees col-
laborate in fields of mutual interest. Other international organizations, governmental and
non-governmental, in liaison with IS0 and IEC, also take part in the work.
In the field of information technology, IS0 and IEC have established a joint technical com-
Draft International Standards adopted by the joint technical
mittee, ISO/IEC JTC 1.
committee are circulated to national bodies for voting. Publication as an International
Standard requires approval by at least 75% of the national bodies casting a vote.
International Standard ISO/IEC 9798-4 was prepared by Joint Technical Committee
ISO/IEC JTC 1, I n f ormation technology, Sub-Committee SC27, IT Security techniques.
ISO/IEC 9798 consists of the following parts, under the general title Information technology
- Security techniques - Entity authentication mechanisms:
- Part 1: General model
- Part 3: Entity authentication using a public key algorithm
ISO/IEC 9798 consists of the following parts, under the general title Information technology
- Security techniques - Entity authentication:
- Part 2: Mechanisms using symmetric encipherment algorithms
- Part 4: Mechanisms using a cryptographic check function
- Part 5: Mechanisms using zero knowledge techniques
NOTE - The introductory element of the titles of parts 1 and 3 will be aligned with
the introductory element of the titles of parts 2,4 and 5 at the next revision of parts
1 and 3 of ISO/IEC 9798.
Further parts may follow.
Annexes A, B, C and D of this part of ISO/IEC 9798 are for information only.
0 ISO/IEC 1995
All rights reserved. Unless otherwise specified, no part of this publication may be
regroduced or utilized in any form or by any means, electronic or mechanical, including
photocopying and microfilm, without permission in writing from the publisher.
ISO/IEC Copyright Office l Case postale 56 l CH-1211 Gen&ve 20 l SwitzerlancI
Printed in Switzerland
ii
---------------------- Page: 2 ----------------------
ISO/IEC 9798-4: 1995 (E)
INTERNATIONAL STANDARD @ lso’*E)c
Information technology - Security techniques -
Entity authentication -
Part 4: Mechanisms using a cryptographic check function
3 Definitions and notation
1 Scope
This part of ISO/IEC 9798 specifies entity authentica-
For the purposes of this part of ISO/IEC 9798, the def-
tion mechanisnm using a cryptographic check function.
initions and notation described in ISO/IEC 9798-l ap-
Two inechanisnls are concerned with the authentication
ply. In addition the following definition and notation
of a single entity (unilateral authentication), while the are used:
remaining are nlechanisms for mutual authentication of
two entities. 3.1 cryptographic check value: Information which
is derived by performing a cryptographic transformation
The n~echanisms specified in this part of ISO/IEC 9798
on the data unit [ISO 7498-21.
use time variant paraiiie ters such as time stamps, se-
quence numbers, or random numbers, to prevent valid 3.2 fK(Z): Cryptographic check value which is the re-
authentication information from being accepted at a sult of applying the cryptographic check function f us-
later time.
ing as input a secret key K and an arbitrary data string
2.
If a time stamp or sequence number is used, one pass
is needed for unilateral authentication, while two passes
3.3 PA: Time variant parameter originated by entity A
are needed to achieve mutual authentication. If a chal-
which is either a time stamp TA or a sequence number
lenge and response method employing random numbers
NA l
is used, two passes are needed for unilateral authentica-
tion, while three passes are required to achieve mutual
authentication.
4 Requirements
Examples of cryptographic check functions are given in
In the authentication mechanisnls specified in this part
annex C.
of ISO/IEC 9798 an entity to be authenticated corrob-
orates its identity by demonstrating its knowledge of a
2 Normative reference secret authentication key. This is achieved by the entity
using its secret key with a cryptographic check function
applied to specific data to obtain a cryptographic check
The following standard contains provisions which,
value. The cryptographic check value can be checked by
through reference in this text, constitute provisions of
anyone knowing the entity’s secret authentication key +
this part of ISO/IEC 9798. At the time of publica-
who can re-calcu .lste the c ryptographic check value and
tion, the edition indicated was valid. All standards are
compare it with the value received.
subject to revision, and parties to agreements based on
this part of ISO/IEC 9798 are encouraged to investi-
The authentication nlechanisms have the following re-
gate the possibility of applying the most recent edition
quirements. If any one of these is not met then the au-
of the standard indicated below. Members of IEC and
thentication process may be coinproinised or it cannot
IS0 maintain registers of currently valid International
be implenient ed.
Standards.
a) A claimant authenticating itself to a verifier shares
ISO/IEC 9798-l: 1991, Information technology - Se-
a con~non secret authentication key with that verifier.
curity techniques - Entity authentication mechanisms
This key shall be known to the involved entities prior
- Part 1: General model.
1
---------------------- Page: 3 ----------------------
@ ISO/IEC
ISO/IEC 9798-4: 1995 (E)
A text field may only be included in the input to the
to the conm~encenlent of any particular run of an au-
cryptographic check function if the verifier can deter-
thentication mechanisnl. The method by which the key
mine it independently, e.g., if it is known in advance,
is distributed to the entities is beyond the scope of this
sent in clear or can be derived from one or both of those
part of ISO/IEC 9798.
sources.
b) The secret authentication key, shared by a claimant
and a verifier, shall be known only to those two entities
Unilateral authentication 5.1 U
and, possibly, to other parties they both trust.
nilateral authentication means that only one of the two
c) The cryptographic check function f which takes as in-
entities is authenticated by use of the mechanism.
put a secret key K and an arbitrary string 2 to produce
fK (2) shall satisfy the following properties:
One pass authentication 5.1.1 I
n this authentication nlechanisnl the claimant A initi-
- for any key K and data string 2 it shall be practical
ates the process and is authenticated by the verifier B.
to conipute fK (2);
Uniqueness / timeliness is controlled by generating and
checking a time stamp or a sequence nunlber (see annex
- for any fixed key K, and given no prior knowledge
.
B)
of K, it shall be computationally infeasible to find
a new pair (X, Y) such that fK(X) = Y, even The authentication nlechanisnl is illustrated in figure 1 6
given knowledge of a set of pairs (Xi, Yi) such that
fK(X?:) = E;:, (i = 1,2,. . .), where the value of Xi
may have been chosen after observing the value of
.
= 1,2,. . . , i - 1).
Yi (3
(1) TokenAB
2
A t B ( 1
I I
d) The strength of the mechanisms is dependent on the
length and the secrecy of the key, on the nature of the Figure 1
cryptographic check function, and on the length of the
c.heck value. These parameters shall be chosen to meet
The form of the token (TokenAB), sent by the claimant
the required security level, as may be specified by the
A to the verifier B is:
security policy.
TokenAB =
PA llTeqlfK,~ (X llwextl)!
5 Mechanisms
where the claimant A uses either a sequence number
NA or a time stamp TA as the time variant parameter.
In these authentication mechanisms the entities A and
The choice depends on the technical capabilities of the
B shall share a comn1on secret authentication key KAB
claimant and the verifier as well as on the environment.
or two uni-directional secret keys KAB and KBA prior
to the comnlencenlent of any particular run of the au- The inclusion of the distinguishing identifier B in
t hentication mechanisnls. In the latter case the uni-
TokenAB is optional.
directional keys KAg and KBA are used respectively
for the authentication of A by B and of B by A. NOTE - Distinguishing identifier B is included in
TokenAB to prevent the re-use of TokenAB on entity
The mechanisms require the use of time variant param-
A by an adversary masquerading as entity B. Its inclu-
eters such as time stamps, sequence numbers or random sion is made optional so that, in environments where
such attacks cannot occur, it may be omitted.
numbers. The properties of these parameters, in partic-
ular that it is most unlikely for them to repeat within
The distinguishin g identifier B may also be omit0 ted if
the life-time of an authentication key, are important for
a uni-directional key is used.
the security of these nlechanisnls. For additional infor-
mation see annex B.
(I) A sends TokenAB to B.
All text fields specified in the following nlechanisn~s are
(2) On receipt of the message containing TokenAB, B
available for use in applications outside the scope of this
verifies TokenAB by checking the time stamp or the
part of ISO/IEC 9798 (they may be empty). Their rela-
sequence nunlber, calculating
tion and contents further depend upon the specific ap-
plication. See annex A for information 011 the use of
f&B
text fields.
2
---------------------- Page: 4 ----------------------
@ ISO/IEC ISO/IEC 9798-4: 1995 (E)
Mutual authentication 5.2 M
and comparing it with the cryptographic check
value of the token, thereby verifying the correct-
utual authentication means that the two communicating
ness of the distinguishing identifier B, if present, as
entities are authenticated to each other by use of the
well as the time stamp or the sequence number.
mechanism.
The two nlechanisnls described in 5.1.1 and 5.1.2 are
Two pass authentication 5.1.2 I
adapted in 5.2.1 and 5.2.2, respectively, to achieve mu-
tual authentication. In both cases this requires one more
n this authentication mechanism the claimant A is au-
pass resulting in two more steps.
thenticated by the verifier B who initiates the process.
Uniqueness / timeliness is controlled by generating and
NOTE - A third mechanism for mutual authenti-
checking a random nunlber RB (see annex B).
cation can be constructed from two instances of the
mechanism specified in 5.1.2, one started by entity A
The authentication mechanism is illustrated in figure 2.
and the other by entity B.
Two pass authentication 5.2.1 I
n this authentication nlechanism uniqueness / timeliness
<
’ (1) RBJITextl
4 is controlled by generating and checking time stamps or
A w B (3)
sequence numbers (see annex B).
(2) TokenAB
l
Figure 2 The authentication nlechanism is illustrated in figure 3.
The form of the token (TokenAB), sent by the claimant
(1) TokenAB
A to the verifier B is:
t
(4) A B (2)
* (3) TokenBA
A
TokenAB =
Text3llfK,B (h3IlqIT~xtq.
Figure 3
The inclusion of the distinguishing identifier B in
The form of the token (TokenAB), sent by A to B, is
TokenAB is optional.
identical to that specified in 5.1.1.
NOTE - Distinguishing identifier B is included in
TokenAB =
PA llText2llfK,, (j$ I(BIITextl) l
TokenAB to prevent a so-called reflection attack. Such
an attack is characterized by the fact that an intruder
The form of the token (TokenBA), sent by B to A, is:
“reflects” the challenge Rg to B pretending to be A.
The inclusion of the distinguishing identifier B is made
TokenBA =
$IB IITeXt4llfK~~ ($!y llA(lText3) *
optional so that, in environments where such attacks
cannot occur, it may be omitted.
The inclusion of the distinguishing identifier B in
The distinguishing identifier B may also be omitted if
TokenAB and the inclusion of the distinguishing identi-
a uni-directional key is used.
fier A in TokenBA are (independently) optional.
NOTE 1 - Distinguishing identifier B is included in
(1) B sends a random number RB and, optionally, a
TokenAB to prevent the re-use of TokenAB on entity
text field Text1 to A.
A by an adversary masquerading
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.