Kiri

German Federal Network Agency Federal Network Agency for Electricity, Gas, Telecommunications, Post and Railway __________________________________________ Technical Guideline implementing legal measures for telecommunications surveillance and information provision [TR TKÜV] * Edition 8.1 As at: Draft Editor and publisher: Federal Network Agency for Electricity, Gas, Telecommunications, Post and Railway Surveillance and Information Unit; Telecommunications emergency preparedness Canisiusstraße 21 55122 Mainz Germany * Notified in accordance with Directive (EU) 2015/1535 of the European Parliament and of the Council of 9 September 2015 laying down a procedure for the provision of information in the field of technical regulations and of rules on Information Society services (OJ L 241, 17.9.2015, p. 1).  TR TKÜV, edition 8.1 (draft) Page 3 Contents 1. Scope ........................................................................................................................................................ 8 2. Content of the present edition of the Technical Guideline ........................................................................ 8 3. Definitions .................................................................................................................................................. 9 3.1 Telecommunications content (content of communication, CC) ............................................................... 9 3.2 Intercept-related information (IRI) ........................................................................................................... 9 3.3 Surveillance copy .................................................................................................................................... 9 3.4 Internet gateway ...................................................................................................................................... 9 3.5 OP telecommunications system (OPTS) ................................................................................................. 9 3.6 Transmission network ............................................................................................................................. 9 3.7 Concept ................................................................................................................................................... 9 4. Normative references ................................................................................................................................ 9 5. Abbreviations ........................................................................................................................................... 10 Part A. Technical implementation of legal measures for telecommunications surveillance ............ 13 1. General .................................................................................................................................................... 13 2. Structure .................................................................................................................................................. 13 2.1 Overview of system-specific and service-specific Annexes and the informative Part .......................... 13 3. Technical specifications .......................................................................................................................... 14 3.1 Surveillance copy transmission ............................................................................................................. 14 3.1.1 General requirements......................................................................................................................... 14 3.1.2 General requirements to avoid multiple transmissions ...................................................................... 15 3.1.3 Requirements on mobile networks and mobile-based IMS platforms ................................................ 15 3.1.4 Requirements on voice, fax and data storage equipment (voicemail systems, unified messaging systems, etc.) .................................................................................................................................... 15 3.1.5 Requirements on the email service .................................................................................................... 15 3.1.6 Requirements on the Internet gateway .............................................................................................. 16 3.1.7 Requirements on VoIP and other multimedia services ...................................................................... 16 3.1.8 Requirements on number-independent interpersonal telecommunications services other than for email services ................................................................................................................................... 16 3.2 Dimensioning and monitoring ................................................................................................................ 16 3.3 Measures to provide the complete surveillance copy at the IP-based handover interface ................... 16 3.3.1 Buffering ............................................................................................................................................. 17 3.3.2 MTU size ............................................................................................................................................ 17 3.3.3 ‘Alive’ test of transmission path availability ........................................................................................ 18 3.3.4 Standardised error messages (HI1 messages).................................................................................. 18 3.4 Protection requirements and technical specifications for order data storage ....................................... 19 4. Other requirements ................................................................................................................................. 19 4.1 Identifiers to implement interception measures..................................................................................... 19 4.2 Transmission procedure for notifications and confirmations of functional tests for recording and analysis equipment of the authorised agencies .................................................................................. 21 Annex A. Data transmission specifications ................................................................................................. 22 Annex A.1 FTP and TCP/IP SPECIFICATIONS ......................................................................................... 22  TR TKÜV, edition 8.1 (draft) Page 4 Annex A.1.1 File name ................................................................................................................................ 22 Annex A.1.2 Parameters ............................................................................................................................. 23 Annex A.2 Specifications for participation in the VPN and an alternative procedure based on HTTPS/TLS .................................................................................................................................. 24 Annex A.3 Transmission of HI1 IRI and HI2 data for additional events ...................................................... 27 Annex A.3.1 Transmission options .............................................................................................................. 27 Annex A.4 Failed transmission of the surveillance copy to the lines of the authorised agency .................. 28 Annex B (Removed: Handover interface for circuit-switched networks (national)) ..................................... 29 Annex C (Removed: PSTN and ISDN (ETSI ES 201 671 and TS 101 671)) ............................................. 30 Annex D. Specifications for mobile networks and mobile-based IMS platforms (3GPP TS 33.108 and TS 33.128)......................................................................................................................................... 31 Annex D.1 Selected options and additional technical requirements ........................................................... 32 Annex D.1.1 Basis: 3GPP TS 33.108 ......................................................................................................... 32 Annex D.1.2 Basis: 3GPP TS 33.128 ......................................................................................................... 39 Annex D.2 Explanatory notes on ASN.1 descriptions ................................................................................. 39 Annex E. Handover interface for voice, fax and data storage equipment (voicemail systems, unified messaging systems, etc.).................................................................................................................. 40 Annex E.1 Definitions .................................................................................................................................. 40 Annex E.2 General explanatory notes ........................................................................................................ 40 Annex E.3 Transmission methods and specification of relevant events ..................................................... 41 Annex E.3.1 Transmission methods for telecommunications under surveillance ....................................... 41 Annex E.3.2 Specification of relevant events .............................................................................................. 42 Annex E.4 Requirements on surveillance of voice and fax messages and SMS as per Annexes B, C or D ............................................................................................................................ 43 Annex E.5 Requirements on surveillance of voice and fax messages, SMS and MMS within an XML- encoded file ....................................................................................................................................... 43 Annex E.5.1 IRI parameters ........................................................................................................................ 43 Annex E.5.2 XML structure and DTD for voice, fax, SMS and MMS .......................................................... 44 Annex F. Email service storage equipment ................................................................................................. 47 Annex F.1 Definitions, basic information ..................................................................................................... 47 Annex F.2 Nationally specified email handover interface ........................................................................... 48 Annex F.2.1 IRI parameters ........................................................................................................................ 50 Annex F.2.2 XML structure and DTD .......................................................................................................... 51 Annex F.3 Email handover interface as per ETSI TS 102 232-2 ................................................................ 52 Annex F.3.1 Selected options and additional technical requirements ........................................................ 53 Annex F.3.1.1 Basis: ETSI TS 102 232-1 ................................................................................................... 53 Annex F.3.1.2 Basis: ETSI TS 102 232-2 ................................................................................................... 54 Annex F.3.2 Explanatory notes on the ASN.1 descriptions ........................................................................ 55 Annex G. Internet gateway (ETSI TS 102 232-3 and ETSI TS 102 232-4) ................................................ 56 Annex G.1 Selected options and additional technical requirements ........................................................... 57 Annex G.1.1 Basis: ETSI TS 102 232-1 ...................................................................................................... 57 Annex G.1.2 Basis: ETSI TS 102 232-3 ...................................................................................................... 58 Annex G.1.3 Basis: ETSI TS 102 232-4 ...................................................................................................... 59 Annex G.2 Explanatory notes on ASN.1 descriptions ................................................................................. 60  TR TKÜV, edition 8.1 (draft) Page 5 Annex H. Specifications for VoIP, other multimedia services in fixed networks and fixed-line IMS platforms (ETSI TS 102 232-5 und ETSI TS 102 232-6) .................................................................................. 61 Annex H.1 Basic requirements on the application of service-specific details for IP multimedia services (ETSI TS 102 232-5) ......................................................................................................................... 62 Annex H.1.1 Definitions ............................................................................................................................... 62 Annex H.1.2 Basic information .................................................................................................................... 62 Annex H.1.3 Provision of CC in cases of separate transmission of signalling ............................................ 62 Annex H.1 Requirements on the application of service-specific details for PSTN/ISDN services (ETSI TS 102 232-6) ......................................................................................................................... 63 Annex H.3 Selected options and additional technical requirements ........................................................... 63 Annex H.3.1 Basis: ETSI TS 102 232-1 ...................................................................................................... 63 Annex H.3.2 Basis: ETSI TS 102 232-5 ...................................................................................................... 65 Annex H.3.3 is removed. ............................................................................................................................. 67 Annex H.3.4 Basis: ETSI TS 102 232-6 ...................................................................................................... 67 Annex H.4 Explanatory notes on ASN.1 descriptions ................................................................................. 68 Annex I. Number-independent interpersonal telecommunications services other than email services (ETSI TS 103 707 and ETSI TS 102 232-2) ............................................................................................... 69 Part B. Technical implementation of legal measures for information provision ................................ 70 1. Basic principles ....................................................................................................................................... 70 2. Transmission procedures ETSI-ESB and Email-ESB ............................................................................. 70 3 Assurance of data security and data quality ............................................................................................ 71 3.1 Safeguards and technical details for order data storage ...................................................................... 71 3.2 Special requirements on transmission of traffic data that must be stored as per § 176 TKG ............... 71 3.2.1 Assurance of a particularly high standard of data security ................................................................ 72 3.2.2 Use of particularly secure encryption methods, buffering in the transmission procedure components and deletion of traffic data in the query system ................................................................................ 73 3.2.3 Application of the four-eyes principle for access to and transmission of traffic data ......................... 73 3.2.4 Physical security of the transmission procedure ................................................................................ 74 3.3 Time until traffic data availability ........................................................................................................... 74 Annex A. ETSI-ESB transmission procedure .............................................................................................. 75 1. Basic information ..................................................................................................................................... 75 1.1 Basic description of the procedure ........................................................................................................ 75 1.2 Procedural requirements ....................................................................................................................... 76 1.3 Details on the different possible applications ........................................................................................ 77 1.3.1 Traffic data retrieval ............................................................................................................................ 78 1.3.2 Real-time traffic data retrieval ............................................................................................................ 79 1.3.3 Retrieval of radio cell structure information ........................................................................................ 80 1.3.4 Subscriber data retrieval .................................................................................................................... 80 1.3.5 Urgent location retrieval ..................................................................................................................... 81 1.3.6 Transmission of orders and other telecommunications interception measures ................................. 81 1.3.7 Transmission of invoice reconciliation data in advance of compensation as per § 23(1) JVEG (optional) ........................................................................................................................................... 83 1.4 Electronically secured order transmission ............................................................................................. 83 2. Handover interface as per ETSI Specification TS 102 657 ..................................................................... 83  TR TKÜV, edition 8.1 (draft) Page 6 2.1 Selected options for ETSI TS 102 657 .................................................................................................. 83 2.2 Additional technical requirements for the interface description as per ETSI TS 102 657 ..................... 85 2.2.1 HTTP transmission method ................................................................................................................ 85 2.2.2 Error handling ..................................................................................................................................... 86 2.2.3 Formats .............................................................................................................................................. 87 2.2.4 Standardisation of response data for selective retrieval of subscriber and traffic data ..................... 89 2.2.5 Flexible use of free text field ‘otherInformation’.................................................................................. 89 3. Definition of national parameters............................................................................................................. 89 3.1 General .................................................................................................................................................. 89 3.2 Description of national XML module ‘Natparas2’ (for requests)............................................................ 90 3.2.1 Usage types ....................................................................................................................................... 90 3.2.2 Supplementary data in national XML module Natparas2 ................................................................... 90 3.3 National XML module ‘Natparas3’ (for responses) ............................................................................... 95 3.3.1 Specifications for supplementary data in national XML module Natparas3....................................... 95 3.3.2 Specifications for supplementary data in national XML module Natparas3....................................... 96 4. Transmission of data to assert the claim for compensation as per Annex 3 to § 23(1) JVEG ............. 100 4.1 Basic information ................................................................................................................................. 100 4.2 Methods of electronic transmission ..................................................................................................... 100 Annex A. Explanation of the procedure ..................................................................................................... 101 Annex A.1 Main communication flow ........................................................................................................ 101 Annex B. Email-ESB transmission procedure ........................................................................................... 106 1. Basic information ................................................................................................................................... 106 2. Additional usage specifications for traffic data as per §§ 175 and 176 TKG ........................................ 106 Part C. Technical implementation of the legal obligation to cooperate in technical identification measures for mobile terminals .................................................................................................... 108 1. Basic information ................................................................................................................................... 108 2. Arrangements for network connection of technical means and the procedure for automated provision of information on identifiers ................................................................................................................. 108 2.1 Connection of technical means with the mobile network .................................................................... 108 2.2 Procedure for automated provision of information on identifiers......................................................... 109 2.2.1 Selected options and additional technical requirements .................................................................. 110 2.3 Protection of network connection and procedure for automated provision of information on identifiers ...................................................................................................................................... 110 Part X. Information Annex ...................................................................................................................... 111 Annex X.1 Proposed changes to the TR TKÜV ........................................................................................ 111 Annex X.1.1 Transmission of packet-switched voice communication services (e.g. VoLTE) ................... 111 Annex X.1.2 Future requirements on mobile communications, in particular 5G ....................................... 112 Annex X.2 Assignment of an identification feature for authorised agencies to guarantee unique reference numbers .......................................................................................................................................... 114 Annex X.3 Registration and certification authority of the Federal Network Agency (TKÜV CA), Unit IS16 (Policy) ............................................................................................................................................ 115 1. General .................................................................................................................................................. 115 1.1 Introduction .......................................................................................................................................... 115 1.2 Identity of registration and certification authority TKÜV CA ................................................................ 115  TR TKÜV, edition 8.1 (draft) Page 7 1.3 General information services of the TKÜV CA .................................................................................... 115 1.4 Validity of this document ..................................................................................................................... 115 2. Services of the TKÜV CA ...................................................................................................................... 115 2.1 Certificate generation, Crypto-box configuration, CA management .................................................... 115 2.2 Security of the CA equipment.............................................................................................................. 116 3. Requirements on participants................................................................................................................ 116 4. Registration rules .................................................................................................................................. 116 4.1 Registration of authorised agencies .................................................................................................... 116 4.2 Registration of obligated parties .......................................................................................................... 116 5. Certification rules ................................................................................................................................... 117 5.1 Data to be provided ............................................................................................................................. 117 5.2 Instructions .......................................................................................................................................... 119 5.3 Test of the security relationships and the Crypto-box configuration used .......................................... 119 5.4 Data sheet for unique addressing of subnets...................................................................................... 119 5.5 Example layout .................................................................................................................................... 120 6. Blocking a Crypto-box configuration ..................................................................................................... 120 7. Distribution and handling of smart cards ............................................................................................... 120 8. Card content .......................................................................................................................................... 121 9. Management of Crypto-box configurations/selected options ................................................................ 122 9.1 Architecture of management system and test equipment at the Federal Network Agency ................ 122 10. Selected options/values ...................................................................................................................... 123 10.1 Log server.......................................................................................................................................... 123 10.2 Heartbeat ........................................................................................................................................... 123 10.3 NTP server ........................................................................................................................................ 123 10.4 Provision of partner subnet IP addresses ......................................................................................... 123 10.5 Hot standby (HSB) ............................................................................................................................ 123 10.6 Crypto-box software version.............................................................................................................. 124 10.7 Smart cards ....................................................................................................................................... 124 11. Other applicable documents................................................................................................................ 124 Annex X.4 Sample draft for preparation of the documentary evidence, test protocols and test reports... 125 Updates ..................................................................................................................................................... 126 Edition list .................................................................................................................................................. 127 TR TKÜV, edition 8.1 (draft) Page 8 1. Scope This Technical Guideline (TR TKÜV) sets out technical specifications implementing legal measures for telecommunications surveillance, cooperation in technical identification measures for mobile terminals and information provision, by virtue of § 170(6) of the Telecommunications Act [TKG] [21] on conjunction with § 36 of the Telecommunications Surveillance Ordinance [TKÜV] [14] in accordance with §§ 9 and 12 of the Telecommunications and Telemedia Data Protection Act [TTDSG] [41] and the first sentence of § 171 and §§ 174(7) and 177(3) TKG. As per § 170(6) TKG, the Federal Network Agency [BNetzA] drafts the TR TKÜV in consultation with the authorised agencies and with the participation of associations of the obligated parties and the manufacturers of surveillance, recording and analysis equipment. This process must take international standards into account, and justify any deviations from the standards. The Federal Network Agency must publish the Technical Guideline on its website; it must announce this publication in its official journal. The Federal Network Agency must use the process to amendments the TR TKÜV to bring it into line with the current state of the art. In principle, the TR TKÜV can define the dates up to which previous technical regulations may still be applied. The TR TKÜV must also specify the types of identifiers that require additional arrangements for technical implementation of orders for specific types of telecommunications systems, in addition to the originating and destination addresses it uses, under the laws governing telecommunication surveillance. In cases where the TR TKÜV does not include new technical developments, the obligated party must coordinate with the Federal Network Agency on the design of its surveillance equipment. 2. Content of the present edition of the Technical Guideline The first edition of the Technical Guideline was published in December 1995 as TR FÜV, edition 1.0. Over the past 20 years, it has undergone continuous amendment for new legislation and for the state of the art; the current 19th edition of the Technical Guideline is published as TR TKÜV, edition 8.1. Edition 8.1 of the TR TKÜV differs from the previous version (8.0) in that it includes provisions on cooperation in technical identification measures for mobile terminals, protection requirements and technical specifications for saving order data, provisions on the transmission of signed documents and amendments due to discontinuation of the ISDN-based handover interface. In addition, other parts of the TR TKÜV have also undergone substantive and editorial amendments. The TR TKÜV, edition 8.1, includes the following four Parts (A, B, C and X):  Part A. Technical implementation of legal measures for telecommunications surveillance This Part gives the technical details on the surveillance equipment and the required technical characteristics of the recording lines.  Part B. Technical implementation of legal measures for information provision This Part gives the technical details on equipment for retrieval of subscriber and traffic data and, in particular, the optional procedure to transmit a copy of the order to implement the measures.  Part C. Technical implementation of the legal obligation to cooperate in technical identification measures for mobile terminals This Part gives the technical provisions enabling use of the technical means of the authorised agencies in public mobile networks to find certain information from mobile terminals and provide automated information on the identifiers temporarily and permanently assigned in a mobile network.  Part X. Information Annex This informative Part includes the planned further amendments to the TR TKÜV, the basis for discussion for the next edition, additional information on Parts A and B of this edition, rules on the registration and certification authority (TKÜV CA) and a version history for the TR TKÜV. TR TKÜV, edition 8.1 (draft) Page 9 3. Definitions In addition to the definitions in the TKÜV, the following definitions also apply in this Guideline: 3.1 Telecommunications content (content of communication, CC) The part of telecommunication under surveillance that contains the content of communication exchanged between users or their terminals (such as voice, email or IP traffic). 3.2 Intercept-related information (IRI) Data to be provided as per § 7 TKÜV on the further circumstances of the telecommunication under surveillance. These data must be provided even if the telecommunications content is not successfully transmitted (e.g. user busy). 3.3 Surveillance copy According to § 2(14) TKÜV, the duplicate of the telecommunication under surveillance to be transmitted (CC and IRI). 3.4 Internet gateway The transmission route that serves for direct user-specific access to the Internet as per § 2(12) in conjunction with § 3(2)(first sentence)(3) TKÜV. 3.5 OP telecommunications system (OPTS) As a general rule, the Obligated Party’s Telecommuniations System is the origin of the telecommunication on the line under surveillance (LuS) for outgoing traffic and its destination for incoming traffic (such as subscriber exchange, UMS, email server). 3.6 Transmission network The network used to transmit the surveillance copy from the OPTS to the authorised agency (CC and/or IRI). 3.7 Concept Documents as per § 170(1)(4)(a) TKG. 4. Normative references The table below gives the references used in the TR TKÜV: [1] to [12] removed [1] ETSI TS 123 003 Digital cellular telecommunications system (Phase 2+) (GSM); Universal Mobile Telecommunications System (UMTS); LTE; 5G; Numbering, addressing and identification [2] TKÜV Ordinance on the technical and organisational implementation of measures for telecommunications surveillance (Telecommunications Surveillance Ordinance [TKÜV]) [15] to [20] (removed) [3] TKG Telecommunications Act [Telekommunikationsgesetz] [22] ETSI ES 201 671/ Telecommunications security; Lawful Interception (LI); Handover interface ETSI TS 101 671 for the lawful interception of telecommunications traffic [23] 3GPP TS 33.108 3G security; Handover interface for Lawful Interception (LI) (ETSI TS 133 108) [24] RFC 4880 OpenPGP Message Format [25] to [28] (removed) [29] ETSI TS 102 232 or Telecommunications security; Lawful Interception (LI); Handover ETSI TS 102 232-1 specification for IP delivery TR TKÜV, edition 8.1 (draft) Page 10 [30] ETSI TS 102 233 or Telecommunications security; Lawful Interception (LI); Service-specific ETSI TS 102 232-2 details for email services [31] ETSI TS 102 234 or Telecommunications security; Lawful Interception (LI); Service-specific ETSI TS 102 232-3 details for Internet access services [32] ETSI TS 102 815 or Telecommunications security; Lawful Interception (LI); Service-specific ETSI TS 102 232-4 details for Layer 2 Lawful Interception [33] ETSI TS 101 909-20-2 Digital Broadband Cable Access to the Public Telecommunications Network; IP Multimedia Time Critical Services; Part 20: Lawful Interception; Sub-part 2: Streamed multimedia services [34] ETSI TS 102 232-5 Telecommunications security; Lawful Interception (LI); Service-specific details for IP Multimedia Services [35] ETSI TS 102 232-6 Telecommunications security; Lawful Interception (LI); Service-specific details for PSTN/ISDN services [36] (removed) [37] ETSI TS 102 657 Telecommunications security; Lawful Interception (LI); Retained data handling; Handover interface for the request and delivery of retained data [38] ETSI TS 103 120 Lawful Interception (LI); Interface for warrant information [39] ETSI TS 103 707 Lawful Interception (LI); Handover for messaging services over HTTP/XML [40] 3GPP TS 33.128 Security; Protocol and procedures for Lawful Interception (LI); Stage 3 (ETSI TS 133 128) [41] TTDSG Act governing data and privacy protection in telecommunications and telemedia (Telecommunications and Telemedia Data Protection Act) [42] ETSI TS 103 221-1 Lawful Interception (LI); Internal Network Interfaces; Part 1: X1 [43] ETSI TS 103 221-2 Lawful Interception (LI); Internal Network Interfaces; Part 2: X2/X3 [44] (removed) [45] BSIG Federal Office for Information Security Act [46] TR-03116-4 Cryptographic requirements on Federal Government projects; Part 4: Communication procedure in applications [47] TR-02102-2 Cryptographic procedures: Recommendations and key lengths; Part 2 - Use of Transport Layer Security (TLS) [48] TR-02103 X.509 Certificates and certification path validation [50] RFC 5322 Internet Message Format [51] RFC 6530 Overview and Framework for Internationalized Email [52] RFC 6531 SMTP Extension for Internationalized Email [53] RFC 6532 Internationalized Email Headers [54] RFC 6533 Internationalized Delivery Status and Disposition Notifications [55] RFC 2045 Multipurpose Internet Mail Extensions, (MIME) - Format of Internet Message Bodies 5. Abbreviations The following abbreviations are used in the TR TKÜV: 3GPP Third Generation Partnership Project 5G 5th Generation Mobile Network ACL Access Control List ASCII American National Standard Code for Information Interchange ASN.1 Abstract Syntax Notation One BC Bearer Capability TR TKÜV, edition 8.1 (draft) Page 11 bS Authorised agency [berechtigte Stelle] BSI Federal Office for Information Security BSIG Federal Office for Information Security Act BSS Base Station Subsystem CA Certificate Authority CC Content of Communication DCF77 77.5-kHz ‘Mainflingen’ time signal transmitter, which broadcasts the official time for the Federal Republic of Germany produced by the National Metrology Institute of Germany [PTB] DTD Document Type Definition ESB Specification of the electronic interface for information and connection data requests and telecommunications surveillance and tracing ETSI European Telecommunications Standards Institute FTP File Transfer Protocol GLI Global Line Identifier GLIC GPRS Lawful Interception Correlation GPRS General Packet Radio Service GSM Global System for Mobile Communications GUTI Globally Unique Temporary UE Identity HI Handover Interface HLC High Layer Compatibility HTTP HyperText Transfer Protocol IMAP Internet Message Access Protocol IMEI International Mobile station Equipment Identity IMPI IP Multimedia Private Identity IMPU IP Multimedia Public Identity IMS IP Multimedia Subsystem IMSI International Mobile Subscriber Identity IN Intelligent Network IP Internet Protocol IPS Internet Protocol Stack IRI Intercept-Related Information ITU-T International Telecommunication Union - Telecommunication Standardization Sector JVEG Judicial Remuneration and Compensation Act LDAP Lightweight Directory Access Protocol LEA Law Enforcement Agencies LI Lawful Interception LI_HIQR Lawful Interception Handover Interface Query Response LLC Low Layer Compatibility LTE Long-Term Evolution MAP Mobile Application Part MMS Multimedia Messaging Service MSC Mobile Switching Centre MSISDN Mobile Subscriber ISDN Number NCI NR Cell Identity NEID Network Element Identifier NR New radio TR TKÜV, edition 8.1 (draft) Page 12 OID Object Identifier PEI Permanent Equipment Identifier PKI Public Key Infrastructure POP3 Post Office Protocol 3 PTB National Metrology Institute of Germany RTCP Real-time Transport Control Protocol RTP Real-time Transport Protocol SEPP Security Edge Protection Proxy SIP Session Initiation Protocol SMS Short Message Service SMTP Simple Mail Transfer Protocol SUCI Subscriber Concealed Identifier SUPI Subscriber Permanent Identifier TCP Transport Control Protocol OPTS Obligated Party’s Telecommunication System [TKA-V] TKG Telecommunications Act TKÜV Telecommunications Surveillance Ordinance TKÜV-CA Registration and certification authority of the Federal Network Agency TTDSG Telecommunications and Telemedia Privacy Act [Telekommunikation-Telemedien- Datenschutz-Gesetz] UDI Unrestricted Digital Information UMS Unified Messaging System UMTS Universal Mobile Telecommunications System URI Uniform Resource Identifier URL Uniform Resource Locator UTF-8 8-bit Unicode Transformation Format (RFC 3629, ISO 10646) UTM Universal Transversal Mercator Projection (Coordinates) VoIP Voice over IP VoLTE Voice over LTE VoNR Voice over New Radio (new 5G radio interface) VMS Voice Mail System VPN Virtual Private Network WGS World Geographic System XML Extensible Markup Language LuS Line under Surveillance TR TKÜV, edition 8.1 (draft) Part A, page 13 Part A. Technical implementation of legal measures for telecommunications surveillance 1. General This Part A of the Technical Guideline [TR TKÜV] sets out technical specifications for surveillance equipment and the required technical characteristics of recording lines, by virtue of § 170(6) TKG [21] in conjunction with § 36 TKÜV [14]. Finally, it also specifies the types of identifiers that require additional arrangements for technical implementation of interception measures for specific types of telecommunications systems, in addition to the originating and destination addresses it uses, under the laws governing telecommunication surveillance. In cases where the TR TKÜV does not yet include technical developments, the obligated party must coordinate with the Federal Network Agency on the design of its surveillance equipment. 2. Structure Dividing Part A into the following sections allows the most straightforward allocation of the technical requirements to the various telecommunication systems or services. For this, separate annexes detail the system-specific or service-specific requirements (such as for voice communication services, Internet gateways or servers for the email service), which along with the general and other requirements, may be used as an independent description of the requirement up to a specific handover interface:  General requirements These requirements apply equally to all handover interfaces and appear in Chapter 3.  Other requirements Where needed, the TR TKÜV may regulate other areas, as indicated in § 36 TKÜV, in addition to giving the technical requirements up to the handover interfaces. Chapter 4 covers these.  System-specific or service-specific requirements The corresponding Annexes give the precise requirements on the design of system-specific or service-specific handover interfaces. Annex A contains provisions on possible transmission methods. 2.1 Overview of system-specific and service-specific Annexes and the informative Part This Part of the TR TKÜV describes the handover interface for telecommunications systems and services in fixed and mobile networks (e.g. GSM, UMTS, VoLTE, VoNR, VoIP and multimedia services), for email, the Internet gateway and number-independent interpersonal telecommunications services. The following Annexes to the TR TKÜV describe the relevant handover interface: Annex Contents Annex A.1 FTP and TCP/IP Annex A.2 Specifications for participation in the VPN and for an alternative method based on HTTPS/TLS Annex A.3 Transmission of HI1 IRI and additional events Annex A.4 Failed transmission of the surveillance copy to the lines of the authorised agency Annex B (removed) Annex C (removed) Annex D Specifications for mobile radio networks and for mobile radio-based IMS platforms according to the 3GPP specifications TS 33.108 [23] and TS 33.128 [40]. Annex E Specifications for storage facilities for voice, facsimile and data (voicemail systems, unified messaging systems). Since such systems are not taken into account in the specifications according to Annexes A to D, these requirements may also have to be met. Annex F Specifications for Email service storage equipment as per national requirements and ETSI Specification TS 102 232-2 [30] TR TKÜV, edition 8.1 (draft) Part A, page 14 Annex G Specifications for the Internet gateway as per ETSI Specifications TS 102 232-3 [31] and TS 102 232-4 [32] Annex H Specifications for VoIP, other multimedia services in fixed networks and fixed-line IMS platforms as per ETSI Specifications TS 102 232-5 [34] and TS 102 232-6 [35] Annex I Specifications for number-independent interpersonal TC services other than email services as per ETSI Specifications TS 102 232-2 [30] and TS 103 707 [39] This text also references the following Annexes to Part X of the TR TKÜV: Annex Contents Annex X.1 Proposed changes to the TR TKÜV Annex X.2 Assignment of an identification feature for authorised agencies to guarantee unique reference numbers Annex X.3 Regulations for the registration and certification authority TKÜV-CA of the Federal Network Agency, Department IS16 (Policy) Annex X.4 Concept template for preparation of the documentary evidence, test protocols and test reports 3. Technical specifications This Part of the TR TKÜV sets out the technical specifications needed to ensure complete collection of the telecommunication under surveillance and design the handover interface to the authorised agencies. The requirements arising directly from the provisions of the TKÜV also apply. 3.1 Surveillance copy transmission 3.1.1 General requirements A telecommunication under surveillance is made up of the (i) content of communication and (ii) intercept- related information. Telecommunications must also be monitored when they are rerouted or forwarded to another destination address. Note: This requirement applies, for instance, to voice communication service features such as call forwarding or call deflection, where the connection is forwarded either by the network or the terminal of the LuS. This requires transmission of the surveillance copy to the authorised agency for as long as the forwarded connection exists. Similarly, it is also necessary to monitor email services if emails are automatically forwarded to another email address of another mailbox. If the LuS initiates transfer of a pre-existing telecommunication in a specific case (such as by Explicit Call Transfer (ECT)), it is necessary to end transmission of its copy to the authorised agency as soon as the connection between the network and the LuS terminates. The IRI must be generated promptly, i.e. immediately after occurrence of the event in question (e.g. start of a telecommunication, use of a service feature for data transmission), and sent to the authorised agency. If necessary, it is permitted to merge multiple similar events (such as a selection sequence) and send them as a single record. In particular, at the start and end of the telecommunication under surveillance, as well as at the time of each event during the telecommunication (e.g. activities in the context of a service feature), it is necessary to transmit an IRI record with the relevant data. ‘Events’ also includes registration/activation processes, such as for service features in the IMS, where these operating options are controlled directly (e.g. by means of the telephone line under surveillance). In addition to the normal case, i.e. transmission of the CC with prompt transmission of IRI, it must be possible, on request from the authorised agency, for a specific interception measure to transmit only the IRI to the authorised agency, without the copy of the corresponding CC. Terminate connections for surveillance copy transmission immediately after successful transmission, i.e. minimise use of access for the authorised agency. During transmission, clearly mark the CC and the associated IRI to enable their correlation (§ 7(2) TKÜV). For this, every interception measure receives a reference number. In addition, each individual connection within an interception measure must receive a unique correlation number. TR TKÜV, edition 8.1 (draft) Part A, page 15 In cases of failed transmission of the surveillance copy, transmit at least the IRI subsequently (Annex A.4). 3.1.2 General requirements to avoid multiple transmissions The surveillance technology design must prevent the possibility of multiple transmissions of the copy of the CC for a particular interception measure to the relevant recording line of an authorised agency. To avoid multiple collection and transmission of IRI, the number of interception points must also be minimised. This should avoid redundant transmission of the IRI determined as per § 7(1) TKÜV. Interception points used exclusively to collect individual IRI – such as the public IP address – can be avoided if this IRI is transmitted over an internal interface (e.g. X2 interface) for collection at another interception point, or integrated into the signalling data for reporting within the signalling data. If IRI transmission using multiple interception points is unavoidable, care must be taken to correlate all IRI assigned to a session and the associated CC with a unique correlation number (CIN). To generate this correlation number, use the session headers included in the signalling (e.g. P-Charging-Vector, session ID). If necessary, it is permitted to edit the existing signalling information or add your own signalling information for this. If the signalling is enriched with additional data to meet the above requirements, ensure that this will not give any indication of the surveillance. This can be achieved, for instance, by applying data enrichment to all users of the relevant telecommunications service, or removing the additional signalling information at the network boundaries of the network operator. If it is only possible to ensure surveillance capabilities through collaboration between different telecommunications systems of an obligated party or by involving different technologies in CC transfer (such as 2G/4G fallback scenarios), the indicated requirements cannot always be met. The document as per § 19(2) TKÜV (concept) must detail the cases in which multiple transmission is unavoidable and the reasons for this. These descriptions may be general, e.g. in relation to technologies used, or telecommunications systems or services. For these cases, also describe the parameters or other circumstances that the recording and analysis equipment of the authorised agency can use for correlation. 3.1.3 Requirements on mobile networks and mobile-based IMS platforms The requirements on handover interface design are based on Annex D and refer to 3GPP Specifications TS 33.108 [23] and TS 33.128 [40]. For packet-switched voice communication services (such as VoLTE), temporary use of combined transmission as per 3GPP TS 33.108 or TS 33.128 and ETSI TS 102 232-5 (Annex H) is permitted. 3.1.4 Requirements on voice, fax and data storage equipment (voicemail systems, unified messaging systems, etc.) If the obligated party offers its customers the option to store messages in voice memory or similar storage equipment allocated to the LuS, the authorised agency must receive copies of all messages coming into and retrieved from this storage equipment, including the corresponding IRI. Also report changes to settings, such as mailing list creation. As a general rule, transmit copies of CC from this storage equipment for the authorised agency to the same destination number as the copy of the CC originating from or destined for the LuS. Where the technical facilities of the OPTS allow, the authorised agency must have the technical option to send the copy of the CC from this storage equipment to another destination number for individual interception measures, on request from the authorised agency. Annex E gives the technical details of the handover interface. 3.1.5 Requirements on the email service Annex F contains two alternative descriptions of a handover interface for surveillance of the email service:  Handover interface under national regulations as per Annex F.2  Handover interface according to ETSI Specification TS 102 232-2 [30] as per Annex F.3 TR TKÜV, edition 8.1 (draft) Part A, page 16 3.1.6 Requirements on the Internet gateway According to § 3 TKÜV, operators of transmission routes that serve for direct user-specific Internet access (such as an Internet gateway over xDSL, CATV, WLAN) must have arrangements in place to monitor all IP traffic. Annex G gives two different alternative methods for this, based on ETSI specifications, for Layer 2 or Layer 3 transmission of the IP traffic under surveillance. 3.1.7 Requirements on VoIP and other multimedia services Annex H covers services based on Session Initiation Protocol (SIP) and Real-time Transport Protocol (RTP) or on ITU-T Standards H.323 and H.248, and in addition to ‘emulated’ PSTN/ISDN services, it also offers the option to transmit the copy of the telecommunications content over RTP instead of ISDN dial-up connections. In addition, Annex H covers multimedia services provided using the IPCablecom architecture. 3.1.8 Requirements on number-independent interpersonal telecommunications services other than for email services Annex I details messaging services and other number-independent interpersonal telecommunications services provided over the Internet. However, only Annex F applies to email services. 3.2 Dimensioning and monitoring § 5(6) TKÜV states that the administration system dimensioning and transmission capacity for surveillance copies for the authorised agency must be tailored to the number of interception measures to be implemented. This in turn requires regular monitoring of the available surveillance and transmission capacity (interception point to Internet handover interface), in particular for bandwidth-based services. If the average bandwidth requirement of a line under surveillance deviates widely from its theoretical maximum available bandwidth, take peak loads into account. The design must detail the relevant technical and organisational arrangements as per § 19(2)(5) TKÜV. 3.3 Measures to provide the complete surveillance copy at the IP-based handover interface Note: The requirements in this section are currently under review, in particular for the use of HI1 messages as per Section 3.3.4 and the descriptions in Section 6.2 of ETSI Specification TS 102 232-1. For this reason, this edition of the TR TKÜV does not apply any amendments here. The obligated party must provide the authorised agency with a complete copy of the telecommunication under surveillance at the handover interface as per § 5(2) TKÜV. § 8(2)(first sentence)(4) TKÜV states that the system design must ensure that, in principle, the quality of the surveillance copy provided at the handover interface is at least equal to that of the telecommunication under surveillance. In addition to the copy of the content (CC) of the telecommunication under surveillance, the obligated party must also provide the intercept-related information (IRI) at the handover interface (§ 7 TKÜV). The obligated party must make suitable arrangements to ensure the completeness of the aforementioned data:  at the interception point of the copy of the CC and IRI;  on the transmission route to the handover interface; and  at the handover interface. (This is possible, for instance, with adequate transmission capacity, redundancies, buffers typical for the network, selection of the appropriate transmission procedure, transmission path monitoring, load balancing at the delivery function input, coordination of MTU size). Here, ‘delivery function’ refers to the technical equipment that receives and processes the internal network data and provides it to the handover interface. In the unusual event that data transmission from the interception point to the handover interface is not possible, the obligated party must send the IRI immediately afterwards, as also required under § 10 TKÜV for data from the handover interface to the recording line. If the transmission protocol used on TR TKÜV, edition 8.1 (draft) Part A, page 17 the path (e.g. TCP) permits, provide at least short-term buffering for the copy of the telecommunication at the interception point, based on the availability and remaining capacity of the transmission path from the interception point to the delivery function input (DF3). If buffering is not possible (e.g. when using UDP), design the transmission path to prevent data loss during peak loads (such as with adequate dimensioning, redundancies). The dimensioning of the input bandwidth of the delivery function (DF3) is adequate if the average data stream measured within 24 hours does not exceed 60% of the maximum input bandwidth. In addition, the input bandwidth available on the data network of the obligated party cannot exceed 3 times the value of the customer line with the highest bandwidth. This should prevent data loss in the case of a bandwidth peak due to heavy use of a line under surveillance. In cases of data multiplication due to multiple transmission in the delivery function (DF3), the dimensioning must include the corresponding additional requirements for processing and transmission capacity. Otherwise multiple transmission must occur at the interception point. TR TKÜV defines the handover interface in accordance with § 8(1) TKÜV. Provide the copy of the telecommunication and the IRI at a TCP/IP-based handover interface over a VPN-secured transmission route to the recording lines of the authorised agency. To ensure this TCP/IP-based transfer, at least the following requirements apply, related to transmissions as per Annexes D, G and H (these arrangements do not affect IRI transmission over FTP). 3.3.1 Buffering In exceptional cases where transmission of the surveillance copy to the recording line is not possible due to transmission problems between the handover interface of the obligated party and the authorised agency, it must be transmitted immediately afterwards. Surveillance copy buffering is permitted on these grounds (third sentence of § 10 TKÜV). This buffering must meet the following requirements:  If using dedicated Crypto-boxes based on the IPSec protocol suite, the buffer size must be designed to ensure a buffer time of 5 minutes. This corresponds to the downtime until the VPN connection is re-established and also covers peak loads on the transmission path that may arise in the internal network.  The buffer dimensioning must enable buffering of twice the average data volume transferred over the handover interface.  After the connection is re-established, the buffer must transfer data based on the FIFO principle. Transfer the entire data stream through a buffer under the FIFO principle. If the maximum buffer size is reached or the buffer cannot be emptied, delete the oldest data in the buffer within 5 minutes. This ensures that any lost data will be in a contiguous block.  The buffering design must enable the full buffer time for every TCP connection established for the authorised agency (regardless of the VPN connection), without the buffers of the different connections affecting each other (such as an overloaded buffer using another one). It is also permitted to design a buffer with dynamic size adjustment to meet the aforementioned objective, though this requires coordination with the Federal Network Agency. 3.3.2 MTU size To avoid data packet fragmentation, which may result in increased bandwidth loads, the relevant packet sizes on the path from creation at the interception point of the obligated party up to handover of the prepared data to the secured transmission route must be set to prevent fragmentation, particularly at the handover interface to the Internet (SINA Box). For transfer through the SINA Box, the manufacturer, Secunet, indicates an 80-byte overhead; take an additional 30 bytes into account for NAT-T and 8 bytes for PPPoE. Assuming that these circumstances regularly occur, set the MTU size of the delivery function to 1380 bytes. The obligated party must however examine the need for a lower or higher MTU size to optimise data transmission and reduce fragmentation. Nevertheless, the MTU size must not exceed 1420 bytes (1500 bytes of data minus 80 bytes of SINA overhead). A test with the Federal Network Agency is strongly recommended to take possible fragmentation in the internal network into consideration as well. The recording lines of the authorised agencies must be capable of receiving data packets up to this MTU of 1420 bytes. If a common interface is needed to connect the surveillance network elements and the SINA Box, coordinate the relevant values, if necessary with the Federal Network Agency as well. The same applies if the network element supports jumbo frames because the MTU size used for this cannot be used between the delivery function and the SINA Box. Although SINA Boxes from version 3.x TR TKÜV, edition 8.1 (draft) Part A, page 18 support jumbo frames, this support currently does not apply due to use of the Internet as a transmission network. 3.3.3 ‘Alive’ test of transmission path availability To monitor the availability of the transmission path between the obligated party and the authorised agency, implement an ‘alive’ test in accordance with the requirements for the ‘keep-alives’ (ETSI TS 102 232-1). Obligated undertakings must activate the ‘alive’ test for the authorised agencies that request it. Contrary to the ETSI standard, it must be possible for the authorised agency not to send a ‘response’ message. This is necessary because it is not always possible for the authorised agency to send these messages for security reasons. The obligated party must therefore implement the following options, configurable for each monitoring centre of an authorised agency:  The ‘alive’ test is not used, at the request of the authorised agency.  The ‘alive’ test is used and the authorised agency answers with a ‘response’ message. The obligated party acknowledges the lack of a ‘response’ message with a corresponding error message.  The ‘alive’ test is used and the authorised agency does not answer with a ‘response’ message. The authorised agency conducts the analysis. The obligated party does not generate an error message. In this case, the authorised agency informs the obligated party of the error. The ‘alive’ test must be conducted independently of existing transmission. The following timeframes apply:  Send an ‘alive’ test once every 60 minutes.  Answer an ‘alive’ test with a ‘response’ message within 30 seconds.  Period within which the obligated party may expect a ‘response’ message after sending an ‘alive’ test: 60 seconds. 3.3.4 Standardised error messages (HI1 messages) To improve error message analysis, the following content and format specifications apply: 1. In the event of data loss (where detectable): report data losses attributable to a measure or connection to the authorised agency as follows:  Initial report at start of data loss and subsequently at 5-minute intervals for as long as the data loss persists during an interval  Indication of the time of the initial loss of data, the amount of data lost since the last report and the total amount (MB)  The relevant LIID, if available  Format: first missing data: DDMMYYhhmmss; data loss: value; total data loss: value (due to an existing restriction on the ETSI parameter to 256 characters, only give values in the following format: ‘DDMMYYhhmmss;value;value’: here, value is a placeholder for the data loss as a whole number in MB (integer)). 2. Failed connection (error during ‘alive’ test) If a ‘response’ message is not received (if the authorised agency has selected this option), the ‘alive’ test interval is reduced to 1 minute. This improves testing for continued interruption. The error message occurs for the first and last detection of the interruption, indicating:  Time of the first missing ‘response’ message  Number of missing ‘response’ messages so far  Optional indication of an ID for the sending DF  Format: first missing response: DDMMYYhhmmss; value missing responses; DF ID value (due to an existing restriction on the ETSI parameter to 256 characters, only give values in the following format: ‘DDMMYYhhmmss;value;value’; here value is a placeholder for the number of missing responses, as a whole number (integer), and/or for the DF ID). Once the connection is restored, use the regular interval and reset the error message counter. TR TKÜV, edition 8.1 (draft) Part A, page 19 3. Insufficient receiving capacity at the authorised agencies If the monitoring centre (MC) of an authorised agency cannot receive the full volume of the data stream from the handover interface of the obligated party (e.g. remote station with insufficient capacity to receive all data correctly), resulting in the obligated party setting up a buffer, send the error message ‘MC is blocking’. Complete blocking by a remote station will result in data losses, which will be reported using the error messages as per paragraph 1. Note: The authorised agency should analyse the error messages. 3.4 Protection requirements and technical specifications for order data storage The requirements below are based on the first sentence of § 170(6) TKG and § 14(1, 2(first, second, fourth and fifth sentences) and 3(second sentence)) TKÜV. Under these provisions, the Federal Network Agency may set specifications in the TR TKÜV to achieve the protection objectives of the aforementioned regulations. The various protection objectives require implementation of the technical arrangements and other measures set out in § 167 TKG in the security requirements catalogue. This regularly involves a greater need for protection of order data, comparable to protection for telecommunications secrecy. The catalogue also requires application of the basic IT protection requirements. A party is presumed to meet the special protection requirements as per § 14(1) TKÜV for state-of-the-art technical and organisational arrangements, in particular for the technical facilities for controlling the surveillance functions and the handover interface as per § 8 TKÜV, if, in addition to the requirements in § 167 TKG, this party also meets the protection requirements of the ETSI and 3GPP specifications referred to in the corresponding Annexes to this TR TKÜV: ETSI TS 103 221-1 [42] and ETSI TS 103 221-2 [43]. Because the technical facilities for implementation of interception measures include the surveillance technology integrated into telecommunications systems and the order data stored there, these requirements also apply within the meaning of § 170(6) TKG to order data storage. To protect transmission of the surveillance copy from the OPTS to the recording lines of the authorised agencies, the provisions of Annex A.2 apply. 4. Other requirements In addition to the technical requirements on the design of handover interfaces for authorised agencies, the TR TKÜV contains further requirements on the technical and organisational implementation of interception measures. 4.1 Identifiers to implement interception measures Based on the sixth sentence of § 36 TKÜV, the provisions below specify the types of identifiers that require additional arrangements for technical implementation of interception measures for specific types of telecommunications systems, in addition to the originating and destination addresses it uses, under the laws governing telecommunication surveillance.  Identifiers in landline telephone networks and IMS platforms - Destination and originating addresses as per E.164 including service numbers (e.g. 0700) - SIP-URI, TEL-URI  Identifiers in mobile networks and mobile-based IMS platforms - MSISDN - IMSI - IMEI - SIP-URI, TEL-URI - PEI, SUPI, IMPI, IMPU, 5G-GUTI, GLI (identifiers for 5G as per 3GPP TS 33.128)  Identifiers for the email service - Email address as per RFC 5322; if applied: internationalised email address as per RFC 6530 [51], RFC 6531 [52], RFC 6532 [53] and RFC 6533 [54] (destination and originating addresses) - Access ID (login name without password, e.g. ‘user name’, ‘phone number’, ‘email address’) of the mailbox TR TKÜV, edition 8.1 (draft) Part A, page 20  Identifiers of the Internet gateway - Identifier of the associated telephone line - Static IP address - User ID assigned to the Internet gateway - MAC address according to the indications below - Other designation for the transmission route, e.g. postal identification (facility address) of the customer-side line of the Internet connection Note on cable networks: In general, technical implementation of the surveillance can only be based on cable modem identification (MAC address). In this case however, it is not necessary to identify the MAC address in the order if another available identifier (such as identifier of the corresponding telephone line, facility address) can identify the transmission route just as clearly. This precludes the need to issue a new order if the cable modem is replaced. If the order indicates the identifier of the corresponding telephone line, this requires organisational arrangements to enable surveillance of the following: - without further details on the scope of the interception measure, only the voice communication service; or - the stated scope if the scope of the interception measure is specified in more detail (e.g. "Internet access only" or "Voice communication service and Internet access"). If the order indicates the cable modem address or the facility address, this requires organisational arrangements to enable surveillance of the following: - without further details on the scope of the interception measure, the entire line with voice communication and Internet access service; or - the stated scope with further indication of the scope of the interception measure (e.g. ‘Internet access only’ or ‘voice communication service only’). Note for WLANs: If none of the aforementioned identifiers are available for a publicly accessible Internet access service over wireless local networks (WLANs or WLAN hotspots), use the identifier of the relevant terminal for Internet access (such as MAC address) as per § 6(3) TKÜV. If public WLAN users are not registered users, then to determine adherence to the relevant marginal limits as per § 3(2)(first sentence)(5) TKÜV, use the number of regularly and concurrently connected users (terminals) on the overall access network in use (i.e. not just that particular hotspot) or use the corresponding values based on past experience. If collaboration between two or more telecommunications networks of one or more operators creates this kind of Internet access service, please refer to the rules in § 170(1)(2) TKG, which nevertheless requires, where possible, surveillance capabilities as if only a single system were providing the service (general rule). This provision assumes switching between the systems where necessary to meet this objective. The obligation to monitor the Internet gateway does not affect the internal content offers of the obligated WLAN operator. For instance, this may be a landing page that contains a specific (internal) information offer, where the user has the opportunity to access further content from the Internet. In this case, the design only needs to facilitate surveillance on Internet access and on the use of Internet-connected services. If the design of the telecommunications surveillance equipment only allows surveillance of all data traffic on the WLAN of the obligated party, i.e. both network-internal content and data traffic to and from the Internet, this may be permitted after consultation with the Federal Network Agency. Implementation of orders for Internet gateways From the point of view of the Federal Network Agency and based on the interpretation of the regulations, implementation of these interception measures for unbundled lines usually requires a two-step procedure: 1. Submit query to the provider of the Internet gateway to determine the operator of the Internet gateway and the identifier required for implementation. TR TKÜV, edition 8.1 (draft) Part A, page 21 2. Issue the order to the operator of the Internet gateway, indicating the requested identifier of the Internet gateway (the operator need not be the provider or have corresponding customer data available). If it is known that the line is a ‘non-unbundled’ line, the telephone number uniquely identifies the operator as well as the DSL transmission route. In these cases, it is permitted to skip step 1.  Identifiers for the VoIP service and other multimedia services based on SIP, H.323 or H.248 in media streaming connections (e.g. RTP) - Destination and originating addresses as per E.164 including service numbers (e.g. 0700) - SIP-URI, TEL-URI - H.323 URL, H.323 ID - Access ID (login name without password, e.g. ‘user name’, ‘phone number’, SIP URI) of the VoIP account 4.2 Transmission procedure for notifications and confirmations of functional tests for recording and analysis equipment of the authorised agencies § 23(1)(first sentence)(3) TKÜV states that functional tests of the recording and analysis equipment of authorised agencies require prior notification from the authorised agency and confirmation from the Federal Network Agency. Based on the ninth sentence of § 23(1) TKÜV, the paragraph below gives the form and transmission procedure for notification and confirmation: 1. The Federal Network Agency provides the authorised agencies with an electronically editable notification form for functional tests. The Federal Network Agency checks the completed notification form and marks it as approved. For confirmation, it then sends the notification form with approval to the obligated party and the requesting authorised agency electronically. Transmission of the form between the authorised agency and the Federal Network Agency and between the Federal Network Agency and the obligated party must follow a procedure as per Part B. TR TKÜV, edition 8.1 (draft) Part A, Annex A, page 22 Annex A. Data transmission specifications Annex A.1 FTP and TCP/IP SPECIFICATIONS This annex gives specifications on the FTP and TCP/IP transfer methods. FTP (file transfer protocol) can be used to transfer the surveillance copy in accordance with the specifications in Annexes D, E and F. In addition to the FTP transmission method, Annexes D, F and H contain requirements for transmission via TCP/IP. The relevant annexes give the required national specifications on the port addresses to use. Annex A.1.1 File name Files are transferred using the FTP transmission method. The file name design is based on File naming method B of ETSI Standard ES 201 671 and ETSI Specification TS 101 671 [22]; 3GPP Specification TS 33.108 [23] contains an identical definition. File name according to File naming method B: <File name> in format ABXYyymmddhhmmsseeeet where: AB : two ASCII characters as identifier of the obligated party (see note) XY : two ASCII characters as identifier of the sending mediation function (see note) yy : two ASCII characters [‘00’...‘99’] to denote the year (last two digits) mm : two ASCII characters [‘01’...‘12’] to denote the month dd : two ASCII characters [‘01’...‘31’] to denote the day hh : two ASCII characters [‘00’...‘23’] to denote the hour mm : two ASCII characters [‘00’...‘59’] to denote the minute ss : two ASCII characters [‘00’...‘59’] to denote the second eeee : four alphanumeric ASCII characters (A-Z, 0-9) to prevent otherwise identical file names during the same second within a single mediation function; lowercase alphabetic ASCII characters are not allowed (a-z). t: one ASCII character to identify the content (see note) Note on ‘AB’: The Federal Network Agency gives the identifiers for obligated parties, to prevent duplicates. It assigns these during surveillance technology setup. At the same time, it sets a 5-digit operator ID for the obligated party, transmitted as a parameter in the IRI (see Annex X.2). Note on ‘XY’: File naming method B requires different sending mediation functions (e.g. two different FTP clients) of an obligated party to differ at least in this identifier, even if they each send a file with a name that is otherwise the same to a specific authorised agency. For ‘X’ (third position in the file name), in principle, the function as per File naming method B must distinguish between multiple mediation functions. The ASCII characters for uppercase letters A to Z and numbers 0 to 9 are permitted for this. If however only one mediation function is provided for an obligated party (e.g. operation of a single FTP client for the entire telecommunications system), it is permitted to use a different value for ‘X’ after consultation with the Federal Network Agency. Because the aforementioned provision still enables transfer of both ASCII-encoded and ASN.1-encoded files over FTP, it is necessary insert a distinguishing criterion for this in the file name. This is indicated by selecting a corresponding value for ‘Y’ (fourth position in the file name). The value used for ‘Y’ can also distinguish between encodings under the ETSI standards and ETSI specifications as well as 3GPP specifications. TR TKÜV, edition 8.1 (draft) Part A, Annex A, page 23 Table A.1.1-1 below is based on use of ASN.1 modules with an Object Identifier (OID). ‘Y’ (4th Meaning position) E Encoding as per Annexes E and F.3 (mandatory) ASN.1-encoded or TLV-encoded records as per ETSI standard or ETSI specification G Encoding as per Annex D (mandatory) ASN.1-encoded or TLV-encoded records encoded as per 3GPP Specification TS 33 108 X Encoding as per Annex E.5 or F.2 (mandatory) XML-encoded content of a monitored email Table A.1.1-1: Specifications for ‘Y’ (modules with OID) Note on ‘t’: The ASCII characters that may be used as values for ‘t’ (21st position in the file name) serve to identify the file contents. The file may contain the following:  IRI: Intercept-related information  HI1: administration data  CC(MO): mobile-originated (MO) content of communication (CC) is included in the intercepted data.  CC(MT): mobile-terminated (MT) content of communication (CC) is included in the intercepted data.  CC(MO&MT): mobile-originated and mobile-terminated (MO&MT) content of communication (CC) is included in the intercepted data.  National use: transmission of IRI and CC as per Annexes E and F Table A.1.1-3 below shows the possible values for ‘t’ and their meanings. ‘t’ (21st position) ‘t’ in binary File contains data in the form: 1 0011 0001 IRI/HI1 2 0011 0010 CC(MO) 4 0011 0100 CC(MT) 6 0011 0110 CC(MO&MT) 8 0011 1000 national use Table A.1.1-3 Specifications for ‘t’ File name example: VPEX06050410431200018 where: VP : Identifier of the obligated party (assigned by the Federal Network Agency) E: Identifier for email surveillance (due to use of a single mediation function (FTP client)) X: XML-encoded content as per Annexes E.5 and F.2 06 : The year 2006 05 : The month of May 04 : Day 04 10 : Hour 10 43 : Minute 43 12 : Second 12 0001 : Extension 0001 to distinguish file names 8: Transmission of IRI and CC in a file as per Annexes E or F Annex A.1.2 Parameters With transmission over FTP, the system of the obligated party acts as sender (e.g. as an FTP client) and the system of the authorised agency as receiver (e.g. as an FTP server). The design of the parameter definitions (e.g. user name and password for each FTP account) must ensure that an obligated party can provide these parameters to each receiver of the authorised agency before administration of interception measures. This also enables bundled transmission of multiple IRI records for different measures in a single file to the same FTP account. TR TKÜV, edition 8.1 (draft) Part A, Annex A, page 24 The provisions below apply here.  Multiple IRI records and copies of the CC to be sent to a receiver at the same authorised agency may be treated as a single file; for ASN.1-encoded records, for instance, this is handled in an ‘IRISequence’.  In the context of a communication link between the OPTS and the receiver of an authorised agency, it is possible to transfer one or more files if they are already available in the OPTS. However, it is necessary to terminate the communication link immediately after file transfer if the OPTS does not have any further records available at that time.  The FTP servers of the authorised agency must allow the overwriting of files, to enable resending in cases of errors. Table A.1.2-2 gives the main FTP parameters. FTP parameters Values/specifications Comments document type binary binary filename Length: 21 characters See specifications as per Annex A.1.1. Characters: The following ASCII characters are permitted: Uppercase letters and numbers (A- Z, 0-9), without umlauts LEA user name for each Length: Maximum of 8 characters Encryption not necessary due to use of FTP account at an VPN. authorised agency Characters: Alphanumeric characters (a-z, A-Z, 0-9), without umlauts LEA password for each Length: Maximum of 8 characters Encryption not necessary due to use of FTP account at an VPN. authorised agency Characters: Alphanumeric characters (a-z, A-Z, 0-9), without umlauts Special characters ‘.’, ‘%’, ‘*’, ‘!’, ‘?’, ‘@’, ‘#’ Directory change No requirement Directory changes by the FTP client within the specified target directory are not required. port for data connection 20 (default value) port for control 21 (default value) connection mode Passive mode must be supported. The authorised agency need not support the extended passive mode; i.e. the obligated party must offer the ‘simple’ active or passive mode. Table A.1.2-2 Main parameters for FTP Annex A.2 Specifications for participation in the VPN and an alternative procedure based on HTTPS/TLS To protect the IP-based handover interface as per the first sentence of § 14(1) TKÜV, dedicated Crypto- boxes based on the IPSec protocol suite are used to connect the subnets of the authorised agencies and the obligated parties to a Virtual Private Network (VPN). To administer the cryptographic keys used for authentication, a Public Key Infrastructure (PKI) is set up, operated by the Federal Network Agency, as the central certification and registration authority. In addition, the Federal Network Agency administers the possible security relationships in an Access Control List (ACL) made available in a directory service. The Crypto-boxes are always installed as dedicated systems before the subnets of the authorised agencies and obligated parties to be protected. These systems ensure authenticity, integrity and confidentiality. TR TKÜV, edition 8.1 (draft) Part A, Annex A, page 25 In addition, the Crypto-boxes only provide limited tools to protect the handover interface, such as from denial-of-service attacks on the authorised agencies, so operators of these subnets must resolve this independently. On the side of the authorised agency, the Crypto-boxes are components of the technical equipment of the authorised agency, and on the side of the obligated party, they are components of the technical equipment of the obligated party; in this regard, planning and operation (e.g. operation of a Syslog server) as well as the maintenance and troubleshooting fall under the responsibility of the relevant subnet operator. The Crypto-boxes must meet the relevant state of the art as per the legal requirements on the level of protection and must be modified as needed to guarantee this level of protection at all times. Operators of the Crypto-boxes in question must implement expansions of this kind (e.g. use of other key lengths) or temporarily required changes to the existing implementation due to subsequent security shortcomings within a timeframe specified for the case at hand, in the context of the expansions or updates provided by the Crypto-box manufacturers, as specified by the Federal Network Agency. Network architecture The Crypto-boxes of the authorised agencies and obligated parties create a mesh network that can establish continuously effective security relationships (point-to-point connections) between the OPTS of the obligated party and the subnets of the authorised agency. Connections between different obligated parties are not permitted. The Federal Network Agency creates the required cryptographic keys for Crypto-box authentication and after successful registration, stores them on the smart card of each Crypto-box, provided by the operators of the relevant subnets. The Crypto-boxes independently generate and update the keys to encrypt the data to be transferred, so they are not available to any participants. Once the Crypto-boxes are commissioned, they automatically set up a secure connection to the directory service at the Federal Network Agency, to retrieve the current ACL. Further ACL updating processes are either automatic or controlled by the Federal Network Agency. The Crypto-boxes send the log data they generate (e.g. successful ACL update, failure) in standard Syslog format (UDP port 514) to the log server of the relevant obligated party or authorised agency for further processing. Internet access and handover interface design Public IP addresses are used to establish the uniqueness of the addressing of the VPN termination point and the sending and receiving devices of the connection path for transmission of the surveillance copy and the IRI. If existing Internet structures are used, this generally requires the use of separate tunnelling to meet the protection requirements under § 14 TKÜV. Different network configurations are however possible in principle. These requirements apply to description of the Internet access and handover point design for the concept to be submitted. Usage scenarios and process flow In the standard procedure, the Crypto-boxes are integral parts of the subnets and are uniquely defined in the ACL, such as by their IP configuration. After successful registration and key generation, the directory service is updated. The Federal Network Agency provides a list of the data needed for ACL management and a description of the overall process (policy) for parties involved in the process. A document that the participants must submit to the Federal Network Agency must provide all details (e.g. the IP address intended for transmission) to enable corresponding ACL maintenance. This also applies to the use of Crypto-boxes with operators of small telecommunications systems as part of what are known as ‘pool’ solutions. Other rules and indications In addition to the above provisions on VPN participation, the following special rules and indications apply:  Regulations for the registration and certification authority of the Federal Network Agency (TKÜV CA), Unit IS16 (Policy) Annex X.3 gives the situation at the time of publication of this edition of the TR TKÜV.  Summary: Description of the overall process for participating in the VPN procedure TR TKÜV, edition 8.1 (draft) Part A, Annex A, page 26  Application to participate in the VPN for the obligated parties and authorised agencies (registration and technical description of the subnet infrastructure with IP addresses and selected options) The documents are available on the Federal Network Agency website at www.bundesnetzagentur.de/tku. List of permitted Crypto-boxes The table below lists the Crypto-boxes that meet the basic system and interoperability requirements. No Manufacturer Product name Contact 1 secunet Security Networks AG SINA Box Public Authorities Division Ammonstraße 74 email: [email protected] 01067 Dresden Tel.: +49 (0)201/5454-0 www.secunet.com Alternative procedure based on HTTPS/TLS As an alternative to the dedicated Crypto-boxes described above, obligated parties based abroad that have the arrangements in place as per Parts A and B and that also use IP-based handover interfaces to implement the legal requirements of another European country may use the HTTPS/TLS-based security procedure described in ETSI Specification TS 103 707. In this case, in addition to the requirements in Sections 6 and 7 of ETSI Specification TS 103 707, the following requirements also apply: For the use of TLS:  Certificate-based two-way authentication, i.e. authentication of both communication partners (TLS server and TLS client) using a certificate  The requirements according to the first sentence of § 8(1) BSIG [45] on the minimum standards for the use of Transport Layer Security by the BSI, in their latest applicable version  The requirements on the identification of communication partners as per Section 6 of Technical Guideline TR-03116-4 ‘Cryptographic requirements on Federal Government projects - Part 4: Communication procedure in applications’ [46] of the BSI, in its latest applicable version NB: This applies in particular to the use and exchange of self-signed certificates for the required certificate-based two-way authentication. Centralised provision of certificates at the Federal Network Agency is not planned for this procedure. In addition, it is also required to follow the recommendations and guidelines in the following documents, in their latest applicable versions:  BSI Technical Guideline TR-03116-4 ‘Cryptographic requirements on Federal Government projects - Part 4: Communication procedure in applications’ [46]  BSI Technical Guideline TR-02102-2 ‘Cryptographic procedures: Recommendations and key lengths - Part 2: Use of Transport Layer Security (TLS)’ [47]  BSI Technical Guideline TR-02103 ‘X.509 Certificates and certification path validation’ [48] The documents to be submitted as per § 19(2) TKÜV must describe the implementation of the aforementioned rules and recommendations. TR TKÜV, edition 8.1 (draft) Part A, Annex A, page 27 Annex A.3 Transmission of HI1 IRI and HI2 data for additional events The international standards and specifications underlying this TR TKÜV describe the transmission and content of HI1 IRI records and HI2 data for additional events. This includes transmission of the HI1 IRI to be transmitted to the authorised agency during activation, deactivation or modification of interception measures and in the case of alarm messages. The options in Annex A.3.1 are available for this. To transmit the actual target identifier for activation of an interception measure as per § 5(5) TKÜV, ASN.1 module ‘HI1NotificationOperations’, from version 6 on, has been expanded with a corresponding parameter. In addition, the national ASN.1 module must be used to transmit HI2 data for additional events for which the international specifications and standards do not define parameters. This includes, in particular, proprietary and system-specific services and service features (where not covered by the HI2 modules of the standards or specifications). ASN.1 module ‘HI1NotificationOperations’ and the national ASN.1 module are integrated differently depending on the standard or specification used. For use of the national ASN.1 module, coordinate with the Federal Network Agency, which specifies the syntax of the ASN.1 module. Annex A.3.1 Transmission options By way of example, the table below explains the options for integrating ASN.1 module ‘HI1NotificationOperations’ and the national ASN.1 module. Other ASN.1 modules use the parameters accordingly. Standard or Method Explanation specification ES 201 671/ Transmission of ASN.1 parameter The ASN.1 parameter can be used to directly integrate TS 101 671 ‘National-HI2-ASN1parameters’ using the HI1 IRI and the HI2 data for additional events into in conjunction HI2 module ‘HI2Operations’ the HI2 module. with TS 102 232-6 3GPP Transmission of ASN.1 parameter The ASN.1 parameter can be used to directly integrate TS 33.108 ‘National-HI2-ASN1parameters’ using the HI1 IRI and the HI2 data for additional events into HI2 module ‘HI2Operations’, which in the HI2 module. Before transmission, import this HI2 turn is imported into modules module into the relevant UMTS module. ‘UmtsHI2Operations’ and ‘UmtsCS- HI2Operations’. Transmission of ASN.1 parameter The ASN.1 parameter can be used to directly integrate ‘National-HI3-ASN1parameters’ using the HI1 IRI and the HI2 data for additional events into HI2 module ‘Umts-HI3-PS’ the HI2 module. TS 102 232-1 Import of the entire ASN.1 module Importing the entire module enables transmission of the ‘HI1NotificationOperations’ using aforementioned HI1 IRI directly to the authorised module ‘LI-PS-PDU’ agency; in addition, the HI1 module contains parameter ‘National-HI1-ASN1parameter’, enabling transmission of HI2 data for additional events. Table A.3-1 Transmission of HI1 IRI and additional events TR TKÜV, edition 8.1 (draft) Part A, Annex A, page 28 Annex A.4 Failed transmission of the surveillance copy to the lines of the authorised agency If it is not possible to transmit the surveillance copy to the authorised agency, it is required, as per § 10 TKÜV, to transmit the IRI immediately afterwards. It is not permitted to impede or delay the telecommunication under surveillance or to store the contents of the surveillance copy on these grounds. It is only permitted to buffer the telecommunication contents where necessary for smooth operation for technical and in particular transmission-related reason. In the case of subsequent telecommunication events under surveillance, it is necessary to re-initiate the connection attempts for transmission of the surveillance copy, unless otherwise agreed with the authorised agency in specific cases (e.g. in cases of long-term incidents). Technical implementation Initial repeated connection setup attempts If transmission of the surveillance copy fails, perform at least three additional connection setup attempts first. If using FTP or TCP/IP, these occur within an interval of up to a few minutes. If these attempts restore the connection to the authorised agency, transmit the buffered and newly generated IRI and the copy of the telecommunications content from the restoration time. If these repeated connection setup attempts do not restore the connection, store the buffered and generated IRI records for subsequent transmission. Additional connection setup attempts After the minimum of three repeated connection setup attempts, continue further connection setup attempts at appropriate intervals for 24 hours until restoration. If a transmission does not occur within this extended period, it must be possible to store the stored IRI on a storage medium (e.g. CD) and transmit it immediately to the authorised agency using an appropriate method (e.g. secure email) and then delete it from the OPTS. The obligated party may extend the aforementioned 24-hour period by up to 1 week, with assurance that the authorised agency can also receive the stored IRI on request during the extension period (for example, using the alternative route provided in the event of an error). If the connection to the authorised agency is restored in this extended period, then in addition to the IRI, also transmit the copy of the telecommunications content from the restoration time. It is necessary to send or report identified incidents and faults that affect telecommunications surveillance or transmission of the surveillance copy to the authorised agency immediately as alarm messages in a separate IRI record or by another method. If IRI record transmission is itself affected by an incident, still generate these alarms for transmission after restoration of the transmission function or sending on a storage medium, to document the incident. In mobile networks, only on request from the authorised agencies, provide information on incidents that merely affect regionally limited areas of the network using an appropriate method (e.g. email). TR TKÜV, edition 8.1 (draft) Part A, Annex B, page 29 Annex B (Removed: Handover interface for circuit-switched networks (national)) Note: With the discontinuation of all transmission over X.25 from 31 December 2017, existing implementations under Annex B were only permitted until 31 December 2021 if they switched to transmission over FTP. New implementations are no longer permitted. The TR TKÜV up to edition 7.0 contains the descriptions in this Annex B. TR TKÜV, edition 8.1 (draft) Part A, Annex C, page 30 Annex C (Removed: PSTN and ISDN (ETSI ES 201 671 and TS 101 671)) Note: Due to discontinuation of ISDN-based transmission technology, existing implementations under Annex C were only permitted until 31 December 2021, and new implementations with ISDN-based transmission were no longer permitted. Descriptions of this Annex C are contained in the TR TKÜV up to edition 8.0. TR TKÜV, edition 8.1 (draft) Part A, Annex D, page 31 Annex D. Specifications for mobile networks and mobile-based IMS platforms (3GPP TS 33.108 and TS 33.128) Note: ISDN-based transmission is not permitted. For packet-switched voice communication services (such as VoLTE), use of combined transmission as per 3GPP TS 33.108 or TS 33.128 and ETSI TS 102 232-5 (Annex H) is permitted (see Notes in Annex X.1.1). This Annex describes the requirements on the handover interface for mobile networks and mobile-based IMS platforms as per 3GPP Specifications TS 33.108 [23] and TS 33.128 [40]. The specifications include the technical description for the circuit-switched and packet-switched areas and for multimedia services. 3GPP Specification TS 33.128 uses the IP-based transmission procedure as per ETSI Specifications TS 102 232-1 and TS 102 232-7, which encapsulates the data as per 3GPP TS 33.128. This IP-based transmission procedure is also possible for 3GPP Specification TS 33.108 and in coordination with the Federal Network Agency, it must be switched to transmission as per ETSI Specifications TS 102 232-1 and TS 102 232-7 by 31 December 2025. Transmission as per ETSI TS 102 232-1 must use pre-defined port number (destination port number) 50100, and direct transmissions as per GPP TS 33.108 must also use port number 50010 until the aforementioned switchover date. The requirements of Annex D.1 apply to the use of 3GPP TS 33.108. Until further notice, the use of the 3GPP TS 33.128 [40] requires coordination with the Federal Network Agency. Part A, Section 4 of this TR TKÜV lists the identifiers to be used to implement telecommunications surveillance. If the order gives an IMEI as the LuS identifier, the data records must contain this IMEI and the associated MSISDN. In addition to the requirements in Part A, Sections 3 and 4, the following Annexes apply: Annex Contents Annex A.1 FTP and TCP/IP Annex A.2 Specifications for participation in the VPN and an alternative procedure based on HTTPS/TLS Annex A.3 Transmission of HI1 IRI and additional events Annex A.4 Failed transmission of the surveillance copy to the lines of the authorised agency This text also references the following Annexes to Part X of the TR TKÜV: Annex X.1 Proposed changes to the TR TKÜV Annex X.2 Assignment of an identification feature for authorised agencies to guarantee unique reference numbers Annex X.3 Regulations for the registration and certification authority of the Federal Network Agency (TKÜV CA), Unit IS16 (Policy) Annex X.4 Concept template for preparation of the documentary evidence, test protocols and test reports Requirements on location information in mobile networks For an identifier under surveillance whose use is not location-specific, § 7(1)(first sentence)(7) TKÜV requires reporting of information on the location of the terminal at the greatest level of detail generally available for this location on the network servicing the terminal. When carrying out orders to provide information on the location of the receive-ready terminal associated with the identifier under surveillance, use the surveillance equipment to be provided accordingly. The following specifications apply here: Encode location information in a format that enables the authorised agency to determine the geographic location of the radio cell without network-specific documentation from the network operator. For this, provide the coordinates of the location of the base station connected to the mobile terminal (e.g. BTS for GSM, NodeB for UMTS, eNodeB for LTE or gNodeB for 5G NR) and cell identifier CGI (Cell Global Identification as per ETSI TS 123 003 [13]) or the ECI (E-UTRAN Cell Identity as per ETSI TS 123 003 [49]) or NCI (NR Cell Identity as per ETSI TS 123 003 [49]). Use angular geographic coordinates based on WGS84. TR TKÜV, edition 8.1 (draft) Part A, Annex D, page 32 If the mobile network does not log the exact location of the mobile terminal, provide at least the radio cell used to establish the connection. Also report the location information or cell identifiers if this information is not available in the core network, but rather only in the access network. In view of the functions currently available from the networks, it is required to report this information for at least the following events:  Circuit-Switched Service Idle Mode: Periodic Location Update Connected Mode: Connection setup and termination, handover between cells and SMS messaging  Data Service, 2.5G Standby Mode: Periodic Routing Area Update, Routing Area Update Ready Mode: GPRS Attach and Detach, Cell Updates (in the active PDP Context) and Routing Area Update  Data Service, 3G Idle Mode: Periodic Routing Area Update, Routing Area Update Connected Mode: GPRS Attach and Detach and Routing Area Update, Cell Updates (in the active PDP Context in CELL_DCH mode)  Data Service, 4G Idle Mode: Periodic Tracking Area Update, Tracking Area Update Connected Mode: Attach and Detach, Tracking Area Update Inter-eNodeB Handover  Data Service, 5G NSA see Data Service 4G  Data Service, 5G SA Specification to be provided in a future edition of the TR TKÜV as per 3GPP TS 33.128 Activation of telecommunications surveillance on an existing telecommunications connection If a telecommunications link under surveillance already exists on activation of an interception measure, it is necessary to collect the CC and the IRI from this time onwards and provide copies of them (see Annex H.3.2, point 5.3). Exceptions for IMEI surveillance Due to the network architecture, the IMEI is generally only collected during network login and may not be available as an identifier to implement interception measures as per Part A, Section 4.1, for certain communication scenarios on the network elements used for this. The document as per § 19(2) TKÜV (concept) must detail any such exceptions. Annex D.1 Selected options and additional technical requirements Annex D.1.1 Basis: 3GPP TS 33.108 The table below describes the options selected for the different chapters and sections of 3GPP Specification TS 33.108, as well as the additional requirements. Unless indicated otherwise, the references in the table are for the sections of the 3GPP specification. Section of Description of the option or issue and Additional requirement, background or additional 3GPP specifications for national application information TS 33.108 4.3 Functional requirements Support the ‘IRI and CC’ and ‘only IRI’ options; no need to support the ‘only CC’ option. 4.4 Overview of handover interface An electronic interface from the LEA to the system HI1 may be used to transmit events (e.g. of the obligated party for direct administration of activation/deactivation/modification of a measure, error measures is not used. messages) from the obligated party system to the LEA (Annex A.3 to the TR TKÜV). Report the events for administration of a measure (e.g. for activation) and error messages. TR TKÜV, edition 8.1 (draft) Part A, Annex D, page 33 Section of Description of the option or issue and Additional requirement, background or additional 3GPP specifications for national application information TS 33.108 4.5 HI2: Interface port for intercept-related information For IRI buffering, the requirement in the adjacent See Annex A.4 to the TR TKÜV. column applies. 4.5.1 Data transmission protocols (HI2) Use FTP to transmit the intercept-related information (IRI) over the HI1 and HI2 interfaces; ROSE is not permitted. Terminate the FTP connection immediately after IRI transmission. Addendum 1 Security aspects The requirements of Annex A.2 apply. Addendum 2 Quantitative aspects The indications in Part A, Section 3.2 TR TKÜV apply to dimensioning of the administration and transmission capacities. Addendum 3 Failure of CC links If connection setup fails, make at least three See Annex A.4 to the TR TKÜV. repeated attempts. Chapter 5. Circuit-switched domain 5.1.2.1 Network Identifier (NID) The NID consists of components such as the 5- character operator (NO/AN/SP) identifier. In Germany, the first two digits are ‘49’, with the Federal Network Agency determining the remaining three characters for the relevant obligated party. 5.2.2.1 Control Information for HI2 In general, give all times (TimeStamp) in the The GeneralisedTime parameter is not encoded as official, local time. universal time and does not use a time difference. The winterSummerIndication must be set to either wintertime or summertime. Delivery of Content of Communication For the SMS and User-to-User Service (UUS), To transmit this CC, select either ASN.1 module transmit the CC as IRI. ‘HI2Operations’ as per Annex D.5 or module ‘HI3CircuitDataOperations’ as per Annex D.6. Both 5.3.1, 5.4 modules provide the relevant parameters for UUS and SMS. Addendum 4 Fault reporting Transmit error messages as intercept-related As an alternative, it is permitted to send error information (IRI) (see Annex A.4 to the TR TKÜV). messages as national parameters or over HI1 interfaces. The minimum error events to be transmitted In mobile networks, only on request from the are based on the national parameter specifications authorised agency, provide information on incidents (see Annex A.3 to the TR TKÜV). that merely affect regionally limited areas of the network. TR TKÜV, edition 8.1 (draft) Part A, Annex D, page 34 Section of Description of the option or issue and Additional requirement, background or additional 3GPP specifications for national application information TS 33.108 5.4 LI procedures for supplementary services For non-standardised (proprietary) service features relevant to surveillance, transmit the required information in the national parameters. Coordinate with the Federal Network Agency on the parameter contents. 5.4.4 Multi-party calls – general principles 5.5.2, 5.5.3, For CW, HOLD and MPTY (up to six users), as an For CW, HOLD, MPTY with up to six users: 5.5.11 alternative, it is permitted to use option A or option Because transmission of a sum signal in an RTP B. For large conferences with more than six users, stream to the authorised agency requires a more use option B. complex correlation and more extensive analysis of the CC under option B (no speaker differentiation by channel), give preference to option A: a dedicated RTP stream for each subscriber. 5.4.5 Subscriber-Controlled Input The obligation to report control actions on operating options as per § 5(1)(4) TKÜV is now removed. However, systems that existed before entry into force of TR TKÜV 7.1 may continue to use these parameters. 5.5.3 Call Hold/Retrieve When HOLD is activated, mute both CC voice channels during the HOLD phase. In addition, the option to only mute the held identifier (held party) will be accepted. 5.5.4 Explicit Call Transfer (ECT) After transfer, implement option 2 (‘The transferred call shall not be intercepted.’). 5.5.15 User-to-User Signalling (UUS) Transmit CC of the UUS service as IRI. See points 5.3.1 and 5.4 in this table. Chapter 6. Packet data domain 6.1.2 Network Identifier (NID) The NID consists of components such as the 5- character operator (NO/AN/SP) identifier. In Germany, the first two digits are ‘49’, with the Federal Network Agency determining the remaining three characters for the relevant obligated party. 6.2.1 Timing In general, give all timestamps in official, local time. The GeneralisedTime parameter is not encoded as universal time and does not use a time difference. The winterSummerIndication must be set to either For IRI buffering, the requirement in the adjacent wintertime or summertime. column applies. See Annex A.4 to the TR TKÜV. 6.3 Security aspects The requirements of Annex A.2 apply. 6.4 Quantitative aspects The indications in Section 3.2 TR TKÜV apply to See Addendum 2 in this table. dimensioning of the administration and transmission capacities. TR TKÜV, edition 8.1 (draft) Part A, Annex D, page 35 Section of Description of the option or issue and Additional requirement, background or additional 3GPP specifications for national application information TS 33.108 6.5.0 PacketDirection Clearly indicate the flow of the CC using to target and from target. IP addresses and port numbers For mandatory transmission of the source and destination IP addresses and the associated port numbers of the participating users, use parameters sourceIPAddress, destinationIPAddress, sourcePortNumber and destinationPortNumber. 6.5.1.1 REPORT record information The REPORT record shall be triggered when, as a This option is not feasible in Germany. national option, a mobile terminal is authorised for Note: Where roaming between network operators is service with another network operator or service possible in Germany, a measure for a specific LuS provider. must cover all the relevant networks. 6.6 IRI reporting for packet domain at GGSN As a national option, in the case where the GGSN This option need not be implemented in Germany. is reporting IRI for an intercept subject, the Note: Where roaming between network operators is intercept subject is handed off to another SGSN possible in Germany, a measure for a specific LuS and the same GGSN continues to handle the must cover all the relevant networks. content of communications subject to roaming agreements, the GGSN shall continue to report the following IRI of the content of communication: - PDP context activation; - PDP context deactivation; - Start of interception with PDP context active. 6.7 Content of communication interception for packet domain at GGSN As a national option, in the case where the GGSN This option is only permitted in Germany if the is performing interception of the content of requirement in § 4(1) TKÜV is met. communications, the intercept subject is handed off Note: Where roaming between network operators is to another SGSN and the same GGSN continues to possible in Germany, a measure for a specific LuS handle the content of communications subject to must cover all the relevant networks. roaming agreements, the GGSN shall continue to perform the interception of the content of communication. Chapter 7. Multimedia domain 7.1.2 Network Identifier (NID) The NID consists of components such as the 5-character operator (NO/AN/SP) identifier. In Germany, the first two digits are ‘49’, with the Federal Network Agency determining the remaining three characters for the relevant obligated party. 7.2.1 Timing In general, give all timestamps in official, local time. The GeneralisedTime parameter is not encoded as universal time and does not use a time difference. The winterSummerIndication must be set to either For IRI buffering, the requirement in the adjacent wintertime or summertime. column applies. See Annex A.4 to the TR TKÜV. 7.3 Security aspects When using an IP-based handover interface, IPSec To protect IP-based handover interfaces, use is applied. dedicated IP Crypto-boxes based on IPSec in combination with a PKI as per Annex A.2 to the TR TKÜV. TR TKÜV, edition 8.1 (draft) Part A, Annex D, page 36 Section of Description of the option or issue and Additional requirement, background or additional 3GPP specifications for national application information TS 33.108 7.4 Quantitative aspects The indications in Section 3.2 TR TKÜV apply to dimensioning of the administration and transmission capacities. 7.5 IRI for IMS In parameter ‘SIPmessage’, in the case of IRIonly surveillance, it is necessary to remove the CC, such as SMS or other messaging content (e.g. immediate messaging), before transmission. 7.5.1 Events and information If the obligated party uses encryption on the network side or collaborates in key generation or exchange, Report parameters Correlation number and and can therefore decrypt the telecommunication, Correlation as per Table 7.2. remove the decryption at the handover interface Report parameter mediaDecryption-info. (§ 8(3) TKÜV). CCKeyInfo.cCSalt if this value is available to the If the obligated party supports encryption of peer-to- obligated party. peer-communications over the Internet by providing key management, without involving its network elements or those of its partners in CC transmission, it must at least provide the authorised agency with the key previously exchanged with its telecommunication system. Transmission of the exchanged key is not required if the obligated party can still remove the encryption on the network side using additional network elements. Chapter 8. 3GPP WLAN Interworking (removed) Chapter 9. Interception of Multimedia Broadcast/MultiCast Service (MBMS) Where publicly accessible services as per Section 9 of 3GPP Specification TS 33.108 are offered in Germany, the resulting requirements always apply. Coordinate with the Federal Network Agency on the further details of the design of the surveillance functionality for these services. Chapter 10. Evolved Packet System (EPS) 10.1.2 Network Identifier (NID) The NID consists of components such as the 5- character operator (NO/AN/SP) identifier. In Germany, the first two digits are ‘49’, with the Federal Network Agency determining the remaining three characters for the relevant obligated party. 10.2.1 Timing In general, give all timestamps in official time. The GeneralisedTime parameter is not encoded as universal time and does not use a time difference. The winterSummerIndication must be set to either For IRI buffering, the requirement in the adjacent wintertime or summertime. column applies. See Annex A.4 to the TR TKÜV. 10.3 Security aspects. When using an IP-based handover interface, IPSec To protect IP-based handover interfaces, use is applied. dedicated IP Crypto-boxes based on IPSec in combination with a PKI as per Annex A.2 to the TR TKÜV. 10.4 Quantitative aspects The indications in Section 3.2 TR TKÜV apply to dimensioning of the administration and transmission capacities. TR TKÜV, edition 8.1 (draft) Part A, Annex D, page 37 Section of Description of the option or issue and Additional requirement, background or additional 3GPP specifications for national application information TS 33.108 10.5.0 PacketDirection Clearly indicate the flow of the CC using to target and from target. IP addresses and port numbers For transmission of the source and destination IP addresses and the associated port numbers of the participating users, use parameters sourceIPAddress, destinationIPAddress, sourcePortNumber and destinationPortNumber. Table Tracking Area Update (REPORT) old location information 10.5.1.1.5 Report this parameter if this value is available for the Provide (only by the old MME), when authorised surveillance functionality of the obligated party. and if available, to identify the old location information for the intercept subject’s MS. Table Bearer Deactivation (END) EPS bearer id 10.5.1.4.1 Report this parameter if this value is available for the surveillance functionality of the obligated party. 10.6 IRI reporting for evolved packet domain at PDN- GW This option need not be implemented in Germany. Under certain conditions (e.g. roaming), the PDN- GW may be the only option for surveillance. In Note: Where roaming between network operators is these cases, implement the surveillance possible in Germany, a measure for a specific LuS functionality for IRI collection and transmission on must cover all the relevant networks. the PDN-GW as per Section 10.6 of 3GPP Specification 33.108. 10.7 CC interception for evolved packet domain at PDN-GW This option is only permitted in Germany if the Under certain conditions (e.g. roaming), the PDN- requirement in § 4(1) TKÜV is met. GW may be the only option for surveillance. In these cases, implement the surveillance Note: Where roaming between network operators is functionality for CC collection and transmission on possible in Germany, a measure for a specific LuS the PDN-GW as per Section 10.7 of 3GPP must cover all the relevant networks. Specification 33.108. Chapter 11: 3GPP IMS Conference Services 11.1.3 Network Identifier (NID) The NID consists of components such as the 5-character operator (NO/AN/SP) identifier. In Germany, the first two digits are ‘49’, with the Federal Network Agency determining the remaining three characters for the relevant obligated party. 11.2.1 Timing In general, give all timestamps in official time. The GeneralisedTime parameter is not encoded as universal time and does not use a time difference. The winterSummerIndication must be set to either wintertime or summertime. For IRI buffering, the requirement in the adjacent column applies. See Annex A.4 to the TR TKÜV. 11.3 Security aspects. When using an IP-based handover interface, IPSec To protect IP-based handover interfaces, use is applied. dedicated IP Crypto-boxes based on IPSec in combination with a PKI as per Annex A.2 to the TR TKÜV. TR TKÜV, edition 8.1 (draft) Part A, Annex D, page 38 Section of Description of the option or issue and Additional requirement, background or additional 3GPP specifications for national application information TS 33.108 11.4 Quantitative aspects The indications in Section 3.2 TR TKÜV apply to dimensioning of the administration and transmission capacities. Chapter 12: 3GPP IMS-based VoIP Services Where publicly accessible telecommunications services as per Section 12 of 3GPP Specification TS 33.108 are offered in Germany, the resulting requirements always apply. Coordinate with the Federal Network Agency on the further details of the design of the surveillance functionality for these telecommunications services. Chapter 13. Interception of Proximity Services (ProSe) Chapter 14. Invocation of Lawful Interception (LI) for Group Communications System Enablers (GCSE) Where publicly accessible telecommunications services as per Sections 13 and 14 of 3GPP Specification TS 33.108 are offered in Germany, the resulting requirements always apply. Coordinate with the Federal Network Agency on the further details of the design of the surveillance functionality for these telecommunications services. Chapter 15. Interception of Messaging Services 15.2.2 SMS over GPRS/UMTS The requirements for point 6.5.1.1 of this table apply. 15.2.3 SMS over IMS The requirements for points 6.5.1.1 and 10.5.1.1.5 of this table apply. 15.3 MMS Chapter 16. Cell Site Reporting Chapter 17. Interception of PTC Chapter 18. PTC Encryption Where publicly accessible telecommunications services as per Sections 16 to 18 of 3GPP Specification TS 33.108 are offered in Germany, the resulting requirements always apply. Coordinate with the Federal Network Agency on the further details of the design of the surveillance functionality for these telecommunications services. Annex A. HI2 delivery mechanisms and procedures A.2 FTP When transmitting IRI over FTP, use File naming method B. The provisions of Annexes A.1 and A.2 to the TR TKÜV also apply. Annex C. UMTS HI3 interface C.1 UMTS LI correlation header It is necessary to implement option ULICv1 in Germany. When using ULIC header version 1, use parameters LIID and timeStamp (mandatory). TR TKÜV, edition 8.1 (draft) Part A, Annex D, page 39 Section of Description of the option or issue and Additional requirement, background or additional 3GPP specifications for national application information TS 33.108 C.1.1 Introduction The TCP/IP transmission method is planned for For transmission, port number 50010 is defined for the Germany. authorised agency (destination port number). Annex D.1.2 Basis: 3GPP TS 33.128 Note: The requirements in this section are in the development and coordination process. They are based on 3GPP TS 33.128, Release 16 (V16.9.0), which contains specifications for Network Layer-Based Interception in Section 6 and Service Layer-Based Interception in Section 7 (7.3 Location, 7.4 Messaging). In addition, it details target identifier formats (e.g. SUPIIMSI, SUPINAI, PEIIMEI, PEIIMEISV, GPSIMSISDN, GPSINAI) and defines the HI4 interface (LI notification: activation, modification, deletion). The TR TKÜV, edition 8.2, strives to provide an analogous description; current implementations must be coordinated with the Federal Network Agency. Annex D.2 Explanatory notes on ASN.1 descriptions The ASN.1 descriptions of the different modules for implementations under this Annex D must come from the different versions of 3GPP Specification TS 33.108, with removal of any ASN.1 module errors (e.g. incorrect domainID) during implementation. Parameters designated as ‘conditional’ or ‘optional’ in the specification must be transmitted if available and if the specification and Annex D.1 do not indicate otherwise. For the ASN.1 types of OCTET STRING format that they contain, the following rules apply:  If the standard defines a format for the parameters in question, such as ASCII or cross-reference to a (signalling or other) standard, use this.  If it does not indicate the format, enter both hexadecimal values in the relevant bytes so the higher-value half byte is in bits 5 to 8 and the lower-value half byte is in bits 1 to 4. (Examples: insert 4F H as 4F H = 0100 1111, not as F4 H; or for instance DDMMYYhmm = 23.07.2002 10:35 h as ‘2307021035’ H, not ‘3270200153’H.) Transmit administrative events (e.g. activation/deactivation/modification of a measure and error messages) as well as additional events (e.g. for proprietary services) as per Annex A.3. TR TKÜV, edition 8.1 (draft) Part A, Annex E, page 40 Annex E. Handover interface for voice, fax and data storage equipment (voicemail systems, unified messaging systems, etc.) This Annex sets out the national requirements on the handover interface for storage equipment (UMS, VMS, etc.), for handover interfaces set up as per Annexes D to H that do not meet these in full. In addition to the requirements in Part A, Sections 3 and 4, the following Annexes apply: Annex Contents Annex A.1 FTP and TCP/IP Transmit the copy of the CC as per this Annex E along with the IRI in an XML-encoded file, which can be sent over FTP. Annex A.1 gives the required specifications. Annex A.2 Specifications for participation in the VPN and an alternative procedure based on HTTPS/TLS Annex A.3 Transmission of HI1 IRI and additional events Annex A.4 Failed transmission of the surveillance copy to the lines of the authorised agency This text also references the following Annexes to Part X of the TR TKÜV: Annex X.1 Proposed changes to the TR TKÜV Annex X.2 Assignment of an identification feature for authorised agencies to guarantee unique reference numbers Annex X.3 Registration and certification authority of the Federal Network Agency (TKÜV CA), Unit IS16 (Policy) Annex X.4 Concept template for preparation of the documentary evidence, test protocols and test reports Annex E.1 Definitions Unified Messaging System All variants of storage equipment operated in telecommunications (UMS) networks, typically intended for multiple forms of telecommunications, such as voice, fax, email, short messages, multimedia messaging service (MMS), etc. (UMS)Box The part of the Unified Messaging System that is allocated to a particular user – the LuS in the cases under consideration here. Annex E.2 General explanatory notes For technical implementation of orders for telecommunications interception measures (TCIMs), please note the system-specific feature that UMS lacks real-time communication between the LuS and its partner. This affects certain aspects of the technical implementation of interception measures of this kind, in particular with regard to transmission of the surveillance copy to the authorised agency:  It is not necessary to separate the telecommunication under surveillance into sending and receiving directions for separate transmission.  The lack of real-time requirements in these cases offers new options for transmission of the telecommunication under surveillance that are both practical and cost-effective. The copy of the CC from the aforementioned storage equipment may be transmitted to the authorised agency with a small but minimal time delay: no later than immediately after storing a message in the storage system, or with a delay not exceeding 10 seconds when retrieving a message. If a full copy of a specific message has already been transmitted, it will suffice to send only the IRI for further events (e.g. subsequent listening to the message). To enable proper correlation of the different transmissions at the authorised agency in these cases, the correlation number field must contain a unique correlation attribute. Because an interception order only covers the telecommunication that is stored, retrieved or copied in the UMS during the specified timeframe, it is not permitted to monitor messages that were already stored in the UMS before this timeframe. Only collect these where appropriate, such as if they are retrieved. TR TKÜV, edition 8.1 (draft) Part A, Annex E, page 41 Annex E.3 Transmission methods and specification of relevant events Annex E.3.1 Transmission methods for telecommunications under surveillance It is permitted to collect and transmit the forms of telecommunication stored in unified messaging systems (voice, fax and SMS) in combination with an implementation as per Annex D, F, H or I. Alternatively, it is possible to transfer these forms of telecommunication in an XML-encoded file to the authorised agency over FTP. Multimedia messages (MMS) stored in a UMS are also transmitted to the authorised agency in an XML- encoded file over FTP. In addition, it is also permitted to transfer MMS to the authorised agency using the handover interface described in Annex H. If the UMS also offers email service functions, or if using email service to transmit the messages, design the handover interface for this form of telecommunication as per Annex F. Moreover, transmission as per Annex F is permitted for all forms of telecommunications, such as those stored in the UMS as emails. The table below shows the various options. Content Transmission methods Over RTP connections as per Annex H (coordinate with the Federal Network Agency on the encoding used1).) In wav or mp3 format in an XML-encoded file 2) along with the IRI as per Annex E.5, which may Voice optionally be transmitted over FTP In email format as per Annex F In XML format as per Annex I Over RTP connections as per Annex H (coordinate with the Federal Network Agency on the encoding used1).) In tif, jpg or png format in an XML-encoded file1) along with the IRI as per Annex E.5, which may Fax optionally be transmitted over FTP In email format as per Annex F In XML format as per Annex I In an IRI record as per Annex D Over RTP connections or SIP messages as per Annex H (coordinate with the Federal Network Agency on the methods and encoding used1).) SMS 3) As an SMS in an XML-encoded file1) along with the IRI as per Annex E.5, which may optionally be transmitted over FTP In email format as per Annex F In XML format as per Annex I Multimedia In email format in an XML-encoded file1) along with the IRI as per Annex E.5, which may messages (MMS) optionally be transmitted over FTP In email format as per Annex F Over RTP connections or SIP messages as per Annex H (coordinate with the Federal Network Agency on the methods and encoding used1).) Email In an XML-encoded file along with the IRI over FTP, as per Annex F In XML format as per Annex I Annex E.3.1-1 Table: Transmission methods for UMS 1) Only use open encoding algorithms for the encoding. 2) Transmission of the XML-encoded file to the authorised agency is subject to the transmission and IRI requirements set in Annexes D and H for transmission and protection. If the first connection attempt fails to transmit the file with the copy of the CC and the IRI to the authorised agency, make at least three further transmission attempts within an interval of a few minutes. See Annex A.4 for further details. TR TKÜV, edition 8.1 (draft) Part A, Annex E, page 42 3) Transmit the message text of an SMS or MMS to the authorised agency as text in the UTF-8 character set. Alternatively, when sending the message content of an SMS, it is permitted to send the content of the entire PDU (including SM header, user data header and user data) in hexadecimal form, as per 3GPP Specification TS 23.040. This corresponds to the requirement in Annexes D and H. Annex E.3.2 Specification of relevant events The following events require transmission of the copy of the CC as well as the IRI. If the UMS has service features that these events do not cover (such as call back in response to a voice message), coordinate with the Federal Network Agency on the relevant requirements: Event Comments Recording or storage Recording or storage of a message (voice, fax or SMS) in the UMS using:  call forwarding with the identifier of the LuS; or  dial-in or sending from any line (such as direct dial-in to the UMS using a service number or web access) Consultation or retrieval Consultation or retrieval of a message (voice, fax or SMS) from the UMS using:  the identifier of the LuS, or by dialling this identifier with subsequent call forwarding to the UMS;  any line (such as direct dial-in to the UMS using a service number or web access). Copying of memory contents Copying of memory contents from one box associated with the LuS identifier to another box, and vice versa Accessing the box and The possible events here (such as setting a notification number, creating mailing modification of settings lists) must be coordinated individually with the Federal Network Agency. Annex E.3.2-1 Table: Events in a UMS TR TKÜV, edition 8.1 (draft) Part A, Annex E, page 43 Annex E.4 Requirements on surveillance of voice and fax messages and SMS as per Annexes B, C or D Note: ISDN-based transmission is no longer permitted. The descriptions in this Annex E.4 are contained in the TR TKÜV up to edition 8.0. Annex E.5 Requirements on surveillance of voice and fax messages, SMS and MMS within an XML-encoded file It is permitted to transmit copies of the different forms of telecommunication (voice, fax, SMS and MMS) in a single unit using an XML-encoded file over FTP. In this case, convert the various forms of telecommunication into a file format as per the table below. This table will be expanded for new technologies. For this, coordinate with the Federal Network Agency on any newly defined parameters. Parameter (tag) Application <audio-wav> Voice message in wav format <audio-mp3> Voice message in mp3 format <fax-tif> Fax message in TIFF format <fax-jpg> Fax message in JPEG format <fax-png > Fax message in PNG format <sms> Short Message <mms> Multimedia Message Present MMS under surveillance in the form of email, with the message text in the text field and the corresponding images in the attachment. Do not enter any parameters in the email header. Annex E.5-1 Table: Parameters (tag) for file formats Annex E.5.1 IRI parameters The table below lists the individual IRI parameters normally transferred along with the copy of the CC to the authorised agency in an XML-encoded file. Parameters Values/definition/explanation <version-identifier> Identifier that the OPTS operator assigns to designate the relevant interface version, in ASCII format (max. 20 characters) <record-type> ‘Report’ as identifier of a unique event <reference-number> Identifying attribute for the interception measure as per the first sentence of § 7(2) TKÜV, in ASCII format <correlation-number> For correlation with the CC, in ASCII format (values of 1 to 65535) <LuS-identifier> Attribute of the identifier under surveillance as per § 7(1)(first sentence)(1) TKÜV (e.g. voice communication service or fax number assigned to the UMS as per E.164, email address) <partner-identifier> 1) Identifier as per § 7(1)(first sentence)(2 to 4) TKÜV used to store or retrieve a message or change settings (e.g. telephone number of the line to which the UMS is assigned, service number) <IP> 1) The IP address transmitted to the UMS as per § 7(1)(first sentence)(2 to 4) TKÜV (the IP address of the telecommunication partner, such as when retrieving or storing messages using web access, if a telephone number is not available as a partner identifier) <start> Start of the telecommunication under surveillance (such the time of message storage) as per § 7(1)(first sentence)(8) TKÜV in format: DD/MM/YY hh:mm:ss Only transmit the file with IRI and/or CC to the authorised agency after the end of the telecommunications process under surveillance. TR TKÜV, edition 8.1 (draft) Part A, Annex E, page 44 Parameters Values/definition/explanation <settings> 1. Details on the settings made in the UMS, starting with the event: ‘access’ (of the box by its owner), ‘create mailing lists’, ‘messaging’ (settings in the messaging service), ‘welcome text’, ‘change’ (other box settings), and 2. followed by indication of the settings applied (parameters) in format: free ASCII- encoded text Separate these data with a ‘;’ (ASCII character No 59). <direction> Details on the event to be reported, such as: ‘received’, ‘retrieved’, ‘listen’ (to messages), ‘box-to-box receipt’, ‘stored’, ‘sent’, ‘recording’ (of messages), ‘box-to-box sending’, ‘messaging’ (for available messages), ‘callback’2); if multiple events occur at nearly the same time, e.g. ‘stored’ and ‘sent’, it is also permitted to enter two values separated by a ‘;’ (ASCII character No 59). <LuS-termination- The reason for termination of the connection under surveillance, such as: reason>  ‘successful’; or  system error message as a text string, such as cancelling a download; for the text string, only ASCII characters of the Base64 scheme are permitted. <interception-measure- Once for each measure, with the time of measure activation (not administration in the case start> of time-controlled actions) in the OPTS as per § 5(5) TKÜV, in format: DD/MM/YY hh:mm:ss <interception-measure- Once for each measure, with the time of measure deactivation (not administration in the end> case of time-controlled actions) in the OPTS as per § 5(5) TKÜV, in format: DD/MM/YY hh:mm:ss Table E.5.1-1 XML file IRI parameters 1) This serves to enable transmission of at least the IP address if a unique <partner identifier> is not available. 2) If a VMS/UMS box owner can initiate a call to a line that left a message, it is necessary to report this event and also ensure surveillance of the call. It is not necessary to correlate the ‘callback’ event with the stored message using the <correlation number> parameter. Annex E.5.2 XML structure and DTD for voice, fax, SMS and MMS Generate the XML-encoded file in UTF-8 format. The following example of an XML structure has values entered for all tags. However, only transmit these tags where appropriate for the event in question. If parameters are not available for the IRI, use an empty tag according to XML syntax, e.g. ‘<interception-measure-start/>’. The comment lines are not needed and may be omitted. XML structure (with example entries): <?xml version="1.0" encoding="UTF-8" standalone="no"?> <!DOCTYPE hi3-ums SYSTEM "hi3-ums_v1.dtd"> <?xml-stylesheet href="ums_v1.xsl" type="text/xsl"?> <hi3-ums> <version-identifier>ABC1234</version-identifier> <record-type>report</record-type> <reference-number><![CDATA[123456789 in Base64 encoding 1]]></reference-number> <correlation-number><![CDATA[123 in Base64 encoding1]]></correlation-number> <LuS-identifier><![CDATA[987654#E.164#national number in Base64 encoding 1]]></LuS-identifier> <IP>111.222.63.254</IP> <partner-identifier><![CDATA[123456#E.164#national number in Base64 encoding 1]]></partner-identifier> <start>31/12/06 10:10:05</start> <settings><![CDATA[welcome text;free text in Base64 encoding 1]]></settings> <direction><!CDATA[retrieved in Base64 encoding 1]]</direction> <LuS-termination-reason><![CDATA[normal call clearing in Base64 encoding 1]]></LuS-termination-reason> <interception-measure-start>01/12/06 01:00:00</interception-measure-start> <interception-measure-end>01/02/07 01:00:00</interception-measure-end> <fax-tif> TR TKÜV, edition 8.1 (draft) Part A, Annex E, page 45 <!-- fax-tif start --> <![CDATA[copy of the complete fax under surveillance in Base64 encoding 1]]> <!-- fax-tif end--> </fax-tif> <fax-jpg> <!-- fax-jpg start --> <![CDATA[copy of the complete fax under surveillance in Base64 encoding 1]]> <!-- fax-jpg end--> </fax-jpg> <fax-png> <!-- fax-png start --> <![CDATA[copy of the complete fax under surveillance in Base64 encoding 1]]> <!-- fax-png end--> </fax-png> <audio-wav> <!-- audio-wav start --> <![CDATA[copy of the complete audio signal under surveillance in Base64 encoding 1]]> <!-- audio-wav end --> </audio-wav> <audio-mp3> <!-- audio-mp3 start --> <![CDATA[copy of the complete audio signal under surveillance in Base64 encoding 1]]> <!-- audio-mp3 end --> </audio-mp3> <sms> <!-- SMS start --> <![CDATA[copy of the complete SMS under surveillance in Base64 encoding 1]]> <!-- SMS end --> </sms> <mms> <!-- MMS start --> <![CDATA[copy of the complete MMS under surveillance is inserted here in email format and Base64 encoding 1 ]]> <!-- MMS end --> </mms> </hi3-ums> Doctype definition <!ELEMENT hi3-ums (version-identifier,record-type,reference-number,correlation-number,LuS- identifier,IP,partner-identifier,start,settings,direction,LuS-termination-reason,interception-measure- start,interception-measure-end,fax-tif,fax-jpg,fax-png,audio-wav,audio-mp3,sms,mms)> <!ELEMENT version-identifier (#PCDATA)> <!ELEMENT record-type (#PCDATA)> <!ELEMENT reference-number (#PCDATA)> <!ELEMENT correlation-number (#PCDATA)> <!ELEMENT LuS-identifier (#PCDATA)> <!ELEMENT IP (#PCDATA)> <!ELEMENT partner-identifier (#PCDATA)> <!ELEMENT start (#PCDATA)> <!ELEMENT settings (#PCDATA)> <!ELEMENT direction (#PCDATA)> <!ELEMENT LuS-identifier (#PCDATA)> <!ELEMENT interception-measure-start (#PCDATA)> <!ELEMENT interception-measure-end (#PCDATA)> <!ELEMENT fax-tif (#PCDATA)> <!ELEMENT fax-jpg (#PCDATA)>  TR TKÜV, edition 8.1 (draft) Part A, Annex E, page 46 <!ELEMENT fax-png (#PCDATA)> <!ELEMENT audio-wav (#PCDATA)> <!ELEMENT audio-mp3 (#PCDATA)> <!ELEMENT sms (#PCDATA)> <!ELEMENT mms (#PCDATA)> 1 The values of the individual tag and the copy of the message under surveillance must be Base64-encoded and integrated as per RFC 5322 or RFC 2045 [30]. Please note that the Base64 encoding requires insertion of a line break every 76 characters. TR TKÜV, edition 8.1 (draft) Part A, Annex F, page 47 Annex F. Email service storage equipment This Annex contains two alternative descriptions of the handover interface for surveillance of the email service:  Annex F.2 defines a national handover interface for transmission of the copy of the email to the authorised agency along with the IRI in an XML file over FTP.  The alternative description of the handover interface in Annex F.3 is based on ETSI Specification TS 102 232-2 [30] and describes an ASN.1 file that also contains the entire surveillance copy and uses TCP/IP for transmission. In addition to the requirements in Part A, Sections 3 and 4, the following Annexes apply: Annex Contents Annex A.1 FTP and TCP/IP In cases of transmission of the copy of the email as per Annex F.2 along with the IRI in an XML-encoded file over FTP, the specifications in Annex A.1 apply. Annex A.2 Specifications for participation in the VPN and an alternative procedure based on HTTPS/TLS Annex A.3 Transmission of HI1 IRI and additional events Annex A.4 Failed transmission of the surveillance copy to the lines of the authorised agency This text also references the following Annexes to Part X of the TR TKÜV: Annex X.1 Proposed changes to the TR TKÜV Annex X.2 Assignment of an identification feature for authorised agencies to guarantee unique reference numbers Annex X.3 Registration and certification authority of the Federal Network Agency (TKÜV CA), Unit IS16 (Policy) Annex X.4 Concept template for preparation of the documentary evidence, test protocols and test reports Annex F.1 Definitions, basic information Email server All telecommunications system variants that store or transmit messages from the email service, regardless of user access options, such as SMTP, POP3, IMAP, WEB, WAP or proprietary access. Email address Address as per RFC 5322. If applied: internationalised email address as per RFC 6530, RFC 6531, RFC 6532 and RFC 6533. The email address is an identifier used to denote the telecommunication under surveillance. Mailbox Storage space for the email messages of a user (email account) that stores sent and received messages. In certain situations, a mailbox under surveillance may be a mailbox for multiple email addresses. Login Process that verifies that the user has access permission for the email mailbox. Login name In addition to the email address, the login name used during login as part of the access ID is also an identifier used to denote the telecommunication under surveillance. As a technical attribute, a telecommunications surveillance order in the email service may contain:  an email address; or  the access ID (login name without password) of a mailbox. TR TKÜV, edition 8.1 (draft) Part A, Annex F, page 48 To monitor the complete telecommunication under the identifier, it is necessary to ensure, in particular for outgoing traffic (e.g. sending emails over SMTP), that the monitored telecommunication can actually be correlated to the LuS using suitable authentication methods. This should prevent situations such as failure to collect an email under surveillance during sending merely because the user has tampered with sender address. While the login authentication procedure (login name and password) generally meets this requirement during surveillance based on the login name, it is only possible to implement email address surveillance in these cases if the protocol-specific authentication method used meets this requirement. Annex F.2 gives further details on the authentication methods permitted for this. If it is not possible to meet this requirement (such as due to an unsuitable authentication method) for the SMTP, POP3 or IMAP protocol, it is instead necessary, for this protocol, to implement an order specific to the email address by monitoring the entire mailbox, which requires collecting the telecommunications of all email addresses of this mailbox. If an integrated authentication procedure is not available for access to the mailbox either, coordinate with the Federal Network Agency on another authentication procedure, or another procedure enabling exclusive surveillance of the telecommunications on the LuS. Merge the CC consisting of the full copy of the email under surveillance (header, body and attachment) and the associated IRI into a single file. Transmit this file to the authorised agency over FTP immediately after the event in question. However, in certain usage scenarios, such as with Multipart Messages, it is permitted not to transmit the email under surveillance in a single file, subject to requirements not to buffer CC and requirements to provide unedited monitored telecommunications. This ensures transmission of individual parts of an incomplete email to the recording lines of the authorised agencies. If the order only requires surveillance of the IRI, only transmit these to the authorised agency (without CC). Annex F.2 Nationally specified email handover interface If a full copy of a specific email has already been transmitted to the authorised agency, it will suffice to send only the IRI for further events as per Tables F.2-1-1 to F.2-1-3 (e.g. subsequent email retrieval). To enable proper correlation of the different transmissions at the authorised agency in these cases, the correlation number field must contain a unique correlation attribute. The list in Tables F.2-1-1 to F.2-1-4 may require expansions or updates depending on the capabilities of the specific email server. The following events require transmission of the CC and the IRI to the authorised agency. Simple Mail Transfer Protocol (SMTP) Event Comments Value of XML Notes on the value of XML parameter parameter <partner-identifier> <direction> Receipt of an Regardless of whether it is ‘received’ For the emails sent to the email address email delivered directly to the user under surveillance, only indicate the under surveillance or stored in sender in IRI field <partner-identifier> the mailbox (envelope: MAIL FROM as per RFC 5322), not the other recipients (envelope: RCPT TO as per RFC 5322). The LuS identifier appears in a RCPT TO field of the envelope or in the TO field of the email header. Storage of an The user under surveillance ‘stored’ For the outgoing emails from the email email 1) transfers an email to the email address under surveillance, fill IRI field server. <partner-identifier> with the contents of all address fields, except for the LuS Sending an email The email server sends a stored ‘sent’ (ENVELOPE: RCPT TO as per RFC email. 5322). Forwarding of an Emails that are received and then ‘sent’ email forwarded Table F.2-1-1 SMTP events 1) The ‘storing of an email’ event also applies to stored or modified email drafts, regardless of the protocol used, even if initially stored without an email address or subject line, for instance. TR TKÜV, edition 8.1 (draft) Part A, Annex F, page 49 Permitted authentication methods  In principle, on connection setup, the SMTP server performs explicit authentication by means of SMTP-AUTH.  The user first logs into the mailbox using the POP server, and uses the access details for authentication (user name and password). The user then has a limited window of time to send emails over SMTP (‘SMTP after POP’). The authentication requirement as per Annex F.1 is only met with an appropriately short time window.  The user receives an IP address that serves as the authentication criterion.  If the email provider is also an access provider, it is permitted to use the authentication performed during network login for the email service as well. Authentication is not relevant for the ‘receipt of an email’ event, because incoming emails must always be transmitted for telecommunications under surveillance. Post Office Protocol Version 3 (POP3) Event Comments Value of XML Notes on the value of XML parameter parameter <partner-identifier> <direction> Retrieval of an The user under surveillance ‘retrieved’ For the emails sent to the email address email retrieves an email from the under surveillance, only enter the sender mailbox, in whole or in part (e.g. in IRI field <partner-identifier>, not the only the header, subject line or other recipients. The MAIL BODY attachment). provides the value to be indicated. Table F.2-1-2 POP3 events Permitted authentication methods  The user logs into the mailbox on the website 1 or on the POP3 server and uses the access details for authentication (login name and password) before retrieving emails. Internet Message Access Protocol (IMAP) Event Comments Value of XML Notes on the value of XML parameter parameter <partner-identifier> <direction> Storage of an A message generated by an ‘stored’ For these emails, fill IRI field <partner- email 2) email client is stored in an IMAP identifier> with the contents of all directory (using IMAP command address fields, except for the LuS. The APPEND) and then synchronised MAIL BODY provides the value to be with the server. indicated. Retrieval of an The user under surveillance ‘retrieved’ For the emails sent to the email address email retrieves an email from the under surveillance, only enter the sender mailbox, in whole or in part (e.g. in IRI field <partner-identifier>, not the only the header, subject line or other recipients. The MAIL BODY attachment). For IMAP however, provides the value to be indicated. only monitor the emails or parts thereof (e.g. only the header, subject line or attachment) that are transmitted between the client and the server due to folder synchronisation (as new email). Table F.2-1-3 IMAP events 2) The ‘storing of an email’ event also applies to stored or modified email drafts, regardless of the protocol used, even if initially stored without an email address or subject line, for instance. Permitted authentication methods  The user logs into the mailbox on the website 1 or on the IMAP server and uses the access details for authentication (login name and password) before retrieving, storing or moving emails. 1 Applies to webmail services based on IMAP or POP3. TR TKÜV, edition 8.1 (draft) Part A, Annex F, page 50 Comments on the above tables  Repeated transmission of records with identical content between different physical parts of a logical IMAP server to the authorised agency is only permitted as a result of Fetch or Append commands to synchronise server or client directories. The authorised agency has the option to triage identical data accordingly using a unique correlation attribute (see parameter <correlation number>).  Emails received by the SMTP server and then immediately forwarded to an email address predefined by the mailbox user also require surveillance. In parameter <direction>, use the value ‘received’ for receipt of the value ‘sent’ and for subsequent sending.  For each event, merge a copy of each email under surveillance with the associated IRI as per Table F.2.1-1 of Annex F.2.1 into a single XML-encoded file. Encode the complete copy of the email (i.e. address fields, subject line, body and any attachments) in Base64. Base64 encoding requires insertion of a line break after every 76 characters.  Transmit the XML-encoded file to the authorised agency over FTP. See Annexes A.1 to A.4 for the design of the file name, FTP parameters, security using a VPN and the procedure for transmission failure. Annex F.2.1 IRI parameters The table below lists the individual IRI parameters normally transferred along with the copy of the CC to the authorised agency in an XML-encoded file. Parameters Definition/explanation <version-identifier> Identifier that the OPTS operator assigns to designate the relevant interface version <record-type> ‘Report’ as identifier of a unique event <reference-number> Identifying attribute for the interception measure as per the first sentence of § 7(2) TKÜV, in ASCII format (1 to 25 characters, character set ‘a’…‘z’, ‘A’…‘Z’, ‘-’, ‘_’, ‘.’, and ‘0’…‘9’) The permitted character set corresponds to the implementations as per ETSI or 3GPP. <correlation-number> Correlation with the CC Here, use the Message ID (as per RFC 5322) of the email under surveillance. This can be copied from the email header or envelope data. <LuS-identifier> Attribute of the identifier under surveillance as per § 7(1)(first sentence)(1) TKÜV (e.g. email address or mailbox user ID) <partner-identifier>1 Identifier as per § 7(1)(first sentence)(2 to 4) TKÜV The value of the parameter depends on the protocol (see Tables F.2-1-1 to F.2-1-3). Separate multiple partner identifiers with a ‘;’ (ASCII character No 59). <IP> The IP address of the email client that is known to the email server and that is used to store or retrieve emails or change settings. <port> Identifier for the transmission protocol used (e.g. HTTP, SMTP, POP3). Implementations based on the TR TKÜV, edition 4.1, are only permitted to continue using the port numbers (e.g. 80, 25, 110) if this information is in accordance with the corresponding well-known ports. <start> Start of the telecommunication under surveillance (such as the time of email receipt) as per § 7(1)(first sentence)(8) TKÜV in format: DD/MM/YY hh:mm:ss Only transmit the file with IRI and/or CC to the authorised agencies after the end of the telecommunications process under surveillance. TR TKÜV, edition 8.1 (draft) Part A, Annex F, page 51 Parameters Definition/explanation <settings> Contains two data, to be separated using ‘;’ (ASCII character No 59). 1. Details on the following settings: ‘access’ (Successful mailbox owner login), ‘mailing lists’ (including changes), ‘messaging’ (such as messaging service settings), ‘forwarding’ (such as email forwarding settings), ‘email address’ (such as creation or deletion of an additional email address in the mailbox under surveillance); and 2. followed by indication of the settings applied (parameters) in format: free ASCII- encoded text <direction> Details on the event being reported as per Tables F.2-1-1 to F.2-1-3: ‘received’, ‘retrieved’, ‘sent’, ‘stored’. If multiple events occur at nearly the same time, e.g. ‘stored’ and ‘sent’, it is also permitted to enter two values separated by a ‘;’ (ASCII character No 59). <LuS-termination- The reason for termination of the connection under surveillance, such as: reason>  ‘successful’; or  system error message as a text string, such as cancelling a download; For the text string, only ASCII characters of the Base64 encoding are permitted. <interception-measure- Once for each measure, containing the time of measure activation (not administration in the start> case of time-controlled actions) in the OPTS as per § 5(5) TKÜV, in format: DD/MM/YY hh:mm:ss <interception-measure- Once for each measure, containing the time of measure deactivation (not administration in the end> case of time-controlled actions) in the OPTS as per § 5(5) TKÜV, in format: DD/MM/YY hh:mm:ss Table F.2.1-1 XML file IRI parameters 1 During analysis, the receiving authorised agency must bear in mind that it is not possible to recognise altered partner identifiers (such as ‘[email protected]’ instead of the real email address). Annex F.2.2 XML structure and DTD Generate the XML-encoded file in UTF-8 format. The following example of an XML structure has values entered for all tags. However, only transmit these tags where appropriate for the event in question. If parameters are not available for the IRI, use an empty tag according to XML syntax, e.g. ‘<interception-measure-start/>’. Comment lines are not required and may be omitted. XML structure <?xml version="1.0" encoding="UTF-8" standalone="no"?> <!DOCTYPE hi3-email SYSTEM "hi3-email_v1.dtd"> <?xml-stylesheet href="Email_v1.xsl" type="text/xsl"?> <hi3-email> <version-identifier>ABC1234</version-identifier> <record-type>report</record-type> <reference-number><![CDATA[123456789 in Base64 encoding 1]]></reference-number> <correlation-number><![CDATA[0474745765656 in Base64 encoding1]]></correlation-number> <LuS-identifier><![CDATA[[email protected] in Base64 encoding 1]]></LuS-identifier> <IP>111.222.63.254</IP> <port>SMTP</port> <partner-identifier><![CDATA[[email protected]; [email protected] in Base64 encoding 1]]></partner- identifier> <start>31/12/06 10:10:05</start> <settings><![CDATA[forwarding; free text in Base64 encoding 1]]></settings> <direction><![CDATA[retrieved in Base64 encoding 1]]</direction>  TR TKÜV, edition 8.1 (draft) Part A, Annex F, page 52 <LuS-termination-reason><![CDATA[successful in Base64 encoding 1]]></LuS-termination-reason> <interception-measure-start>01/12/06 01:00:00</interception-measure-start> <interception-measure-end>01/02/07 01:00:00</interception-measure-end> <email> <!-- email start --> <![CDATA[ Copy of the email under surveillance in Base64 encoding 1]]> <!-- email end --> </email> </hi3-email> Doctype definition <!ELEMENT hi3-email (version-identifier,record-type,reference-number,correlation-number,LuS- identifier,IP,port,partner-identifier,start,settings,direction,LuS-termination-reason,interception-measure- start,interception-measure-end,email)> <!ELEMENT version-identifier (#PCDATA)> <!ELEMENT record-type (#PCDATA)> <!ELEMENT reference-number (#PCDATA)> <!ELEMENT correlation-number (#PCDATA)> <!ELEMENT LuS-identifier (#PCDATA)> <!ELEMENT IP (#PCDATA)> <!ELEMENT Port (#PCDATA)> <!ELEMENT partner-identifier (#PCDATA)> <!ELEMENT start (#PCDATA)> <!ELEMENT settings (#PCDATA)> <!ELEMENT direction (#PCDATA)> <!ELEMENT LuS-identifier (#PCDATA)> <!ELEMENT interception-measure-start (#PCDATA)> <!ELEMENT interception-measure-end (#PCDATA)> <!ELEMENT email (#PCDATA)> 1 The values of the individual tags and the copy of the email under surveillance must be Base64-encoded and integrated as per RFC 5322 or RFC 2045. Please note that Base64 encoding requires insertion of a line break every 76 characters. Annex F.3 Email handover interface as per ETSI TS 102 232-2 As an alternative to the nationally specified handover interface as per Annex F.2, it is also permitted to design the handover interface as per ETSI TS 102 232-2 [30]. The principles as per Annex F.1 apply here. If a full copy of a specific email has already been transmitted to the authorised agency, it will suffice to send only the IRI for further events (email events) as per Section 6 of ETSI TS 102 232-2 (e.g. subsequent email retrieval). To enable proper correlation of the different transmissions at the authorised agency in these cases, it is necessary to provide a unique correlation attribute. In addition to the events defined in ETSI TS 102 232-2, report on email address or mailbox settings if they fall within the order timeframe. For this, fill ASN.1 field national-EM-ASN1parameters of the ASN.1 module as defined in TS 102 232-2. Based on the event to be collected, fill ASN.1 parameter ‘Email Recipient List’ accordingly (see requirement as per Annex F.3.1.2). TR TKÜV, edition 8.1 (draft) Part A, Annex F, page 53 Annex F.3.1 Selected options and additional technical requirements Annex F.3.1.1 Basis: ETSI TS 102 232-1 The table below describes the options selected for the different chapters and sections of ETSI Specification TS 102 232-1, as well as the additional requirements. Unless indicated otherwise, the references in the table are for the sections of the ETSI specification. Section of Description of the option or issue and Additional requirement, background or additional TS 102 232-1 specifications for national application information 5.2.1 Version The use of an OID in the ASN.1 description precludes the need for a separate parameter. 5.2.3 Authorisation country code In Germany, use ‘DE’. 5.2.4 Communication identifier In Germany, use the delivery country code ‘DE’. The communication identity number identifies the IRI The Federal Network Agency assigns the operator and CC of a communication process, corresponding to identifier as per Annex A.1. This always begins with the correlation number as per § 7(2) TKÜV. ‘49...’. The network operator assigns the network element identifier. This identifies the network element that collects the telecommunication. 5.2.5 Sequence number The sequence number must be created when the In exceptional cases where this condition cannot be surveillance copy is first generated (interception met, ensure that this function is set up in the Delivery point). Function at the latest. However, sequence numbers only created here must match the exact counting method at the place of origin. If UDP is used on this path, take additional measures to prevent potential package loss and secure the sequence. 5.2.6 Payload timestamp In general, give all times (TimeStamp) in the official From the TR TKÜV edition 7.0 and later, it is only (local) time as a permitted to use the MicroSecondTimeStamp. MicroSecondTimeStamp (with maximum resolution If the timestamp is not available in and accuracy). MicroSecondTimeStamp format at the interception In principle, the MicroSecondTimeStamp must be point, generate the timestamp in this format as closely created when the surveillance copy is first as possible to the interception point of the surveillance generated (interception point). copy. 5.2.11, 5.2.13 Interception Point Identifier and Extended Interception Point Identifier The network operator assigns the Interception In general, use the Interception Point Identifier. If the Point Identifier or Extended Interception Point identifier is longer than 8 characters, use the Extended Identifier. This identifies the logical point (inside a Interception Point Identifier. network element) where the data (IRI and/or CC) are collected in the network. 6.2.2 Error reporting Transmission is based on Annex A.4 to the TR TKÜV. 6.2.3 Aggregation of payloads Use combined transmission of monitored IP However, this should not take more than a few packets, to avoid unnecessary overhead. seconds, and it requires coordination with the Federal Network Agency. 6.2.5 Padding data As an option, the obligated party may implement The relevant authorised agency must approve of the this. use of padding. TR TKÜV, edition 8.1 (draft) Part A, Annex F, page 54 Section of Description of the option or issue and Additional requirement, background or additional TS 102 232-1 specifications for national application information 6.3.1 General Use TCP/IP. 6.3.2 Opening and closing of connections Section 3.1 TR TKÜV applies. This states that the Delivery Function must terminate to avoid unnecessary occupation of the lines of the authorised agency. 6.3.4 Keep-alives As an option, the obligated party may implement In principle, after successful data transmission, a timer this. must terminate the TCP connection. The relevant authorised agency must approve the use of padding keep-alives, which keep the TCP connection open continuously. 6.4.2 TCP settings For transmission, set port number 50100 for the The port number applies when using service authorised agency (destination port). specifications TS 102 232-2, TS 102 232-3, TS 102 232-4, TS 102 232-5 and TS 102 232-6. 7.1 Type of networks Transmit the payload over the public Internet. 7.2 Security requirements The requirements in Annex A.2 to the TR TKÜV apply. 7.3.2 Timeliness Any use of separate managed networks requires coordination between the obligated party and the authorised agencies. Annex F.3.1.2 Basis: ETSI TS 102 232-2 The table below describes the options selected for the different chapters and sections of ETSI Specification TS 102 232-2, as well as the additional requirements. Unless indicated otherwise, the references in the table are for the sections of the ETSI specification. Section of Description of the option or issue and Additional requirement, background or additional TS 102 232-2 specifications for national application information 6.2.3, 6.3.3, IRI 6.4.3 Always transmit the IRI indicated in Tables 1, 2 and See also the point ‘email format’. 3 for events ‘email send’, ‘email receive’ and ‘email download’. 7 Email attributes Transmit the email attributes according to the 7.3 Email recipient list requirements of the specification. This applies in For emails sent to the identifier under surveillance, particular to attribute ‘AAAInformation’. In addition, only indicate the sender, not the other recipients, such the requirements appearing at side apply. as those in the CC and/or BCC. 7.10 AAAInformation Also report POP3 or SMTP authentication parameters, such as ‘user name’, ‘password’, ‘authMethod’, etc. TR TKÜV, edition 8.1 (draft) Part A, Annex F, page 55 Section of Description of the option or issue and Additional requirement, background or additional TS 102 232-2 specifications for national application information A.4, B.4, C.2 HI2 event-record mapping In addition to the events described here, report the For transmission of settings, use the national settings for the following service features: ASN.1 module as per Annex A.3 to this TR TKÜV, sent to the authorised agency using the ASN.1 module of - Mailing lists (including changes), TS 102 232-2. - Messaging (such as messaging service settings) - Forwarding (automatic email forwarding) When monitoring a mailbox, the following as well: - Email address (such as creation or deletion of an additional email address in the mailbox) Annex D Email format When using well-known ports and implementing the Do however provide them for IRI-Only measures. ‘IP packet’ email format, it is not necessary to report IRI parameters ‘client address’, ‘server address’, ‘client port’ or ‘server port’ additionally, as they can be derived from the IP or TCP header data. Annex F.3.2 Explanatory notes on the ASN.1 descriptions The ASN.1 descriptions of the different modules for implementation under this Annex F.3 must come from the different versions of ETSI Specifications TS 102 232-1 and TS 102 232-2, with removal of any ASN.1 module errors (e.g. incorrect domainID) during implementation. Parameters designated as ‘conditional’ or ‘optional’ in the specifications must be transmitted if available and if the specifications and Annex F.3 do not indicate otherwise. For the ASN.1 types of OCTET STRING format that they contain, the following rules apply:  If the standard defines a format for the parameters in question, such as ASCII or cross-reference to a (signalling or other) standard, use this.  If it does not indicate the format, enter both hexadecimal values in the relevant bytes so the higher-value half byte is in bits 5 to 8 and the lower-value half byte is in bits 1 to 4. (Examples: insert 4F H as 4F H = 0100 1111, not as F4 H; or for instance DDMMYYhmm = 23.07.2002 10:35 h as ‘2307021035’ H, not ‘3270200153’H.) Transmit administrative events (e.g. activation/deactivation/modification of a measure and error messages) as well as additional events (e.g. for proprietary services) as per Annex A.3. TR TKÜV, edition 8.1 (draft) Part A, Annex G, page 56 Annex G. Internet gateway (ETSI TS 102 232-3 and ETSI TS 102 232-4) This Annex sets out the conditions for the handover interface as per ETSI Specifications TS 102 232-03 [31] and TS 102 232-4 [32] for transmission routes (e.g. xDSL, CATV, WLAN) for direct user-specific access to the Internet. These ETSI specifications use the general IP-based handover interface as described in ETSI Specification TS 102 232-1 [29]. This Annex covers the decisions on the options in the specifications, as well as additional technical requirements. In addition to the Internet access service, if radio broadcasting services or similar services intended for the public (e.g. IPTV, video on demand) are implemented over platforms operated by the operator of the Internet gateway or entry points via this Internet gateway that do not require arrangements as per § 3(2)(first sentence)(4) TKÜV, then wherever possible, do not include these parts of the telecommunication in the surveillance copy of the Internet access. On the other hand, in the case of individualised distribution services that are not offered to the public (e.g. distribution of self-created content to closed user groups), these parts of the telecommunication do not fall under the exemption in § 3(2)(first sentence)(4) TKÜV and must be included in the surveillance. § 7(1)(first sentence)(9) TKÜV requires reporting of the public IP addresses of the participating users that are known to the telecommunications system of the obligated party. In addition to the requirements in Part A, Sections 3 and 4, the following Annexes apply: Annex Contents Annex A.2 Participation in the VPN and an alternative procedure based on HTTPS/TLS Annex A.3 Transmission of HI1 IRI and additional events Annex A.4 Failed transmission of the surveillance copy to the lines of the authorised agency This text also references the following Annexes to Part X of the TR TKÜV: Annex X.1 Proposed changes to the TR TKÜV Annex X.2 Assignment of an identification feature for authorised agencies to guarantee unique reference numbers Annex X.3 Registration and certification authority of the Federal Network Agency (TKÜV CA), Unit IS16 (Policy) Annex X.4 Concept template for preparation of the documentary evidence, test protocols and test reports TR TKÜV, edition 8.1 (draft) Part A, Annex G, page 57 Annex G.1 Selected options and additional technical requirements Annex G.1.1 Basis: ETSI TS 102 232-1 The table below describes the options selected for the different chapters and sections of ETSI Specification TS 102 232-1, as well as the additional requirements. Unless indicated otherwise, the references in the table are for the sections of the ETSI specification. Section of Description of the option or issue, Additional requirement, background or additional TS 102 232-1 specifications for national application information 5.2.1 Version The use of an OID in the ASN.1 description precludes the need for a separate parameter. 5.2.3 Authorisation country code In Germany, use ‘DE’. 5.2.4 Communication identifier In Germany, use the delivery country code ‘DE’. The communication identity number identifies the IRI The Federal Network Agency assigns the operator and CC of a communication process, corresponding to identifier as per Annex A.1. This always begins with the correlation number as per the second sentence of ‘49...’. § 7(2) TKÜV. The network operator assigns the network element identifier. This identifies the network element that collects the telecommunication. 5.2.5 Sequence number The sequence number must be created when the In exceptional cases where this condition cannot be surveillance copy is first generated (interception met, ensure that this function is set up in the Delivery point). Function at the latest. However, sequence numbers only created here must match the exact counting method at the place of origin. If UDP is used on this path, take additional measures to prevent potential package loss and secure the sequence. 5.2.6 Payload timestamp In general, give all times (TimeStamp) in the official From the TR TKÜV edition 7.0 and later, it is only (local) time as a permitted to use the MicroSecondTimeStamp. MicroSecondTimeStamp (with maximum resolution If the timestamp is not available in and accuracy). MicroSecondTimeStamp format at the interception point, generate the timestamp in this format as closely In principle, the MicroSecondTimeStamp must be as possible to the interception point of the surveillance created when the surveillance copy is first copy. generated (interception point). . 5.2.7 Payload direction Clearly indicate the flow of the CC using to target or from target. 5.2.11, 5.2.13 Interception Point Identifier and Extended Interception Point Identifier The network operator assigns the Interception In general, use the Interception Point Identifier. If the Point Identifier or Extended Interception Point identifier is longer than 8 characters, use the Extended Identifier. This identifies the logical point (inside a Interception Point Identifier. network element) where the data (IRI and/or CC) are collected in the network. 6.2.2 Error reporting The transmission is in accordance with Annex A.4 to the TR TKÜV. 6.2.3 Aggregation of payloads Use combined transmission of monitored IP However, this should not take more than a few packets, to avoid unnecessary overhead. seconds, and it requires coordination with the Federal Network Agency. TR TKÜV, edition 8.1 (draft) Part A, Annex G, page 58 Section of Description of the option or issue, Additional requirement, background or additional TS 102 232-1 specifications for national application information 6.2.5 Padding data As an option, the obligated party may implement The relevant authorised agency must approve of the this. use of padding. 6.3.1 General Use TCP/IP. 6.3.2 Opening and closing of connections In principle, Part A, Section 3.1 TR TKÜV applies. This states that the Delivery Function must terminate to avoid unnecessary occupation of the lines of the authorised agency. 6.3.4 Keep-alives The requirements in Part A, point 3.3.3 apply for In principle, after successful data transmission, a timer the obligatory use of keep-alives. must terminate the TCP connection. The relevant authorised agency must agree to the use of keep- alives, in which the TCP connection is maintained at all times. 6.4.2 TCP settings For transmission, set port number 50100 for the The port number applies when using service authorised agency (destination port). specifications TS 102 232-2, TS 102 232-3, TS 102 232-4, TS 102 232-5 and TS 102 232-6. 7.1 Type of networks Transmit the payload over the public Internet. 7.2 Security requirements The requirements in Annex A.2 to the TR TKÜV It is not permitted to use TLS, signatures and hash apply. codes. 7.3.2 Timeliness Any use of separate managed networks requires coordination between the obligated party and the authorised agencies. Annex G.1.2 Basis: ETSI TS 102 232-3 The table below describes the options selected for the different chapters and sections of ETSI Specification TS 102 232-3, as well as the additional requirements. Unless indicated otherwise, the references in the table are for the sections of the ETSI specification. Section of Description of the option or issue, Additional requirement, background or additional TS 102 232-3 specifications for national application information 4.3.1 Target Identity In principle, the requirements in Part A, Section 4 For instance, surveillance implementations based on a TR TKÜV apply. Any deviating technical cable modem identifier are permitted, but must take implementations must behave accordingly. into account possible connection of another cable modem to the Internet gateway under surveillance, or possible connection of the ‘monitored’ cable modem to another Internet gateway. 4.3.2 Result of interception, Timestamps In general, give all times (TimeStamp) in the official The GeneralisedTime parameter is encoded as (local) time. universal time and does not use a time difference. 6.1 Events Implement the events as per Table 1. TR TKÜV, edition 8.1 (draft) Part A, Annex G, page 59 Section of Description of the option or issue, Additional requirement, background or additional TS 102 232-3 specifications for national application information 6.2.1 Use of targetIPAddress, additionalIPAddress Use parameters ‘targetIPAddress’ and When using NAT, this requirement is suspended until ‘additionaIPAddress’ to report the public IP further specification in a future edition of the TR TKÜV. addresses of the LuS known to the network of the obligated party, as per § 7(1)(first sentence)(9) TKÜV. 6.2.2 Use of location field Use parameter ‘location’ to report information on the location of the terminal as per § 7(1)(first sentence)(7) TKÜV, provided that the use is not location-specific. 8 ASN.1 for IRI and CC For these cases under § 7(3) TKÜV, it is not For these cases, in addition to the administrative data necessary to implement the included ASN.1 (e.g. LIID), it is only required to transmit the ASN.1 description for ‘IRIOnly’. data from ‘IPIRIContents’. This is in accordance with the requirement to transmit everything except the CC part for these kinds of orders. Annex G.1.3 Basis: ETSI TS 102 232-4 The table below describes the options selected for the different chapters and sections of ETSI Specification TS 102 232-4, as well as the additional requirements. Unless indicated otherwise, the references in the table are for the sections of the ETSI specification. Section of Description of the option or issue, Additional requirement, background or additional TS 102 232-4 specifications for national application information 4.2.1 Target Identity In principle, the requirements in Part A, Section 4 For instance, surveillance implementations based on a TR TKÜV apply. Any deviating technical modem MAC address are permitted, but must take into implementations must behave accordingly. account possible connection of another modem to the Internet gateway under surveillance, or possible connection of the ‘monitored’ modem to another Internet gateway. 4.3.2 Result of interception In general, give all times (TimeStamp) in the official The GeneralisedTime parameter is encoded as (local) time. universal time and does not use a time difference. 6.1 Events Implement the events as per Table 1. 8.1 ASN.1 specification For cases under § 7(3) TKÜV, it is permitted to For these cases, only the opening and closing of a implement the included ASN.1 description for Layer2 tunnel is known. ‘IRIOnly’ instead of the description of ASN.1 parameter ‘ L2IRIContents’. Addendum 1 Use parameter ‘location’ in ASN.1 module ‘LI-PS- PDU’ to report information on the location of the terminal as per § 7(1)(first sentence)(7) TKÜV, provided that the use is not location-specific. Addendum 2 Coordinate with the Federal Network Agency on When using NAT, this requirement is suspended until reporting the public IP addresses of the LuS known further specification in a future edition of the TR TKÜV. to the network of the obligated party as per § 7(1)(first sentence)(9) TKÜV. TR TKÜV, edition 8.1 (draft) Part A, Annex G, page 60 Annex G.2 Explanatory notes on ASN.1 descriptions The ASN.1 descriptions of the different modules for implementations as per this Annex G are available in the different versions of ETSI Specifications TS 102 232-1, TS 102 232-3 and TS 102 232-4. Parameters designated as ‘conditional’ or ‘optional’ in the specifications must be transmitted if available and if the specifications and Annex G.1 do not indicate otherwise. For the ASN.1 types of OCTET STRING format that they contain, the following rules apply:  If the standard defines a format for the parameters in question, such as ASCII or cross-reference to a (signalling or other) standard, use this.  If it does not indicate the format, enter both hexadecimal values in the relevant bytes so the higher-value half byte is in bits 5 to 8 and the lower-value half byte is in bits 1 to 4. (Examples: insert 4F H as 4F H = 0100 1111, not as F4 H; or for instance DDMMYYhmm = 23.07.2002 10:35 h as ‘2307021035’ H, not ‘3270200153’H.) Transmit administrative events (e.g. activation/deactivation/modification of a measure and error messages) as well as additional events (e.g. for proprietary services) as per Annex A.3. TR TKÜV, edition 8.1 (draft) Part A, Annex I, page 61 Annex H. Specifications for VoIP, other multimedia services in fixed networks and fixed-line IMS platforms (ETSI TS 102 232-5 und ETSI TS 102 232-6) This Annex sets out the conditions on the handover interface as per ETSI Specification TS 102 232-5 [34] for IP multimedia services and ETSI Specification TS 102 232-6 [35] for emulated PSTN/ISDN services. This ETSI specification uses the general IP-based handover interface described in ETSI Specification TS 102 232-1 [29]. In cases of shared use of an IMS platform or use of identical IMS platforms for mobile and landline telecommunications, coordinate with the Federal Network Agency on the use of an interface as per Annex D. The conditions for the application of these ETSI specifications for mobile networks and mobile-based IMS platforms are based on Annex D. This Annex covers the decisions on the options in the specifications, as well as additional technical requirements. In addition to the requirements in Part A, Sections 3 and 4, the following Annexes apply: Annex Contents Annex A.2 Specifications for participation in the VPN and an alternative procedure based on HTTPS/TLS Annex A.3 Transmission of HI1 IRI and additional events Annex A.4 Failed transmission of the surveillance copy to the lines of the authorised agency This text also references the following Annexes to Part X of the TR TKÜV: Annex X.1 Proposed changes to the TR TKÜV Annex X.2 Assignment of an identification feature for authorised agencies to guarantee unique reference numbers Annex X.3 Registration and certification authority of the Federal Network Agency (TKÜV CA), Unit IS16 (Policy) Annex X.4 Concept template for preparation of the documentary evidence, test protocols and test reports TR TKÜV, edition 8.1 (draft) Part A, Annex I, page 62 Annex H.1 Basic requirements on the application of service-specific details for IP multimedia services (ETSI TS 102 232-5) ETSI Specification TS 102 232-5 describes a handover interface for VoIP and other multimedia services based on Session Initiation Protocol (SIP), ITU-T Standards H.323 and H.248, as well as Real-time Transport Protocol (RTP) and Real-time Transport Control Protocol (RTCP). Annex H.1.1 Definitions Multimedia server Telecommunications systems involved in the provision of the VoIP service or (VoIP server) and any other multimedia service based on SIP, H.323 or H.248 in combination participating network with the media stream (e.g. RTP) elements VoIP identifier The VoIP identifier designates the telecommunication under surveillance. This term is used as a general designation for the various types of possible identifiers. VoIP account An account set up for collective management of multiple VoIP identifiers for the user. In certain cases, a VoIP account under surveillance may contain multiple VoIP identifiers. Login Process that verifies that the user has access permission for the VoIP account. Login name The login name used during login as part of the access ID is also an identifier used to denote the telecommunication under surveillance. Annex H.1.2 Basic information As a technical attribute, a telecommunications surveillance order may contain:  a VoIP identifier; or  the access ID (login name without password) of a VoIP account. To monitor the complete telecommunication under the VoIP identifier, it is necessary to ensure that the monitored telecommunication can actually be correlated to the LuS using suitable authentication methods. This should prevent situations such as failure to collect a VoIP communication under surveillance merely because the user has tampered with sender address. If this requirement cannot be met (such as due to an unsuitable authentication method), it is necessary instead to carry out an order related to a VoIP identifier by monitoring the entire VoIP account, with collection of the telecommunications of all VoIP identifiers of this account. If a telecommunications link already exists on activation of an interception measure, it is necessary to collect the CC and the IRI from this time onwards and provide copies of them (see Annex H.3.2, point 5.3). § 7(1)(first sentence)( 9 and 10) TKÜV requires reporting of the public IP addresses of the participating user that are known to the telecommunications system of the obligated party, as well as the known encoding used to transmit the telecommunication under surveillance. Annex H.1.3 Provision of CC in cases of separate transmission of signalling In principle, it is necessary to provide the IRI generated based on the signalling and the CC at the handover point. According to ETSI Specification TS 102 232-5, the CC consists of all the RTP and RTCP packets as well as any other protocols that transport the media stream (e.g. gateway protocols). With VoIP in particular however, the CC is sometimes transmitted separately from the signalling by other operators. The following options are available for CC provision: 1. The VoIP provider itself operates network elements to transmit the CC. These network elements may be: a) the Internet gateway, regardless of whether this is based on its own or a leased local loop (however, this does not include complete resale products such as DTAG Resale DSL); b) the hub that contains the connection point to the Internet, c) the transport or connection network for CC; or TR TKÜV, edition 8.1 (draft) Part A, Annex I, page 63 d) the handover interface to/from PSTN (e.g. media gateway). This Annex H sets out the further requirements for this. 2. The VoIP provider uses a specific network element operator as described in point 1 to transmit the CC. For this, in addition to the requirements of Annex H, an implementation option is available as per § 170(1)(2) TKG. The obligated VoIP provider is however responsible for implementing the associated collaboration. For separate provision of CC and IRI, § 7(2) TKÜV requires the marking of these parts with a single reference number as well as a correlation number. In cases of CC surveillance using special routing, such as to a central hub, it is critical to ensure that the VoIP user participating in the telecommunication cannot detect this, as per § 5(4) TKÜV. Annex H.1 Requirements on the application of service-specific details for PSTN/ISDN services (ETSI TS 102 232-6) For emulated PSTN and ISDN services, ETSI Specification TS 102 232-6 provides the option to use a purely IP-based handover interface. This involves transmission of the copy of the telecommunication as an RTP/RTCP data stream through the general IP-based handover interface as per TS 102 232-1. In addition, the IRI encoded using module HI2Operatons is also transmitted with the TS 102 232-1. Annex H.3 Selected options and additional technical requirements Annex H.3.1 Basis: ETSI TS 102 232-1 The table below describes the options selected for the different chapters and sections of ETSI Specification TS 102 232-1, as well as the additional requirements. Unless indicated otherwise, the references in the table are for the sections of the ETSI specification. Section of Description of the option or issue and Additional requirement, background or additional TS 102 232-1 specifications for national application information 5.2.1 Version The use of an OID in the ASN.1 description precludes the need for a separate parameter. 5.2.3 Authorisation country code In Germany, use ‘DE’. 5.2.4 Communication identifier In Germany, use the delivery country code ‘DE’. The communication identity number identifies the IRI and CC of a communication process, corresponding to The Federal Network Agency assigns the operator the correlation number as per the second sentence of identifier as per Annex A.1. This always begins with § 7(2) TKÜV. ‘49...’. The network operator assigns the network element identifier. This identifies the network element that collects the telecommunication. 5.2.5 Sequence number The sequence number must be created when the In exceptional cases where this condition cannot be surveillance copy is first generated (interception met, ensure that this function is set up in the Delivery point). Function at the latest. However, sequence numbers only created here must match the exact counting method at the place of origin. If UDP is used on this path, take additional measures to prevent potential package loss and secure the sequence. TR TKÜV, edition 8.1 (draft) Part A, Annex I, page 64 Section of Description of the option or issue and Additional requirement, background or additional TS 102 232-1 specifications for national application information 5.2.6 Payload timestamp From the TR TKÜV edition 7.0 and later, it is only permitted to use the MicroSecondTimeStamp. In general, give all times (TimeStamp) in the official (local) time as a If the timestamp is not available in MicroSecondTimeStamp (with maximum resolution MicroSecondTimeStamp format at the interception and accuracy). point, generate the timestamp in this format as closely as possible to the interception point of the surveillance In principle, the MicroSecondTimeStamp must be copy. created when the surveillance copy is first generated (interception point). 5.2.7 Payload direction Clearly indicate the flow of the CC using to target or from target. Encoding information As a general rule, various optional audio data In principle, for simple transmission of IRI, report the encodings are available to the terminal. According codec used (if known to the network) as IRI. If the IRI to § 7(1) TKÜV, the transmitted IRI must include is collected at different points in the network, the codec actually used for audio data transmission sometimes resulting in transmission of different codecs and known to the network. (e.g. codec change in the network), the Interception (The TR TKÜV includes a reference to the existing Point Identifier should help merge the relevant IRI legal situation due to the use of different codecs record with the intercepted CC (audio data) (see point that may be unknown to the analysis system.) 5.2.11). 5.2.11, 5.2.13 Interception Point Identifier and Extended Interception Point Identifier In general, use the Interception Point Identifier. If the The network operator assigns the Interception identifier is longer than 8 characters, use the Extended Point Identifier or Extended Interception Point Interception Point Identifier. Identifier. This identifies the logical point (inside a The Interception Point Identifier and the Extended network element) where the data (IRI and/or CC) Interception Point Identifier should help better identify are collected in the network. the associated IRI in cases of multiple IRI transmissions (e.g. through different interception points) and if possible, combine the codec described using the IRI record with the intercepted CC (audio data). Implement this requirement as follows if reporting multiple codecs in the IRI: If the audio data codec is changed within the network, provide the CC data to be transmitted with the same Interception Point Identifier as the associated IRI record containing the correct codec. If the correlation described above is not possible, coordinate with the Federal Network Agency on alternative methods. 6.2.2 Error reporting Transmission is based on Annex A.4 to the TR TKÜV. 6.2.3 Aggregation of payloads Use combined transmission of monitored IP However, this should not take more than a few packets, to avoid unnecessary overhead. seconds, and it requires coordination with the Federal Network Agency. 6.2.5 Padding data As an option, the obligated party may implement The relevant authorised agency must approve of the this. use of padding. 6.3.1 General Use TCP/IP. TR TKÜV, edition 8.1 (draft) Part A, Annex I, page 65 Section of Description of the option or issue and Additional requirement, background or additional TS 102 232-1 specifications for national application information 6.3.2 Opening and closing of connections In principle, Part A, Section 3.1 TR TKÜV applies. This states that the Delivery Function must terminate to avoid unnecessary occupation of the lines of the authorised agency. 6.3.4 Keep-alives As an option, the obligated party may implement In principle, after successful data transmission, a timer this. must terminate the TCP connection. The relevant authorised agency must agree to the use of keep- alives, in which the TCP connection is maintained at all times. The requirements in Part A, point 3.3 apply for the obligatory use of keep-alives. 6.4.2 TCP settings For transmission, set port number 50100 for the The port number applies when using Specifications TS authorised agency (destination port). 102 232-2, TS 102 232-3, TS 102 232-4, TS 102 232-5 and TS 102 232-6. 7.1 Type of networks Transmit the payload over the public Internet. 7.2 Security requirements The requirements in Annex A.2 to the TR TKÜV apply. 7.3.2 Timeliness Any use of separate managed networks requires coordination between the obligated party and the authorised agencies. Annex H.3.2 Basis: ETSI TS 102 232-5 The table below describes the options selected for the different chapters and sections of ETSI Specification TS 102 232-5, as well as the additional requirements. Unless indicated otherwise, the references in the table are for the sections of the ETSI specification. Section of Description of the option or issue, Additional requirement, background or additional TS 102 232-5 specifications for national application information 4.3 General requirements In principle, transmit the copies of the signalling The concept must use examples to explain the information (e.g. SIP messages) as IRI. parameters and combinations of messages that characterise the various individual services (e.g. basic call, call forwarding). Where known, it is also necessary to explain individual services that the user terminals (clients) can control, with regard to altered behaviour in signalling or in the RTP streams (such as simultaneous RTP sessions in conferences); provide updates for any subsequent expansions. IRI that is not part of the signalling must also be Use module HI2Operations from TS 101 671 to transmitted separately. transmit all IRI, with a separate parameter for the SIP messages; transmit the module according to the requirements of TS 102 232-6. A general mapping, such as according to ANSI T1.678, is not planned. TR TKÜV, edition 8.1 (draft) Part A, Annex I, page 66 Section of Description of the option or issue, Additional requirement, background or additional TS 102 232-5 specifications for national application information 5.2.2 Provisioning of the H.323 IRI IIF For each specific case, discuss the exact signalling messages of the different protocols in the H.323 family to be transmitted as IRI with the Federal Network Agency. 5.2.3 Location information Use parameter ‘targetLocation’ to report information on the location of the terminal as per § 7(1)(first sentence)(7) TKÜV, provided that the use is not location-specific. 5.3 Assigning a value to the CIN The CIN is normally assigned at the start of a new Mark the first signalling information (e.g. INVITE) as session with the first signalling information (CC or IRI-BEGIN, and all further signalling information (e.g. IRI). INVITE from the SIP server for partner identifier) as IRI-CONTINUE. Mark the last (expected) signalling If a session already exists on activation of the information as IRI-END. interception measures, generate the CIN with the first IRI or CC message. If a telecommunications link with the monitored identifier already exists on activation of an interception measure, it is necessary to collect the CC and the IRI from this time onwards and provide copies of them. 5.3., 5.3.1 Assigning a CIN value to SIP-related IRI The description assumes use of the Call ID and the The requirement to generate a single CIN for the ‘O’ field of the SDP to generate a single CIN individual communication sessions applies regardless (correlation number) for the overall call. of whether the described parameters can be used. For processing different media streams within the same session, use the stream identifier as per Section 5.5. 5.4 Events and IRI record types The various call-specific IRI is reported as IRI- The option to send all IRI as REPORT is not permitted. BEGIN, IRI-CONTINUE and IRI-END; report a In certain exceptional cases, after coordination with the subsequent event (after an IRI-END) as IRI- Federal Network Agency, it is permitted to report some REPORT, as described. data from an existing session as REPORT. (This may be a call forwarding scenario, for instance, with the session first reported as BEGIN/CONTINUE/END and after forwarding as REPORT.) For each event, it is only permitted to mark one session as IRI-BEGIN or IRI-END. In other words, mark the first signalling information (e.g. INVITE) as IRI-BEGIN, and all further signalling information (e.g. INVITE from the SIP server for partner identifier) as IRI-CONTINUE. Mark the last (expected) signalling information as IRI-END. 5.5 Interception of Content of Communication If the obligated party uses encryption on the If the obligated party supports encryption of peer-to- network side or collaborates in key generation or peer-communications over the Internet by providing exchange, and can therefore decrypt the key management, without involving its network telecommunication, remove the decryption at the elements or those of its partners in CC transmission, it handover interface (§ 8(3) TKÜV). This applies in must at least provide the authorised agency with the the cases as per H.1.4, which require provision of key previously exchanged with its telecommunication the CC. system. Coordinate with the Federal Network Agency on the required procedure. Transmission of the exchanged key is not required if the obligated party can still remove the encryption on the network side using additional network elements. Use parameter streamIdentifier for multiple media streams within a session. TR TKÜV, edition 8.1 (draft) Part A, Annex I, page 67 Section of Description of the option or issue, Additional requirement, background or additional TS 102 232-5 specifications for national application information 7 ASN.1 specification for IRI and CC Use parameters ‘iPSourceAddress’ and Reporting internal IP addresses of the network, such ‘iPDestinationAddress’ to transmit the public IP as if the public IP addresses of the communication addresses of the participating user that are known partners are present at the network boundaries, but not to the network of the obligated party, as per § directly on the VoIP server, does not meet the 7(1)(first sentence)(9) TKÜV. regulation. Paragraph As an alternative to using the ASN.1 parameters, it is permitted to report the public IP addresses within the SIP messages. If using this alternative, the document as per § 19 TKÜV (concept) must describe this, indicating the SIP message or SIP parameter used. Annex H.3.3 is removed. Annex H.3.4 Basis: ETSI TS 102 232-6 The table below describes the options selected for the different chapters and sections of ETSI Specification TS 102 232-6, as well as the additional requirements. Unless indicated otherwise, the references in the table are for the sections of the ETSI specification. Section of Description of the option or issue, Additional requirement, background or additional TS 102 232-6 specifications for national application information 5.2 Structures  Encode the IRI with module HI2Operations and transmit it directly with TS 101 232-1 using parameter ETSI671IRI.  Transmit the copy of the CC (RTP packets with UDP and IP headers) using TS 102 232-6 parameter pstnIsdnCCContents as TS 102 232-1 CCContents of type pstnIsdnCC.  Also transmit the information needed to interpret the RTP packets using TS 102 232-6 parameter PstnIsdnIRIContents as TS 102 232-1 IRIContents of type pstnIsdnIRI. 6.2 CC format If the obligated party uses encryption on the If the obligated party supports encryption of peer-to- network side or collaborates in key generation or peer-communications over the Internet by providing exchange, and can therefore decrypt the key management, without involving its network telecommunication, remove the decryption at the elements or those of its partners in CC transmission, it handover interface (§ 8(3) TKÜV). This applies in must at least provide the authorised agency with the the cases as per H.1.4, which require provision of key previously exchanged with its telecommunication the CC. system. Coordinate with the Federal Network Agency on the required procedure. Transmission of the exchanged key is not required if the obligated party can still remove the encryption on the network side using additional network elements. 6.2, 6.3.2 Supplementary information G.711 should be used as the default (mediaAttributes = ‘1’). A copy of the entire SDP message should always Transmission of the entire SDP message provides the be sent in field copyOfSDPMessage (mandatory); authorised agency with a complete copy of the the optional individual fields sessionName and telecommunication; it also prevents potential errors by sessionInfo are not required (optional). the obligated party when copying over the individual parameters. Addendum 1 ASN.1 specification for IRI and CC When using this interface, report the public IP For this, use parameter ‘Other-Services’ from ASN.1 addresses of the participating user that are known module ‘HI2Operations’ of ETSI TS 101 671. For other to the network of the obligated party, as per § options, coordinate with the Federal Network Agency. 7(1)(first sentence)(9) TKÜV. TR TKÜV, edition 8.1 (draft) Part A, Annex I, page 68 Annex H.4 Explanatory notes on ASN.1 descriptions The ASN.1 descriptions of the different modules for implementations as per this Annex H are available in the different versions of ETSI Specifications TS 102 232-1, TS 102 232-5 and TS 102 232-6. Parameters designated as ‘conditional’ or ‘optional’ in the specifications must be transmitted if available and if the specifications or Annex H.2 do not indicate otherwise. For the ASN.1 types of OCTET STRING format that they contain, the following rules apply:  If the standard defines a format for the parameters in question, such as ASCII or cross-reference to a (signalling or other) standard, use this.  If it does not indicate the format, enter both hexadecimal values in the relevant bytes so the higher-value half byte is in bits 5 to 8 and the lower-value half byte is in bits 1 to 4. (Examples: insert 4F H as 4F H = 0100 1111, not as F4 H; or for instance DDMMYYhmm = 23.07.2002 10:35 h as ‘2307021035’ H, not ‘3270200153’H.) Transmit administrative events (e.g. activation/deactivation/modification of a measure and error messages) as well as additional events (e.g. for proprietary services) as per Annex A.3. TR TKÜV, edition 8.1 (draft) Part A, Annex I, page 69 Annex I. Number-independent interpersonal telecommunications services other than email services (ETSI TS 103 707 and ETSI TS 102 232-2) For messaging services and other number-independent interpersonal telecommunications services provided based on proprietary and non-uniform protocols and for which a separately developed surveillance technology will regularly also be used to meet the legal requirements of another European country, the interfaces described here must have been set up by 1 December 2023. Annex F gives the requirements on email services. This Annex sets out the conditions for the XML/HTTP-based handover interface as per ETSI Specification TS 103 707 [39] and for the ASN.1/TCP-based handover interface as per ETSI Specification TS 102 232- 2 [30]. ETSI Specification TS 103 707 [39] uses the IP-based transmission procedure described in ETSI Specification TS 103 120 [38]. Transmission of the telecommunications surveillance order and related messages, such as specific activation of a measure, must also be in accordance with Part B of this edition, not the procedure described in ETSI Specification TS 103 120. In addition, it is possible to use the ASN.1/TCP-based handover interface as per ETSI Specification TS 102 232-2 [30] in cases where the provisions of this specification and Annex F suffice to meet the requirements of the TKÜV. This ETSI specification uses the general IP-based handover interface described in ETSI Specification TS 102 232-1 [29]. When using the two methods, it may be necessary to provide the handover interface as per ETSI Specification TS 102 232-5 in accordance with Annex H as well. Annex A.2 gives the specifications on protection of the IP-based handover interface. The use of ETSI Specifications TS 103 707 [39] and TS 103 120 [38] is subject to consultation with the Federal Network Agency until further notice. The use of ETSI Specification TS 102 232-2 [30] is subject to the requirements in Annex F.3. In addition to the requirements in Part A, Sections 3 and 4, the following Annexes apply: Annex Contents Annex A.2 Specifications for participation in the VPN and an alternative procedure based on HTTPS/TLS Annex A.3 Transmission of HI1 IRI and additional events Annex A.4 Failed transmission of the surveillance copy to the lines of the authorised agency This text also references the following Annexes to Part X of the TR TKÜV: Annex X.1 Proposed changes to the TR TKÜV Annex X.2 Assignment of an identification feature for authorised agencies to guarantee unique reference numbers Annex X.3 Registration and certification authority of the Federal Network Agency (TKÜV CA), Unit IS16 (Policy) Annex X.4 Concept template for preparation of the documentary evidence, test protocols and test reports TR TKÜV, edition 8.1 (draft) Part B, page 70 Part B. Technical implementation of legal measures for information provision 1. Basic principles This Part B of TR TKÜV describes the following based on § 170(6) TKG [21] in conjunction with §§ 9 and 12 TTDSG [41] and §§ 174(7) and 177(3) TKG: 1. The required technical details for requests for information from the authorised agencies and the provision of information on subscriber and traffic data as well as secure electronic transmission of orders from the authorised agencies by the obligated telecommunications undertakings 2. The technical characteristics of the required sending and receiving equipment of the obligated parties and of the authorised agencies 3. The requirements to ensure a particularly high standard of data security and quality as per § 180(1) TKG when transmitting traffic data that require storage as per the first sentence of § 177(3) TKG. For messaging services and other number-independent interpersonal telecommunications services provided based on proprietary and non-uniform protocols and for which a separately developed retrieval technology will regularly also be used to meet the legal requirements of another European country, the interfaces described here must have been set up by 1 December 2023. Furthermore, this Part B of the TR TKÜV describes further optional applications for the interface, to boost the effectiveness of the overall procedure. This part also gives the technical details for secure electronic transmission of orders for traffic data retrieval and telecommunications surveillance as per § 12(2) TKÜV as well as for other uses. The transmission procedures described in this Part B of the TR TKÜV must or can (‘optional’ indication) be used for the following purposes: a. Subscriber data retrieval b. Traffic data retrieval c. Real-time transmission of the order to retrieve traffic data d. Radio cell structure retrieval1 (optional) e. Location retrieval f. Transmission of the telecommunications surveillance order (optional) g. Transmission of invoice reconciliation data in advance of compensation as per Annex 3 to § 23(1) of the Judicial Remuneration and Compensation Act [JVEG] (optional) In the interest of readability, this TR TKÜV uses the term ‘retrieval’ synonymously for the request to provide information (request), transmission of the order (warrant) and for the provision of information (response). 2. Transmission procedures ETSI-ESB and Email-ESB Use the transmission procedures described in Annexes A and B below as follows:  The ETSI-ESB transmission procedure, i.e. the interface as per the second sentence of § 174(7) TKG (Annex A), must be available to provide information on subscriber and traffic data as well as to receive corresponding orders for obligated parties with 100 000 or more contractual partners.  § 174(7) TKG states that all obligated parties must provide email-based transmission procedure Email-ESB (Annex B) to retrieve subscriber data, and Part 4 of the TKÜV states that obligated 1 For the purposes of this Guideline, a ‘radio cell’ is the area covered by a mobile aerial element that has been assigned its own cell identifier. TR TKÜV, edition 8.1 (draft) Part B, page 71 parties with less than 100 000 contractual partners must provide it to receive information requests and retrieve traffic data. For traffic data retrieval, as an alternative, obligated parties with less than 100 000 contractual partners may use the ETSI-ESB transmission procedure. Here, mixed operation for different applications may be permitted (e.g. ETSI-ESB for traffic data information including transmission of the corresponding order, and Email-ESB for information on subscriber data), in consultation with the Federal Network Agency. These transmission procedures may be used for the other purposes referred to in Section 1. Other transmission procedures and local handover are not possible if the systems are also provided for traffic data retrieval as per § 176 TKG. Non-secure transmission procedures, such as unencrypted transmission by email or sending of unencrypted data carriers by post, are also prohibited outside of use of the systems provided for traffic data retrieval as per § 176 TKG. According to § 1(1)(7) TKÜV, these requirements apply accordingly to the recording equipment of the authorised agencies, even when also using centralised input interfaces. In addition, it is not permitted to operate Email-ESB outside of authorised agencies, outside the premises of the obligated parties or outside the premises of their vicarious agents. Convert orders and information requests into multi-page TIFF format (ITU-T Fax Group 4) or PDF format for transmission. The maximum file size is 5 MB. If a follow-up order does not contain all the necessary data (e.g. legal basis, identifier, timeframe), transmit it in a file along with the original order. It is no longer necessary to send the original or a certified copy of the order subsequently by post when using the ETSI-ESB or Email-ESB transmission procedures. 3 Assurance of data security and data quality 3.1 Safeguards and technical details for order data storage The following requirements are based on § 170(6) and the fourth sentence of § 174(7) TKG and § 31(1) in conjunction with § 14(1 and 3) TKÜV, which state that the Federal Network Agency may set requirements in this TR TKÜV for the protection objectives defined in these individual regulations. In principle, the various protection objectives require the general basic protection as defined in § 167 TKG in the security requirements catalogue. In addition, the provisions of § 14(1) TKÜV apply, which state that the obligated party must protect its technical and organisational arrangements for the implementation of measures and transmission to the receiving equipment of the authorised agency from unauthorised use in accordance with the state of the art. Transmissions to the authorised agency must be encrypted; the transmission procedure descriptions below give the procedures for this. The requirements in § 14(3) TKÜV also apply to the administration of network elements via public networks for telecommunications surveillance or for information retrieval, including storage of the necessary information in these network elements. Implementation of these requirements is subject to the relevant international standards and the BSI recommendations. 3.2 Special requirements on transmission of traffic data that must be stored as per § 176 TKG The first sentence of § 177(3) in conjunction with the first sentence of § 180(1)TKG requires assurance of a particularly high standard of data security and data quality when transmitting traffic data as per § 176 TKG. The Federal Network Agency, along with BSI and BfDI, has developed the requirements catalogue as per § 180 TKG. Compliance with this catalogue offers a presumption of compliance with the legal requirements in §§ 176 to 179 TKG. TR TKÜV, edition 8.1 (draft) Part B, page 72 The special requirements below apply to the transmission procedures used for this, provided they are used:  exclusively for provision of information on traffic data as per § 176 TKG; or  in addition to other forms of use permitted under Section 1 above, for the provision of information on traffic data as per § 176 TKG. The figure below from the requirements catalogue shows a possible implementation of the overall architecture: Netz des Verpflichteten Physisch zutrittgesicherte Umgebung für das Verkehrsdatenspeichersystem Datenquellen Ablage- Zugriffs Datenspeicher Abfragesystem system -system Firewall Firewall Schlüssel- Kontroll- und management Filtereinrichtung Rufnummern nach § 11 TTDSG Firewall Firewall ETSI-ESB Bestandsdaten- speicher, ... Wartungszugänge Berechtigte Stelle Figure: Sample implementation of the basic architecture (source: requirements catalogue as per § 180 TKG) Netz des Verpflichteten Network of the obligated party Physisch zutrittgesicherte Umgebung für das Physically secure environment for the Verkehrsdatenspeichersystem traffic data storage system Ablagesystem Storage system Datenspeicher Data storage Zugriffs-system Access system Abfragesystem Query system Kontroll- und Filte reinrichtung Control and filter setting Rufnummern nach § 11 TTDSG Call numbers under § 11 TTDSG Schlüssel-management Key management Wartungszugänge Maintenance access Bestandsdaten-speicher, ... Subscriber data memory, ... Berechtigte Stelle Authorised agency The requirements catalogue as per § 180 TKG sets the following requirements, in particular, on transmission as per § 177(3) TKG: 3.2.1 Assurance of a particularly high standard of data security All components of the ETSI-ESB and Email-ESB transmission procedures, from the query system to the handover interface where the authorised agency receives the encrypted transmission (dedicated Internet connection), must meet the basic IT protection requirements of the BSI with security level ‘High’ (see Basic IT Protection Methodology, BSI Standard 200-2). TR TKÜV, edition 8.1 (draft) Part B, page 73 3.2.2 Use of particularly secure encryption methods, buffering in the transmission procedure components and deletion of traffic data in the query system During transmission, encrypt traffic data using a suitable procedure. The descriptions of the two transmission methods below include requirements for this. It is not permitted to use encryption methods other than those indicated. For traffic data retrieval as per § 176 TKG, the requirements catalogue as per § 180 TKG provides for traffic data decryption in the access system. To transmit the query results through the query system as part of the transmission procedure, it is permitted to temporarily buffer these unencrypted in the RAM or encrypted in the persistent memory, with regular renewal of the keys used. If using the query system and the transmission procedure to provide further information as per Section 1 above, ensure that the connection to other systems required for this is secured with a firewall. The provisions on firewall configuration and the log files apply in accordance with Section 5.2.4 of the requirements catalogue as per § 180 TKG. Delete the plain data that arise when processing queries in the query system and in the transmission procedure (decrypted traffic data and other temporary data) from the RAM immediately after transmission. In addition, prevent non-secure swapping of sensitive data from the RAM. Moreover, the requirements as per Section 5.2.5 of the requirements catalogue as per § 180 TKG apply. 3.2.3 Application of the four-eyes principle for access to and transmission of traffic data Processing of information requests from authorised agencies by specially authorised employees of the obligated party requires controlled access over the query system under the four-eyes principle. The specially authorised persons must provide authentication to the query system with individual user IDs. The corresponding TKÜV logging requirements apply here. Depending on the transmission procedure used, the query system design must enable the two specially authorised persons to perform the following checks: a) ETSI-ESB transmission procedure When using ETSI-ESB, the authorised agency must transmit the order and relevant query parameters. In separate, independent steps, the two persons with special access authorisation check that the query parameters contained in a judicial order or public prosecutor’s order or in an official information request are in accordance with the query parameters provided for access. The query system must ensure that the check by the obligated party cannot alter the query parameters indicated by the authorised agency. Report any errors or points of uncertainty to the authorised agency in accordance with the section on error handling. In the event of an error on the part of the authorised agency, restart the process (solutions such as correction by the obligated party by phone are not permitted). b) Email-ESB transmission procedure When using Email-ESB, the authorised agency does not transmit any predefined query parameters other than the order and any further explanatory notes. In an initial step, the first of the two specially authorised persons must define the query parameters for access to the traffic data. The first person sets the query parameters in accordance with the judicial or public prosecutor’s order or the official information request in the query system. TR TKÜV, edition 8.1 (draft) Part B, page 74 In a separate, independent step, the second person checks that the query parameters contained in the judicial order or public prosecutor’s order or in the official information request are in accordance with the query parameters provided for access. If the check is passed, the second person initiates access to the traffic data as well as transmission of the query results to the authorised agency. If the check is not passed, the two persons must reconcile the query parameters again. If this does not produce a clear result, report this back to the authorised agency with indication of the identified discrepancy. In the event of an error on the part of the authorised agency, restart the process (solutions such as correction by the obligated party phoning the authorised agency are not permitted). 3.2.4 Physical security of the transmission procedure Physically protect the query systems and other equipment in the transmission procedure from access by persons without special authorisation. 3.3 Time until traffic data availability According to the third sentence of § 31(3) TKÜV, the design of the systems available to deliver traffic data from network elements of their own telecommunications network must ensure that the collected data are available for retrieval by the authorised agency within 24 hours of the event in question. Deviations from this are permitted in individual cases. The documentary evidence must indicate the expected timeframe between collection and availability for retrieval. TR TKÜV, edition 8.1 (draft) Part B, page 75 Annex A. ETSI-ESB transmission procedure 1. Basic information This Annex sets out the national requirements on the ETSI-ESB transmission procedure based on ETSI Specification TS 102 657. For messaging services and other number-independent interpersonal telecommunications services provided based on proprietary and non-uniform protocols, it is possible, as an alternative, to use the ETSI-ESB transmission procedure based on ETSI Specification TS 103 707 in conjunction with ETSI TS 103 120. To protect the IP-based handover interface as per the first sentence of § 14 (1) TKÜV when using ETSI- ESB, the provisions in Part A, Annex A.2 apply. The specifications below pertain to implementation of ETSI-ESB based on ETSI Specification TS 102 657. 1.1 Basic description of the procedure In principle, the method is based on the mechanisms described in ETSI Specification TS 102 657. Because this specification requires definition of further technical details at the national level and does not include pre-existing requirements in Germany (e.g. the order obligation), additional provisions are required that go beyond the options selected for the specification. The basic transmission mechanism requires one receiver and one sender at both the authorised agency and the obligated undertaking, who transmit an initial request message from the authorised agency to the undertaking, followed by the requested data in a separate response message. These processes are generally initiated by electronic transmission of the order in a warrant request, followed by one or more actual queries, contained in separate data requests. Because the ETSI specification does not distinguish between warrant requests and data requests, these terms refer to the uniform request described there. The section below sets out the procedure based on an information request and the associated provision of traffic data for different identifiers, including different timeframes: Authorised agency Undertaking Authorised agency Req Recipient Undert. Req (TIFF metadata) system Sender XML check TIFF order Req HTTP OK Metadata TIFF order Metadata Other data Recipient Response ReqAck Sender XML Scanner ReqAck check HTTP OK Or der SINA VPN 1. Administration of the request at the authorised agency includes entering all metadata needed for the warrant request and an electronic copy of the order. The metadata contain the information on the order for the various identifiers and timeframes for actual electronic processing. If the metadata pertain to multiple identifiers to be queried, provide them with a targetNumber as a sequential number. In addition, it is also permitted to administer other data that will not be sent (e.g. file number, retrieval frequency). Automatically mark the warrant request with an individual requestNumber (such as 4711). 2. After receipt of the warrant request and the automatic readability and completeness checks, perform the manual check and approval of the metadata falling within the scope of the order, for provision of the information by the person(s) specially authorised for this by the obligated party. TR TKÜV, edition 8.1 (draft) Part B, page 76 Approval is only permitted if the metadata are in accordance with the details of the surveillance order. Approval applies to the order in question for all identifiers it indicates, including the timeframes; this approval is identified by the requestNumber of the warrant request (here, 4711). Each specific traffic data query requires a separate data request: 1. Based on the settings in the authorised agency system, a separate data request is sent manually or automatically, containing the query for a specific identifier and a specific timeframe. This data request is identified in turn with its own requestNumber (e.g. 4922) and as a reference to the warrant request, contains its requestNumber as the referencedRequestNumber (here, 4711). In addition, the targetNumber is used to refer to the sequential number in the metadata of the warrant requests. 2. After receipt of the data request and the automatic readability and completeness check, perform the automatic check against the metadata and targetNumber stored by the approval operation. If the metadata cover the specifically requested identifier and timeframe, perform automatic retrieval. Transmit the data collected for the identifier underlying the query in a separate response message identified with the requestNumber of the data request (here, 4922). Transmit messages from the undertaking using the same procedure, but with the roles reversed. 1.2 Procedural requirements  Use of ETSI definitions and national addenda Provision of an electronic order and metadata in the warrant request and the subsequent data requests requires the use of a national XML definition, Natparas2, transmitted using the XML module of the ETSI Specification. Other uses (e.g. subscriber data, positioning) require transmission of the supplementary XML definition, Natparas3, for transmission of the response data by means of the response message.  Metadata not in accordance with order If the metadata in the warrant request are not in accordance with the details of the order, it is not permitted to approve the relevant data of this part of the warrant request, for the provision of information. In these cases, report back with a ResponseIncomplete message as per Section 2.2.2.4 with a machine-readable list (TargetNumber) of the identifiers considered invalid. It is necessary to approve error-free queries for further identifiers that match the order. After clarification by the authorised agency, it is required to resubmit the process in a separate warrant request if the provision of information is still required for the incorrect entries. For this, the new warrant request may contain either: - a corrected order with unchanged metadata for the relevant identifiers; or - an unchanged order with corrected metadata for the relevant identifiers. If queries are not received for identifiers indicated in the order, do not enter any metadata for these (this does not require an error message). It is only permitted to reject an entire warrant request in cases of confirmed or suspected fundamental errors (such as a poor electronic copy of the order, or all metadata are incorrect or missing). Here as well, report back with a FailureResponse message as per Section 2.2.2.3.  Parallel sending of warrant and data requests It is common to send a warrant request at the same time as its initial data requests. The receiving system of the undertaking must have a mechanism available for immediate processing of received data requests on approval of the associated warrant request.  Separate procedures for different uses of the interface To maximise the simplicity of the query system process, it is not permitted to combine the usage cases listed in ‘1. Basic information’. Different uses require different warrant requests, even if using the same electronic order for the same identifier. TR TKÜV, edition 8.1 (draft) Part B, page 77  Multiple identifiers per warrant request, one identifier per subsequent query or assignment Every actual query or assignment (e.g. data request, activation request, etc.) contains exactly one specific identifier (in addition to the types listed in Chapter 4.1 in Part A of this TR TKÜV, the identifier may also consist of multiple components, such as name and address, where necessary for unique identification); the meta requests in the warrant request may contain multiple identifiers according to the possible multiple responses for the order.  Details on transmission of orders to implement interception measures In parallel with traffic data retrieval, it is permitted to use this interface to transmit orders to implement interception measures as per Section 1.3.6.  Use of uniform formats and parameters As with the requirements as per Part A of the TR TKÜV, the ETSI Specification offers various options for data retrieval (such as IP address in ASCII or Binary format). If the data that the undertaking has available must first be converted into one of these formats, use the encoding listed in Section 2.2.3. The authorised agencies must use the encodings indicated there in their requests. In addition, Section 2.2.4 specifies the XML parameters to use if the structure of the ETSI specification permits alternative parameters (standardisation).  Use of newer versions and format specifications of the national XSD and ETSI XSD Obligated parties are normally not permitted to use newer versions of the national XML modules and the ETSI XSD until at least 6 months after their publication. The Federal Network Agency website will publish a list of the permitted modules and any deviating transition deadlines, as well as the modules not permitted in initial implementations. Use parameters <additionalInformation> or <other_LegalBasis> to retrieve data not defined in previous versions. The Federal Network Agency has specified the data formats in Section 2.2.3. The authorised agencies must support and use the versions used by the individual obligated parties. Obligated parties must update older versions as per § 170(8) TKG. The aforementioned list sets an implementation timeframe for this (based on requirements where applicable). In cases of conflicts between versions, send an error message as per Section 2.2.2.2, indicating the supported version.  Deviations from the ETSI specification requirements To simplify the process and meet the specific requirements in Germany, the following deviations from the mechanism in the ETSI specification apply: 1. To enable requests for the traffic data of all services (e.g. voice communication service, Internet access service) used by an identifier, contrary to Chapter 6.2.1 of the ETSI specification, the response message may contain traffic data from different services. 2. To use a standard scheme for data requests, the telephony part of the ETSI specification applies. For instance, for a request for the traffic data of all processes of an email address, this requires entry of the email address in field emailAddress of the partyInformation in the telephony part. Section 2.2.3.4 states that combined retrieval is also possible. This expands field nationalTelephonyServiceUsage to enable retrieval of the Internet access service at the same time as the voice communication service.  Requirements on encryption procedures If using the ETSI-ESB transmission procedure, it is only permitted to use the systems set out in Annex A.1 to this Part of the TR TKÜV and in the current policy (Annex X.3) with the encryption procedures described there. The systems do not feature storage for the data to be transmitted. The automated transmission logging does not contain any indications of the type of the data transmitted. 1.3 Details on the different possible applications The section below gives details on the different possible applications. TR TKÜV, edition 8.1 (draft) Part B, page 78 1.3.1 Traffic data retrieval Traffic data retrieval requires transmission and verification of a warrant request before automatic processing of data requests. Transmission of the order over this interface is mandatory. Separate transmission of data requests enables the authorised agency to customise the frequencies and required timeframes based on information from the obligated undertaking for the retention periods for the provided traffic data. Therefore, the system does not provide for fixed retrieval frequencies for future queries. Only send the data request after the end of the query timeframe it indicates. Provide the information immediately. According to the second sentence of § 177(3) TKG, it is mandatory to mark the traffic data to be retrieved as per §§ 9 and 12 TTDSG (operational traffic data) and § 176 TKG (retained traffic data). For retrieval of larger data volumes, the ETSI specification, as per Section 5.1.7, provides for transmission in different parts. 1.3.1.1 Retrieval of forward-looking traffic data for an urgent order It is always required to set the needsConfirmation flag in the warrant request for retrieval of forward- looking traffic data initiated by an urgent order. Judicial confirmation is performed in a warrant request with the flag isConfirmation. 1.3.1.2 Correction of a decision already implemented To correct a decision after provisional implementation, such as due to suboptimal readability of an original fax transmission, with a new decision, the authorised agency sends a warrant request with the isCorrection flag. 1.3.1.3 Order extension It is only possible to extend active measures with a new decision. This requires sending a warrant request with a new end time to the obligated party and any necessary data requests. 1.3.1.4 Selection of traffic data type To clarify whether or not traffic data retrieval should include location data, every warrant request contains a corresponding flag (LocationCriteria). Another flag indicates whether the traffic date arose before or after the decision date. If both elements are set to false, location data will not be retrieved. 1.3.1.5 Data source Every warrant request contains unique information on the origin of the data source. The choice is between operational traffic data and traffic data stored based on a legal obligation (see also ‘Act introducing a storage obligation and maximum retention period for traffic data’ [Gesetz zur Einführung einer Speicherpflicht und Höchstspeicherfrist für Verkehrsdaten]). 1.3.1.6 Automatic delivery of late records after specification by the authorised agency As specified in Section 3.3, the design of the systems of the obligated party must ensure that records within the network are available for retrieval by the authorised agencies within 24 hours after the event in question. The obligated party must indicate the exact timeframe, which may be longer in certain cases, in its documentary evidence. The authorised agency may be take this into account in data request scheduling. To receive potentially late non-network records as well (e.g. roaming data), contrary to the practice of immediate provision of information, authorised agencies may use appropriately flagged data requests (see Section 3.2.2.3) to specify retrieval of late traffic data (late records) that are only available after the end of the timeframe indicated in the warrant request and after a waiting period that the obligated party sets for non-network records. The length of the waiting period, to be coordinated with the Federal Network Agency, must ensure that late records are regularly collected in full. Handle retrieval in a regular response message, including all the traffic data stored up to this time point over the entire timeframe. Authorised agencies may cancel this specification using a cancel message. TR TKÜV, edition 8.1 (draft) Part B, page 79 1.3.1.7 Selective traffic data retrieval Selective traffic data retrieval must be possible (§ 101a(1)(first sentence)(1) of the Code of Criminal Procedure [StPO]). For this, use XML element <requestedData> of the ETSI XSD to indicate the parameters to be retrieved in XPATH notation. Unlike with non-selective retrieval, the response only includes the parameters required by the authorised agency. Contrary to the procedure in Section 1.3.1, this XML element is only used to transmit selectively requested data. If the selected element features ‘child nodes’, the entire underlying XML subtree is considered selected. Only absolute path indications are permitted, i.e. wildcards and other search and logical operators such as AND, OR and XOR are not allowed. 1.3.1.8 Selective traffic data retrieval in an targeted call search By way of supplement to the preceding section, in addition to the flag (see Section 3.2.2.3), fill the following parameters in Natparas2 of the ETSI XSD to retrieve traffic data to a specific destination address or from a known telephone number (origin address) to unknown destination addresses (targeted call search):  Targeted call search to a known destination address: TelephonyServiceUsage/partyInformation/partyNumber: Destination number (E.164 format): Indication of the known destination address TelephonyServiceUsage/TelephonyPartyInformation/TelephonyPartyRole: Tag number 1, ‘terminating-Party’  Targeted call search from a known telephone number (origin address): TelephonyServiceUsage/partyInformation/partyNumber: Origin address (E.164 format): Indication of the known origin address TelephonyServiceUsage/TelephonyPartyInformation/TelephonyPartyRole: Tag number 1, ‘originating-Party’. 1.3.1.9 Premature deactivation of individual identifiers of an existing order related to traffic data If the authorised agency does not intend to request any further traffic data on a particular identifier for the duration of the order, it should inform the obligated party of such. To enable premature deactivation of targets of a valid warrant related to traffic data, a WarrantTarget must be disabled. For this, the authorised agency sends a warrant with the DeactivateTarget flag set for each target to be terminated prematurely. Targets not listed are not deactivated. For acknowledgement, this is followed by either ResponseComplete (all changes applied), ResponseIncomplete (some changes rejected with error message for each target) or ResponseFailed (all changes rejected, also with error message). Acknowledge any subsequent incoming data requests for deactivated targets with FailureResponse. The DeactivateTarget flag cannot be used for other purposes. 1.3.2 Real-time traffic data retrieval By way of supplement to Section 1.3.1, the following apply: To meet the conditions of the real-time requirement, obligated undertakings as per § 32(3) TKÜV that provide the interface for transmission of telecommunications under surveillance as per Part A may implement information requests of this kind by administering an IRIOnly measure (provision of data as per § 7 TKÜV). This requires modification of the surveillance technology so: 1. the data transmitted to the agency authorised to receive the information do not contain any message content; 2. location data are also collected for receive-ready terminals and transmitted to the agency authorised to receive information; and 3. it is possible to limit the transmission of location data as per paragraph 2 to law enforcement agencies as per § 100g(1) of the Code of Criminal Procedure and to other agencies authorised to receive information under the applicable provisions of the law. TR TKÜV, edition 8.1 (draft) Part B, page 80 Depending on the system, transmit SMS short messages in the signalling channel. In the case of real- time traffic data retrieval, remove this SMS CC before transmission to the authorised agencies. In this process, do not change any parameter values such as lengths or checksums that describe the original packet size. Alternative arrangements to comply with these kinds of information requests must be equivalent, and designed in coordination with the Federal Network Agency. For the associated messages (warrantRequest and dataRequest), Section 2.2.1 stipulates use of the port for transmitting the telecommunication surveillance order. To distinguish between the types of use, a flag explicitly indicates real-time traffic data retrieval (as per Section 3.2.2.2). 1.3.3 Retrieval of radio cell structure information As an option, it is permitted to use the described interface and the procedure as per Section 1.3.1 to retrieve information on the structure of radio cells. The specific query data are defined in the ETSI XSD. Transmission of the warrant request and data request also sends the request to retrieve a radio cell structure. As an option, the warrant request may contain XML element <warrantTIFF>, <warrantPDF> or <warrantTextform>. The data request is sent with the warrant request or immediately afterwards. The response takes the form of a TIFF file or PDF file and contains a map section with the calculated range of the requested cell as well as the corresponding information (NE- name/status/geocoordinates/HSR/aperture angle (optional), owner). 1.3.4 Subscriber data retrieval § 174(7) TKG requires use of ETSI-ESB and the procedure described in Section 1.3.1 to retrieve subscriber data for all telecommunications providers with 100 000 or more contractual partners. Transmission of the warrant request and data request also sends the subscriber data query. The warrant request must meet the formal requirements of § 174(2) TKG (including on form and indication of the legal basis). This also includes the optional list of selective queries. As an option, XML element <warrantTIFF> or <warrantTextform> is available to implement the required form. The data request is sent with the warrant request or immediately afterwards. The contents of the data request do not exhibit any deviations (such as excessive volumes) from the warrant request. Where the ETSI XSD does not provide suitable fields for query data, the national addendum defines the necessary fields. If a data request does not follow warrant request (or vice versa) within one hour, close it and send a FailureResponse for the warrant request (or data request). Request processing starts with a formal warrant request check by a responsible specialist as soon as the data request is available. The check and approval by a responsible specialist may be omitted if the technical design of the electronic interface can automatically verify compliance with the formal requirements set out in § 174(2) TKG. Perform retrieval after receipt of the data request. 1.3.4.1 Selective subscriber data retrieval The subscriber data retrieval must also be possible in a selective form. For this, use XML element <requestedData> of the ETSI XSD to indicate the parameters to be retrieved in XPATH notation. Unlike with non-selective retrieval, the response only includes the parameters required by the authorised agency. When using this XML element, only transmit the selectively requested data. If the selected element features ‘child nodes’, the entire underlying XML subtree is considered selected. Only absolute path indications are permitted, i.e. wildcards and other search and logical operators such as AND, OR and XOR are not allowed. If the request includes data field PUK of the ETSI XSD, this includes a request for the PIN, which, if present, the obligated party must report in the corresponding field in NatParas3. The Federal Network Agency website (www.bundesnetzagentur.de/tku) publishes a table of subscriber data that may be requested, an explanation of the expected result for each parameter and the corresponding XPath. TR TKÜV, edition 8.1 (draft) Part B, page 81 1.3.4.2 Specification of request scope The data field scope of type ScopeForSubscriberData specifies the scope of the request and how to perform the search. Regardless of whether or not a query uses XPath, three options are available: 1. customer: all selected data on a particular customer. Please note that the same customer can have multiple customer relationships with the same obligated party, and the request only covers the customer relationship corresponding to the requested identifier. 2. contract: all selected data on a particular contract; a contractual relationship found based on the requested identifier. 3. empty scope(neither customer nor contract are selected): all selected data on a particular identifier. Do not retrieve data on any identifiers or contracts other than those belonging directly to the requested identifier. 1.3.5 Urgent location retrieval For mobile terminal positioning and in cases that require line location requests that cannot be postponed in the processing, Section 2.2.1 stipulates use of port 50220. Positioning can be used for the following purposes: a) Mobile terminal positioning b) IP address positioning c) Retrieval of the name and address of a physical line or customer ID (LineID) d) Positioning based on another identifier (OtherID in combination with OtherIDtype) The requirement for the fastest possible availability of the results of these queries at changing locations (e.g. locations for missing person searches), an electronic procedure based on local exchanges cannot always meet this requirement. It may therefore be necessary to maintain a ‘manual’ procedure in parallel, such as by phone. It is not required to accept requests of this kind outside normal business hours. The obligated party must describe the actual organisational arrangements in the documentary evidence (concepts). 1.3.6 Transmission of orders and other telecommunications interception measures Use of this interface meets the requirements of the first sentence of § 12(2) TKÜV for secure electronic transmission of a copy of the order. In this case, this does not require presentation of the original order or a certified copy thereof. 1.3.6.1 Implementation of interception measures As with the traffic data retrieval procedure, implementation of interception measures first requires an approval based on a warrant request; measure activation and deactivation is sent in a separate activation or deactivation request. The various identifiers involved are identified by a targetNumber as a sequential number. Use of this option must meet the logging obligation as per § 16 TKÜV, which requires recording of every use of the surveillance equipment, regardless of whether this use is manual or automated. TR TKÜV, edition 8.1 (draft) Part B, page 82 The figures below show the process for implementing an interception measure with two identifiers (Figure A) and for extension of a measure (Figure B): Activation of a TCIM for ‘Premature’ identifier A deactivation of Change of the Order as per with LIID TCIM with TCIM with § 100a StPO 111222 identifier A identifier A new requestNumber new requestNumber new requestNumber requestNumber: 56789 referencedRequestNumber: 56789 refReqNumber: 56789 refReqNumber: 56789 LIID: 111222 LIID: 111222 Activation of a ‘Premature’ TCIM for deactivation of identifier B TCIM with with LIID identifier B 55555 new requestNumber new requestNumber referencedRequestNumber: 56789 refReqNumber: 56789 LIID: 55555 Figure A. Implementation of an interception measure for identifiers A and B Activation of a TCIM for identifier C Order as per with LIID § 100a StPO 454545 new requestNumber requestNumber: 56899 referencedRequestNumber: 56899 ‘Premature’ Extension of a Order as per deactivation of TCIM with § 100a StPO TCIM with identifier C extension identifier C new requestNumber: 57123 new requestNumber new requestNumber referencedRequestNumber: 56899 refRequestNumber: 57123 refRequestNumber: 57123 LIID: 454545 LIID: 454545 Figure B. Implementation and extension of an interception measure for identifier C 1.3.6.2 Implementation of urgent orders If an interception measure must be implemented by means of an urgent order, the needsConfirmation flag must be set in the warrant request. Judicial confirmation is performed in a warrant request with the flag isConfirmation. 1.3.6.3 Corrections to orders for measures already implemented It is permitted to correct a decision after provisional implementation, such as due to suboptimal readability of an original fax transmission, with a new decision. For this, a warrant request is transmitted with the flag isCorrection. 1.3.6.4 Changes to measures already implemented Use a modify request to apply changes to an active measure which do not require an additional order. TR TKÜV, edition 8.1 (draft) Part B, page 83 1.3.6.5 Order extension It is only possible to extend active measures with a new decision. This requires sending a warrant request with a new end time to the obligated party as well as a renewal request. To initiate changes to an active measure which do require an additional order, it is necessary to use a second warrant request and activate them with a second activation request. The second warrant request initiating the change must not contain the metadata of individual measures or identifiers from the first warrant request that are not affected by the change. As with the traffic data retrieval procedure, activation, modification modify and renewal request may be processed automatically after checking against the metadata in the warrant request. 1.3.7 Transmission of invoice reconciliation data in advance of compensation as per § 23(1) JVEG (optional) See Section 4. 1.4 Electronically secured order transmission Use of one of the interfaces described in Part B ensures the security of electronic transmission within the meaning of the requirement in § 12(2) TKÜV. However, when applying these procedures and any default settings for administration interfaces, ensure that automatic implementation of the order is not possible. In fact, a ‘manual check’ is required in each individual case. Only after this manual check and subsequent release in the system is it possible to activate a measure, either manually, or automatically with a further request. This does not affect the rule as per the second sentence of Section 1.3.4(4). 2. Handover interface as per ETSI Specification TS 102 657 This section describes the conditions on the handover interface as per ETSI Specification TS 102 657 [37]. This Annex covers the decisions on the options in the specifications, as well as additional technical requirements. Use the XML module described in the ETSI specification to transmit a query; it is not permitted to bundle multiple queries. In addition to the requirements of this Part, the following Annexes to Part X of the TR TKÜV apply: Annex Contents Annex X.1 Proposed changes to the TR TKÜV Annex X.3 Regulations for the registration and certification authority of the Federal Network Agency (TKÜV CA), Unit IS16 (Policy) 2.1 Selected options for ETSI TS 102 657 The table below describes the options selected for the different chapters and sections of ETSI Specification TS 102 657, as well as the additional requirements. Unless indicated otherwise, the references in the table are for the sections of the ETSI specification. Section of Description of the option or issue and Additional requirement, background or additional TS 102 657 specifications for national application information 4.1 Reference model Different Authorised Organisations for HI-A and For this, see the specifications in this table for HI-B do not apply. Chapter 5.4 4.5 Model used for the RDHI Use XML/HTTP as the transmission For this, see the specifications in this table for mechanism. Chapter 7 or those following this table. TR TKÜV, edition 8.1 (draft) Part B, page 84 Section of Description of the option or issue and Additional requirement, background or additional TS 102 657 specifications for national application information 5.1.2 Message flow modes Only the General situation variant as per The obligated party transmits requested data to the Chapter 5.2 applies. authorised agency immediately (push procedure). 5.1.5 Errors and failure situations Report errors as defined in 5.1.5.2 to the For this, see the specifications in Section 2.2.2 TR authorised agency, with a qualified error TKÜV after this table. message. The receiver must reject transmissions with formal errors (errors as per 5.1.5.3). 5.1.7 Delivery of results It is necessary to implement the single shot With the single shot delivery option, each query has delivery option, and optional to implement the exactly one response. For forward-looking orders multi-part delivery option. requesting information on traffic data, the authorised agency must send separate queries (requests) to the undertaking for each order, taking into account the timeframes for storage of the data by the undertaking. The multi-part delivery option enables subdivision of the retrieved data in cases of high volumes. If this option is applied, use parameter ResponseNumber. The concept document must detail the use and its exact design. For both options, the following additional indications apply: 1. The basic obligation on telecommunications undertakings as per §§ 9 and 12 TTDSG to delete unneeded traffic data immediately after terminating the connection remains unchanged. 2. The design of the technical procedure does not give rise to any obligation or authorisation to store traffic data within the framework set out in §§ 9 and 12 TTDSG. 5.5 HI-A and HI-B addressing The deliveryPointHIB field is not used. Different IP addresses for an Authorised Organisation are not permitted in the same request or its corresponding response, i.e. source IP address for HI-A and destination IP address for HI-B must be identical. 6.1.2 RequestID field specification The Federal Network Agency assigns the The Authorised Organisation Code of the authorised required Authorised Organisation Code identifier agency corresponds to the authorised agency ID of the authorised agency. assigned as a unique reference number for telecommunications interception measures (for this, see Annex X.2 to the TR TKÜV). If the authorised agency does not receive an ACK message for a transmitted request, it may Acknowledgement of duplicate RequestNumbers by resend the same request with the same the obligated party is limited to the data available to RequestNumber. Section 2.2.2.5 of this TR it. This does not give rise to any right to deviate from TKÜV describes this procedure. deletion requirements under data protection law. 6.1.3 CSP identifiers The Federal Network Agency assigns the The CSP ID of the obligated party corresponds to the required CSP ID and Third-Party CSP ID to the operator ID assigned as part of the obligation under obligated party. Part A and/or Part B of this TR TKÜV. 6.1.4 Timestamp The restrictions in Section 2.2.3.1 of this TR TKÜV apply. TR TKÜV, edition 8.1 (draft) Part B, page 85 Section of Description of the option or issue and Additional requirement, background or additional TS 102 657 specifications for national application information 6.3.1 Information contained within a request 6.3.2 Request identifiers with equals. Do not use: Only use range parameters lessThanOrEqualTo notEqualTo, lessThan, greaterThan, startsWith, and greaterThanOrEqualTo for time indications. endsWith, isAMemberOf. 6.3.3 Additional information in requests All requests have the same priority. Do not use parameter MaxHits. 6.4 Error messages Compose informative error messages. For instance, if version conflicts arise, the error messages must include at least the expected version. 7 Data exchange techniques Use XML/HTTP as the transmission For this, see the specifications in Section 2.2 TR mechanism. Perform transmission over the TKÜV or after this table. public Internet using a VPN as per Annex A.2. 7.2 HTTP data exchange Use the Mutual client/server option. For this, see the specifications following this table. 7.2.3 Mutual client/server URI is uniform for HI-A and HI-B /ETSI. A host header is not needed. 8 Security measures The requirements of Annex A.2 apply. Annex A Data fields The Annex describes the data fields used and Examples of common queries and the expected the specifications within an ASN.1 definition. results are available from the Federal Network The applicable XML definition is available on the Agency. ETSI website, as is the ETSI specification. 2.2 Additional technical requirements for the interface description as per ETSI TS 102 657 The handshake mechanism described in the ETSI specification requires more stringent national specifications on the HTTP transmission method it describes, to ensure smooth interaction between the different systems. 2.2.1 HTTP transmission method For electronic transmission to a participating undertaking, this undertaking provides the required addressing information (IP address) to the Federal Network Agency, which forwards this information to the authorised agencies. The port numbers of the receiver (destination port) are identical for HI-A and HI-B, and must be used as shown in the table below. If the request requires an order, this is transmitted over the same port. Application destination port Traffic data retrieval 50200 Subscriber data retrieval 50210 Location retrieval 50220 Transmission of the telecommunications surveillance order 50230 Real-time traffic data retrieval Retrieval of radio cell structure information 50250 TR TKÜV, edition 8.1 (draft) Part B, page 86 Transmission of data to assert the claim for compensation as per Annex 3 50260 to § 23(1) JVEG Transmit each message (Req, ReqAck, Res, ResAck, etc.) in an individual HTTP session using the POST method. The server uses an HTTP 200 (OK) to acknowledge successful transmission and server- side validation of the XML message. After transmitting the HTTP status codes, the server terminates the connection. If 60 seconds pass without any client or server activity, it is permitted to terminate a connection. If the server terminates the connection, it must first send an HTTP 408 (request time-out) to the client. Only one request per HTTP session is permitted; for multiple requests, transmit each in a separate HTTP session. Use of ‘Content-Encoding: gzip’ in the HTTP POST request of the client is optional. The server must be able to process the requests and responses. As per the XML standard, it is necessary to replace special characters with the corresponding escape characters, to enable validation. 2.2.2 Error handling 2.2.2.1 Request or information encoding error (as per ETSI TS 102 657, Section 5.1.5.3) In cases of formal transmission errors in a request or in information (invalid XML, or required parameter missing), the HTTP server must reject this with HTTP status code 422 (Unprocessable Entity). Transmit an informative error message in the HTTP body. For instance, if the version of the transmitted Natparas does not match the version expected by the obligated party, the HTTP body of the error message must indicate the version used by the obligated party. Annex A.4 in Part A of this TR TKÜV applies accordingly for the requirement to make repeated attempts to transmit information. 2.2.2.2 Status errors (as per ETSI TS 102 657, Section 5.1.5.3) In cases of status errors (‘wrong messages at the wrong time’), send an error message (ErrorAck) that refers to the RequestID of the request. As an option, this may also contain comments. 2.2.2.3 Request cannot be fulfilled (as per ETSI TS 102 657, Section 5.1.5.2) If a request cannot be fulfilled (e.g. incorrect parameters, does not match the order, or data request is for a rejected warrant), send a FailureResponse message with indication of the reasons, composed as in the example below. This procedure is necessary if: a) the manual check of a request message (e.g. after transmission of an order or a subscriber data query) finds that the entire request cannot be fulfilled; or b) the automatic check (e.g. on a request message of the usageData type) detects a parameter error. This normally requires subsequent transmission of a new request with a new requestNumber. This FailureResponse message may also be used when technical or other errors on the part of the obligated undertaking cause retrieval delays that must be reported to the requesting agency. 2.2.2.4 Sending the ResponseComplete or ResponseIncomplete message In the absence of errors, acknowledge a request of the warrant type with a ResponseComplete message. TR TKÜV, edition 8.1 (draft) Part B, page 87 If parts of the order cannot be implemented, send a ResponseIncomplete message with a machine- readable list of the specific identifiers considered invalid. It is permitted to add a short error message (RejectedTargetErrorMessage) for each rejected identifier (RejectedTargetNumber). 2.2.2.5 Repeated transmission of the same message Use a corresponding ACK message to acknowledge every request, response or cancel message. If this ACK message is not received, it is permitted to resend the same original message (such as a request) including the same requestNumber. The receiving system must be able to recognise that the same message is being resent, and:  return an ACK message;  but prevent further processing of the second message (e.g. traffic data retrieval) if the first message has already been received and is in processing. Resent messages must have the same content; if an optional check of the original and repeated messages finds a discrepancy, suspend processing and send a FailureResponse message. 2.2.2.6 Sending a cancel message Authorities can use a cancel message to stop unprocessed data requests that are no longer required. Data requests already in processing will still be retrieved. 2.2.3 Formats In principle, wherever possible, the obligated undertaking must provide the data to be retrieved in the format in which they are available to it. If certain data available for retrieval must first be converted into a format prescribed in the ETSI specification, use the encoding listed in Section 2.2.3.4 below. In their requests, the authorised agencies must use the encodings indicated there. Because these provisions may be subject to updates based on new applications or types of traffic data, this section reflects the state of affairs at the time of publication of this edition of the TR TKÜV. The Federal Network Agency will coordinate with the stakeholders when adopting new provisions. The current version of the format specifications is available for download on the website of the Federal Network Agency at (www.bundesnetzagentur.de/tku). 2.2.3.1 Date and time formats For this part of the TR TKÜV, use of the GeneralisedTime encoding for date and time indications is uniform and standard. Here, the GeneralisedTime format is restricted to YYYYMMDDhhmmss.fraction +/- time differential, where YYYY is the year, MM the month, DD the day, hh the hour (00 to 23), mm the minute (00 to 59) and ss the second (00 to 59). An option for further precision is available (fractions of seconds). In principle, times are always in official German time (local time). To differentiate between different times and between summer and winter time, indicate the time difference from UTC. This requirement also applies to retrieved data generated in the internal system or network of the obligated undertaking; for time indications received from foreign roaming partners, it is permitted to deviate from the rule and use the time value provided. 2.2.3.2 Formats for geographic location information as per ETSI TS 102 657 For the default values for coordinate data, use geographic coordinates in decimal notation (‘geoCoordinatesDec’) or as angular geographic coordinates (‘geoCoordinates’). Indicate the coordinates within the ‘extendedLocation’ structure based on the WGS84 reference system. If known, include the main radiation direction (azimuth) in the location information. If the description of a geographic location, such as for a ‘radio cell query’ or to provide mobile terminal positioning information, must be provided by means of postal information, use parameter ‘postalLocation’ within structure ‘extendedLocation’ to provide this. 2.2.3.3 Formats for radio cell identifiers for radio cell queries For radio cell queries, transmit the requested radio cell identifier from 2G to 4G (including 5G NSA) in field ‘userLocationInformation’. Please note that the userLocationInformation block can only contain a TR TKÜV, edition 8.1 (draft) Part B, page 88 single indication. It is not permitted to use other data fields, such as GlobalCellID. For 5G SA radio cell identifiers, use field nCGI instead (already available in TS 102 657). Similarly, for radio cell identifiers in traffic data information, only use field ‘userLocationInformation’. For 5G SA radio cell identifiers, use field nCGI instead. 2.2.3.4 Formats for other identifiers as per ETSI TS 102 657 Table A below lists the identifiers as per ETSI TS 102 657 for which only one format option is available, and explains their application. Table B contains identifiers for which the ETSI specification offers multiple formatting options or where an explanation appears helpful, and explains the variants to be used according to the above explanation or that require requests from the authorised agencies: Table A Identifier Format as per TS 102 657 Example of encoding as per TS 102 657 (or national addendum) PartyNumber E.164 in international format as Identifier 0123/4567890 (telephone number, a UTF string MSISDN, VLR) ETSI format 491234567890 IMSI Octet string size 3-8 Identifier 262071234567890 as per 3GPP TS 09.02 ETSI format 62021732547698F0 IMEI Octet string size 8 Identifier 12345678901234 as per 3GPP TS 09.021 ETSI format 21436587092143F0 userLocationInformation Octet string size 1-35 as per 3GPP TS 29.274 emailAddress UTF8String Identifier [email protected] (email address) ETSI format [email protected] 1 If only positions 1 to 14 are available for an IMEI, fill the remaining positions with padding (11110000) or ‘F0’. When comparing IMEIs, an IMEI should be considered equivalent to the requested IMEI even if the checksum or software version digits are different or missing. Table B Identifier Format as per Example of encoding as per TS 102 657 TS 102 657 IPv4 address Octet string size 4 Identifier 127.0.0.1 ETSI format 7F000001 IPv6 address Octet string size 16 Identifier 2001:0db8:85a3:08d3:1319:8a2e:0370:7344 ETSI format 20010DB885A308D313198A2E03707344 For otherwise required identifiers for which the ETSI specification does not provide any corresponding parameters, national XML module Natparas2 includes expansions for ETSI parameter nationalTelephonyPartyInformation (see Part B, Section 3.2.2 of this TR TKÜV). Thus, do not use ETSI parameters TelephonyDeviceID or subscriberID for those options. 2.2.3.5 Combined retrieval of traffic data for the voice communication and Internet access services of an identifier (optional) ETSI Specification TS 102 657 draws a basic distinction between retrieval for different services, such as voice communication services and Internet access services. Thus, retrieval of traffic data for the voice TR TKÜV, edition 8.1 (draft) Part B, page 89 communication and Internet access services of a specific identifier (landline or mobile number) would require separate retrieval. To prevent duplicate traffic data requests and retrievals, this TR TKÜV allows the following optional procedure: 1. Both the warrant request and the data request use the usageData parameter to indicate whether to retrieve the traffic data for the voice communication service or the Internet access service. If both possible values are set to true, the request is for combined retrieval. 2. To transmit traffic data for combined requests, the field ‘nationalTelephonyServiceUsage’ in the ETSI specification is expanded (in bold in the shaded section below) so retrieval for the voice communication service can also include the Internet access service. TelephonyServiceUsage ::= SEQUENCE { partyInformation [1] SEQUENCE OF TelephonyPartyInformation OPTIONAL, communicationTime [2] TimeSpan OPTIONAL, -- Time and duration of the communication nationalTelephonyServiceUsage[10] NationalTelephonyServiceUsage OPTIONAL } NationalTelephonyServiceUsage :: = SEQUENCE { countryCode [1] UTF8String (SIZE (2)), version [2] UTF8String (SIZE (2)), internetAccess [3] NAServiceUsage OPTIONAL } The concept must indicate the option to use this method. If the obligated undertaking does not support this option, it must respond to a request of this kind with an error message as per Section 2.2.2.3. 2.2.4 Standardisation of response data for selective retrieval of subscriber and traffic data A national survey on the selection of suitable ETSI parameters for subscriber and traffic data found that the specification does lend itself to different interpretations and may therefore result in deviating parameter selections in certain cases. To ensure a uniform level of information for selective retrieval, tables must give cross-manufacturer definitions of the parameters to be used (see also Sections 1.3.1.7, 1.3.1.8 and 1.3.4.1 of this Annex). The Federal Network Agency website (www.bundesnetzagentur.de/tku) publishes the tables to be used. 2.2.5 Flexible use of free text field ‘otherInformation’ For all parameters that lack clear correspondences in the ETSI structure, use free text field ‘otherInformation’ (responseMessage/responsePayload/ResponseRecord/additionalInformation/otherInformation). The syntax to be used here is available in Section 3.3.2.1. 3. Definition of national parameters 3.1 General The international standards and specifications underlying this TR TKÜV offer the possibility to transmit national parameters. The section below defines additional national XML modules ‘Natparas2’ for transmitting the copy of the order and the additional metadata in the warrant request and data request and ‘Natparas3’ for transmitting the response for the other uses (such as for mobile terminal positioning). Only the Federal Network Agency is permitted to make changes or expansions. As per the XML standard, it is necessary to replace special characters with the corresponding escape characters, to enable validation. TR TKÜV, edition 8.1 (draft) Part B, page 90 Insert module Natparas2 into field NationalRequestParameters of the RequestMessage, and insert module Natparas3 into field NationalResponsePayload of the ResponseMessage. The latest versions of the national modules are available on the Federal Network Agency website (www.bundesnetzagentur.de/tku). The published Natparas versions are not linked to the current ETSI XSD version. However, if it is not possible to use national module versions with certain ETSI XSD versions, such as due to XML compatibility issues, the Federal Network Agency website will note this. 3.2 Description of national XML module ‘Natparas2’ (for requests) This Annex contains the XML description for national module ‘Natparas2’, for transmitting the copy of the order as well as the additional metadata in the warrant request and data request. Because this XML description may be subject to expansions for new parameters, this Annex only reflects the state of affairs at the time of publication of this edition of the TR TKÜV. The Federal Network Agency coordinates new parameters with the stakeholders (authorised agency, obligated party) and expands the XML module. After coordination, the latest version of the XML description of the national parameters as well as the individual parameter definitions below will available for download on the Federal Network Agency website (www.bundesnetzagentur.de/tku). It is permitted to insert the information on the legal bases into element <other_Legalbasis> of ComplexType ‘LegalBasis’. 3.2.1 Usage types Module Natparas2 is defined for the following usage types:  Transmission of the order and metadata (warrant type) Here, the ETSI RequestMessage merely serves as a transmission envelope.  Transmission of specific queries for subscriber and traffic data retrieval (subscriberData and usageData types) Here, the national module only contains supplementary data, while the ETSI RequestMessage contains the actual query by filling in the corresponding known parameters (such as transmission of the telephone number and a timeframe for traffic data retrieval).  Transmission of requests for positioning (locating type) and radio cell structure (radioStructure type) Here, the ETSI RequestMessage merely serves as a transmission envelope.  Transmission of the activation or change messages for implementation of telecommunications interception measures (lawfulInterception type) Here, the ETSI RequestMessage merely serves as a transmission envelope.  Transmission of a premature deactivation of individual targets (deactivateTarget type) of an existing warrant related to traffic data The usage types linked to an order may contain multiple identifiers in the warrant request (marking of the different identifiers with parameter <targetNumber> as a sequential number). For usage types usageData, locating and radioStructure, only one identifier is permitted per request. 3.2.2 Supplementary data in national XML module Natparas2 XML module Natparas2 is inserted into field NationalRequestParameters of the RequestMessage and is structured as follows: 3.2.2.1 Specifications for the header NationalRequestParameters Parameters Description M/C/O <countryCode> Value: ‘DE’ M <headerID> Version number of national module Natparas2 M The version number format is as follows: ETSI version.TR edition No, where: ETSI version: 8 characters TR edition: 4 characters No: 2 characters TR TKÜV, edition 8.1 (draft) Part B, page 91 Example: 01.26.01.07.2.01 means: 01.26.01 07.2 01 ETSI TS 102 657 relevant TR consecutive numbering for the NatParas version version No TKÜV edition 01.26.01 7.2 <referencedRequestNumber> This refers to the RequestNumber (RequestID in the ETSI XSD) of a C previously transmitted order in a warrant request; this is a required parameter for all requests following a warrant request. <targetNumber> Sequential number of the relevant identifier in the warrant request C referred to in the subscriberData and lawfulInterception requests, to initiate the retrieval or TCI measure for an identifier. This parameter is required in these cases. <groupID> Only use the sequential number to group different requests within a O WarrantRequest for billing purposes. (for instance, grouping 10 retrievals per IP address as per § 23(1) of Annex 3, No 201, JVEG) <additionalInformation> Free text to be taken into account before processing the applications: O <subscriberData>, <locating> and <radioStructure>. <requestDetails> This specifies the possible application modules as a choice. M requestDetails Parameters Description M/C/O <warrant> For transmission of an order including metadata C <usageData> For requests for traffic data, with the specific query data defined in the C ETSI XSD; the national addendum as per Section 3.2.2.3 also distinguishes between the service to which the query pertains (voice communication service or Internet access service). <subscriberData> For requests for subscriber data beyond the query options of the ETSI C XSD <locating> Positioning as per Section 1.3.5 C <radioStructure> For requests for the radio cell structure, with the specific query data defined in the ETSI XSD <lawfulInterception> For the activation/change/deactivation of a TCI measure, after C transmission of the order <compensation> Data type for asserting claims for compensation C 3.2.2.2 Warrant request for the national XSD addendum Warrant Parameters Description M/C/O <warrantTIFF> Order (Base64-encoded TIFF document as described above) C <warrantPDF> Order (Base64-encoded PDF document) C <warrantTextform> Implementation of the required form for subscriber data requests as C per § 174(2) TKG, as an alternative to <warrantTIFF> or <warrantPDF> <warrantType> Parameters for indicating the request format (warrantTIFF, M warrantPDF or warrantTextform) for subscriber data requests <warrantDate> Date of the order, in format YYYYMMDD M <warrantTargets> List of individual identifiers, with sequential numbering; M  see definition of <WarrantTarget>. <legalBases> Legal basis for the order; M  see the XSD. <needsConfirmation> If a confirmation is still required, such as for an urgent order for TCI, C (Sections 1.3.1 and 1.3.6) <isConfirmation> Flag to confirm transmissions such as an (urgent) order sent C previously with <needsConfirmation> (Sections 1.3.1 and 1.3.6) <isCorrection> Flag to indicate that the new decision corrects a minor defect C (Sections 1.3.1 and 1.3.6) <usageDataInRealtime> Flag to indicate that the order is for real-time traffic data retrieval C (Section 1.3.2) <usageDataInRealtimeWithout Flag to indicate that the order is for real-time retrieval of traffic data C LocData> without location data (Section 1.3.2) TR TKÜV, edition 8.1 (draft) Part B, page 92 <usageDataInRealtimeOnlyLoc Flag to indicate that the order is for real-time retrieval of traffic data C Data> containing only location data (Section 1.3.2) <isVsnfd> Identifies the order or request as VS-NfD C WarrantTarget Parameters Description M/C/O <targetNumber> Sequential number to identify the identifier within the metadata and M related requests <deactivateTarget> For premature termination of individual targets of an active warrant for O the provision of traffic data <target> This contains element TelephonyPartyInformation with corresponding M data field values from the ETSI XSD and if necessary, parameter nationalTelephonyPartyInformation with the national expansions from XSD module Natparas2. <startDateTime> Start of the timeframe specified in the order for this identifier, in M GeneralisedTime format <endDateTime> End of the timeframe specified in the order for this identifier, in M GeneralisedTime format <targetType> This field serves to distinguish whether: M  for the identifier, the order is for subscriber data retrieval, traffic data retrieval, positioning, a radio cell structure or a TCI measure;  traffic data retrieval in combination with parameter <usageData> is for <telephonyService>, <dataService> or a combined request;  the TCI measure in combination with parameter <interceptionCriteria> is for Voice+Data or IRIOnly. <interceptionCriteria> Required field for TCI measures; gives the potential scope of C surveillance according to the order (CC+IRI or IRIOnly). The activation request sets the actual scope to be activated here (this enables changes such as carrying out an existing CC+IRI order as an IRIOnly measure, for reasons attributable to the authorised agency). WarrantTextform Parameters Description M/C/O <originator> Name of requesting party M <originatorContactDetails> Phone number of requesting party M <endOfText> The text field needed to indicate the end of the required form; enter M ‘This document is valid without a signature!’ as the parameter value. NationalTelephonyPartyInformation Parameters Description M/C/O <countryCode> Value: ‘DE’ M <headerID> Version number of national module Natparas2 M The version number format is as follows: ETSI version.TR edition No, where: ETSI version: 8 characters TR edition: 4 characters No: 2 characters Example: 01.26.01.07.2.01 means: 01.26.01 07.2 01 ETSI TS 102 657 relevant TR consecutive numbering for the NatParas version version No TKÜV edition 01.26.01 7.2 <partyNumberAKUE> The foreign telephone number to be specified in the order, starting C with the country code (e.g. 33 for France) <voipID> VoIP identifier not in E.164 format (e.g. [email protected]) C <lineID> Line identifier or technical key of an Internet gateway C <userName> Account name of an Internet connection C <postBoxAddress> Mailbox address or account name of a mailbox C <macAddress> MAC address of a terminal used for Internet access in cable networks C TR TKÜV, edition 8.1 (draft) Part B, page 93 <ipAddress> Fixed IP address of an Internet connection C <hostMacAddress> hostMacAddress for WiFi hotspot C <mailboxID> For mailbox queries such as retrieve, download, delete emails C 3.2.2.3 usageData requests in the national XSD addendum For traffic data retrieval, the request data for the specific traffic data for retrieval are transmitted in the ETSI XSD (such as transmission of the telephone number and a timeframe for traffic data retrieval). In addition to the information in the header (including the reference to the warrant request and the relevant targetNumber), the national XSD addendum contains information on the queried service (voice communication service, data service, combined request). UsageData Parameters Description M/C/O <usageData> Indication whether to retrieve traffic data from the voice M communication service or the Internet access service, for the landline or mobile number; set both options for combined retrieval as per Chapter 2.2.3.5. Possible values: - telephonyService: true or false - dataService: true or false - lateRecordRequest: true or false - targetedCallRequest: true or false A special data request for retrieval of delayed traffic data (late record), which will only be available after a waiting period and after the end of the query timeframe in the warrant request targetedCallRequest to indicate a targeted call search locationCriteria Parameters Description M/C/O <retrogradLocation> The requested location data pertain to a time period before to the M decision date. <anterogradLocation> The requested data pertain to the time period between the decision M date and the end time. typeOfData Parameters Description M/C/O <betrieblicheVerkehrsdaten> Traffic data available on operational grounds C (operational traffic data) <bevorrateteVerkehrsdaten> Traffic data stored due to a legal obligation (see also the ‘Act C (retained traffic data) introducing a storage obligation and maximum retention period for traffic data’). 3.2.2.4 Specifications for subscriberData requests in the national XSD addendum For subscriber data retrieval, the request attributes for the specific subscriber data for retrieval are transmitted in the ETSI XSD (such as transmission of the telephone number or a name with address). 3.2.2.5 Specifications for locating requests in the national XSD addendum For retrieval for positioning requests as per Section 1.3.5, the ETSI XSD merely serves as a transmission envelope and to indicate a requestNumber. The national XSD addendum included in the ETSI XSD contains the search criterion. Locating requests are subject to the procedure in Section 1.3.1. Inserting the <referencedRequestNumber> field in the header of the location request links it to the warrant request. TR TKÜV, edition 8.1 (draft) Part B, page 94 In addition to the result, if retrieval of the structure of the relevant radio cell is also required, do this separately with an independent radioStructure request. Locating Parameters Description M/C/O <mSISDN> Telephone number of the mobile terminal to be located, in E.164 C format; see Section 2.2.3.4. <iMSI> IMSI of the mobile terminal to be located, in 3GPP TS 09.02 format; C see Section 2.2.3.4. <legalBases> Legal basis for the retrieval; C  see the XSD. <iP> IP address of the line to be located C <lineID> Line identifier or technical key of an Internet gateway leading to the C physical address of the line <otherID> Other ID which, in combination with otherIDtype, leads to the physical C address of the line <otherIDtype> Defines the type of the other ID C 3.2.2.6 Specifications for radioStructure requests in the national XSD addendum Use parameter userLocationInformation of the ETSI XSD to retrieve radio cell structure information. Please note that with radio cell requests, the userLocationInformation or nCGI block can only contain a single indication. For 5G SA radio cell identifiers, use field nCGI instead. 3.2.2.7 lawfulInterception requests in the national XSD addendum The different lawfulInterception request variants are used to activate, modify, deactivate, extend or renew (after interruption) TCI administration processes transmitted in a warrant request and approved by the undertaking. This involves insertion of one of the ETSI XSD modules described below. LawfulInterception Parameters Description M/C/O <activation> To activate an approved TCI measure (warrant request) C  see definition of <Activation>. <renewal> To extend a TCI measure; requires approval of an additional warrant C request.  See definition of <Renewal>. <modification> To modify a TCI measure, if this does not require a order (e.g. change C of transmission address)  see definition of <Modification>. <deactivation> For premature deactivation of a TCI measure C  see definition of <Deactivation>. Activation Parameters Description M/C/O <target> Identifier under surveillance M  For this parameter, use parameter telephonyPartyInformation from the ETSI XSD. <lIID> Contains the LIID to be used. C Obligated undertakings expressly assigned the LIID by the Federal Network Agency due to operation of older switching equipment must indicate the actual activated LIID in the response message. <interceptionCriteria> Details on the scope of surveillance M  see definition of <InterceptionCriteria>. <monitoringCenter> Details on the transmission targets M  see definition of <MonitoringCenter>. <startDateTime> 2 Time of planned activation of the measure, in GeneralisedTime C format; no value means immediate activation. <endDateTime> 2 Time of planned deactivation, in GeneralisedTime format M 2 These values may deviate from those indicated in the warrant request, but must be within the timeframe defined by those original values. TR TKÜV, edition 8.1 (draft) Part B, page 95 Renewal Parameters Description M/C/O <lIID> LIID of the measure M <endDateTime> Time of the new end time, in GeneralisedTime format M Modification Parameters Description M/C/O <lIID> LIID of the measure M <newLIID> New LIID, if it should be changed C <newInterceptionCriteria> New data for field InterceptionCriteria if the scope of the TCI measure C should be changed <newMonitoringCenter> New data for field MonitoringCenter, if the transmission targets should C be changed Deactivation Parameters Description M/C/O <lIID> LIID of the measure M <endDateTime> Time of planned deactivation, in GeneralisedTime format No value in C this parameter means immediate deactivation. InterceptionCriteria Parameters Description M/C/O <interceptVoice> 1 Indicates whether to monitor the voice communication service M <interceptData> 1 Indicates whether to monitor the Internet access service M <interceptIdlemodeHandover> Indicates whether to monitor handover of a mobile terminal in idle C mode as well 1 If both values are ‘false’, the request is for an IRIOnly measure. MonitoringCenter Parameters Description M/C/O <destinationNumber> HI3 transmission target for ISDN-based voice transmission, format C E.164 <ipAddress> HI2 and HI3 transmission target for IP-based voice transmission as C well as data; for the relevant port, see Part A of the TR TKÜV. <ftpAddress> IP address of the HI2 transmission target for FTP transmission C <ftpUsername> FTP user name of the HI2 transmission target C <ftpPassword> FTP password of the HI2 transmission target C 3.3 National XML module ‘Natparas3’ (for responses) This Annex gives the XML description of national module ‘Natparas3’ for transmission of additional response data (such as for mobile terminal positioning) in the response message. Because this XML description is subject to expansions for new parameters, this Annex only reflects the state of affairs at the time of publication of this edition of the TR TKÜV. The Federal Network Agency coordinates new parameters with the stakeholders and expands the XML module. After coordination, the latest version of the XML description of the national parameters as well as the individual parameter definitions below will available for download on the Federal Network Agency website (www.bundesnetzagentur.de/tku). 3.3.1 Specifications for supplementary data in national XML module Natparas3 Module Natparas3 is defined for the following usage types:  Transmission of response data on mobile terminal positioning (locatingResult type) and the radio cell structure (radioStructureResult type) Here, the ETSI ResponseMessage merely serves as a transmission envelope.  Transmission of additional response data for subscriber data retrieval Depending on the scope of the query, the ETSI ResponseMessage either only serves as a transmission envelope, or contains supplementary information. TR TKÜV, edition 8.1 (draft) Part B, page 96  Transmission of confirmations for activation or modification processes for implementation of TCI measures (lawfulInterception type) Here, the ETSI ResponseMessage merely serves as a transmission envelope. This transmission serves as a response at the administrative level and replaces the HI1 messages as per Part A of Annex A.3 to the TR TKÜV, which the obligated undertaking may choose to deactivate. 3.3.2 Specifications for supplementary data in national XML module Natparas3 XML module Natparas3 is inserted into field NationalResponsePayload of the ResponseMessage and is structured as follows: 3.3.2.1 Specifications for the header NationalResponsePayload Parameters Description M/C/O <countryCode> Value: ‘DE’ M <headerID> Version number of national module Natparas3 M The version number format is as follows: ETSI version.TR edition No, where ETSI version: 8 characters TR edition: 4 characters No: 2 characters Example: 01.26.01.07.2.01 means: 01.26.01 07.2 01 ETSI TS 102 657 relevant TR consecutive numbering for the NatParas version version No TKÜV edition 01.26.01 7.2 <additionalInformation> Free text for specific information from the obligated undertaking on the O retrieval <additionalDocument> Option to transmit an additional document as a supplement O <documentType> Indicates the type of file delivered in additionalDocument (extension M without dot) <responseDetails> This specifies the possible application modules. M Field additionalInformation may be filled with different information (similarly to Section 2.2.5) as described below: <Info> <List> <Info> <Comment> <Info> <List>;<Comment> <List> <ListItem> <List> <ListItem>;<List> <ListItem> “<FieldName>”=“<FieldValue>” <Comment> COMMENT=<text> Read the above identifiers in angle brackets as non-terminals. Any string is permitted for parameters <FieldName>, <FieldValue> and <text>. Where double-quote or backslash characters appear in parameters <FieldName> and <FieldValue>, use a backslash to escape these characters. In addition to the operator-specific fields, parameter <Comment> enables free text comments. An example without free text: ”Criterion searched“=”12345“;”Timeframe“=”01.05.2015 00:00:00 – 02.05.2015 23:59.59-”;”Carrier Id”=”66221” TR TKÜV, edition 8.1 (draft) Part B, page 97 The same example with free text: ”Criterion searched“=”12345“;”Timeframe“=”01.05.2015 00:00:00 – 02.05.2015 23:59.59-”;”Carrier Id”=”66221”;COMMENT=The cell information was already partially deleted because the data are more than 7 days old. For missing parameters, use free text field ‘otherInformation’ from the ETSI XSD as per Section 2.2.5. responseDetails Parameters Description M/C/O <locatingResult> For positioning results; if multiple SIM cards are assigned to the C identifier, fill this parameter for each SIM card and transmit it as a separate <locatingResult> in the <responseDetails>. <radioStructureResult> For responses to radio cell structure requests, with the specific query C data defined in the ETSI XSD <lawfulInterceptionResult> For responses to the activation/change/deactivation of a TCI C measure, after transmission of the order <rejectedTargets> This indicates rejected targets. If multiple targets have been rejected, C use element <RejectedTargetNumber> accordingly. 3.3.2.2 Specifications for rejectedTargets in the national XSD addendum rejectedTargets Parameters Description M/C/O <rejectedTargetInfo> For numbering of rejected targets and communication of rejection M reasons 3.3.2.3 Specifications for locatingResult in the national XSD addendum For use of type locating, give one locatingResult per SIM card. If multiple SIM cards are assigned to the identifier indicated in the locating request, add parameter locatingResult to the header with the relevant response parameters for each SIM card. locatingResult Parameters Description M/C/O <mSISDN> Telephone number of the located mobile terminal in E.164 format, C format as per Section 2.2.3.4 <iMSI> IMSI of the located SIM card in 3GPP TS 09.02 format, C format as per Section 2.2.3.4 <iMEI> IMEI of the located mobile terminal in 3GPP TS 09.02 format, C format as per Section 2.2.3.4 <loginStatus> Indication of the status of the mobile terminal (attached/registered C or detached/unregistered) <detachReason> Reason for derecognition in free text, e.g. ‘switched off by user’ C <vLR> VLR identifier in E.164 format, C format as per Section 2.2.3.4 <mME> Mobility Management Entity C Use is analogous to VLR identifier. <lastRadioContact> Time of last radio contact in GeneralisedTime format, format as per C Section 2.2.3.1 <transmitterDetails> Indication of network technology (GSM or UMTS) C  see definition in the ETSI XSD (TransmitterDetails parameter). <userLocationInformation> In 3GPP TS 09.02 format, C format as per Section 2.2.3.4 <nCGI> For the transmission of queries for 5G cells C <extendedLocation> For transmission of the geographic coordinates of the aerial C  see definition in the ETSI XSD (ExtendedLocation parameter) as defined in Section 2.2.3.2. <postalLocation> Postal address of the aerial, for additional provision of the postal C address for the geographic coordinates  see the definition in the ETSI XSD (postalLocation parameter). <subscribedTelephonyServices> To retrieve queries that are not for a location, but rather a person, C such as IP address retrieval <additionalInformation> Free text for information from the obligated undertaking that cannot C be reported correctly and in full with the other parameters TR TKÜV, edition 8.1 (draft) Part B, page 98 The indication ‘conditional’ refers to the scope of the legal basis for the query. 3.3.2.4 Specifications for radioStructureResult in the national XSD addendum radioStructureResult Parameters Description M/C/O <radiationPattern> Graphic illustration of the theoretical radiation area (Base64-encoded M TIFF or PDF document) <radiationPatternFileType> Indicates whether the file is a TIFF or PDF M <userLocationInformation> Contains cell information such as cell ID, LAC, ECI, etc. O <nCGI> For the transmission of queries for 5G cells C <azimuth> Main radiation direction O 3.3.2.5 lawfulInterceptionResult in the national XSD addendum lawfulInterceptionResult Parameters Description M/C/O <lIID> Reference number M <begin> Activation time of the surveillance C Date and time in GeneralisedTime format as per Section 2.2.3.1 <end> Deactivation time of the surveillance C Date and time in GeneralisedTime format as per Section 2.2.3.1 <modification> Modification time of surveillance C Date and time in GeneralisedTime format as per Section 2.2.3.1 3.3.2.6 subscriberDataResult in the national XSD addendum Subscriber data retrieval is for the special subscriberDataRequest as per Section 3.2.2.4 and always occurs in the ETSI XSD. Producing the reference to the request requires transmission of the header as per Section 3.3.2.1 as well. For actual retrieval of a subscriberData-Request, use parameter TelephonySubscriber from the ETSI XSD for the voice communication service, which enables transmission of multiple contract data fields (e.g. contracts for different mobile numbers) in a response. This is also the retrieval method for attributes billingMethod, bankAccount, billingAddress or contractPeriod in the ETSI XSD. Field NationalResponsePayload is not suitable for transmission of supplementary data for individual contracts or mobile numbers because it can only be used once per response. Thus, for contract-specific supplementary data, expand parameter nationalTelephonySubscriptionInfo in parameter TelephonySubscriber of the ETSI XSD as follows: nationalTelephonySubscriptionInfo Parameters Description M/C/O <countryCode> Value: ‘DE’ M <headerID> Version number of national module Natparas3 M The version number format is as follows: ETSI version.TR edition No, where: ETSI version: 8 characters TR edition: 4 characters No: 2 characters Example: 01.26.01.07.2.01 means: 01.26.01 07.2 01 ETSI TS 102 657 relevant TR consecutive numbering for the NatParas version version No 01.26.01 TKÜV edition 7.2 <pIN> PIN of the requested identifier C <other> Free text for retrieval of further queries corresponding to parameter C <other> in the subscriberDataRequest  TR TKÜV, edition 8.1 (draft) Part B, page 99 The ETSI XSD excerpt below shows the structure of parameter TelephonySubscriber with various options for subscriber data retrieval. TelephonySubscriber ::= SEQUENCE { subscriberID [1] TelephonySubscriberId OPTIONAL, -- unique identifier for this subscriber, e.g. account number genericSubscriberInfo [2] GenericSubscriberInfo OPTIONAL, -- generic personal information about this subscriber [...] subscribedTelephonyServices [4] SEQUENCE OF SubscribedTelephonyServices OPTIONAL, -- a subscriber (or account) may have more than one service listed against them ..., nationalTelephonySubscriberInfo [5] NationalTelephonySubscriberInfo OPTIONAL -- To be defined on a national basis -- Only to be used in case the present document cannot fulfil the national requirements } SubscribedTelephonyServices ::= SEQUENCE { [...] timeSpan [3] TimeSpan OPTIONAL, -- Start and end data, if applicable, of the subscription registeredNumbers [4] SEQUENCE OF PartyNumber OPTIONAL, -- The set of telephone numbers registered for this service [...] iMSI [9] IMSI OPTIONAL, pUKCode [13] UTF8String OPTIONAL, pUK2Code [14] UTF8String OPTIONAL, iMEI [15] SEQUENCE OF IMEI OPTIONAL, nationalTelephonySubscriptionInfo [16] NationalTelephonySubscriptionInfo OPTIONAL, -- To be defined on a national basis -- Only to be used in case the present document cannot fulfil the national requirements paymentDetails [17] PaymentDetails OPTIONAL } Excerpt from ETSI XSD TS 102 657 3.3.2.7 Marking of records by data origin For each record, parameter NationalRecordPayload requires selection of whether data retrieval is based on §§ 9 and 12 TTDSG or §176 TKG. Similarly, this meets the obligation as per the second sentence of § 177(3) TKG. NationalRecordPayload Parameters Description M/C/O <countryCode> Value: ‘DE’ M <headerID> See also Section 3.2.2.1 M <typeOfData> Indication of data origin (operational or retained traffic data) M typeOfData Parameters Description M/C/O <betrieblicheVerkehrsdaten> Traffic data available on operational grounds C (operational traffic data) <bevorrateteVerkehrsdaten> Traffic data stored due to a legal obligation (see also the ‘Act C (retained traffic data) introducing a storage obligation and maximum retention period for traffic data’). RejectedTargetInfo Parameters Description M/C/O <rejectedTargetNumber> For numbering of rejected targets M <rejectedTargetErrorMessage> Text field for communicating the reason for rejection in a few words O TR TKÜV, edition 8.1 (draft) Part B, page 100 4. Transmission of data to assert the claim for compensation as per Annex 3 to § 23(1) JVEG 4.1 Basic information This section describes the technical option to transmit data used to assert claims for compensation as per § 23(1) JVEG. 4.2 Methods of electronic transmission With transmission of what are known as ‘pre-check files’ (e.g. as a CSV or Excel file), obligated undertakings can send authorised agencies the data relevant to compensation that arise within a certain timeframe, for inspection. The pre-check files help provide consensus on positions that the authorised agencies believe could be incorrect, before drafting the actual claim for compensation with the obligated party, to minimise cancellations/reversals. For this, these files contain the invoicing data for all information needed for compensation, including the case numbers, amounts and discount scales specified in Annex 3 to § 23(1) JVEG. For instance, for provision of subscriber or traffic data information, the RequestID of the DataRequest or the WarrantRequest (e.g. for grouping up to 10 identifiers requested simultaneously in the same procedure, for the provision of information) is the unique identifier of an event for which a claim for compensation may be asserted as per Annex 3 to § 23(1) JVEG, and must therefore be indicated on the claim for compensation. Neither the pre-check files nor the claims for compensation are permitted to contain the personal or personally identifiable data underlying the information request (e.g. identifier for the retrieval). TR TKÜV, edition 8.1 (draft) Part B, Annex A, page 101 Annex A. Explanation of the procedure Annex A provides further explanations and illustrations of the procedure. Example records for the different use cases as well as the latest versions of national XML modules Natparas2 and Natparas3 are available on the Federal Network Agency website at www.bundesnetzagentur.de/tku. Annex A.1 Main communication flow The figures below explain the basic uses of the interface, as a supplement to the figures in ETSI TS 102 657. Division into system, sender and receiver: a) Successful transmission of a request berechtigte Stelle Authorised agency Verpflichteter obligated party SINA-VPN über Internet SINA VPN via internet Sender sender Req über HTTP req via HTTP Empfänger recipient System Verpfl. obligated party system XML-Schema Prüfung erfolgreich XML schema check successful Automatische Checks automatic checks Manuelle Checks nach ReqAck manual checks by ReqAck ReqAck über HTTP ReqAck via HTTP System bSt system bSt TR TKÜV, edition 8.1 (draft) Part B, Annex A, page 102 b) Successful transmission of a response berechtigte Stelle Authorised agency Verpflichteter obligated party SINA-VPN über Internet SINA VPN via internet Sender sender Req über HTTP req via HTTP Empfänger recipient System Verpfl. obligated party system XML-Schema Prüfung erfolgreich XML schema check successful Automatische Checks automatic checks Manuelle Checks nach ReqAck manual checks by ReqAck ReqAck über HTTP ReqAck via HTTP System bSt system bSt TR TKÜV, edition 8.1 (draft) Part B, Annex A, page 103 c) Transmission of a bad message (fault 5.1.5.3) The figure shows an example of a bad request message. This error can occur with any message type (Req, ReqAck, etc.). berechtigte Stelle Authorised agency Verpflichteter obligated party SINA-VPN über Internet SINA VPN via internet Sender Sender Req über HTTP req via HTTP Empfänger recipient System Verpfl. obligated party system XML-Schema Prüfung erfolgreich XML schema check successful Automatische Checks automatic checks Manuelle Checks nach ReqAck manual checks by ReqAck ReqAck über HTTP ReqAck via HTTP System bSt system bSt TR TKÜV, edition 8.1 (draft) Part B, Annex A, page 104 d) Successful transmission of a request and multi-part response as per Section 5.2.3 of ETSI TS 102 657 TR TKÜV, edition 8.1 (draft) Part B, Annex A, page 105 berechtigte Stelle Authorised agency Verpflichteter obligated party SINA-VPN über Internet SINA VPN via internet Sender sender Req über HTTP req via HTTP Empfänger recipient System Verpfl. obligated party system XML-Schema Prüfung erfolgreich XML schema check successful Automatische Checks automatic checks Manuelle Checks nach ReqAck manual checks by ReqAck ReqAck über HTTP ReqAck via HTTP System bSt system bSt TR TKÜV, edition 8.1 (draft) Part B, Annex B, page 106 Annex B. Email-ESB transmission procedure This Annex describes the national requirements on the Email-ESB transmission procedure. 1. Basic information Use of the Email-ESB transmission procedure is based on Sections 1 to 3 of this Part of the TR TKÜV. To use the E-Mail-ESB, the authorised agency must exchange the public keys, to be used in the encryption procedure, with the obligated party. This is also permitted before a specific order or request exists. This transmission procedure does not provide for centralised provision of the keys, such as on a key server. For subscriber data retrieval, please note that according to the fourth sentence of § 174(7) TKG, continuous availability to receive requests for information is not required. The obligated party must describe the actual organisational arrangements in the documentary evidence (concepts). In addition to the order or other request, the authorised agencies may send explanations on the requested traffic data (e.g. targeted call search, real-time transmission) and the query timeframes (times for retrieval, delivery of late records after the indicated timeframe) to facilitate processing. Processing is based on the relevant specifications for the ETSI-ESB transmission procedure. When using the E-Mail-ESB transmission procedure, only use software solutions that support an encryption procedure as per the OpenPGP standard specified in RFC4880 [24] in a hybrid application. The OpenPGP standard supports the most common Crypto-boxes and algorithms. For application, use an asymmetric RSA encryption with a key length of at least 4096 bits and a symmetric AES encryption with a key length of at least 256 bits. The recording and analysis equipment of the authorised agencies must support these procedures. For the Email-ESB transmission procedure, encrypt either the entire email (including attachment) or the email attachment. If only the attachment is encrypted, ensure that the email does not contain any sensitive information. Do not apply double encryption (attachment and email with attachment). Other encryption procedures using proprietary PGP or other end-to-end encryption methods are not permitted. If the authorised agency needs to transmit confidential documents (e.g. a classified order), it is responsible for deciding on a dedicated encryption for this document and sending it with Email-ESB in consultation with the undertaking. This does not affect the encryption process under the OpenPGP standard. With transmission of the order or in a separate email, the authorised agencies may request retrieval of late traffic data (late records), which will only be available after a waiting period and after the end of the query timeframe in the order. The length of the waiting period, to be coordinated with the Federal Network Agency, must ensure that late records are regularly collected in full. Retrieval of these late records occurs after this waiting period and also contains any and all traffic data stored for the entire timeframe up to this time. Authorised agencies may cancel this specification by sending a new email. 2. Additional usage specifications for traffic data as per §§ 175 and 176 TKG If using Email-ESB to provide information on traffic data that must be stored as per §§ 175 and 176 TKG, the following requirements apply in addition to the basic IT security requirements: If the Email-ESB transmission procedure is not integrated into the query system, the connection between the query system and the Email-ESB requires transport security as per Section 4.1 of the requirements catalogue pursuant to § 180 TKG. Data transfer between devices by means of a data carrier (e.g. USB stick) is not permitted. To protect against access from the Internet, the following rules apply to obligated parties:  Do not use the hardware and software components used for the Email-ESB transmission procedure for any other purpose.  Disconnect the Email-ESB transmission procedure from the Internet after use.  Install a firewall between the Email-ESB transmission procedure and the Internet connection. In addition, delete the plain data generated during the Email-ESB transmission procedure from the RAM after transmission. Also prevent swapping to a hard drive or, for instance, a folder for ‘Sent objects’, etc. TR TKÜV, edition 8.1 (draft) Part B, Annex B, page 107 The second sentence of § 177(3) TKG requires indication of the traffic data stored pursuant to § 176 TKG in the transmission to the authorised agency. For this, mark each individual traffic record with the syntax ‘retained traffic data’. Mark operationally stored traffic data to be transmitted with the syntax ‘operational traffic data’. TR TKÜV, edition 8.1 (draft) Part C, page 108 Part C. Technical implementation of the legal obligation to cooperate in technical identification measures for mobile terminals 1. Basic information Use of the interfaces described in this Annex will be binding once the provisions of the TKÜV come into force, which include provisions to meet the obligation to cooperate in technical identification measures for mobile terminals as per § 171 TKG. Based on § 170(6) TKG [21] in conjunction with § 171 TKG, this Part C of the TR TKÜV gives the technical details to enable use of technical means of authorised agencies in public mobile networks starting from 5G network technology, for identification of certain information on mobile terminals as well as automated and immediate retrieval of identifiers temporarily and permanently assigned in a public mobile network. To implement the two related but distinct obligations under § 171(first sentence)(1 and 2) TKG, it is necessary to provide the technical procedures described below, which are independent of one another. This enables actions such as receipt of automated information as per § 171(first sentence)(2) TKG on a system of the authorised agency, without the need for the technical means to identify the information on mobile terminals as per § 171(first sentence)(1) TKG. § 170(10) TKG states that the Federal Network Agency must approve the technical design of the technical means operated by the legally authorised agencies that are used to intervene in telecommunications secrecy and in network operation. This must also take into account the technical conditions described in this Part C as well as the precise implementations of mobile network operators to be coordinated with the Federal Network Agency. 2. Arrangements for network connection of technical means and the procedure for automated provision of information on identifiers Make the technical arrangements described in Sections 2.1 and 2.2 below as follows:  The use of the technical means of the authorised agency in public mobile networks to identify specific information on mobile terminals requires the availability of a network connection as per Section 2.1.  Automated and immediate provision of information on identifiers temporarily and permanently assigned in a mobile network requires the availability of the information procedure as per Section 2.2. Connection of the technical means of the authorised agencies must be handled exclusively with the centralised equipment of the authorised agencies. This limits the interfaces between the authorised agencies and mobile network operators to what is necessary and allows the authorised agencies to operate and manage their technical means independently. This also prevents third-party technical means connecting to the mobile networks. 2.1 Connection of technical means with the mobile network For the network connection to be provided as per § 171(first sentence)(1) TKG for the technical means using the centralised equipment of the authorised agency, provide a technical interface according to the specifications below: a) The immediate connection uses the SEPP-SEPP connection over a dedicated N32 interface. b) The connection must be undetectable to the end user on the mobile network and to other operators of mobile networks whose users are connected under an agreement. c) The connection must enable identification of information on all mobile terminals connected to the mobile network. d) A ‘positive list for SEPP IP addresses’ ensures that unauthorised third parties cannot connect to the mobile network using the network connection provided. Coordinate with the Federal Network Agency on the exact procedure used to ensure that only ‘trusted’ SEPPs of the authorised agencies can establish a network connection with the SEPPs of the mobile network operators. Use of the N9 interface is based on the provisions of the TKÜV. TR TKÜV, edition 8.1 (draft) Part C, page 109 2.2 Procedure for automated provision of information on identifiers Set up the LI_HIQR interface as per 3GPP TS 33 128 [40] for the automated information procedure to be provided under § 171(first sentence)(2) TKG. For this, use the interface as per ETSI TS 103 120 [38] for transmission. Use of ETSI TS 103 120 is subject to the specifications in Annex 2.2.1. Provide this procedure for the following information on the temporary and permanent identifiers assigned in the relevant German mobile network: a) Information on a temporary identifier based on a permanent identifier (P2T) b) Information on a permanent identifier based on a temporary identifier (T2P) This includes information on identifiers of another mobile network (inbound roaming) if assignment of temporary to permanent identifiers occurs for this on the mobile network of the obligated party. In principle, the information must be for individual queries, with one information delivery per request. The use of modification queries (OngoingIdentityAssociation) is based on the provisions of TKÜV. § 171 TKG does not permit the provision of information on identifiers based on a single location indication or retrieval of a location indication based on an identifier. It is however possible, as an option, to transmit location indications in the request as additional search parameters for a temporary or permanent identifier. Requests must contain an identifier for the requesting authorised agency and a sequential number. Proper application of the procedure includes meeting the following time requirements: a) Provide the information immediately if the requested identifiers are available. The identifiers in the cache (ICF) are only available after the end of a specific waiting period that is required for technical reasons. This waiting period and the retention time in the cache follow from the technical implementation of the mobile network operator and require coordination with the Federal Network Agency. b) The design of the information procedure must ensure that a response, in particular for P2T information, is as immediate as possible. Coordinate average response times with the Federal Network Agency. c) The retention time for association of P2T or T2P identifiers in the cache is calculated from the period of validity of the association and after the end of an association period from a subsequent buffer time. Coordinate the buffer time with the Federal Network Agency. The retention period may be longer, to enable complete processing of the request from the authorised agency by the mobile network operator. d) Provide time synchronisation based on the official time. Where applicable, coordinate with the Federal Network Agency on further conditions on the use of the two types of information provision. TR TKÜV, edition 8.1 (draft) Part C, page 110 2.2.1 Selected options and additional technical requirements The table below describes the options selected for the different chapters and sections of 3GPP TS 33.128, as well as the additional requirements. Unless indicated otherwise, the references in the table are for the sections of the 3GPP specification. Section of Description of the option or issue, Additional requirement, background or additional 3GPP TS specifications for national application information 33.128 5.7.2.1, Field ‘Reference’ Table 5.7.2-1 For identification of the authorised agency and the request, use the specification as per the Annex X.2. Use the value of the reference number as a request number accordingly. Fields ‘DesiredStatus’ and ‘RequestDetails’ Values as indicated in the table Field ‘DeliveryDetails’ Not used. The ‘delivery destination’ is always the same as the technical point from which the request is made. 5.7.2.1, Field ‘Type’ Table 5.7.2-2 Values as indicated in the table Field ‘Oberserved Time’ Use is based on the specification in the TKÜV. Field ‘RequestValues’ Values as indicated in the table 5.7.2.1, Field ‘IdentityAssociation’ Table 5.7.2-3 Values as indicated in the table Field ‘OngoingIdentityAssociation’ Use is based on the specification in the TKÜV. 2.3 Protection of network connection and procedure for automated provision of information on identifiers To protect the IP-based network connection as well as the procedure for automated provision of information on identifiers as per Section 2, use dedicated Crypto-boxes based on the IPSec protocol suite as per Part A, Annex A.2. TR TKÜV, edition 8.1 (draft) Part X, Annex X.1, page 111 Part X. Information Annex Part X contains the proposed changes to the TR TKÜV, which should serve as a basis for discussion of the next edition, as well as additional information on the various Annexes to this edition. Annex X.1 Proposed changes to the TR TKÜV This Annex is not binding within the meaning of § 170(6) TKG. It merely provides information on possible future changes, the need for which will only be clear after finalisation of this edition or international standards under development or with the launch of corresponding services or technologies. These changes will be coordinated during preparation of the next edition of the TR TKÜV. For the provision of proof as per § 170(1)(4) TKG, the Federal Network Agency will recognise implementations based on this information annex as technically correct. The proposed changes appear in the relevant copy of the text excerpt, in bold, italics and underlined. Annex X.1.1 Transmission of packet-switched voice communication services (e.g. VoLTE) In view of the end of the option for ISDN-based transmission, and the current disconnection of the access network from IMS in mobile communications, the relevant parties have agreed on the roadmap below for transmission of packet-switched voice communication services (such as VoLTE), to be implemented according to available 3GPP specifications. The current rule (step 1), described below, also applies to the provision of corresponding services by mobile virtual network operators (MVNOs) that offer their services (e.g. VoLTE) independently of the access network. In this case, the IMS operator (typically the MVNO) transmits the VoIP part and the operator of the EPS serving gateway (typically the operator of the mobile access network used) transmits the LocationInformation. The information is correlated as follows. Step Description Time limitation 1 Current situation Transmission is currently handled in parallel as per 3GPP TS 33.108 and ETSI TS 102 232-5:  ETSI TS 102 232-5 for the VoIP part as per Annex H  3GPP TS 33.108 as IRI-only for the LocationInformation as per Annex D  Correlation is possible using the LIID and timeStamp; the CIN is not correlated between the two transmissions. The dual transmission method is tolerated under the following circumstances: 1. The timeStamp indications must be correct. 2. Unique correlation must be possible for all services and service features (e.g. Multi-SIM) using the LIID, timeStamp and where applicable, IMSI. The concept document must include any applicable explanations. 3. Report the transmission of the LocationInformation with the timestamp when it becomes known to the network; transmission must take place immediately after this event. 4. It must also be possible, based on an order, to provide the LocationInformation for merely receive-ready terminals, thus meeting the requirement in the second clause of § 7(1)(first sentence)(7) TKÜV. 2 Exclusive use of 3GPP TS 33.128 modules Use of ETSI TS 102 232-5 will be replaced with the use of the corresponding 3GPP TS 33.128 modules adapted to the services in question. The need for dual transmission as per 3GPP TS 33.128 from the access network as well as the IMS with correlation using LIID and timeStamp, as described in step 1, continues to apply here and under the same conditions. TR TKÜV, edition 8.1 (draft) Part X, Annex X.1, page 112 Annex X.1.2 Future requirements on mobile communications, in particular 5G Future network technologies may pose new challenges in meeting the legal requirements on telecommunications surveillance. These challenges must be identified and overcome. This Information Annex is intended to describe new technologies and the problems or challenges based on current knowledge, to raise awareness amongst manufacturers, network operators and authorised agencies during the development process and to develop solutions for future telecommunications surveillance through standardisation. It is also intended to provide standardised surveillance solutions, on which new network technologies can rely, by means of the technical implementation descriptions in this Guideline. This would otherwise require specific national solutions, whose individual implementation would pose significantly higher costs. Technical requirements for the new 5G mobile telecommunications standard are currently under development, at the same time as standardisation of the LI requirements. In principle, the surveillance functionalities must also meet the legal requirements in future networks, with an assumption of lower quality or more complex analysis due to stronger encryption. The section below covers certain aspects of developments up to this point and comments on specific challenges for future surveillance functionality. - Identity recognition Where possible, IDs in 5G should be routed over the network using pseudonyms that cannot be traced back to the user (keyword ‘privacy’). In the future, for LI, please note that the design of all LI-relevant interfaces must enable subsequent correlation of the pseudonymised identities with a user. In roaming scenarios as well, operators must include the required mechanisms at the interfaces for handover and recognition mechanisms. - Network slicing 5G network slicing will allow network operators to divide individual physical networks into multiple virtual networks, in which these network slices can be retrieved as needed. Thus, in the future, it will be possible to implement networks across multiple countries. This may cause problems with data security/integrity when enforcing a judicial order. For instance, target lists may be managed abroad, or foreign operators may lease entire network sub-services. When designing services abroad, network operators are responsible for implementing the security and transmission requirements in accordance with German law. - NFV - Network Functions Virtualisation The introduction of Network Functions Virtualisation under 5G will enable operators to implement their networks in a virtual environment, thus reducing dependence on hardware. It is necessary to ensure that the use of Network Functions Virtualisation does not restrict LI functionality. TR TKÜV, edition 8.1 (draft) Part X, Annex X.1, page 113 Note on location data: In the case of other or future networks (e.g. 5G), it is necessary to ensure that the location information available and thus far provided on the overall network will be reported even if standardisation does not include transfer of this information to the core network or the IRI interception points. TR TKÜV, edition 8.1 (draft) Part X, Annex X.2, page 114 Annex X.2 Assignment of an identification feature for authorised agencies to guarantee unique reference numbers Basic information The first sentence of § 7(2) TKÜV requires every obligated undertaking to mark every provided surveillance copy with the reference number of the interception measure, indicated by the authorised agency, if transmitting this copy to the authorised agency over telecommunications networks with switchboard functionality. According to the TR TKÜV and the underlying ETSI and 3GPP specifications, the reference number comprises up to 25 characters. The permitted character set consists of all uppercase and lowercase letters ‘a’…‘z’, ‘A’…‘Z ‘ (without umlauts), all numbers and the symbols ‘-’, ‘_’ and ‘.’. However, when using ISDN channels to transmit the copy of the CC, only the digits ‘0’ to ‘9’ are permitted. Depending on the implementation of the ETSI interface and the associated change in administrative interfaces, the authorised agencies are now largely able to specify the reference number. Possible issues Many network elements do however depend on unique reference numbers for measures in administration. In practice, receiving the same reference number from different authorised agencies could create ambiguity and thus also potential technical errors in the surveillance technology during correlation and transmission of surveillance copies. For instance, this could result in total or partial failure to transmit copies of the CC to the authorised agencies. Guarantee of unique reference numbers To ensure uniqueness, and thus also flawless operation of transmission systems, the reference number must contain an additional identification feature. This identification feature ensures differentiation between the authorised agencies, which in turn fill in the remaining positions of the reference number independently to uniquely identify the interception measure. For this, the Federal Network Agency assigns a one-time, three-character AA ID [bs-ID] to each authorised agency [bS]. In future TCI measures, this AA ID goes in the first three positions of the reference number, provided that the obligated undertaking carrying out the order has already introduced the ETSI implementation. The authorised agency provides the obligated party with the complete reference number including the AA ID. Thus, the complete reference number is as follows: 1 2 3 4 5 6 7 8 9 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 AA ID 22 characters to assign a unique reference number to each authorised agency Permitted characters, in principle: ‘a’…‘z’, ‘A’…‘Z’ (without umlauts), ‘-’, ‘_’, ‘.’, and ‘0’…‘9’. Permitted characters for ISDN transmission: ‘0’...‘9’ The assigned AA ID is also used for the interface for technical implementation of legal measures for traffic data information requests (see Part B of this TR TKÜV). TR TKÜV, edition 8.1 (draft) Part X, Annex X.3, page 115 Annex X.3 Registration and certification authority of the Federal Network Agency (TKÜV CA), Unit IS16 (Policy) The Federal Network Agency sets the regulations on the registration and certification authority (TKÜV CA) and on participation in the Virtual Private Network (TKÜV VPN). This process must take the state of the art into account (§ 14 TKÜV). If advances in the state of the art create a need for further requirements on the arrangements to be taken or changes to arrangements in place, the VPN participants must make the necessary adjustments according to the instructions of the Federal Network Agency, within the timeframe it sets in each individual case. The currently applicable policy is available for download at: www.bundesnetzagentur.de/tku 1. General 1.1 Introduction This policy contains the regulations of the registration and certification authority of the Federal Network Agency, Unit IS16, (TKÜV CA) for participation in the Virtual Private Network (TKÜV VPN), the data that the subnet operators must provide for management of the public key infrastructure (TKÜV PKI) and a description of the overall process. These provisions are binding on both the authorised agencies participating in the procedure and the obligated parties as per § 170 and/or § 174 TKG, as subnet operators of the VPN. 1.2 Identity of registration and certification authority TKÜV CA Address: Federal Network Agency Unit IS16 Canisiusstraße 21 D-55122 Mainz Germany email: [email protected] Note on emailing: When sending confidential data (such as a VPN participation application) by email, use PGP encryption software. 1.3 General information services of the TKÜV CA The Federal Network Agency website, www.bundesnetzagentur.de/tku, provides further information and guidelines on the TKÜV CA. 1.4 Validity of this document This document is edition 3.1 and is valid for operation of the TKÜV VPN until rescinded or until a new edition is published. The general information services of the TKÜV CA will publish information on the validity of this document on the website mentioned above. 2. Services of the TKÜV CA 2.1 Certificate generation, Crypto-box configuration, CA management The TKÜV CA generates and manages the certificates for participation in the TKÜV VPN, to enable secure transmission between obligated parties and authorised agencies. For this, it registers the participants, generates the cryptographic keys needed for system authentication for each participant and certifies these with its own CA key. The certificates generated in this way are stored on smart cards, provided by the relevant TKÜV CA participants. Crypto-boxes are hardware that initially lack configuration and thus also a function. To enable participation in the VPN, the TKÜV CA generates Crypto-box configurations and provides them to participants using smart cards and over an LDAP server. The Crypto-box loads the configuration information into the internal memory to obtain the necessary operating information. TR TKÜV, edition 8.1 (draft) Part X, Annex X.3, page 116 The TKÜV CA also creates and maintains the access control list (ACL) based on the details provided by the participants, and makes this list available for use by the Crypto-boxes over an LDAP directory service. To administer any local routers, the required IP addresses of the ACL are made available on request to the subnet operators. To verify the security relationships or the Crypto-box configurations used, the TKÜV CA operates a test station, which is available, bearing in mind the normal risk of failures. The system does not allow the Federal Network Agency to test the security relationships between the obligated parties and authorised agencies. 2.2 Security of the CA equipment All technical equipment of the TKÜV CA that is required to operate the TKÜV VPN is located in special access-controlled spaces. Dedicated computers are used for the administration of TKÜV CA services; communication of the Crypto-boxes operated in the VPN with the directory service and the associated centralised management system is itself protected by a cryptographic procedure. Certificate creation and ACL processing follow the ‘four eyes’ principle. The system manufacturers provide support for operation of the equipment of the TKÜV CA. These contractual agreements do not cover the systems used by the authorised agencies or the obligated parties. 3. Requirements on participants TKÜV VPN participants within the meaning of this policy are the authorised agencies and the obligated parties, with their relevant subnets. For the TKÜV CA, each participant designates one CA manager and possibly also a deputy, who serve as contacts for the relevant subnets and are responsible for security in particular. In urgent cases, the CA managers receive the required information from the CA administrator by phone, email or post. It is necessary to ensure prompt queries for these messages. The following requirements apply to CA managers and their deputies:  They must handle the smart cards prepared by the TKÜV CA with due care to prevent misuse by unauthorised persons, and may only provide them to persons entrusted with operation and administration of the relevant Crypto-boxes.  On request, such as in the case of subsequent detection of security flaws, they must return the smart cards for deletion of the content data from the TKÜV CA.  If it is necessary to block a Crypto-box configuration (e.g. shutdown, loss of the smart card, misuse), they must report this the TKÜV CA immediately so it can take the necessary follow-up steps.  Otherwise, the requirements of the TKÜV apply, in particular § 15 TKÜV (confidentiality). 4. Registration rules For registration, the TKÜV CA website provides instructions and a form for registration and the IP configuration of the Crypto-boxes (VPN participation application). 4.1 Registration of authorised agencies Due to unique identification of the authorised agency, a personal identity check for the CA manager is not required. A CA manager designated by the authorised agency must request registration and a smart card from the TKÜV CA by email and in writing, indicating all the necessary details. The TKÜV CA must be notified immediately (VPN participation application) in the event of a new appointment, change or dismissal of the person serving as CA manager or representative; these changes do not require replacement of the smart card. 4.2 Registration of obligated parties For the obligated parties, registration of the CA managers and deputies must include at least a personal identity check based on submission of a valid identity card or passport. TR TKÜV, edition 8.1 (draft) Part X, Annex X.3, page 117 For designating CA managers and deputies, the Management of the undertaking should give preference to the persons responsible for the availability of the surveillance equipment as per § 19 TKÜV or persons with administrative duties. The CA manager must request registration and a smart card from the TKÜV CA by email and in writing (VPN participation application), indicating all the necessary details on the persons being registered. The TKÜV CA performs the registration. Replacement of a registered person of the obligated party requires a new registration. Dismissal of a registered person or a change in the name of the obligated party must be reported to the TKÜV CA immediately (VPN participation application); these changes do not require replacement of the smart card. 5. Certification rules The TKÜV CA only issues certificates for the entire TKÜV VPN process. The TKÜV CA website provides instructions and forms for certification. Certificates have a maximum period of validity of 4 years; the user certificate issued is linked to a single smart card. 5.1 Data to be provided For certification (VPN participation application), participants provide the basic data for generation of the X.509 certificates and creation/expansion of the ACL in the directory service. The TKÜV CA makes the subsequent specifications independently. The submitted details are stored securely. The TKÜV CA defines the name scheme. Due to the closed VPN, it is not necessary to observe other naming conventions. A. Data for the X.509 certificates (Specification by the TKÜV CA) The X.509v3 certificates used in the procedure link the identity of the participant in the TKÜV PKI in the form of an X.500 Distinguished Name (DN) and a public key, authenticated by the digital signature of the TKÜV CA. The DN is linked as a subject in the certificate with the public key. The table below gives the format. Table: Format of the X.500 Distinguished Name (DN) Field Meaning Value C Country DE SP State or province name . 1) L Locality name . 1) O Organisation name regtp_sina OU Organisational unit name Further subdivision if necessary (in addition to CN) CN Common name Name of the authorised agency or obligated party (e.g. ‘LKA_Stuttgart_1’) email email address of the identity To simplify the administration of names (derived automatically from the data in the form: CN@[OU].O.C) 1) If ‘.’ is entered, the field remains blank. The Distinguished Name corresponds to the user name that is used in the Crypto-box configuration and can be retrieved on the Crypto-box display. Example: C: DE, O: regtp_sina, CN: LKA_Stuttgart_1,  LKA_Stuttgart_1@regtp_sina.de TR TKÜV, edition 8.1 (draft) Part X, Annex X.3, page 118 Table: Format of the X.509v3 certificate Field Meaning Value version Version of the X.509 certificate 3 serial number Unique number for each certificate Sequential number signature Signature algorithm used issuer Distinguished Name of the TKÜV CA See above. validity Period of validity subject Name Distinguished Name of the authorised agency or obligated party subject PublicKeyInfo Public key of the owner (subject Name) unique Identifiers Not used Extensions rfc5322Name Mapping of the DN to an email address Used for IPSec; automatic B. Data to create/expand the ACL (Specification by the TKÜV CA based on general information from participants) The access control list (ACL) contains all valid security relationships of the participants, and is managed exclusively by the TKÜV CA. After commissioning or restarting the Crypto-box with the smart card issued by the TKÜV CA, the Crypto-box automatically sets up a connection with the directory service and loads the current ACL. The provided ACL is always signed by the TKÜV CA; the Crypto-boxes will not accept unsigned ACLs. After this, the system is ready for operation. The data needed to create and expand the ACL pertain to the certificate issued and the unique IP addresses used to address the application (IP endpoint) behind the Crypto-box (IP WAN and IP local), to be provided by the participants. For IP address assignment, the subnet operators receive a guideline with an example configuration (VPN participation application, chart). Subnet operators are responsible for the accuracy of their data; the Federal Network Agency can only conduct a simple plausibility check. Table: Public IP addresses needed for unique addressing Field Meaning Value IP-Router-WAN Internal IP address of the (default) Internet-facing Required router IP-Crypto-WAN IP address/subnet mask of the Internet-facing Crypto- Required (WAN Crypto IP) box IP-Crypto-Local IP address/subnet mask of the internal network-facing Required (Local Crypto IP) Crypto-box IP-Router-Local IP address of the internal router used to connect more Optional (depends on (Local router IP) subnets to the box network structure) IP-Anwendung IP address(es) of the systems provided to implement Required 1) (Application IP) the legal measures IP-Logserver IP address of a dedicated log server for receiving Required 1) (Log server IP) operation and audit logs 1) Private IP addresses can be used for the connection; these must be connected by means of network address translation (NAT) to the public IP address of the Crypto-box [IP-Krypto-Lokal]. The NAT, in turn, must of course receive a unique IP address for the Crypto-box. TR TKÜV, edition 8.1 (draft) Part X, Annex X.3, page 119 5.2 Instructions  Inalterability of the Crypto-box connection to the Internet The exact Crypto-box connection to the Internet (IP configuration) as the participant side of the security relationship with the management system and the LDAP Server of the TKÜV CA and with a dedicated IP log server is persistently stored on the smart card with the Auto-Init option, to enable ACL download and error reporting on Crypto-box startup. In case of changes, the application procedure (VPN participation application) requires issue of a new smart card. Changes to telecommunications surveillance equipment (IP application, application) that do not affect the IP configuration do not require the issue of a new smart card.  Only enable defined hosts (applications) behind the Crypto-box In addition to the security relationships between the Crypto-box and the management system and LDAP server of the TKÜV CA and the dedicated IP log server, only explicitly permitted hosts (applications) are allowed as security relationships within the ACL, which are entered in the Crypto-box configuration; it is possible to enable an entire subnet. However, the TKÜV CA reserves the right to limit the number of individual security relationships and/or the size of the subnet, at its sole discretion. Security relationships between the hosts of the obligated parties and those of the authorised agencies are always reciprocal.  Use of routers, packet filters, firewalls, etc. When using routers or network elements with packet filter or firewall functions on the internal side between Crypto-box and host on the subnets, ensure that their administration does not cause any delays or obstacles when carrying out orders. It is necessary to indicate any network elements of this kind that are relevant to the IP configuration.  Provision of partner IP addresses To enable administration of any network elements for routing, the TKÜV CA provides lists of the required IP addresses on an FTP server operated by the TKÜV CA and protected by a Crypto- box. Subnet operators receive access rights on request; the relevant subnet operator is responsible for retrieval and use of these lists. The contents of the lists must be treated confidentially. 5.3 Test of the security relationships and the Crypto-box configuration used After commissioning the subnet, it is necessary use the TKÜV CA test facility to conduct a test for the authorised agencies and the obligated parties, to ensure proper functioning. This test verifies the functioning of the IP configuration, as well as the security relationships established for the management and test systems; this is conducted on the side of the obligated parties before the technical functional compliance test on the telecommunications surveillance equipment. The system does not allow the Federal Network Agency to test the security relationships between the obligated parties and authorised agencies. 5.4 Data sheet for unique addressing of subnets For participation in the VPN and associated use of Crypto-boxes in the subnets of the obligated parties and the authorised agencies, it is necessary to demonstrate the method of compliance with the requirement for unique addressing of the relevant subnet. In addition, it is necessary to report the IP addresses needed for the procedure to the TKÜV CA. To support participants in their planning, a data sheet has been developed, and is available from the information services. Due to the variety of possible technical solutions, the completeness of the data sheet cannot be guaranteed. TR TKÜV, edition 8.1 (draft) Part X, Annex X.3, page 120 5.5 Example layout Log server IP Network Log admin. server In-house network Internet WAN Local Crypto-box Firewall router router Application IP WAN Router IP WAN Crypto IP Local router IP Local Crypto IP Diagram 1. Example of a subnet with unique IP addresses The VPN participation application contains another example. 6. Blocking a Crypto-box configuration To block a Crypto-box configuration, make a corresponding entry in a blacklist, which is transmitted to all participating Crypto-boxes or retrieved when they restart. Entry on the blacklist excludes a Crypto-box configuration and associated certificates and smart cards from participating in the VPN. It may be necessary to block a Crypto-box configuration in cases such as:  loss or compromise of a smart card;  invalid data on the certificate (change of IP configuration, cessation of operations);  misuse, or failure to meet the TKÜV CA specifications;  other circumstances that require temporary blocking of the Crypto-box configuration. As a general rule, Crypto-box configuration blocking occurs after consultation with the VPN participant. Where justified however, a block may also be applied immediately. In any case, VPN participants must report any possible grounds for blocking immediately. Depending on the grounds for blocking, it is also possible to remove a Crypto-box configuration from the blacklist, for reuse in normal operation. 7. Distribution and handling of smart cards For the configuration and authentication data, smart cards are used to store information on the user and the Crypto-box configuration. The VPN participant must enclose the correct number of blank cards with the VPN participation application. It is generally recommended to have an identical replacement card produced for each Crypto- box. The TKÜV CA issues smart cards in person or by post to the designated persons (registered persons) of the relevant VPN participant. Smart cards are standardly protected by a PIN/PUK combination. The TKÜV CA sets the PIN to a value, and the Crypto-box boots into its operational mode after power-up without prompting for the PIN. It is in fact possible to overwrite the PIN using the Crypto-box keyboard; however, any PIN other than the registered PIN will require manual entry on the Crypto-box with each system reboot (off/on). Therefore, the PIN should not be changed! TR TKÜV, edition 8.1 (draft) Part X, Annex X.3, page 121 8. Card content On delivery from the TKÜV CA, the smart card stores the values given in the table below. The special terms apply here:  Column T (as in tamper-proof): data with an 'X' in this column are stored on the smart card in a tamper-proof manner.  IP address keyword: ‘black side’ and ‘black network’ refer to the Internet-facing and thus insecure, encrypted side of the Crypto-box. ‘Red side’ and ‘red network’ refer the unencrypted area in the secure network. Keyword T Value/keyword CA public key X CA certificate X Certificate and public key of the certification authority Key pair of the user X Certificate, public and private key of the user Validity of the certificates X Encoded in the user certificate; 4 years Parameter sets for key Cryptographic parameters necessary for the calculation of temporary keys exchange between participants Security relationships A security relationship with the management system and the LDAP directory (necessary for initial ACL download after Crypto-box startup). These security relationships are generally stored persistently; this means that ACL entries cannot overwrite these relationships. Part of the security relationship is the cryptographic functions used (one-way function/encryption algorithm). PIN/PUK Security mechanism IP address of the Crypto- Interface name (ethX), IP address/subnet mask box (black side) IP address of the WAN IP address router (black side) IP address of the Crypto- Interface name (ethY), IP address/subnet mask box (red side) Enabled hosts IP addresses of the enabled hosts IP address of the Syslog IP address of the dedicated Syslog server server(s) IP address of the NTP The TKÜV CA operates its own NTP server, whose IP address is entered; it is server(s) also permitted however to use a dedicated NTP server. Time limit Time interval for querying the NTP server IP address of the hot Only if used: interface name (ethZ), IP address/subnet mask standby interface The menu system of the card reader integrated into the Crypto-box can be used to read various operating settings and change some of them (PIN, time); please see the Crypto-box manual for further details. Examples: Keyword Value/keyword IP configuration, ‘black side’  Interface name (ethX)  IP address/subnet mask IP configuration, ‘red side’  Interface name (ethY)  IP address/subnet mask LDAP server  IP address Syslog server  IP address NTP server  IP address Identities  username = Distinguished Name Versions  ACL version  Number of policies Show/set time  Display/edit the date and time  TR TKÜV, edition 8.1 (draft) Part X, Annex X.3, page 122 9. Management of Crypto-box configurations/selected options 9.1 Architecture of management system and test equipment at the Federal Network Agency The architecture of the overall management system at the TKÜV CA for the Crypto-boxes used in the subnets is divided into two subsystems:  A management station to administer Crypto-box configurations, set up security relationships and create smart cards  A server for the directory service (LDAP) and a general database Both subsystems are connected to the Internet through Crypto-boxes. The overall management system is duplicated for redundancy. For each Crypto-box configuration of the subnets of the authorised agencies and the obligated parties, the smart card must have a hard-coded security relationship from its Crypto-box (not that of the underlying hosts) to each management subsystem. The management system must contact the Crypto- boxes to enable an ACL update and the Crypto-boxes must contact the server to load the current ACL. The TKÜV CA creates all security relationships. Security relationships with the management subsystems must be hard-coded on the smart cards; the security relationships between the hosts of the obligated parties and those of the authorised agencies are entered in the ACL of the directory service, and the TKÜV CA then loads them into the Crypto-boxes automatically or manually. Obligated party Authorised agency Internet Technical equipment Analysis for transmission equipment ‘Management access II’ ‘Management access I’ ‘Test access’ Secondary LDAP and Primary Crypto-box database LDAP and Test stations PKI management database Reference system Structure of the PKI and the test station/reference system at the Federal Network Agency Diagram 2. Architecture of the management system and test equipment at the Federal Network Agency The test equipment (reference system) of the Federal Network Agency is used for functional testing as per § 170 and/or § 174 TKG as well as on the Crypto-box configurations of the authorised agencies and the obligated parties after Crypto-box commissioning. The system does not allow the Federal Network Agency to perform functional testing of the connections that the ACL defines between obligated parties and authorised agencies. However, participants do have this option as per § 23 TKÜV. TR TKÜV, edition 8.1 (draft) Part X, Annex X.3, page 123 10. Selected options/values The management system allows various options for configuration of the Crypto-boxes and security relationships, which must be selected before issue of the smart cards. The sections below describe these options. 10.1 Log server Because each subnet operator is individually responsible for Crypto-box planning, operation, maintenance and troubleshooting, they must each operate their own log server. The Federal Network Agency does not provide log servers for participants, nor does it receive access to the participant-side log servers. The Crypto-boxes used lack local mass storage devices, such as hard drives or SD cards. Therefore, they cannot store event logs locally. However, because these are necessary for monitoring the Crypto- boxes and the network, log servers must be set up. The smart card persistently stores the IP address of the log server and the connection between the Crypto-box and the associated log server. In general, the UDP protocol with port 514 is used. It is possible to set up multiple Syslog servers per Crypto-box, in which case the log data go to all log servers. 10.2 Heartbeat In addition to the log server, it is possible to set a time interval at the Crypto-box sends a message to the log server(s) to indicate that it is running, even when no other activities require logging. This information is used to keep track of certain system states, such as interface statistics, uptime, etc. If a value is not entered, the system will not produce heartbeats. However, it will always log normal activities, regardless of this setting. The heartbeat setting applies to all indicated log servers. As part of the application procedure ( VPN participation application, options sheet), subnet operators may indicate how to apply this function. 10.3 NTP server The NTP server provides the time service within the PKI. The Crypto-box uses the time (and date) retrieved from this server to determine whether a certificate is still valid. If a box does not yet have access to an NTP server (this connection must be set up first), it uses the local time given by the system clock for verification. After successful connection to an NTP server, the Crypto-box also synchronises its clock to the server time. The Federal Network Agency provides an NTP server exclusively for Crypto-boxes by means of its management system; the smart card persistently stores the required security relationships. The reference time is UTC, from the official time of the Federal Republic of Germany. As an option, participants may enter their own NTP servers. It is possible to set up multiple NTP servers per Crypto-box. In this case, they are queried in the order stored on the smart card. Querying an NTP creates a Syslog entry. 10.4 Provision of partner subnet IP addresses To enable administration of any network elements for routing/filtering, the TKÜV CA provides a list of the required IP addresses on its own FTP server protected by a Crypto-box. Subnet operators receive access rights on request; the subnet operator is responsible for retrieving this list. The list is only updated as needed. 10.5 Hot standby (HSB) In hot standby mode, two Crypto-boxes are installed as a cluster. One device is active (master or Sys1), whereas the second (slave or Sys2) takes over in the event of failure of the first device. This mode of operation requires specially prepared smart cards. TR TKÜV, edition 8.1 (draft) Part X, Annex X.3, page 124 10.6 Crypto-box software version At present, the only Crypto-boxes used are SINA Boxes by manufacturer Secunet. Only version 3.7.4.3 or newer is permitted for SINA Box operating software. 10.7 Smart cards Only Starcos smart cards version 3.5 with the BSI patch ECGDSA are currently permitted. 11. Other applicable documents Other applicable documents, in their latest applicable versions, are:  Telecommunications Act [TKG]  Telecommunications Surveillance Ordinance [TKÜV]  Technical Guideline implementing legal measures for telecommunications surveillance, information provision and cooperation in technical identification measures for mobile terminals [TR TKÜV]  VPN participation application TR TKÜV, edition 8.1 (draft) Part X, Annex X.4, page 125 Annex X.4 Sample draft for preparation of the documentary evidence, test protocols and test reports The Federal Network Agency provides the following documents for the preparation of the documents as per § 19(2) and § 34(1) TKÜV as well as for verification of the organisational arrangements as per § 17(4) and the seventh sentence of § 35 TKÜV: Concept templates As per § 19(2) TKÜV, the Federal Network Agency may set requirements on the documents (concept) to be submitted by the obligated party. It does this by providing service-specific concept templates for the topics listed in § 19(2) TKÜV. This is intended to help the obligated parties submit the necessary documents for review. For instance, the concept templates may cover organisational arrangements (such as general manager, business hours, contacts, contact persons) or technical descriptions (such as explanation of telecommunications services and performance features to support analysis, description of the telecommunications system, surveillance equipment or information provision systems). A concept template for each of the different services is available on the website at www.bundesnetzagentur.de/TKU . The obligated system operator must use the concept template to prepare the documentary evidence (concept) to be submitted. Test protocols and test reports The Federal Network Agency uses test protocols or test reports to verify the technical and organisational arrangements as per § 170(1)(4) TKÜV and conduct the inspection as per § 17(4) and the seventh sentence of § 35 TKÜV. To prepare the obligated undertakings for the verification to be conducted and for the requirements arising from the TKÜV and TR TKÜV, the Federal Network Agency provides the documents on request or prior to the verification. TR TKÜV, edition 8.1 (draft) Part X, continuation, page 126 Updates The procedure for updating the TR TKÜV is based on the provisions of § 170(6) TKG, which state that the Federal Network Agency determines the necessary details with the participation of associations representing the obligated parties, the authorised agencies and the manufacturers of the surveillance, recording and analysis equipment. Fundamental changes to this Guideline will be indicated by a new edition number before the decimal point. Changes and additions to parts of the TR TKÜV that were described in a previous edition are indicated by a new version number after the decimal point. In both cases, the Federal Gazette and the Official Journal of the Federal Network Agency will announce new versions of the TR TKÜV. TR TKÜV, edition 8.1 (draft) Part X, expenditure summary, page 127 Edition list Edition Date Reason for change 1.0 December 1995 First edition of the TR TKÜV 2.0 April 1997 Updated as announced in Dec. 95 2.1 March 1998 1. Requirements for voicemail systems and similar storage systems/inclusion of additional variant for IRI transmission 2. Time basis for time indications in the records 3. Editorial corrections 2.2 December 2000 Corrections to edition 2.1 1. Updates to Annex 1 2. Annex 3 Designation of unused digits by either hex ‘F’ or ‘odd/even’ indicator and hex ‘0’ according to TABLE 4-10/Q.931 3. Updates to Annex 6 3.1 Transmission method ‘Eurofile’ and ‘subaddress’ for IRI deleted. 3.2 Transmission to active fax devices at authorised agencies (support for procedures as per ITU-T T.30 and use of the BC ‘audio’ and HLC ‘Facsimile’) 3.0 November 2001 Inclusion of national requirements for implementation of ETSI Standard ES 201 671 V2.1.1 in Germany as Annex 7 3.1 May 2002 Editorial adjustments to the Technical Guideline for the TKÜV, change of abbreviation to the TR TKÜ 4.0 April 2003 1. Technical requirements in Section 5.2.3 for packet-switched, non-IP-based networks deleted. 2. Flexible application of the FTAM and FTP transmission protocols, associated requirements for file names in Annex 1 3. Inclusion of requirements for secure transmission of telecommunications under surveillance over IP networks using IPSec as Appendix 4 to Annex 7 4. Requirements on bundling of IRI in cases of implementation as per Annex 7 5. Inclusion of national requirements on implementation of 3GPP Specification TS 33.108 in Germany as Annex 8 6. Inclusion of national requirements on email surveillance as Annex 9 4.1 November 2004 1. Note on notification on title page 2. References to coordination with international committees in Annexes 7 and 8 deleted. 3. New version 4 of the ASN.1 module with the national parameters (Annex 7, Appendix 3) 4. Indication of the port number for TCP in Annex 7, point F.3.1.3 5. In Table 1/A.5, value for maximum file length increased to 25. 6. In Annex 1, a reference to the IRI transmission option as per TS 102 232 included. 7. In Annex 5, specifications added for the main parameters when using FTP. 8. In Annex 7, Appendix 2, reference added to the option to transmit the HI1 notifications. 9. National parameters added as an integral component of the HI2 module in Annex 7, Appendix 2. 10. Log file processing further specified in Annex 7, Appendix 4. 11. Annex 9, inclusion of requirements based on ETSI Standard TS 102 233 TR TKÜV, edition 8.1 (draft) Part X, expenditure summary, page 128 12. Annex 10, inclusion of requirements on IP-based transmission based on ETSI Standard TS 102 232 5.0 December 2006 1. Restructuring of the TR TKÜ 2. New provisions as per the (former) sixth sentence of § 11 TKÜV (identifiers for surveillance) 3. Detailed provisions on Internet gateways based on ETSI specifications 4. Adjustments for unified messaging systems and email 5. New provision on transmission of SMS messages according to the national variant (Annex B) 6. Other editorial corrections 5.1 February 2008 1. Requirements on VoIP and other multimedia services based on the SIP, RTP or H.323 and H.248 protocols or the IPCablecom architecture and for emulated PSTN/ISDN services 2. Adjustments for email by including all protocols in ETSI Specification TS 102 232-2 3. For Internet gateways, specification of services distributed through them, such as IP TV and video on demand. 4. Adjustments for requirements in case of failed transmission of the surveillance copy to the receiving equipment of the authorised agency 5. Inclusion of the CGI field as an additional required field for coordinates as per Annex B 5. Other editorial corrections 6.0 December 2009 1. Restructuring/renaming 2. Expansion with an optional handover interface for provision of information on traffic data as per ETSI Specification TS 102 657 3. Optional electronic transmission of orders 4. Other editorial corrections 5. Copy of the new policy, version 1.4 for the TKÜV CA 6. Process description to ensure unique reference numbers for TCI measures 6.1 January 2012 1. Adjustments to standard values, Section 3.2 2. Expansions of possible identifiers for Internet gateway surveillance, Section 4.1 3. Inclusion of a procedure description as per § 23(1)(3) TKÜV 4. Clarification of FTP transmission procedures, Annex A.1.2.2 5. New version of the national ASN.1 module ‘Natparas’, Annex A.3.2 6. Value of calling party subaddress for international exchange surveillance, Annex B.3 7. Loosening of requirements on the use of the COLP check, Annexes B.1, C.1 and D.1 8. Specification of ULICv1 for packet-switched in mobile telephony, Annexes C.1 and D.1 9. Adjustments for email, Annex F 10. Clarification of correlation of different SIP messages to IRI events and use of IP source/destination addresses, Annexes H.3.2, H.3.3 and H.3.4 11. Additions to the table of usable ASN.1 modules, Annex X.4 12. Uniform requirement on the use of timestamps 6.2 August 2012 1. Recasting and merging of the provisions of previous Parts B and C into a new Part B, to reflect refinement of the new interfaces introduced previously in edition 6.0 TR TKÜV, edition 8.1 (draft) Part X, expenditure summary, page 129 2. Adjustment to Annex X.4 6.3 6 April 2016 1. Editorial revision of the entire document 2. Annex A: addition of point 3.3 (Data losses) 3. Annex A: further clarification of WLAN (point 4.1) 4. Annex B: indication of end of use of transmission as per Annex B 5. Annex C: indication of end of use of transmission as per Annex C 6. Annex C: restriction of validity to ISDN/PSTN (mobile telephony no longer included) 7. Annex D: addition for location information 8. Annex D: explanations for: packet direction, IP addresses and ports (table) 9. Annex F.3.1.1: explanations for: network element identifier, payload direction (tables) 10. Annex G.1.1: explanations for: network element identifier, payload direction (tables) 11. Annex H: explanation of mid-session interception (H.1.2), obligation for typically complete transmission of telecommunications (H.1.4) 12. Annex H.3.1: Annex G.1.1: explanations for: network element identifier, payload direction, keep-alives and IP addresses (tables) 13. Annex X.3: adjustment to policy 14. Part B: adjustment for the current legal basis 15. Part B: further development of underlying ETSI specification 16. Part B: selective subscriber data queries 17. Part B: standardisation/harmonisation of network operator responses for BDA and VDA 18. Part B: flexible use of free text fields 19. Part B: addition of national modules with regard to text form requirement and introduction of versioning 7.0 14 June 2017 1. Editorial revision of the entire document 2. Part A, Annex A: further clarification of WLAN (point 4.1) 3. Part A, Annex D.1 (Table C.1.1): specification of port number 4. Part A, Annex F.3.1.1 (Table 5.2.4): additional reference to ‘Communication identifier’ 5. Part A, Annex F.3.1.1 (Table 5.2.6): new specification for ‘Payload timestamp’ 6. Part A, Annex F.3.1.1 (Table 5.2.11): new specification for ‘Interception Point identifier’ 7. Part A, Annex G.1.1 (Table 5.2.4): additional reference to ‘Communication identifier’ 8. Part A, Annex G.1.1 (Table 5.2.6): new specification for ‘Payload timestamp’ 9. Part A, Annex G.1.1 (Table 5.2.11): new specification for ‘Interception Point identifier’ 10. Part A, Annex H.1.2: additional information on activating an interception measure with existing telecommunications link 11. Part A, Annex H.3.1 (Table 5.2.4): additional reference to ‘Communication identifier’ 12. Part A, Annex H.3.1 (Table 5.2.6): new specification for ‘Payload timestamp’ 13. Part A, Annex H.3.1 (Table): reference to encoding information 14. Part A, Annex H.3.1 (Table 5.2.11): new specification for ‘Interception Point identifier’ TR TKÜV, edition 8.1 (draft) Part X, expenditure summary, page 130 15. Part A, Annex H.3.2 (Table 5.4): additional references to ‘Events and IRI record types’ 16. Part B: adjustments to ‘1. Basic information’ 17. Part B: new specifications for transmission procedures 18. Part B: specifications for assurance of data security and data quality 19. Part B, Annex A: clarification of various usage procedures, real-time traffic data, cancel messages, radio cell queries, urgent orders 20. Part B, Annex A: inclusion of versioning, late record, targeted call search, flagging of records 21. Part B, Annex B: specifications for new ‘Email-ESB’ transmission procedure 22. Part X, Annex X.3: adjustment to policy 7.1 11 June 2018 1. Editorial revision of the entire document 2. Deletion of Annex B (Part A) due to removal of X.25/X.31 3. Notes on IP addresses and encodings, no acceptance of control options, request for encryption (requirements from the new TKÜV; various Annexes in Part A) 4. Note on TCI activation (various Annexes in Part A) 5. Use of relevant standards for mobile telecommunications transmission, exceptions for IMEI surveillance, Annex D (Part A), as well as note in Annex X.1.1 6. Adjustments to Part B, Annex 1: use of newer versions/use of legal bases (Chapter 1.2), late records (Chapter 1.3.1.1), real-time retrieval (Chapter 1.3.2), time until availability (Chapter 1.3.3.2; 3.3), premature deactivation of a warrant (Chapter 1.3.1.4), rejected targets (Chapter 1.3.1.4), radio cell structure of foreign mobile lines (Chapter 3.2.2.5) 9. Note on future protection requirements and requirements for 5G (Annexes X.1.2 and X.1.3) 10. Note on test protocol and concept template (Annex X.5) 7.2 23 November 1. Editorial revision of the notes on MTU size (Part A, Chapter 3.3.2), on 2020 identifiers for implementation of interception measures on the Internet gateway (Part A, Chapter 4.1) and on the transmission of FTP files (Part A, Annex F.1) 2. Part A, Annex I: inclusion of specifications for messaging services 3. Part B: adjusted specifications for warrant request (Chapters 1.3.x, 3.2.2.2) 4. Part B: expansion of retrieval for positioning of mobile terminals to include all types of location indications and to prevent danger to life, limb, health or freedom of a person (Chapters 1.3.5, 3.2.2.5) 5. Part B: expanded indications for traffic data requests (1.3.5, 3.2.2.3) 6. Part X, Annex X.3: update to policy 7. Part X, Annex X.5: editorial revision 8.0 26 January 2022 Formal changes to the references to the individual obligations as per §§ 170 et seq TKG, due to entry into force of the amended TKG and the correspondingly updated TKÜV on 1 December 2021 8.1 dd.mm.yyyy 1. Part A: expansions to the requirements of Annex I for all number- independent interpersonal telecommunications services other than email services, inclusion of protection requirements and technical details for the storage of order data, additions to the specifications on an alternative procedure for protection of the IP-based handover interface based on HTTPS/TLS, substantive and editorial adjustments to Annexes C to I. 2. Part B: clarifications on the use of ETSI-ESB and Email-ESB, clarification on positioning, expansion of the approved file formats to include PDF, reduction of the individual legal bases within Natparas2 to the free text field, editorial adjustments TR TKÜV, edition 8.1 (draft) Part X, expenditure summary, page 131 3. Part C: inclusion of initial requirements for the technical implementation of legal measures to include cooperation in technical identification measures for mobile terminals. Maret Ots Saatja: Karl Stern <[email protected]> Saatmisaeg: kolmapäev, 16. november 2022 15:11 Adressaat: Mart Laas; Maret Ots Teema: teatis Manused: 2022674D.docx Tere Saadan Saksamaa teatise 674 „Tehniline suunis telekommunikatsiooni järelevalve ja teabe avalikustamise õiguslike meetmete rakendamise kohta (TR TKÜV), versioon 8.1“. Ooteaeg lõpeb 9.01. Teema. Tehnilised vahendid telekommunikatsiooni järelevalve ja teabe avalikustamise meetmete rakendamiseks vastavalt Saksamaa seadustele. Tutvustus. TR TKÜV versioon 8.1 erineb eelmisest versioonist 8.0 selles osas, et on lisatud sätted koostöö kohta mobiilsideterminalide tehniliste identifitseerimismeetmete osas, kaitsenõuded ja tehnilised kirjeldused tellimuste andmete säilitamise kohta, sätted allkirjastatud dokumentide edastamise kohta ja muudatused, mis tulenevad ISDN- põhise edastuspunkti katkestamisest. Lisaks tehti TR TKÜV teistes osades sisulisi ja toimetuslikke kohandusi. Üksikasjad on loetletud tehnilise suunise lõpus tabelireal 8.1 „Kulude kokkuvõte“ (vt teavitamiseks esitatud tehnilise suunise viimast lehekülge, lk 136). Põhjendus. Tehnilise suunise kohandamine on vajalik selleks, et anda käitajatele ja eelkõige tehniliste vahendite tootjatele ja arendajatele üksikasjalikud spetsifikatsioonid, mis on vastavate ETSI ja 3GPP standardite rakendamisel ja täiendamisel kohustuslikud seadmete tehniliseks projekteerimiseks seadusega reguleeritud valdkondades: a) telekommunikatsiooni järelevalve meetmed, b) mobiilsideterminalidega seotud tehniliste uurimismeetmete alane koostöö ja c) teabe esitamine inventari ja liiklusandmete kohta ning mis on hädavajalikud nende rajatiste ning õiguskaitse- ja julgeolekuasutuste omavaheliseks suhtlemiseks. Karl 1