Implementing ETSI ES 201 671 in the Netherlands Version 0.1.1 October 2000 Contents Introduction 3 1 Scope of this document 3 2 General requirements 3 3 HI1 specification 3 4 HI2 Specification 4 4.1 IRI continue records 4 5 HI3 Specification 4 5.1 Mono/stereo mode 4 6 Specific identifiers for LI 5 6.1 Lawful interception identifier (LIID) 5 6.2 Call identifier (CID) 5 6.2.1 Network identifier (NID) 5 6.2.2 Call identity number (CIN) 5 6.3 CC link identifier (CCLID) 6 7 Timing definitions 6 7.1 Definition of interception start 6 7.2 Date & time indication 6 8 Security aspects 6 8.1 Security requirements at the interface port HI2 7 8.1.1 Authentication 7 8.1.2 Confidentiality 7 8.1.3 Integrity 7 8.1.4 TLS parameter 7 8.2 Security requirements at the interface port HI3 8 8.2.1 Verification 8 8.2.2 Authentication 8 9 Undefined parameters 9 E.1 Use of sub-address to carry correlation information 10 E.1.1 Introduction 10 E.1.2 Subaddress options 10 E.1.3 Subaddress coding 10 E.1.3.1 BCD Values 10 E.1.3.2 Field order and layout 11 E.1.4 Field coding 14 E.1.4.1 Direction 14 E.2 Coding of the Calling Party Number 15 Introduction This document lists and fills in the specific items related to the ETSI-LI standard ES 201 671 version 1.1.1. This standard describes a handover interface for the transport of lawful intercepted information between a network operator, access provider and/or service provider and a Law Enforcement Agency (LEA). In the Netherlands, this interface shall be used as the standard interface for the transport of circuit switched lawful intercepted information. General remark: the highlighted text is still under discussion. 1 Scope of this document This document only relates to the sections of ES 201 671 concerning 64 kbit/s based services like PSTN, ISDN and GSM. GPRS is not included. This document should be read a side ES 201 671 v1.1.1. The sections of this document will clarify the Dutch implementation of ES 201 671 v1.1.1 2 General requirements ES 201 671 section 4.3 It shall be possible to implement up to three simultaneous delivery addresses for one target. In practice these three addresses can be part of one, two or three simultaneous ?? lawful authorizations. Remark: Different lawful authorizations can ask for different interception functionalities. This can also apply if the same target is part of different lawful authorizations. 3 HI1 specification ES 201 671 section 4.3, 5.1, 7.2, 12.3 HI1 is the administrative interface. In the this document only references to the functionality of this interface will be made.. At the moment HI1 is a manual interface. The lawful authorization shall be sent via HI1 to the administration center of the NWO/AP/SvP. The LEA shall provide the following information: * Telephone number, IMSI or IMEI number of the interception subject; * Lawful Interception Identifier (LIID); * Start and end time of the interception ; * Kind of information to be provided ( IRI and CC or just the IRI); * * Datanet 1, X.25 address of the LEMF, to which the IRI-Records shall be sent; * ISDN number of the LEMF, to which the content of communication (CC) shall be sent; * Secret key K1 and K2 for the authentication of HI3; * A reference for authorization of the interception; * Technical contact for issues relating to setup and execution of the interception; Note: Stereo mode and option A are preferable to use. See respectivily sections 5.1 and 6.3 of this document. Normally, the NWO/AP/SvP shall send conformation of the acceptance, implementation and expiration of the lawful authorization. In exceptional cases messages could be sent that for example to indicate that the target service is out of order or the interception facility is out of order. Besides information related to an intercept also unrelated information could be sent from the NOW/AP/SvP. Examples are the network, service or intercept facility is (temporarily) not available or being available again. 4 HI2 Specification ES 201 671 section 5.2, 8.1, 8.2 Handover interface HI2 shall transport the Intercept Related Information (IRI). For this interface the public X.25 data network, Datanet 1 shall be used. Other X.25 data networks that are generally available could be used. In this case there has to be an interconnection between this data network and Datanet 1, to prevent the necessity of more interfaces to the LEMF's. The public Internet shall not be used! For the application layer ROSE shall be used while for the layers 1 to 3 TCP/IP on top of X.25 shall be used. 4.1 IRI continue records ES 201 671 section 8.2 An IRI continue record has to be sent at any time during the call that relevant information is available. Examples : any change in location information of intercepted mobile subscribers. In the fixed network examples are UUS messages. 5 HI3 Specification ES 201 671 section 5.3, 9.2 Handover interface HI3 shall transport the Content of Communication (CC). For the delivery of the circuit switched Content of Communication, a public circuit switched ISDN network shall be used while for the delivery of non-circuit switched Content of Communication, e.g. UUS and SMS, HI3 shall use the same physical delivery mechanism as used for HI2 information. 5.1 Mono/stereo mode ES 201 671 section 9 In order to obtain optimal interpretation of the HI3 signal two channels (stereo mode) shall be used. In exceptional cases (strong technical reasons) only the mono signal may be delivered. The LEMF shall implement both options. Each HI3 channel shall have a clear identifier for the part of communication it contains. For transport of the indication of mono/stereo mode in the HI3 message, the "direction" field in the Calling Party Sub address shall be used. 6 Specific identifiers for LI 6.1 Lawful interception identifier (LIID) ES 201 671 section 6.1 For each interception measure, a unique identifier is defined by the lawful Enforcement Agency (LEA), the Lawful Interception Identifier (LIID). The LIID is part of the unique identifier in the information sent via HI2 and HI3. The LIID shall consist of 5 decimal characters. For transport of the LIID in the HI3 message, the Calling Party Subaddress shall be used. The LIID shall be mapped to octets 4, 5 and 6 together with a field separator. 6.2 Call identifier (CID) ES 201 671 section 6.2 For each call or other activity relating to a target identity, a CID is generated by the relevant network element. The CID consists of the following two identifiers: * Network identifier (NID); * Call identity number (CIN). 6.2.1 Network identifier (NID) ES 201 671 section 6.2.1 The network identifier is an international unique parameter describing an operator and a specific mediation function (MF). It consists of the following two identifiers: 1) Operator identifier. This parameter shall consist of 5 decimal characters describing internationally unique a network operator, access provider or service provider 31 + laatste drie cijfers OPTA. For transport of the operator-id. in the HI3 message, the Called Party Subaddress shall be used. The operator-id. shall be mapped to octets 4, 5 and 6 together with a field separator. 10xyz ?? 2) Network element identifier (NEID). The purpose of the NEID is to uniquely identify the relevant mediator function carrying out the LI operation. The NEID is the Calling party number which is available via the ISDN supplementary service CLIP. 6.2.2 Call identity number (CIN) ES 201 671 section 6.2.2 The call identity number is a temporary identifier of an intercepted call, relating to a specific target identity, to identify uniquely an intercepted call. In the HI3 message, the Called Party Subaddress shall be used. The call identity number is 8 decimal digits long and shall be mapped to octets 7, 8, 9 and 10. 6.3 CC link identifier (CCLID) ES 201 671 section 6.3, 10.4 This identifier is only used at the interface ports HI2 and HI3 in case of reuse of CC links (option B). Juridical from the LEA side the need to know accurately which communication is going on demand option A. Juridical from the operator side there is no reason to exclude option A. On the implementation side the capacity issue seems not to be relevant. The actual availability of option A and B in the switch could be an item for discussion. The LEMF shall support both options A and B. If applicable, in the HI3 message the Called Party Subaddress shall be used. The CC link identifier is 8 decimal digits long and shall be mapped to octets 11 - 15. Note1: CCLID is not the same as the CIN. The CIN may implicitly represent the CCLID (see ES 201 671 section 6.3) Note2: CCLID must (also) be sent after a HI3 channel has been set up. This implies UUS3. Since only subaddresses are available, option B will cause a conflict and must be avoided. 7 Timing definitions 7.1 Definition of interception start ES 201 671 section 8.2 In order to decrease the possibility that the first part of the conversation to be intercepted is missed (the call content will not be buffered), the call setup to the LEMF should start at the earliest possible moment. If possible, interception (connection of the circuit of the target to the circuit of the LEMF) should start directly after reception of the answer signal in the call of the target. 7.2 Date & time indication ES 201 671 section 8.4.1 We choose for the option LocalTimeStamp as defined in the 201 671 A.5. Local Dutch time shall be used. There shall be an indication for winter- or summertime. 8 Security aspects ES 201 671 section 13. The two communicating entities, the LEMF and the MF, must be convinced of each other's identity. The LEMF must only accept information sent by an authorized MF. The MF must only send information to a real LEMF. 8.1 Security requirements at the interface port HI2 ES 201 671 section 13.2 The protocol used to transport data at HI2 is standard TCP/IP [ref]. The data transported at HI2 must have the following security properties: The two communicating parties must be authenticated and the transported data must have integrity and confidentiality. Integrity means that the data cannot be altered unnoticed during transport and confidentiality means that the data cannot be interpreted by third parties eavesdropping on the communications link. A standard security mechanism that incorporates all these requirements is TLS [ref] Transport Layer Security. This paragraph will specify the security parameters of TLS. TLS uses the notion of a client and a server. The client initiates the session to the server. In our setup, the MF shall be the client that transports data to the server LEMF. 8.1.1 Authentication Every TLS connection MUST have both client-side and server-side authentication. That means that the MF can be sure that it is talking to the right LEMF, and the LEMF can be sure that it receives data from the correct MF. If either one of these authentication steps fail an alarm MUST be generated. The LEMF can choose whether or not it wants to receive data from a MF which authentication failed. An MF can NEVER send data to an LEMF that fails authentication. (If that would happen, confidential or secret information would end up in a wrong place). The key material for authentication is stored in certificates. A certificate is a dataset that contains the identity of the communicating party together with the necessary cryptographic key material to perform the authentication. These certificates should be renewed every year (this is a standard amount of time for renewal of authentication certificates) RSA is an authentication mechanism that recently has been given free because of the expiration of the patent date. RSA is the mechanism that will be used for authentication. 8.1.2 Confidentiality For the confidentiality of the data Triple DES shall be used. This is a free, standard cryptographic algorithm that has been studied for more than twenty years. 8.1.3 Integrity For the integrity of the data SHA will be used. This is a free, standard cryptographic algorithm. 8.1.4 TLS parameter TLS as defined in RFC 2246 will be used with the following Cipher suite: Cipher suite TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x00, 0x0a) With both client-side authentication and server-side authentication. 8.1.5 Distribution of certificates 8.2 Security requirements at the interface port HI3 ES 201 671 section 13.3 8.2.1 Verification For verification CLIP and COLP shall be checked by the LEMF and MF. IN the Netherlands, ISDN CUG is not available and therefore not applicable. 8.2.2 Authentication Before CC can be delivered from the MF to the LEMF, the communication link shall be authenticated using cryptographic techniques. For authentication, a minimum of two messages is required: one from the MF to the LEMF and one back from the LEMF to the MF. The only messages that are transferred transparently through the ISDN network are subaddressing and user-to-user signalling (UUS). UUS is not supported in the Netherlands and in-band signalling is not an option. Only sub addressing is suitable for authentication. During the administrative phase, two secret 128 bits keys K1 and K2 for use in a symmetric crypto system, shall be transferred from the LEA to the MF via interface port HI1. As a result, for each monitored subscriber, there shall be a unique secret key pair K1 and K2. Before a HI3 setup message is sent from the MF to the LEMF, the MF creates an 8 octet number CHAL1. This number consists of the following fields: * Sequence number SEQ. This is a 3 octet number which is increased by 1 for any new setup message. In case of rollover SEQ advances from 0xFFFFFF to 0x000000. In every MF there is one SEQ for every LEMF. * The LIID. This 3 octet field holds all 5 digits of the LIID plus the field seperator. * Handle value HV. This is a 2 octet random value. CHAL18 octet = SEQ3 octet + LIID3 octet + HV2 octet CHAL1 is encrypted using Triple DES and secret key K2 to produce cipher text CIPH1. Triple DES is a free, standard cryptographic algorithm that has been studied for more than twenty years. In the future it will be replaced by AES. When implementations of AES come available, that could also be used. In this version, however, Triple DES will be used. Ciphertext CIPH1 is send from the MF to the LEMF in the Called Party Sub address. CIPH1 is 8 octets long and shall be mapped to octet 16 to 23. In the LEMF, CIPH1 is decrypted with secret key K2 to obtain CHAL1. The LIID shall be compared with the LIID which is also transmitted in plain text via the Calling Party Sub address. In case of a mismatch, an alarm should be raised and the pending communication link with the MF must be terminated immediately. If no mismatch occurred, the LEMF constructs a similar challenge CHAL2. This is a concatenation of SEQ, LIID and the result of HV exored with magic value 0xFB3C. CHAL28 octet = SEQ3 octet + LIID3 octet + HV2 octet ( 0xFB3C CHAL2 shall be encrypted using Triple DES and secret key K1 to produce cipher text CIPH2. This is send via the Connected Party Sub address back to the MF. In the MF, CIPH2 shall be decrypted using secret key K1 to produce challenge CHAL2. After xoring HV with magic value 0xFB3C, CHAL2 must be compared with CHAL1. In case of any mismatch an alarm should be raised and the connection must be terminated immediately. 9 Undefined parameters ES 201 671 section 8.5, 10.1 In all cases signals have to be translated into existing ASN.1 codes. In cases this is not possible (no examples available) the owner of the specification should assign new codes. 10 Specification of alarm messages E.1 Use of sub-address to carry correlation information Note: This section is based on enhancements made by TC SEC WG LI on the use of sub addressing in HI3. E.1.1 Introduction Not all ISDN networks fully support the use of the UUS1 service [23]. Some networks may be limited to the transfer of only 32 octets of UUS1 user information rather than the 128 required for full support of the UUS1 service. Some networks may not support UUS1 at all. This informative annex describes a procedure to provide correlation information which is appropriate: a) if a network does not support the delivery of UUS1; or b) if a network does not support the delivery of 128 octets for UUS1. If a network supports the delivery of 128 octets for UUS1 then this procedure is not appropriate, and the scheme of subclause 9.3.1 shall be used. The calling party number, the calling party subaddress and the called party subaddress are used to carry correlation information. E.1.2 Subaddress options The coding of a subaddress information element is given in [6]. The following options shall be chosen: Table E.1.1 Option Value Type of subaddress user specified Odd/even indicator (employed for called party subaddress) E.1.3 Subaddress coding The coding of subaddress information shall be in accordance with [6]. E.1.3.1 BCD Values The values 0-9 shall be BCD coded according to their natural binary values. The hexadecimal value F shall be used as a field separator. This coding is indicated in table E.1.2: Table E.1.2 Item BCD representation Bit 4 Bit 3 Bit 2 Bit 1 0 0 0 0 0 1 0 0 0 1 2 0 0 1 0 3 0 0 1 1 4 0 1 0 0 5 0 1 0 1 6 0 1 1 0 7 0 1 1 1 8 1 0 0 0 9 1 0 0 1 Field separator 1 1 1 1 When items are packed two to an octet, the least significant item shall be coded by mapping bit 4 to bit 8, bit 3 to bit 7, etc. E.1.3.2 Field order and layout Fields shall be presented in to the subaddress in the following order: Order Field 1 Network Operator ID 2 CIN 3 CCLID 4 CIPH1 Table E.1.3.1: Field in the Called Party Subaddress Order Field 1 Lawful Interception Identifier (LIID) 4 Direction 2 Service Octets Table E.1.3.2; Fields in the CallingParty Subaddress Each field noted above shall be included, whether empty or not, and a field separator shall separate each field. When a field is empty, that shall be indicated by two consecutive field separators. There shall be no field separator after the final field The Service Octets as available shall always be mapped into octets 19 to 23, as appropriate. If one of the parameters TMR, BC or HLC is not available, the octet shall be fill with 'FF' hex. If Mobile Teleservice Code is not available, octet 23 shall not be transmitted. If Mobile Teleservice Code and Mobile Bearer Service Code are not available, octets 22 and 23 shall not be transmitted. BCD digits shall be mapped two to an octet, the least significant item shall be coded by shifting its 4 bit representation 4 bits to the left, such that bit 8 is filled from bit 4, bit 7 from bit 3, etc. The tables E.1.4 represent calling party subaddress, called party subaddress and connected party subaddress with the maximum length of the identifiers: Bits 5-8 Bits 1-4 Octet Called party subaddress identifier 1 Length of called party subaddress contents 2 Type of subaddress = user specified, odd/even indicator 3 Operator-ID Operator-ID 4 Operator-ID Operator-ID 5 Field separator Operator-ID 6 CIN CIN 7 CIN CIN 8 CIN CIN 9 CIN CIN 10 CCLID Field separator 11 CCLID CCLID 12 CCLID CCLID 13 CCLID CCLID 14 Field separator CCLID 15 CIPH1 16 CIPH1 17 CIPH1 18 CIPH1 19 CIPH1 20 CIPH1 21 CIPH1 22 CIPH1 23 Table E.1.4.1: Called Party Subaddress NOTE 1: Octets 16 - 23 of the Called Party Subaddress are reserved for national use, e.g. for authentication purposes Bits 5 - 8 Bits 1-4 Octet Calling party subaddress identifier 1 Length of called party subaddress contents 2 Type of subaddress = user specified, odd/even indicator according to the amount of BCD-digits 3 LIID LIID 4 LIID LIID 5 LIID LIID 6 LIID LIID 7 LIID LIID 8 LIID LIID 9 LIID LIID 10 LIID LIID 11 LIID LIID 12 LIID LIID 13 LIID LIID 14 LIID LIID 15 Field separator LIID 16 Field separator Direction 17 spare spare 18 Q.763 TMR (note 1) 19 Q.931 BC octet 3 (note 2) 20 Q.931 HLC octet 4 (note 3) 21 Mobile Bearer Service Code (note 4) 22 Mobile Teleservice Code (note 5) 23 Table E.1.4.2: Calling Party Subaddress NOTE 1: if available, the Transmission Medium Requirement according to ITU-T Q.763, 3.54 . If not available, the value is 'FF' hex. NOTE 2: if available, only octet 3 of the Bearer Capability I.E. according to EN 300 403 (or ITU-T Q.931, 4.5.5 ). If not available, the value is 'FF' hex. NOTE 3: if available, only octet 4 of the High Layer Compatibility I.E. according to EN 300 403 (or ITU-T Q.931, 4.5.17). If not available, the value is 'FF' hex. NOTE 4: if available, the Mobile Bearer Service Code according to ETS 300 974, cl. 14.7.10. If not available, the octets 22 and 23 shall not be transmitted. NOTE 5: if available, the Mobile Teleservice Code according to ETS 300 974, cl. 14.7.9. If not available, the octet 23 shall not be transmitted). Bits 5-8 Bits 1-4 Octet Connected party subaddress identifier 1 Length of connected party subaddress contents 2 Type of subaddress = user specified, odd/even indicator 3 CIPH2 4 CIPH2 5 CIPH2 6 CIPH2 7 CIPH2 8 CIPH2 9 CIPH2 10 CIPH2 11 12 13 14 15 16 17 18 19 20 21 22 23 Table E.1.4.1: Connected Party Subaddress . E.1.4 Field coding Each field except for the Service Octets and the authentication octets shall employ decimal coding. Other values are not permitted. E.1.4.1 Direction The direction field shall be coded as follows: Table E.1.5 Indication Value Mono mode (combined signal) 0 CC from target 1 CC to target 2 E.2 Coding of the Calling Party Number The Network Element Identifier (NEID) shall be carried by the calling party number information element. The coding shall be as follows, depending on the type of network access (note 1): Numbering plan identification: ISDN/telephony numbering plan (Recommendation E.164) Nature of address: International number (in case of ISUP signalling) Type of number: International number (in case of DSS1 signalling) Screening indicator Network provided (in case ISUP signalling) Screening indicator User-provided, not screened (in case of DSS1 signalling, note 2) Presentation indicator: Presentation allowed NOTE 1: Usually, the IIF respectively the Mediation Function is connected to the network by links using Signalling System Number 7 and ISDN User Part (ISUP), whereby the parameters are coded according to [5]. But in some cases, the IIF respectively the Mediation Function may be connected via a Basic Rate Access or a Primary Rate Access using D-Channel signalling, whereby the parameters are coded according to [6]. NOTE 2: The network will perform screening, i.e. the number will arrive at the LEMF as 'user-provided, verified and passed'. A network provided number shall also be accepted at the LEMF. 10 Version 0.1.1 october 2 2000 10