Remarks:  - Section 11.2 Security Mechanisms, second last paragraph: It is true that the integrity of data can be achieved by using a hash function. This can also be achieved by using an other checksum mechanism like a CRC (Cyclic Redundancy Checksum). Such schemes (including the hash function approach) are not useful for achieving data integrity from a security point of view. The reason is, that everybody who knows the data integrity algorithm can generate the fingerprint of the data. Therefore an attacker can change the data, recalculate the data integrity checksum and send this new data to the recipient. The recipient can successfully verify the fingerprint although the data integrity - from a security point of view - is not given anymore. The text in the document is misleading and does not describe data integrity in a security point of view. If the data integrity checksum is used standalone and not protected by any other cryptographic means (e.g. if it is used as a Message Authentication Code) then a secret, which is only know by the sender and the recipient must be applied during the calculation of the fingerprint. A possible solution would be to use a hash function which requires a key to calculate the fingerprint of its input data. - Section 11.2 Security Mechanisms, last paragraph: The text does not describe very well the authentication mechanism based on public key cryptography. The text seems to describe a mixture of data encryption and data authentication. The public key of any user is normally not used in the authentication process. Everybody (user X or an attacker) can encrypt something with the public key of user Y. User Y has no possibilities to find out who encrypted this data. The operation in which the public key is used is normally called 'data encryption'. Data authentication is achieved when user X uses its own private key. Any user can verify the authenticity of the data by encrypting the data with the public key of user X. This process is normally called 'data signing/making a digital signature'.

Remarks:  Reviewed product Title : Handover Interface for the Lawful Interception of telecommunication traffic Legenda Code : ETSI ES 201 671 Categories (for detailed findings): Version : final draft v2.1.1 1 Inadmissible, adjustment required Date : 2000-07 2 Major, adjustment required : 3 Minor, textual imperfection Author(s) : ETSI TC Security WG Lawful Interception 4 Remark : Reviewers Rev. # Name Company/department Date Time Spend 1 Peter van der Arend KPN OVN 7 August 2001 General recommendation ES 201 671 is under ETSI Membership Voting. The only way to get modifications into ES 201 671 is to vote against the publication of the present final draft v2.1.1. There are no major objections against the specification, however the specification needs several modifications as indicated below and the specification contains several clauses that are not completed in this version of the specification. Detailed findings Comment reviewers Feedback author Nr. Paragraph Page Finding, comment and recommendation Cat. Rev. # Adapted No / version 1 2 11 Reference [53] shall be "void". TR 101 876 is not referenced and is similar to Annex F 3 2 6 19 "...are defined in the clauses below" Which clauses are involved ? Clauses 6.1 to 6.2.2 ? 3 3 6.2 20 The Communication Identity Number (CIN) is indicated as Optional. The CIN is mandatory for the IRI (as indicated in Clause 6.2.2). The indication "optional" has to be removed (see also next issue). 2 4 6.2.2 21 The Communication Identity Number (CIN) is indicated as "Optional". It is also stated that the CIN is mandatory for the IRI in specific cases. This is conflicting and confusing. The indication "optional" has to be removed. It could be added that the CIN is optional for inclusion of the CC (if that is the intention). 2 5 8 22 Last sentence of the 1st paragraph is indicating "e.g. if an other party is not available it need not to be requested.......". This example is not clear and can be removed from the text. 2 6 8.2 23 2) The IRI-END record is generated at the end of a communication or communication attempt. The present statement is only indication the communication attempt. 3) Same for the IRI-CONTINUE record. 2 7 8.2 23 The 3rd paragraph and 6th paragraph: "For some packet oriented data ...." is purely related to GPRS and has be removed to the Packet related Annex B. 3 8 A 27 "64 k based" must be "64 kbit/s based" 3 9 A.2 27 The statement for the HI1 interface port should be the same as in clause B.2: "No additions according to clause 7." 1 10 A.3.2.1 28 Table A.3.1 indicates the ASN.1 name of the "Version indication". Only "Version1" is indicated. It can also be "Version2’. 2 11 A.5.3 40 There is no underlining or any other indication in Table A.5.1 as indication for the served user as stated in the 1st paragraph. 3 12 A.7 49 The statement that this ES is not covering fixed network technologies suggests the impression that LI for the fixed network is not covered at all. However the whole ES including clauses A.1 to A.6 is covering LI of ISDN networks. Please add a text explaining the intention of this Clause. 1 13 B.1 53 If "in addition to clause 6 at present no Specific identifiers for Packet switched network are defined" then that could be stated, in stead of not covered. 2