SIST ETS 300 393-7:1999

2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.Radijska oprema in sistemi (RES) - Vseevropski sistem snopovnega radia (TETRA) - Optimiran sistem za prenos paketiranih podatkov (PDO) - 7. del: VarnostRadio Equipment and Systems (RES); Trans-European Trunked Radio (TETRA); Packet Data Optimized (PDO); Part 7: Security33.070.10Prizemni snopovni radio (TETRA)Terrestrial Trunked Radio (TETRA)33.020Telekomunikacije na splošnoTelecommunications in generalICS:Ta slovenski standard je istoveten z:ETS 300 393-7 E13SIST ETS 300 393-7:1999en01-PDM-19993SIST ETS 300 393-7:1999SLOVENSKI
STANDARD



SIST ETS 300 393-7:1999



EUROPEANETS 300 393-7TELECOMMUNICATIONMay 1997STANDARDSource: ETSI TC-RESReference: DE/RES-06004-7ICS:33.020Key words:TETRA, PDO, SECURITYRadio Equipment and Systems (RES);Trans-European Trunked Radio (TETRA);Packet Data Optimized (PDO);Part 7: SecurityETSIEuropean Telecommunications Standards InstituteETSI SecretariatPostal address: F-06921 Sophia Antipolis CEDEX - FRANCEOffice address: 650 Route des Lucioles - Sophia Antipolis - Valbonne - FRANCEX.400: c=fr, a=atlas, p=etsi, s=secretariat - Internet: secretariat@etsi.frTel.: +33 4 92 94 42 00 - Fax: +33 4 93 65 47 16Copyright Notification: No part may be reproduced except as authorized by written permission. The copyright and theforegoing restriction extend to reproduction in all media.© European Telecommunications Standards Institute 1997. All rights reserved.SIST ETS 300 393-7:1999



Page 2ETS 300 393-7: May 1997Whilst every care has been taken in the preparation and publication of this document, errors in content,typographical or otherwise, may occur. If you have comments concerning its accuracy, please write to"ETSI Editing and Committee Support Dept." at the address shown on the title page.SIST ETS 300 393-7:1999



Page 3ETS 300 393-7: May 1997ContentsForeword.51Scope.72Normative references.73Definitions and abbreviations.73.1Definitions.73.2Abbreviations.84Air Interface authentication and key management mechanisms.84.1Air interface authentication mechanisms.84.1.1Overview.84.1.2Authentication of a user.94.1.3Authentication of the infrastructure.104.1.4Mutual authentication of user and infrastructure.114.1.5The authentication key.134.1.5.1Generation of K.134.1.6Equipment authentication.144.2Service Description and Primitives.144.2.1BS Authentication primitives.144.2.2MS Authentication primitives.154.3Definition of Protocols.164.3.1Authentication State Transitions.164.3.2Overview of authentication protocol.174.3.2.1Case 1: RPDI authenticates MS.174.3.2.2Case 2: MS authenticates RPDI.184.3.2.3Case 3: Mutual authentication initiated by RPDI.184.3.2.4Case 4: Mutual authentication initiated by MS.204.3.2.5Case 5: RPDI authenticates MS during registration.214.3.2.6Case 6: MS authenticates RPDI during registration.224.3.2.7Case 7: Mutual authentication initiated by MS duringregistration.234.3.2.8Case 8: RPDI rejects authentication demand from MS.254.3.2.9Case 9: MS rejects authentication demand from RPDI.264.3.3PDU descriptions.264.3.3.1D-AUTHENTICATION DEMAND.294.3.3.2D-AUTHENTICATION RESPONSE.294.3.3.3D-AUTHENTICATION RESULT.304.3.3.4D-AUTHENTICATION REJECT.304.3.3.5U-AUTHENTICATION DEMAND.304.3.3.6U-AUTHENTICATION RESPONSE.314.3.3.7U-AUTHENTICATION RESULT.314.3.3.8U-AUTHENTICATION REJECT.314.3.3.9U-TEI PROVIDE.324.3.4MM PDU type 3 information elements coding.324.3.4.1Authentication uplink.324.3.4.2Authentication downlink.324.3.5PDU Information elements coding.334.3.5.1Address extension.334.3.5.2Authentication result.334.3.5.3Authentication reject reason.334.3.5.4Mobile country code.334.3.5.5Mobile network code.334.3.5.6Mutual authentication flag.344.3.5.7PDU type.344.3.5.8Proprietary.34SIST ETS 300 393-7:1999



Page 4ETS 300 393-7: May 19974.3.5.9Random challenge.344.3.5.10Reject cause.354.3.5.11Random seed.354.3.5.12Response value.354.3.5.13TEI.354.3.5.14TEI information.354.3.5.15TEI request flag.364.3.5.16Type 3 element identifier.364.4Boundary conditions for the cryptographic algorithms and procedures.364.5Dimensioning of the cryptographic parameters.384.6Summary of the cryptographic processes.395Secure Enable and Disable mechanism.395.1General relationships.395.2Mechanisms.405.3Service description and primitives.405.4Definition of enable-disable protocol.415.4.1Enable/Disable state transitions.415.4.2Overview of enable-disable protocol.425.4.2.1Disabling an MS using authentication.435.4.2.2Enabling an MS using authentication.445.4.3MM PDUs structures and contents.455.4.3.1D-DISABLE.465.4.3.2D-ENABLE.465.4.3.3U-DISABLE STATUS.475.4.4MM Information elements coding.475.4.4.1Address extension.475.4.4.2Authentication challenge.475.4.4.3Disabling type.475.4.4.4Enable/disable result.485.4.4.5Equipment disable.485.4.4.6Equipment enable.485.4.4.7Equipment status.485.4.4.8Intent/confirm.495.4.4.9PDU Type.495.4.4.10Proprietary.495.4.4.11Subscription disable.495.4.4.12Subscription enable.495.4.4.13Subscription status.505.4.4.14TETRA equipment identity.50History.51SIST ETS 300 393-7:1999



Page 5ETS 300 393-7: May 1997ForewordThis European Telecommunication Standard (ETS) has been produced by the Radio Equipment andSystems (RES) Technical Committee of the European Telecommunications Standards Institute (ETSI).This ETS is a multi-part standard and will consist of the following parts:Part 1:"General network design".Part 2:"Air Interface (AI)".Part 7:"Security".Part 10:"SDL Model of Air Interface", (DE/TETRA-04004-10).Part 11:"PICS Proforma", (DE/TETRA-04004-11).Transposition datesDate of adoption:2 May 1997Date of latest announcement of this ETS (doa):31 August 1997Date of latest publication of new National Standardor endorsement of this ETS (dop/e):28 February 1998Date of withdrawal of any conflicting National Standard (dow):28 February 1998SIST ETS 300 393-7:1999



Page 6ETS 300 393-7: May 1997Blank pageSIST ETS 300 393-7:1999



Page 7ETS 300 393-7: May 19971ScopeThis European Telecommunication Standard (ETS) describes the security mechanisms in theTrans-European Trunked Radio (TETRA) Packet Data Optimized (PDO) standard. It providesmechanisms for authentication and key management mechanisms for the air interface.Clause 4 describes the authentication and key management mechanisms for the TETRA air interface.The following two authentication services have been specified for the air-interface in ETR 086-3 [3], basedon a threat analysis:-authentication of a user by the RPDI;-authentication of the RPDI by a user.The use of encryption is not described in this ETS but may be provided by the application using TETRAPDO as a transport and network service.2Normative referencesThis ETS incorporates by dated and undated reference, provisions from other publications. Thesenormative references are cited at the appropriate places in the text and the publications are listedhereafter. For dated references, subsequent amendments to or revisions of any of these publicationsapply to this ETS only when incorporated in it by amendment or revision. For undated references the latestedition of the publication referred to applies.[1]ETS 300 393-1: "Radio Equipment and Systems (RES); Trans-EuropeanTrunked Radio (TETRA); Packet Data Optimized (PDO); Part 1: Generalnetwork design".[2]ETS 300 393-2: "Radio Equipment and Systems (RES); Trans-EuropeanTrunked Radio (TETRA); Packet Data Optimized (PDO); Part 2: Air Interface(AI)".[3]ETR 086-3: "Radio Equipment and Systems (RES); Trans European TrunkedRadio (TETRA) systems; Technical requirements specification; Part 3: Securityaspects".[4]ISO 7498-2: "Information processing systems - Open Systems Interconnection -Basic reference model - Part 2: Security Architecture".[5]ETS 300 392-7: "Radio Equipment and Systems (RES); Trans-EuropeanTrunked Radio (TETRA); Voice and
Data (V+D); Part 7: Security".3Definitions and abbreviations3.1DefinitionsFor the purposes of this ETS, the following definitions apply:Authentication Code (AC): A (short) key to be entered by the user into the terminal.Authentication Key (K): The primary secret, the knowledge of which has to be demonstrated forauthentication. On the infrastructure side, it is stored in a secure place of the home network. In theterminal it is generated in one of three ways: 1)the authentication key may be generated from anauthentication code AC that is manually entered by the user; 2) the authentication key may be generatedfrom a user authentication key UAK stored in a module (detachable or not); 3) the authentication key maybe generated from both the UAK stored in a module and the PIN entered by the user.Personal Identification Number (PIN): Entered by the user into the terminal and used to generate theauthentication Key (K)together with the User Authentication Key (UAK).Proprietary Algorithm: An algorithm which is the intellectual property of a legal entity.SIST ETS 300 393-7:1999



Page 8ETS 300 393-7: May 1997Random challenge (RAND1, RAND2): A random value generated by the infrastructure to authenticate auser or in a terminal to authenticate the infrastructure, respectively.Random Seed (RS): A random value used to derive a session authentication key from the authenticationkey.Response (RES1, RES2): A value calculated in the terminal from RAND1 and the KS to prove theauthenticity of a user to the infrastructure or by the infrastructure from RAND2 and the KS' to prove itsauthenticity to a user, respectively.Session Authentication Key (KS, KS'): Generated from the authentication key and a random seed forthe authentication of a user. It has a more limited lifetime than the authentication key and can be stored inless secure places and forwarded to visited networks.Spoofer: An entity attempting to obtain service from or interfere with the operation of the system byimpersonation of an authorized system user or system component.User Authentication Key (UAK): Stored in a (possibly detachable) module within the terminal and usedto derive the authentication key (with or without a PIN as an additional parameter).3.2AbbreviationsFor the purposes of this ETS, the following abbreviations apply.ACAuthentication codeAIAir InterfaceBSBase StationITSIIndividual TETRA Subscriber IdentityKAuthentication KeyKSSession authentication KeyLLCLogical Link ControlMACMedium Access ControlMLEMobile Link EntityMMMobility ManagementMSMobile StationPDUProtocol Data UnitPINPersonal Identification NumberRAND1Random challenge 1RAND2Random challenge 2RES1Response 1RES2Response 2RPDIRadio Packet Data InfrastructureRSRandom SeedSAP Service Access PointSDU Service Data UnitTATETRA AlgorithmUAKUser authentication keyXRES1Expected response 1XRES2Expected response 24Air Interface authentication and key management mechanismsNOTE:The algorithms referred to in this clause may be the same as those defined inETS 300 392-7 [5] with some outputs ignored.4.1Air interface authentication mechanisms4.1.1OverviewAuthentication is optional, however if it is used it shall be as described in this clause.SIST ETS 300 393-7:1999



Page 9ETS 300 393-7: May 1997The authentication method described is a symmetric secret key type. In this method one secret, theauthentication key, shall be shared by each of the authenticating parties, and there should be strictly twoparties with knowledge of the secret. Authentication shall be achieved by the parties proving to each otherknowledge of the shared secret.The authenticating parties shall be the authentication centre of the Radio Packet Data Infrastructure(RPDI) and the Mobile Station (MS). The MS is considered, for the purposes of authentication, torepresent the user as defined by the Individual TETRA Subscriber Identity (ITSI). At the air interface theBase Station (BS) is assumed to be trusted by the RPDI and the authentication exchange provesknowledge given to the BS by the authentication centre. This knowledge shall be the sessionauthentication key.Authentication and provision of keys for use at the air-interface shall be linked by the use of a commonalgorithm set. This algorithm set shall include a means of providing keys for use in group calls. Thecontrolling party in all authentication exchanges shall be the RPDI.The authentication process describes a 3-pass challenge-response-result protocol.It is assumed that the intra-system interface linking the BS to the authentication centre is adequatelysecure.4.1.2Authentication of a userIn this subclause, a mechanism is described that shall be used to achieve the authentication of a user ofan MS by the RPDI. This shall be done using a challenge response protocol, with a session authenticationkey derived from an authentication key that shall be shared by the user and the infrastructure. The sessionauthentication key shall be provided by an authentication centre of the home system.The computation of the session authentication key shall be carried out by an algorithm, TA11. Thecomputation of the response shall be done by another algorithm, TA12P.The BS shall generate a random number as a challenge RAND1. The MS shall compute a response,RES1, and the BS shall compute an expected response, XRES1. The BS on receipt of RES1 from the MSshall compare it with XRES1. If the values are equal the result R1 shall be set to TRUE, else the result R1shall be set to FALSE.The process is summarized in figure 1.SIST ETS 300 393-7:1999



Page 10ETS 300 393-7: May 1997Generate RSACKRSTA11KSRS, KSMSGenerate RAND1BSKRSRAND1, RSKSRAND1TA11TA12PKSRAND1XRES1TA12PRES1Compare RES1 toRES1R1XRES1 to give R1RPDIFigure 1: Authentication of a user by the infrastructure4.1.3Authentication of the infrastructureAuthentication of the infrastructure by a user shall be carried out in the same way as described insubclause 4.1.2 with the roles of the claimant and verifier reversed. The MS shall generate a challenge,RAND2, the BS shall generate an actual response, RES2, and the MS shall generate an expectedresponse, XRES2. The MS on receipt of RES2 from the BS shall compare it with XRES2. If the values areequal the result R2 shall be set to TRUE, else the result R2 shall be set to FALSE.The same authentication key K shall be used as in the case of authentication of the user by theinfrastructure together with a random seed RS. However, the algorithms shall be different: TA11 shall bereplaced by TA21 and TA12P by TA22P. Hence, there should also be a different value for the sessionauthentication key, KS'. The process is summarized in figure 2.SIST ETS 300 393-7:1999



Page 11ETS 300 393-7: May 1997Generate RSACKRSTA21KS'RS, KS'Generate RAND2MSBSKRSRAND2KS'RAND2TA21TA22PKS'RAND2RES2TA22PRES2, RSXRES2R2Compare RES2 toXRES2 to give R2RPDIFigure 2: Authentication of the infrastructure by a user4.1.4Mutual authentication of user and infrastructureMutual authentication of user and infrastructure shall be achieved using a combined three passmechanism. The algorithms and key K used shall be same as those used in the one way authenticationdescribed in the previous subclauses. The decision to make the authentication mutual shall be made bythe first party to be challenged, not the initial challenging party. Thus mutual authentication shall be startedas a one way authentication by the first challenging party, and shall be made mutual by the respondingparty.If the first authentication in such a case fails the second authentication shall be abandoned.If the authentication was initiated by the RPDI, it shall use K and one random seed RS with algorithmsTA11 and TA12P to generate a session key KS. It shall then send random challenge RAND1 to the MStogether with random seed RS. The MS shall run TA11 to generate session key KS, and because theauthentication is to be made mutual it shall also run algorithm TA12P to generate a second session keyKS'. Both MS and RPDI shall run algorithm TA12P; the MS then sends its response RES1 back to theRPDI. However, the MS also sends its mutual challenge RAND2 to the RPDI at the same time. The RPDIshall compare the response from the MS RES1 with its expected response XRES1, and because it hasreceived a mutual challenge, it shall run TA12P to generate session key KS'. The RPDI shall then runTA22P to produce its response to the MS's challenge RES2. RES2 is sent to the MS, which shall also runTA22P to produce expected response XRES2. The MS shall compare RES2 with XRES2; and if thesame, mutual authentication will have been achieved.The process is shown in figure 3.SIST ETS 300 393-7:1999



Page 12ETS 300 393-7: May 1997Generate RSKRSACTA11TA21KSKS'RS, KS, KS'Generate RAND2MSGenerate RAND1BSKRSRAND1, RSKS'RAND2TA11TA21TA22PRES1. RAND2KSRAND1KS'RAND2RES2TA12PTA22PRES2, R1KSRAND1RES1XRES2R2TA12PCompare RES2 toXRES2 to give R2XRES1Compare RES1 toXRES1 to give R1RPDIFigure 3: Mutual authentication initiated by RPDIThe mutual authentication process may also occur if a one way authentication is initiated by the MS, andthen made mutual by the RPDI. In this case, the algorithms are the same, however the sequence isreversed as shown in figure 4.SIST ETS 300 393-7:1999



Page 13ETS 300 393-7: May 1997Generate RSKRSACTA11TA21KSKS'RS, KS, KS'Generate RAND2MSGenerate RAND1BSKRSRAND2KS'RAND2TA11TA21TA22PRES2, RS, RAND1KSRAND1KS'RAND2RES2TA12PTA22PRES1, R2KSRAND1RES1XRES2R1TA12PCompare RES2 toXRES2 to give R2XRES1Compare RES1 toXRES1 to give R1RPDIFigure 4: Mutual authentication initiated by MS4.1.5The authentication keyUsers should be authenticated by a process that is carried out in the MS, as described in subclause 4.1.2.To provide against misuse of lost, or stolen, MS, and to authenticate the user to the MS, the user shouldbe required to make an input before K is available and valid for use. K may be stored in a module, whichmay or may not be detachable, and the user may be required to make an input to this module, e.g. apersonal identification number (PIN).4.1.5.1Generation of KACUAKPINUAKKTB1TB2TB3KKFigure 5: Generation of the authentication keyThe generation of K shall be carried out using at least one of the following cases, summarized in figure 5:SIST ETS 300 393-7:1999



Page 14ETS 300 393-7: May 19971)K may be generated from an Authentication Code (AC) that is manually entered by the user. In thiscase AC shall be remembered by the user and should not normally be longer than a few digits. Theprocedure to generate K from AC is labelled TB1.2)K may be generated from a User Authentication Key (UAK). In this case the UAK can be a randomvalue of a desirable length (e.g. 128 bits). The procedure to generate K from UAK is labelled TB2.3)K may be generated from both the UAK stored in a module and the PIN entered by the user. Theprocedure to generate K from UAK and PIN is labelled TB3. In this case the actual checking shallbe carried out implicitly by the infrastructure through the authentication process.4.1.6Equipment authenticationThe authentication of the TETRA Equipment Identity (TEI) is outside the scope of this ETS. However theprotocol described in subclause 4.3 provides a mechanism whereby the BS may demand an MS toprovide TEI in encrypted form as part of the registration exchange.4.2Service Description and PrimitivesNOTE:The primitives described in this subclause are not testable and may be interpreted asfor information only.The primitives of the authentication service are shown in figure 6.MS ApplicationRPDIACTNMM-MS-AUTHENTICATETNMM-BS-AUTHENTICATETNMM-SAPTNMM-SAPLayer 3AI PDUsLayer 3Figure 6: TNMM-AUTHENTICATE primitivesThe description of the authentication mechanisms in subclause 4.1 assigns TA11 and TA21 to AC, andTA12P and TA22P to the BS for the SwMI side. The primitives in the BS and MS may be different.The convention used in this ETS is to pair primitives as in table 1.Table 1: Pairing of primitives across TNMM SAPMM to ApplicationApplication to MMIndicationResponseConfirmRequest4.2.1BS Authentication primitivesAt the TNMM service access point, a specific service shall be provided to allow an application to initiate anauthentication exchange and to receive its result. The primitives required should be as follows (TNMM-BS-AUTHENTICATE in each case):Indication:Used by MM to indicate to AC that a terminal is requesting authentication of the RPDI,or that in systems where authentication is required that a terminal is registering.Response:Used by the AC to supply the session key(s) and random seed to the BS.Request:Used by AC to request authentication of a terminal.Confirm:Used by MM to indicate result of an authentication request.SIST ETS 300 393-7:1999



Page 15ETS 300 393-7: May 1997The content of the primitives should be as shown in table 2.Table 2: Parameters in TNMM-BS-AUTHENTICATE primitiveParameterIndicationResponseRequestConfirmITSIMMMMTypeM-M-Session key-MM-Random seed-MM-Mutual authentication flag-MM-Second session key-CC-Result---MThe parameters should be coded as below:Type =Registration;Authentication demand.Result =Success;RPDI authentication fail;Terminal authentication fail;Terminal authentication reject.Parameters ITSI, KS, RS, MF, KS', R should be coded as binary streams with maximum lengths asdefined by table 32.4.2.2MS Authentication primitivesAt the TNMM service access point, a specific service shall be provided to allow an application to initiate anauthentication exchange and to receive its result. The MS-MM shall respond to an authentication demandfrom the RPDI. The primitives required should be as follows (TNMM-MS-AUTHENTICATE in each case):Indication:Used by MM to indicate to the application that the RPDI is requesting the terminal toauthenticate itself.Response:Used by the application to supply the session key(s) and random seed to the terminal.Request:Used by the application to request authentication of the RPDI.Confirm:Used by MM to indicate result of an authentication request.The content of the primitives should be as shown in table 3.Table 3: Parameters in TNMM-MS-AUTHENTICATE primitiveParameterIndicationResponseRequestConfirmTypeM-M-Session key-MM-Random seed-MM-Mutual authentication flag-MM-Second session key-CC-Result---MSIST ETS 300 393-7:1999



Page 16ETS 300 393-7: May 1997The parameters should be coded as below:Type =Registration;Authentication demand;Result =Success;RPDI authentication fail;RPDI authentication reject;Terminal authentication fail;Terminal authentication reject.Parameters KS, RS, MF, KS', R should be coded as binary streams with maximum lengths as defined bytable 32.4.3Definition of Protocols4.3.1Authentication State TransitionsFigure 7 gives an overview of the received PDUs that result in a change of authentication state. It isassumed that the initial state is Not-Authenticated and that demands for authentication may also be madewhen parties are in an authenticated state.AUTHENTICATE Result (success)AUTHENTICATE DemandAuthenticatedAuthenticatePendingNotAuthenticatedAUTHENTICATE DemandAUTHENTICATE Result (fail)Any message containing anAny message containing anAny message containing anAny message containing anFigure 7: Authentication State transitionsSIST ETS 300 393-7:1999



Page 17ETS 300 393-7: May 19974.3.2Overview of authentication protocolThe air interface authentication protocol shall use the Mobility Management (MM) service of layer 3 in theTETRA protocol stack (see ETS 300 393-2 [2], clause 15).An authentication exchange can be requested, either explicitly or as part of the registration procedure. Itcan be initiated by the MS or RPDI. The initiating side shall send an "AUTHENTICATION DEMAND" PDUthat shall always be answered by the other side with an "AUTHENTICATION RESPONSE" PDU. Successor failure of the authentication shall be communicated by a specific "AUTHENTICATION RESULT" PDU.The recipient of the first authentication demand may instigate mutual authentication by use of the mutualauthentication indicator, and by sending its challenge together with the response to the first challenge. Inthis case, the response to this second challenge shall be sent together with the result of the firstchal
...