ISO/IEC 9798-2:1994
(Main)Information technology — Security techniques — Entity authentication — Part 2: Mechanisms using symmetric encipherment algorithms
Information technology — Security techniques — Entity authentication — Part 2: Mechanisms using symmetric encipherment algorithms
Technologies de l'information — Techniques de sécurité — Authentification d'entité — Partie 2: Mécanismes utilisant des algorithmes de chiffrement symétriques
General Information
Relations
Standards Content (Sample)
INTERNATIONAL
lSO/IEC
STANDARD
9798-2
First edition
1994-12-15
Information technology - Security
techniques - Entity authentication
Part 2:
Mechanisms using symmetric enciphe
rme nt
algorithms
Technologies de /‘information - Techniques de &cur-it6 -
Authentification d’entitb -
Partie 2: Mbcanismes utjlisant des algorithmes de chiffrement
sym6 triques
Reference nun-her
ISO/1 EC 9798-2: 1994(E)
---------------------- Page: 1 ----------------------
ISO/IEC 9798-2: 1994(E)
Foreword
IS0 (the International Organization for Standardization) and IEC (the Inter-
national Electrotechnical Commission) form the specialized system for worldwide
standardization. National bodies that are members of IS0 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.
IS0 and IEC technical committees collaborate 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 committee, ISO/IEC JTC 1. Draft International Standards adopted by the
joint technical 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-2 was prepared by Joint Technical Com-
mittee ISO/IEC JTC 1, Information technology, Subcommittee SC 27, IT Security
techniques.
ISO/IEC 9798 consists of the following parts, under the general title Information
Entity authentication mechanisms:
technology - Security techniques -
- Part 1: General model
- Part 3: Entity authentication using a public key algorithm
ISO/IEC 9798 also 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 and C of this part of ISO/IEC 9798 are for information only.
0 ISO/IEC 1994
All rights reserved. Unless otherwise specified, no part of this publication may be
reproduced 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 Geneve 20 l Switzerland
Printed in Switzerland
ii
---------------------- Page: 2 ----------------------
INTERNATIONAL STANDARD a lso’lac ISO/IEC 9798-2: 1994 (E)
Information technology - Security techniques -
Entity authentication -
Part 2: Mechanisms using symmetric encipherment algorithms
of the standard indicated below. Members of IEC and
1 Scope
IS0 maintain registers of currently valid International
Standards.
This part of ISO/IEC 9798 specifies entity authentica-
tion inechanisms using symmetric encipherment algo-
ISO/IEC 9798-l: 1991, Information technology - Se-
rithms. Four of them deal with authentication mecha-
curity techniques - Entity authentication mechanisms
nisms between two entities where no trusted third party
- Part I: General model.
is involved; two of these four are concerned with the
authentication of a single entity (unilateral authentica-
tion), while the other two are mechanisms for mutual
3 Definitions and notation
authentication of two entities. The remaining mecha-
uisnls require a trusted third party for the establishment
For the purposes of this part of ISO/IEC 9798 the defini-
of a common secret key, and realize mutual or unilateral
tions and notation described in ISO/IEC 9798-l apply.
entity authentication.
The inechanisins specified in this part of ISO/IEC 9798
4 Requirements
use time variant parameters such as time stamps, se-
quence numbers, or random numbers, to prevent valid
In the authentication mechanisuis specified in this part
authentication information from being accepted at a
of ISO/IEC 9798 an entity to be authenticated corrob-
later time.
orates its identity by demonstrating its knowledge of a
secret authentication key. This is achieved by the entity
If no trusted third party is involved and a time stamp
using its secret key to encipher specific data. The en-
or sequence number is used, one pass is needed for uni-
ciphered data can be deciphered by anyone sharing the
lateral authentication, while two passes are needed to
entity’s secret authentication key.
achieve mutual authentication. If no trusted third party
is involved and a challenge and response method em-
The authentication mechanisins have the following re-
ploying random numbers is used, two passes are needed
quirements. If any one of these is not met then the au-
for unilateral authentication, while three passes are re-
thentication process may be compromised or it cannot
quired to achieve mutual authentication. If a trusted
be implemented.
third party is involved, any additional coimnunication
between an entity and the trusted third party requires
a) A claimant authenticating itself to a verifier shares
two extra passes in the coininunication exchange.
a comnlon secret authentication key with that verifier,
in which case the mechanisms of clause 5 apply, or each
entity shares a secret authentication key with a con~uon
2 Normative reference
trusted third party, in which case the mechanisms of
clause 6 apply. Such keys shall be known to the involved
The following standard contains provisions which,
parties prior to the comnlencenlent of any particular
through reference in this text, constitute provisions of
run of an authentication mechanism. The method by
this part of ISO/IEC 9798. At the time of publica-
which this is achieved is beyond the scope of this part
tion, the edition indicated was valid. All standards are
of ISO/IEC 9798.
subject to revision, and parties to agreeum~ts based ou
this part of ISOJIEC 9798 are encouraged to investi- b) If a trusted third party is involved it is trusted by
both the claimant and the verifier.
gate the possibility of applying the most receu% edition
1
---------------------- Page: 3 ----------------------
@ ISO/IEC
ISO/IEC 9798-Z: 1994 (E)
part of ISO/IEC 9798 (they may be empty). Their re-
c) The secret authentication key shared by a claimant
lationship and contents depend upon the specific appli-
and a verifier, or by an entity and a trusted third party,
cation. See annex A for information ou the use of text
is known only to those two parties and, possibly, to other
fields.
parties they both trust.
5.1 Unilateral authentication
NOTE 1 - The encipherment algorithm and the key
life-time should be chosen so that it is computationally
Unilateral authentication means that only one of the
infeasible for a key to be deduced during its life-time.
two entities is authenticated by use of the mechanism.
In addition, the key life time should be chosen to pre-
vent known plaintext or chosen plaintext attacks.
5.1.1 One pass authentication
d) Either assumption dl) or assumption d2) is met.
In this authentication mechanism the claimant A initi-
ates the process and is authenticated by the verifier B.
dl) The encipherment algorithm and the mode of oper-
Uniqueness / timeliness is controlled by generating aud
ation used in the authentication mechanisius shall pro-
checking a time stamp or a sequence number (see annex
vide the recipient with the means to detect forged or
.
B)
manipulated data. This requires that sufficient redun-
dancy is present in the data, and that any modification
The authentication mechanisni is illustrated in figure 1.
in the plaintext results in an unpredictable modification
of a large number of ciphertext bits.
-
A possible way to provide sufficient redundancy is to
(1) TokenAB
append a hash-code to the data before encipherment. A + B (2)
I
Hash-functions are standardized in Figure 1
NOTE 2 -
ISO/IEC 10118.
The form of the token (TokenAB), seut by the claimant
A to the verifier B is:
If a block cipher algorithm is used for encipherment aud
the block size is smaller than the length of the data to
TokenAB = Text2lleKAB ( pA IIBllTextl),
be enciphered, then the replacement of any block shall
be detectable.
where the claimaut A uses either a sequeuce uumber
NA or a time stamp TA as the time variant parameter.
d2) The integrity of the enciphered data shall be eusured
The choice depends on the technical capabilities of the
by an independent data integrity mechanisiu.
claimant aud the verifier as well as ou the envirounlent.
NOTE 3 - A data integrity mechanism is standard-
The inclusion of the distinguishing ideutifier B in
ized in ISO/IEC 9797.
TokenAB is optional.
5 Mechanisms not involving a trusted NOTE - Distinguishing identifier B is included in
TokenAB to prevent the re-use of TokenAB on entity
third party
A by an adversary masquerading as entity B. Its inclu-
sion is made optional so that, in environments where
In these authentication mechanisms the entities A and
such attacks cannot occur, it may be omitted.
B shall share a coumlon secret authentication key KAB
B may also be omitted
The distinguishing identifier
prior to the coiiiiiiencenient of any particular ruii of the
if entities A and B share a secret key KLo used only
authentication mechanisms.
for the authentication of A by B. The token then
becomes:
The ulechanisms require the use of time variant param-
TokenAB = Text2(leKiB (2 IITextl).
eters such as time stamps, sequence numbers or random A
numbers. The properties of these parameters, in partic-
(1) A sends TokenAB to B.
ular that it is most unlikely for then1 to repeat within
the life-time of an authentication key, are important for
(2) On receipt of the message containing TokenAB,
the security of these mechanisms. For additional infor-
B verifies TokenAB by deciphering the enciphered
mation see annex B.
part and checking the correctness of the distinguish-
ing identifier B, if present, as well as the time stamp
All text fields specified in the following mechanisuls are
or the sequence number.
available for use in applications outside the scope of this
2
---------------------- Page: 4 ----------------------
ISO/IEC 9798-2: 1994(E)
@ ISO/IEC
NOTE - A third mechanism for mutual authenti-
5.1.2 Two pass authentication
cation can be constructed from two instances of the
In this authentication mechanism the claimant A is au- mechanism specified in 5.1.2, one started by entity A
and the other by entity B.
thenticated by the verifier B who initiates the process.
Uniqueness / timeliness is controlled by generating and
checking a random number RB (see annex B).
5.2.1 Two pass authentication
The authentication mechanism is illustrated in figure 2.
In this authentication mechanism uniqueness / time-
liness is controlled by generating and checking time
stamps or sequence numbers (see annex B) .
* (1) RBIlTextI
4
The authentication mechanism is illustrated in figure 3.
+ (3)
A B
(2) TokenAB
\
Figure 2
(1) TokenAB
The form of the token (TokenAB), sent by the claimant
*
(4) A B 0
A to the verifier B is:
4 (3) TokenBA
1
Figure 3
TokenAB = Text3lleKAB (RgIIBIIText2).
The form of the token (TokenAB), sent by A to B, is
The inclusion of the distinguishing identifier B in
identical to that specified in 5.1.1.
TokenAB is optional.
TokenAB = Text2lIeKAB (2A IIBI(Textl).
NOTE - Distinguishing identifier B is included in
TokenAB to prevent a so-called reflection attack. Such
The form of the token (TokenBA), sent by B to A, is:
an attack is characterized by the fact that an intruder
“reflects” the challenge Rg to B pretending to be A.
TokenBA =
Text4lIeKAB ( pB IIAIIText3).
The inclusion of the distinguishing identifier B is made
optional so that, in environments where such attacks
The inclusion of the distinguishing identifier B in
cannot occur, it may be omitted.
TokenAB and the inclusion of the distinguishing identi-
The distinguishing identifier B may also be omitted
if entities A and B share a secret key KLB used only fier A in TokenBA are (independently) optional.
for the authentication of A by B. The token then
becomes:
NOTE 1 - Distinguishing identifier B is included in
TokenAB to prevent the re-use of TokenAB on entity
TokenAB = TextSIJeK& (RgIlText2).
A by an adversary masquerading as entity B. For sim-
ilar reasons the distinguishing identifier A is present in
TokenBA. Their inclusion is made optional so that,
(1) B sends a randonl nunlber RB and, optionally, a
in environments where such attacks cannot occur, one
text field Text1 to A.
or both may be omitted.
(2) A sends TokenAB to B.
The distinguishing identifiers A and B may also be
omitted if entities A and B share two secret keys KLB
(3) On receipt of the message containing TokenAB,
and K&, used respectively for the authentication of
B verifies TokenAB by deciphering the enciphered
A by B and B by A. The tokens then become:
part and checking the correctness of the distinguish-
TokenAB = Text211eKiB (2A IITextl),
ing identifier B, if present, and that the random
number RB, sent to A in step (l), agrees with the
TokenBA = Text411eKkA ( cB IIText3).
random number contained in TokenAB.
The choice of using either time stamps or sequence nuns-
bers in this mechanism depends on the capabilities of the
5.2 Mutual authentication
claimant and the verifier as well as on the environment.
Mutual authentication means that the two communicat-
Steps (1) and (2) are identical to those specified in 5.1.1,
ing entities are authenticated to each other by use of the
one pass authentication.
mechanism.
The two nlechanisnls described in 5.1.1 and 5.1.2 are
(3) B sends TokenBA to A.
adapted in 5.2.1 and 5.2.2, respectively, to achieve mu-
(4) The message in step (3) is handled in a manner
tual authentication. In both cases this requires one more
analogous to step (2) of 5.1.1.
pass resulting in two more steps.
3
---------------------- Page: 5 ----------------------
@ ISO/IEC
ISO/IEC 9798-2: 1994(E)
(4) B sends TokenBA to A.
NOTE 2 - The two messages of this mechanism are
not bound together in any way, other than implicitly
by timeliness; the mechanism involves independent use
(5) On receipt of the message containing TokenBA,
of mechanism 5.1 .l twice. If it is desired to bind these
A verifies TokenBA by deciphering the enciphered
messages further, appropriate use could be made of
part and checking that the random number RB, re-
text fields (see annex A).
ceived from B in step (1) agrees with the random
number contained in TokenBA aud that the ran-
5.2.2 Three pass authentication
dom number RA, sent to B in step (2), agrees with
the random number contained in TokenBA.
In this authentication mechanism uniqueness / timeli-
ness is controlled by generating and checking random
numbers (see annex B).
6 Mechanisms involving a trusted third
The authentication iuechanism is illustrated in figure 4.
party
These authentication mechanisms do uot make use of a
(1) RB IlTextl
4
secret key shared by the two entities prior to the au-
(2) TokenAB
t B (3)
(5) A
thentication process. They do, however, make use of a
trusted third party (with distinguishing identifier TP)
-4 (4) TokenBA
with which the entities A and B each share a secret key,
KAT and KBT respectively. In each iiieclianisu1 one of
Figure 4
the entities requests a key KAB from the trusted third
The tokens are of the following form:
party. This is followed by an adaptatiou of the ulecha-
nisms described in 5.2.1 and 5.2.2, respectively.
TokenAB =
Text3lle&B (h(IhIIBIIText2)
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.