SIST-TS TS 102 165-2 V4.1.1:2004

SLOVENSKI STANDARD
01-april-2004
Harmonizacija telekomunikacij in internetnega protokola prek omrežij (TIPHON), 4.
izdaja - Definicija okvira protokola - Varnostne metode in protokoli - 2. del:
Protiukrepi
Telecommunications and Internet Protocol Harmonization Over Networks (TIPHON)
Release 4; Protocol Framework Definition; Methods and Protocols for Security; Part 2:
Counter Measures
Ta slovenski standard je istoveten z: TS 102 165-2 Version 4.1.1
ICS:
33.020 Telekomunikacije na splošno Telecommunications in
general
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

Technical Specification
Telecommunications and Internet Protocol
Harmonization Over Networks (TIPHON) Release 4;
Protocol Framework Definition;
Methods and Protocols for Security;
Part 2: Counter Measures
2 ETSI TS 102 165-2 V4.1.1 (2003-02)

Reference
DTS/TIPHON-08005-2R4
Keywords
IP, protocol, security, VoIP
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: +33 4 92 94 42 00  Fax: +33 4 93 65 47 16

Siret N° 348 623 562 00017 - NAF 742 C
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° 7803/88

Important notice
Individual copies of the present document can be downloaded from:
http://www.etsi.org
The present document may be made available in more than one electronic version or in print. In any case of existing or
perceived difference in contents between such versions, the reference version is the Portable Document Format (PDF).
In case of dispute, the reference shall be the printing on ETSI printers of the PDF version kept on a specific network drive
within ETSI Secretariat.
Users of the present document should be aware that the document may be subject to revision or change of status.
Information on the current status of this and other ETSI documents is available at
http://portal.etsi.org/tb/status/status.asp
If you find errors in the present document, send your comment to:
editor@etsi.org
Copyright Notification
No part may be reproduced except as authorized by written permission.
The copyright and the foregoing restriction extend to reproduction in all media.

© European Telecommunications Standards Institute 2003.
All rights reserved.
TM TM TM
DECT , PLUGTESTS and UMTS are Trade Marks of ETSI registered for the benefit of its Members.
TM
TIPHON and the TIPHON logo are Trade Marks currently being registered by ETSI for the benefit of its Members.
TM
3GPP is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners.
ETSI
3 ETSI TS 102 165-2 V4.1.1 (2003-02)
Contents
Intellectual Property Rights.6
Foreword.6
1 Scope.7
2 References.7
3 Definitions and abbreviations.7
3.1 Definitions.7
3.2 Abbreviations.8
4 Provision of counter-measures in TIPHON .8
4.1 Required security services.8
4.2 Location of standardization of security services .9
5 Authentication counter-measures.9
5.1 Introduction.9
5.1.1 Description.9
5.2 Keying policy in TIPHON .10
5.2.1 Release 4.10
5.2.1.1 Review of service attributes .11
5.2.2 Release 5 and future.11
6 A1 = Authentication of the terminal.11
6.1 Purpose.11
6.2 Definition.11
6.3 Description.11
6.4 Procedures.12
6.4.1 Provision/withdrawal.12
6.4.2 Normal procedures.13
6.4.2.1 Invocation and operation.13
6.4.3 Exceptional procedures.13
6.4.3.1 Activation/deactivation/registration/interrogation.13
6.4.3.2 Invocation and operation.13
6.5 Interactions with other TIPHON services .13
6.6 Interworking considerations.13
6.7 Functional entity model.14
6.7.1 Description of model.14
6.8 Information flows.14
6.8.1 Definition of information flows.14
6.8.1.1 Relationship ra.14
6.8.1.1.1 A1Auth (req/ind/resp/conf).14
6.8.1.1.2 A1AuthResult.15
6.8.1.2 Relationship rb.15
6.8.1.2.1 A1ChallengeRequest.15
6.9 Information flow sequences .16
6.9.1 Information flows in A1 .17
6.9.1.1 Normal behaviour.17
6.9.1.2 Exceptional behaviour.18
6.9.1.2.1 UserId not recognized by A1-FE3.18
6.9.1.2.2 Key is not available at A1-FE1.19
6.9.2 Functional entity actions.19
6.9.2.1 Actions of A1-FE1.20
6.9.2.2 Actions of A1-FE2.20
6.9.2.3 Actions of A1-FE3.20
6.9.3 Functional entity behaviour .20
6.9.3.1 Behaviour of A1-FE1.21
6.9.3.2 Behaviour of A1-FE2.22
6.9.3.3 Behaviour of A1-FE3.23
ETSI
4 ETSI TS 102 165-2 V4.1.1 (2003-02)
6.9.4 Allocation of functional entities to domains .23
7 A2 = Authentication of the registrar.23
7.1 Purpose.23
7.2 Definition.23
7.3 Description.24
7.4 Procedures.25
7.4.1 Provision/withdrawal.25
7.4.2 Normal procedures.25
7.4.2.1 Invocation and operation.25
7.4.3 Exceptional procedures.25
7.4.3.1 Activation/deactivation/registration/interrogation.25
7.4.3.2 Invocation and operation.25
7.5 Interactions with other TIPHON services .25
7.6 Interworking considerations.25
7.7 Functional entity model.25
7.7.1 Description of model.25
7.8 Information flows.26
7.8.1 Definition of information flows.26
7.8.1.1 Relationship ra.26
7.8.1.1.1 A2Auth.26
7.8.1.1.2 A2AuthResult.27
7.9 Information flow sequences .27
7.9.1 Information flow in A2, normal behaviour.28
7.9.2 Functional entity actions.28
7.9.2.1 Actions of A2-FE1.29
7.9.2.2 Actions of A2-FE2.29
7.9.2.3 Actions of A2-FE3.29
7.9.3 Allocation of functional entities to domains .29
8 A3 and A4, A34 = Mutual authentication terminal and SpoA .29
8.1 Purpose.29
8.2 Definition.30
8.3 Description.30
8.3.1 Overall authentication exchange.31
8.3.1.1 Token definitions.32
8.4 Procedures.33
8.4.1 Provision/withdrawal.33
8.4.2 Normal procedures.33
8.4.2.1 Invocation and operation.33
8.4.3 Exceptional procedures.33
8.4.3.1 Activation/deactivation/registration/interrogation.33
8.4.3.2 Invocation and operation.33
8.5 Interactions with other TIPHON services .33
8.6 Interworking considerations.33
8.7 Functional entity model.34
8.7.1 Description of model.34
8.8 Information flows.35
8.8.1 Definition of information flows.35
8.8.1.1 Relationship ra.35
8.8.1.1.1 A34UserToSpoAAuth.35
8.8.1.1.2 A34UserToSpoAAuthorizedAttach.35
8.8.1.2 Relationship rb.35
8.8.1.2.1 A34SpoAWithUserAuth.35
8.8.1.3 Relationship rc.35
8.8.1.3.1 A34SealingKeyRequest.35
8.9 Information flow sequences .36
8.9.1 Information flow in A3, normal behaviour.37
8.9.2 Functional entity actions.38
8.9.2.1 Actions of A34-FE1.38
8.9.2.2 Actions of A34-FE2.38
8.9.2.3 Actions of A34-FE3.38
ETSI
5 ETSI TS 102 165-2 V4.1.1 (2003-02)
8.9.2.4 Actions of A34-FE4.39
9 A5 = Authentication of the SpoA by the registrar.39
10 A6 = Authentication of the registrar by the SpoA.39
11 Confidentiality service.39
11.1 Provided services.39
11.1.1 E1 = Confidentiality of user communication on the access interface .39
11.1.2 E2 = Confidentiality of signalling on the access interface.39
11.1.3 E3 = Confidentiality of signalling between SpoA entities.39
11.1.4 E6 = Confidentiality of TIPHON-id on signalling interfaces .39
11.1.5 E7 = Confidentiality of signalling between SpoA and Registrar .40
11.2 Confidentiality services E1 and E2 step B specification .40
11.2.1 Description.40
11.2.2 Encryption mechanism.41
11.3 Confidentiality services E3 and E7 step B specification .41
11.3.1 Description.41
11.3.1.1 Algorithm requirements for EA7 .41
Annex A (normative): Boundary conditions of algorithms .42
A.1 Authentication algorithms.42
A.1.1 A1-1.42
A.1.2 A1-2.42
A.1.3 A1-3.42
A.1.4 A2-1.42
A.1.5 A2-2.43
A.1.6 A2-3.43
A.1.7 A34-1.43
A.1.8 A34-2.43
A.1.9 A34-3.43
A.1.10 A34-4.44
A.1.11 A34-5.44
A.1.12 A34-6.44
A.1.13 A34-7.45
A.1.14 A34-8.45
A.1.15 A34-9.45
A.1.16 A34-10.45
A.2 Dimensioning of the cryptographic parameters .45
A.2.1 Terminal-identity.46
A.3 Encryption algorithms.46
A.3.1 EA12 - Confidentiality algorithm.46
A.3.1.1 Overview.46
A.3.1.2 Use.46
A.3.1.3 Extent of standardization .46
A.3.1.4 Implementation and operational considerations.46
A.3.1.5 Type of algorithm .46
A.3.1.6 Interfaces to the algorithm .46
A.3.1.6.1 CK.46
A.3.1.6.2 TVP.47
A.3.1.6.3 DIRECTION.47
A.3.1.6.4 LENGTH.47
A.3.1.6.5 KEYSTREAM.47
A.3.1.6.6 PLAINTEXT.47
A.3.1.6.7 CIPHERTEXT.48
Annex B (informative): Bibliography.49
History .50

ETSI
6 ETSI TS 102 165-2 V4.1.1 (2003-02)
Intellectual Property Rights
IPRs essential or potentially essential to the present document may have been declared to ETSI. The information
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web
server (http://webapp.etsi.org/IPR/home.asp).
All published ETSI deliverables shall include information which directs the reader to the above source of information.
Foreword
This Technical Specification (TS) has been produced by ETSI Project Telecommunications and Internet Protocol
Harmonization Over Networks (TIPHON).
The present document is part 2 of a multi-part deliverable covering Methods and Protocols for security in TIPHON
Release 4, as identified below:
Part 1: "Threat Analysis";
Part 2: "Counter Measures".
ETSI
7 ETSI TS 102 165-2 V4.1.1 (2003-02)
1 Scope
The present document defines by means of an information model, a functional entity behavioural model, and by
validated SDL a model of the abstract behaviour of each service and service capability identified as being essential in
TIPHON R4.
The present document defines by means of meta-protocol, algorithm boundary conditions, and guidance text the
security countermeasures identified in TS 102 165-1 [1].
2 References
The following documents contain provisions which, through reference in this text, constitute provisions of the present
document.
• References are either specific (identified by date of publication and/or edition number or version number) or
non-specific.
• For a specific reference, subsequent revisions do not apply.
• For a non-specific reference, the latest version applies.
Referenced documents which are not found to be publicly available in the expected location might be found at
http://docbox.etsi.org/Reference.
[1] ETSI TS 102 165-1: "Telecommunications and Internet Protocol Harmonization over Networks
(TIPHON) Release 4; Protocol Framework Definition; Methods and Protocols for Security;
Part 1: Threat Analysis".
[2] ETSI TR 101 877: "Telecommunications and Internet Protocol Harmonization Over Networks
(TIPHON); Requirements Definition Study; Scope and Requirements for a Simple call".
[3] ETSI TS 101 878: "Telecommunications and Internet Protocol Harmonization Over Networks
(TIPHON) Release 3; Service Capability Definition; Service Capabilities for a simple call".
[4] ITU-T Recommendation I.130: "Method for the characterization of telecommunication services
supported by an ISDN and network capabilities of an ISDN".
[5] ISO/IEC 9798-2: "Information technology - Security techniques - Entity
authentication - Part 2: Mechanisms using symmetric encipherment algorithms".
[6] ISO/IEC 9798-3: "Information technology - Security techniques - Entity
authentication - Part 3: Entity authentication using a public key algorithm".
[7] ITU-T Recommendation Z.100: "Specification and description language (SDL)".
3 Definitions and abbreviations
3.1 Definitions
For the purposes of the present document, the terms and definitions given in TR 101 877 [2] and TS 101 878 [3] apply.
ETSI
8 ETSI TS 102 165-2 V4.1.1 (2003-02)
3.2 Abbreviations
For the purposes of the present document, the abbreviations given in TR 101 877 [2], TS 101 878 [3] and the following
apply:
CK Cipher Key
FE Functional Entities
FFS For Further Study
KSG Key Stream Generator
KSS Key Stream Segment
MSC Message Sequence Chart
PDU Protocol Data Unit
RSO Random Seed
SDU Service Data Unit
SpoA Service point of Attachement
TpoA Transport point of Attachement
TVP Time Variant Parameter
4 Provision of counter-measures in TIPHON
4.1 Required security services
In TS 102 165-1 [1] the threats to a TIPHON system have been analysed and a set of recommended countermeasures
identified that when implemented will reduce the overall risk to users of TIPHON systems. A subset of these
countermeasures has been identified as essential to counter most threats.
The following security services are identified in [1] as required to minimize the risk to TIPHON to an acceptable level
and are required to be standardized.
- A1 = Authentication of the terminal by the registrar (home of the user profile);
- A2 = Authentication of the registrar by the terminal;
- A3 = Authentication of the terminal by the Service point of Attachment (SpoA);
- A4 = Authentication of the SpoA by the terminal;
- A5 = Authentication of the SpoA by the registrar;
- A6 = Authentication of the registrar by the SpoA;
- C1 - C5 = Access control to services, to service data in databases, to data in terminals,
and to the service provider's software and hardware, respectively;
- E1 = Confidentiality of user communication on the access interface;
- E2 = Confidentiality of signalling on the access interface;
- E3 = Confidentiality of signalling between SpoA entities;
- E6 = Confidentiality of TIPHON-id on signalling interfaces;
- E7 = Confidentiality of signalling between SpoA and Registrar;
- P1 = Bill limitations;
- P2 = Secure billing administration;
- P3 = Subscriber and terminal management;
- P9 = Security related reports to the service providers; and
- P10 = Secure subscription process.

The implementation method of these countermeasures can reduce the risk. However each countermeasure introduces
new threats to the system by adding complexity, and different implementations of the same conceptual countermeasure
may introduce different levels of risk. In some instances a specific countermeasure cannot be applied to a particular
technology.
ETSI
9 ETSI TS 102 165-2 V4.1.1 (2003-02)
4.2 Location of standardization of security services
Not all security services are standardized in the present document. Table 1 identifies the location of standardized
countermeasures.
Table 1: Where counter-measures are provided in TIPHON specifications
Security service Form of standardization Location
A1 Meta-protocol and algorithm specification The present document,
clause 6
A2 Meta-protocol and algorithm specification The present document,
clause 7
A3 Meta-protocol and algorithm specification The present document,
clause 8
A4 Meta-protocol and algorithm specification The present document,
clause 9
A5 Meta-protocol and algorithm specification The present document,
clause 10
A6 Meta-protocol and algorithm specification The present document,
clause 11
C1 Meta-protocol specification TS 101 882-2
C2-C4 FFS TBD
E1 Algorithm specification and application guideline The present document,
clause 12
E2 Algorithm specification and application guideline The present document,
clause 12
E3 Algorithm specification and application guideline The present document,
clause 12
E6 Application guideline The present document,
clause 12
E7 Algorithm specification and application guideline The present document,
clause 12
P1, P2, P3, P9, P10 Management framework requirements TS 101 303

Services A1 and A5 are functionally identical and are described only once. In both cases the entity being authenticated
has direct access to the shared secret, whereas the entity performing the authentication (the registrar) maintains the key
to identity relationship through a third party (the authentication centre). The specific algorithms invoked in A1 and A5
may be different.
Services A2 and A6 are functionally identical and are described only once. The specific algorithms invoked in A2 and
A6 may be different.
Services A3 and A4 are described in the present document as a single mutual authentication service A34.
5 Authentication counter-measures
5.1 Introduction
5.1.1 Description
The primary purpose of the authentication service is to counter masquerade attacks. This may prevent attack on the
system by determining that the user is legitimate, and may prevent an attack on the user by determining that the system
is legitimate. The authentication services when successfully performed provide the first step in provision of access
control to services (C1).
The authentication services are specified with respect to the entities and identities shown in figure 1.
ETSI
10 ETSI TS 102 165-2 V4.1.1 (2003-02)

Registrar
m
m
User Registrant-
id
1m
n
m n
Service SpoA
1 k
NOTE 1: A single user may be associated with many registrant-ids
NOTE 2: A registrant-id shall be associated with only one user
NOTE 3: A registrant-id shall be associated with only one registrar
NOTE 4: A registrar may be associated with many registrant-ids
NOTE 5: A service may be associated with many SpoAs
NOTE 6: In any registration instance a service shall be associated with only one SpoA
NOTE 7: An SpoA shall be associated with only one Service
NOTE 8: A registrant-id may be associated with many Services

Figure 1: Ordinal relations in TIPHON
5.2 Keying policy in TIPHON
5.2.1 Release 4
In TIPHON Release 4 the policy towards keying will assume only symmetric keying methods. This method requires
pre-arrangement between the authenticating entities but ensures that the authentication framework is able to provide a
mapping to existing terminals which employ strong authentication (e.g. GSM, 3GPP-UMTS, DECT, TETRA).
In order to consider the authentication of the principal participants of TIPHON the following constraints on keying arise
from the relations shown in figure 1.
• Registrant to Registrar shall use symmetric key authentication methods.
• Registrar to SpoA shall employ symmetric key authentication methods.
• Registrant to SpoA shall employ a symmetric session key to achieve authentication.

Registrar
User Registrant-
(AuC)
Secret Key K
id
PIN (A7)
(A1&A2)
Secret
key
(A5&A6)
Session
key
exchange
SpoA
(A3&A4)
Figure 2: Key relationships in TIPHON
ETSI
11 ETSI TS 102 165-2 V4.1.1 (2003-02)
As a user may have many registrant-ids the user should be able to identify which to use and access to the registrant-id
should be authenticated using a Personal Identification Number (PIN) or similar. The authentication service (A7) that
provides for this protection of this identity is not described in this edition of the present document.
The symmetric keying authentication methods will be based upon the provisions described in ISO/IEC 9798-2 [5].
5.2.1.1 Review of service attributes
The authentication protocol should have the following properties:
• Bi-directional challenge-response type;
• Able to be initiated either explicitly or as part of the registration procedure;
• Able to be initiated by the terminal or the network;
• The recipient of the first authentication demand may instigate mutual authentication by use of a mutual
authentication indicator, and by sending its challenge together with the response to the first challenge; and
• Where authentication is initiated as part of the registration the authentication timer TA shall always be less
than or equal in value to any registration timer.
5.2.2 Release 5 and future
In TIPHON Release 5 and onwards the policy towards keying will encompass both symmetric and asymmetric keying
methods.
The introduction of asymmetric methods may better counter the threats imposed by soft terminals and replace methods
currently available that are based upon weak authentication methods (e.g. user-name and password). The public keying
authentication methods will be based upon the provisions described in ISO/IEC 9798-3 [6].
6 A1 = Authentication of the terminal
6.1 Purpose
Service A1 offers strong authentication of a terminal to minimize the risk of masquerade of a terminal to the network.
6.2 Definition
The terminal shall contain a unique identity known to the registrar and authentication shall confirm this identity through
proof of knowledge of a secret shared by the registrar and the terminal. This countermeasure is the corollary of A2.
6.3 Description
NOTE: The mechanism here is similar to the three pass authentication method defined in ISO/IEC 9798-2 [5].
The authentication method described is a symmetric secret key type using a challenge-response protocol. In this method
one secret, the authentication key (K-A1), is shared by each of the authenticating parties, and there should be strictly
two parties with knowledge of the secret. Authentication is achieved by the parties proving to each other knowledge of
the shared secret. The authenticating parties are the authentication centre attached to the registrar and the terminal
representing the user.
The following sequence of events illustrates the requirement:
1) The authentication centre shall generate a random challenge and send it to the terminal.
2) Both parties shall generate the intermediate result Intermediate-Result from algorithm A1-1 using the random
challenge and K-A1 as inputs.
ETSI
12 ETSI TS 102 165-2 V4.1.1 (2003-02)
3) The terminal shall generate a random seed for the second stage of the authentication exchange.
4) The terminal shall generate the cryptographic response response using algorithm A1-2 with inputs seed and
Intermediate-Result.
5) The terminal shall send the random seed and the response to the authentication centre.
6) Upon receipt the authentication centre shall generate the expected cryptographic response using the received
random seed and the pre-determined Intermediate-Result with algorithm A1-2. In addition A1-2 should
generate an encryption key derived in this exchange for use in later confidentiality services.
7) The authentication centre shall compare the expected cryptographic response and the received response, if
they are the same the terminal has proven knowledge of K-A1.
In addition to the above event sequence the protocol should be able to confirm randomness of the challenge and of the
second stage seed.
Terminal AuC
Received Generated
Challenge K-A1 Challenge K-A1
A1-1 Challenge A1-1
Generated Received
Seed Int-Result Seed int-Result
Seed, Response
A1-2 A1-2
Response CryptoKey Result X-Response CryptoKey
Response
A1-3
Result
NOTE: The split of the authentication algorithms allows K-A1 and algorithm A1-1 to be stored and maintained
separately (remotely) from the location of A1-2.

Figure 3: Authentication service A1, algorithm invocations
6.4 Procedures
6.4.1 Provision/withdrawal
Authentication shall al
...