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

• Abstract:

  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. This part defines, by means of meta-protocol, algortihm boundary conditions, and guidance text the security countermeasures identified in WI-08005-1R4.

• Status: Published
• Publication Date: 31-Mar-2004
• ICS: 33.020 - Telecommunications in general
• Technical Committee: SPN - Services and Protocols for Networks
• Current Stage: 6060 - National Implementation/Publication (Adopted Project)
• Start Date: 01-Apr-2004
• Due Date: 01-Apr-2004
• Completion Date: 01-Apr-2004
• Ref Project: ETSI TS 102 165-2 V4.1.1 (2003-02) - Telecommunications and Internet Protocol Harmonization Over Networks (TIPHON) Release 4; Protocol Framework Definition; Methods and Protocols for Security; Part 2: Counter Measures

SIST-TS TS 102 165-2 V4.1.1:2004 is the Slovene version of ETSI TS 102 165-2 V4.1.1 for TIPHON Release 4 security methods and protocols, Part 2: Counter Measures. It specifies the countermeasures used to secure TIPHON services, especially authentication and confidentiality, for engineers and implementers of terminals, Service point of Attachement (SpoA), registrars, and related service providers.

The standard describes the abstract behaviour of the essential TIPHON R4 services by using an information model, a functional entity behavioural model, and validated SDL. It gives the meta-protocol, algorithm boundary conditions, and guidance text for the security countermeasures identified in TS 102 165-1.

What does SIST-TS TS 102 165-2 V4.1.1:2004 specify?

SIST-TS TS 102 165-2 V4.1.1:2004 defines the standardized security countermeasures for TIPHON Release 4 and shows how they are organized in the protocol framework. The document focuses on authentication and confidentiality, and it ties those services to the TIPHON service model, functional entities, and information flows.

Clause 4 lists the essential security services identified for TIPHON and shows where each one is standardized. Clause 5 introduces the authentication policy and keying approach, clauses 6 to 10 describe the authentication services A1 to A6, and clause 11 covers the confidentiality services E1, E2, E3, E6 and E7.

Annex	What it covers
Annex A	Normative boundary conditions of algorithms, including authentication algorithms, cryptographic parameter sizes, and the EA12 confidentiality algorithm
Annex B	Informative bibliography

What are the key requirements of SIST-TS TS 102 165-2 V4.1.1:2004?

Clause 4 says that TIPHON security uses a defined set of countermeasures, but this part standardizes only the authentication services A1 to A6 and the confidentiality services E1, E2, E3, E6 and E7. In practice, that tells an implementer which security functions are fully specified here and which are handled in companion documents.

Authentication is based on symmetric key methods in Release 4

Clause 5.2.1 states that TIPHON Release 4 uses symmetric keying methods only. Registrant to Registrar, Registrar to SpoA, and Registrant to SpoA authentication all rely on symmetric secrets or symmetric session keys, so implementations must support shared-key handling rather than only public-key methods.

The same clause says the protocol should support bidirectional challenge-response, explicit or registration-triggered initiation, and initiation by either the terminal or the network. That matters because authentication may be part of normal registration or an on-demand security check, not just a separate login step.

A1 and A2 are paired terminal-registrar authentications

Clause 6 defines A1 as authentication of the terminal by the registrar, and clause 7 defines A2 as authentication of the registrar by the terminal. In both cases the exchange is a symmetric secret-key challenge-response method with an intermediate result, a random seed, and a response comparison.

In practice, A1 and A2 both require the parties to prove knowledge of a shared secret without revealing it. If the expected response does not match, authentication fails and A3, A4, A5 and A6 shall not be invoked, so the document makes authentication a gate before later security exchanges.

A34 is the mutual authentication service for terminal and SpoA

Clause 8 combines A3 and A4 into A34, the mutual authentication of terminal and SpoA. The registrar acts as a trusted third party and the authentication centre creates a session key K34 that is sealed and distributed in tokens.

This matters because there is no direct shared secret between the terminal and the SpoA. The exchange uses challenge values, sealing keys, and the tokens T34-A, T34-B and T34-C to confirm both sides and to finalize authorized attachment.

Authentication supports access control and confidentiality

Clauses 6.5, 7.5 and 8.5 say that the authentication services provide keying material for confidentiality services E1, E2 and E7, and form the basis for access control service C1. That means the authentication exchange is not only for identity proof - it also feeds later security functions with keys and authorization evidence.

E1 and E2 use the EA12 stream cipher model

Clause 11.2 says E1 and E2 are provided by an encryption service between the service encoding unit and the transport service. The required mechanism is a streaming cipher in bit replacement mode, and the same service can protect user communication and signalling on the access interface.

Annex A.3.1 defines EA12 as the confidentiality algorithm. It uses a Cipher Key (CK), a Time Variant Parameter (TVP), a direction bit, and a requested length, and it generates a keystream that is XORed with plaintext. In practical terms, implementers must generate the right keystream length, keep uplink and downlink separate by direction, and derive CK from the authentication cycle.

E3 and E7 protect signalling between service entities

Clause 11.3 says E3 and E7 are also delivered by encryption between the service encoding unit and the transport service. E7 uses a crypto-key derived from A5 and A6, while E3 may require a secure exchange because no pre-provisioned key is guaranteed.

For E7, the standard says the encryption algorithm EA7 shall be defined by its boundary conditions and security shall be maintained for "n" messages. That is a practical lifetime constraint on the protected keying material.

Annex A sets the algorithm boundaries and sizes

Annex A defines the required inputs and outputs for the authentication and encryption algorithms A1-1, A1-2, A1-3, A2-1, A2-2, A2-3, A34-1 to A34-10, and EA12. It also gives the bit lengths of key parameters such as K, Challenge, Response, Seed and CryptoKey.

That annex is what developers use to build interoperable implementations and what test teams use to check that the exchanged values and parameter sizes match the standard.

What terms does SIST-TS TS 102 165-2 V4.1.1:2004 define?

• SpoA - Service point of Attachement; the attachment point that participates in authentication and confidentiality exchanges.
• FE - Functional Entities; the protocol roles used to model the user agent, local authorizing agent, and secret-holder behavior.
• CK - Cipher Key; the key input used by EA12 to generate a keystream for confidentiality.
• TVP - Time Variant Parameter; a time-dependent input to EA12 that forms part of the encryption process.
• RSO - Random Seed; a random value used in the A34 key-sealing and token generation exchanges.
• MSC - Message Sequence Chart; the notation used for the information flow sequences that illustrate normal and exceptional behavior.
• SDU - Service Data Unit; the protected payload unit that is encrypted for confidentiality services.

Who uses SIST-TS TS 102 165-2 V4.1.1:2004?

This standard is used by protocol designers, security engineers, and implementers of TIPHON terminals, registrars, SpoA equipment, and authentication centres. It is also relevant to service providers that need to define access control, confidentiality, and authentication behavior across the service and access interfaces.

Test and interoperability teams use it to check information flows, SDL behavior, and the algorithm boundary conditions in Annex A. Quality managers and buyers can use it to confirm whether a product supports the specific TIPHON security functions needed for a deployment.

Which standards are used with SIST-TS TS 102 165-2 V4.1.1:2004?

• ETSI TS 102 165-1 - provides the threat analysis that identifies the countermeasures standardized in this part.
• ETSI TR 101 877 - supplies definitions used for the TIPHON simple call requirements context.
• ETSI TS 101 878 - supplies additional definitions used in the TIPHON service capability context.
• ITU-T Recommendation I.130 - defines the characterization of telecommunication services and the information flow sequence approach used here.
• ISO/IEC 9798-2 - provides the symmetric entity authentication mechanisms that the Release 4 policy follows.
• ISO/IEC 9798-3 - provides the public-key entity authentication mechanisms mentioned for later release policy.
• ITU-T Recommendation Z.100 - defines SDL, which is used for the functional entity behavior diagrams.
• ETSI TS 101 882-2 - carries the registration and service attachment meta-protocol used alongside the authentication services.
• ETSI TS 101 303 - carries the management framework requirements for P1, P2, P3, P9 and P10.

What does the SIST-TS TS 102 165-2 V4.1.1:2004 document contain?

The document contains clause-by-clause service definitions, information flow sequences, functional entity models, and SDL process diagrams for the authentication services A1, A2 and A34. It also includes token definitions for the A34 exchange and tables that allocate functional entities to TIPHON domains.

Annex A contains the algorithm boundary conditions, the parameter dimensions, and the EA12 interface definitions for CK, TVP, DIRECTION, LENGTH, KEYSTREAM, PLAINTEXT and CIPHERTEXT. Annex B gives the bibliography used by the standard.

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.: [phone]  Fax: [phone]

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:
[e-mail]
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
...