View source for My ETSI TS 103 120 Notes

Find and download [https://www.etsi.org/ ETSI] standards [https://www.etsi.org/standards here] 

My notes on ETSI TS 103 120 document titled '''Lawful Interception (LI); Interface for warrant information'''.

== 103 120 Scope ==

ETSI TS 103 120 document defines an electronic interface between two systems for the exchange of information relating to the establishment and management of lawful required action, typically Lawful Interception. Typically this interface
would be used between: on one side, a Communications Service Provider; and, on the other side, a Government or Law Enforcement Agency who is entitled to request a lawful action.

The ETSI reference model for LI (ETSI TS 102 232-1) defines three interfaces between law enforcement and CSPs, called HI-1, HI-2 and HI-3. The protocol defined in 103 120 document is designed to provide a large part of the functionality for HI-1. It is not designed to be used for HI-2 (delivery of intercept related information) or HI-3 (delivery of communications content). The protocol designed in 103 120 document may also be used for interfaces which require structured exchange of information relating to the establishment and management of Lawful Interception. The general view is that the HI-1 concept can also be used for other legal actions than LI. For that reason the present
document could, besides LI, also be applied for retained data requests, seized data requests, data preservation orders and other similar legal requests

See specification for full details.

== Message Structure ==

See 6.1 overview for details.

Each message consists of two parts:
* Message Header
* Message Payload (Request | Response)

Request format:

Message > Header > Request Payload > Action Request (one to many) > (GET | CREATE | UPDATE | LIST) > (Object Identifier, Object)

Response format:

Message > Header > Response Payload > Action Response (one to many) > (GET | CREATE | UPDATE | LIST) Response > (Object Identifier, Object)

Top level container for all HI-1 message

Header contains routing and timestamp information - see clause6.2

Payloads contain multiple Actions (either Requests or Responses) - see clause 6.3

Each Action has a Verb such as GET or CREATE – either a request or a response, depending on the message. See clauses 6.4.5 through 6.4.8.

This generally contains an Object Identifier, which identifies the Object being acted on (see clause 7 and clause 8). Depending on the verb. It may also contain an Object.

There may be many Action Requests in a Request message. Each will generally act on a separate message.

In the response, there should be an Action Response for each Action Request (in the absence of errors)

== 8.3 LDTaskObject ==

=== 8.3.1 Overview ===

An Lawful Disclosure Task Object (LDTaskObject) represents the state of an LD Task - that is, the act of disclosing information. This corresponds to the WarrantTargetID and WarrantTechSpec elements defined in ETSI TR 103 690. In general, multiple tasks may be authorised by a single warrant.

The LDTaskObject consists of the following fields.

{| class="wikitable sortable"
|+ LDTaskObject
|-
! Field !! Format !! Description !! Reference
|-
| Reference||LDID (see ETSI TS 103 280) ||LDID assigned to the product of task. || Clause 8.3.2
|-
| Status|| LDTaskStatus Dictionary Entry.|| The current status of the task as determined by the Receiver.|| Clause 8.3.3
|-
| StatusReason || ActionUnsuccessful structure (see clause 6.4.9).|| Optional information for the Receiver to indicate why the Object is in a certain state (such as Invalid or Rejected). Usage for national agreement.|| Clause 6.4.9
|-
| DesiredStatus|| LDTaskDesiredStatus Dictionary Entry.|| The current status of the task as specified by the Sender.|| Clause 8.3.4
|-
|RequestDetails  ||LDRequestDetails (see clause 8.3.5). || Details regarding the content of the disclosure request, such as identifiers and dates.|| Clause 8.3.5
|-
| DeliveryDetails || List of LDDeliveryDestination structures (see clause 8.3.6).||Destination(s) for the disclosure product. || Clause 8.3.6
|-
| ApprovalDetails|| ApprovalDetails (see annex E).|| Details regarding the approval for this Task, including dates and signatures where appropriate.|| Clause 8.2.9
|-
|CSPID  ||EndpointID (see clause 6.2.4). || Describes the CSP required to implement the Task.|| Clause 8.2.10
|-
| HandlingProfile||LDHandlingProfile (see clause 8.2.11). || A dictionary entry which gives the name of a handling profile that represents a set of configuration information associated with this task.||Clause 8.2.11
|-
|Flags  ||LDTaskFlags (see clause 8.3.7). ||A set of flags associated with the Task Object. || Clause 8.3.7
|-
| NationalLDTaskingParameters || See annex G. ||See annex G. || Annex G
|}

=== 8.3.2 Reference ===

The Reference field gives a reference identifier for the Task, for correlation with other processes. For LD, this shall be set to the LDID that will be assigned to the product of the disclosure. Format will be as per ETSI TS 103 280.

=== 8.3.3 Status ===
The Status field gives the status of the LDTaskObject as determined by the Receiver. A Sender shall not attempt to set the Status as part of a CREATE or UPDATE Request, and a Receiver shall return an Action Unsuccessful Information Response if the Sender attempts to do so.

The Status field provides a key mechanism for mapping the content of the Object to the relevant nationally-defined processes. The rules for evaluating the correct value of the Status field shall be defined in the relevant national profile.

Given as a LDTaskStatus Dictionary Entry. The LDTaskStatus Dictionary is defined in table 8.16 (see annex F for more details on Dictionaries).

{| class="wikitable"
|+ LDTaskStatus Dictionary
|-
! Dictionary Owner !! Dictionary Name
|-
| ETSI || LDTaskStatus.
|}

{| class="wikitable sortable"
|+ Defined DictionaryEntries
|-
! Value !! Meaning
|-
| AwaitingApproval || he Task is still waiting approval from one or more relevant authorities.
|-
| AwaitingDisclosure || The Task is approved, but is not yet processed by the LD system.
|-
| Disclosed || The Task has been processed and the product has been disclosed by the LD system.
|-
| DisclosureNotAvailable || The Task has been processed and the CSP has determined there is no product available to disclosure.
|-
| Rejected || The Task has been explicitly denied or rejected by one or more relevant authorities.
|-
| Cancelled  ||The Task has been permanently cancelled.
|-
| Error || The Task has not been processed due to a problem with the underlying LD system.
|-
| Invalid || The Task has not been processed to a problem with the current information populated in the Task Object.
|}

=== 8.3.4 DesiredStatus ===
The DesiredStatus field gives the status of the LDTaskObject as determined by the Sender. Given as a LDTaskDesiredStatus Dictionary Entry. The LDTaskDesiredStatus Dictionary is defined in table 8.17 (see annex F for more details on Dictionaries).

{| class="wikitable"
|+ LDTaskDesiredStatus Dictionary
|-
! Dictionary Owner !! Dictionary Name
|-
| ETSI || LDTaskDesiredStatus.
|}

{| class="wikitable sortable"
|+ Defined DictionaryEntries
|-
! Value !! Meaning
|-
| AwaitingApproval || The Task is still waiting approval from one or more relevant authorities.
|-
| AwaitingDisclosure || The Task is approved, but is not yet processed by the LD system.
|-
| Disclosed || The Task has been processed and the product has been disclosed by the LD system.
|-
| Rejected || The Task has been explicitly denied or rejected by one or more relevant authorities.
|-
| Cancelled || The Task has been permanently cancelled.
|}

=== 8.3.5 RequestDetails ===

==== 8.3.5.1 Overview ====
The RequestDetails structure specifies the content of the disclosure request. It consists of the following fields.

{| class="wikitable sortable"
|+ LDRequestDetails
|-
! Field !! Format !! Description
|-
| Type || RequestType (see clause 8.3.5.2). || Specifies the products to be disclosed.
|-
| StartTime || QualifiedDateTime (see ETSI TS 103 280). || If a date/time range needs to be applied to the request, the StartTime and EndTime shall be provided.
|-
| EndTime || QualifiedDateTime (see ETSI TS 103 280). || If a date/time range needs to be applied to the request, the StartTime and EndTime shall be provided.
|-
| ObservedTime || QualifiedDateTime (see ETSI TS 103 280). || If an observed date/time needs to be applied to the request. This field may be used to indicate at which date/time a certain value was observed by the requestor.

If multiple observed dates/times need to be applied to the request, the ObservedTimes field shall be used instead of this field.
|-
| ObservedTimes || List of QualifiedDateTime (see ETSI TS 103 280). || If multiple observed dates/times all need to be applied to the request. This field may be used to indicate at which dates/times a certain value was observed by the requestor.

This field shall only be used if multiple dates/times need to be applied to the request.
|-
| RequestValues || List of RequestValue structures (see clause 8.3.5.3). || Specifies the value(s) used to define the disclosure request.
|}

==== 8.3.5.2 RequestType ====

Type of disclosure or disclosures to produce using the specified RequestDetails.

Given as a list of RequestType DictionaryEntries. The usage and meaning of the Request Type is likely to be closely coupled to national legislation, as will the permissible combinations of Request Values and Request Types. It is
therefore expected that most national profiles will need to define their own extensions to this dictionary.

{| class="wikitable"
|+ RequestType Dictionary
|-
! Dictionary Owner !! Dictionary Name
|-
| ETSI || RequestType
|}


As of document V1.11.2 (2022-05) no dictionary entries have been defined for this dictionary.

==== 8.3.5.3 RequestValues ====

The RequestValues field contains a list of RequestValue structures, which are combined (with ordering and Boolean ANDed together) to identify the requested disclosure. Each RequestValue structure contains the following fields.

{| class="wikitable"
|+ RequestValues
|-
! Field !! Format  !! Description
|-
| FormatType || As defined below. || Specifies a Request Value Format (see below) which defines the format for the Request Value fields. See annex C for the list of Request Value Formats defined by ETSI. Other definitions may be managed on a national basis.
|-
| Value || LongString (see ETSI TS 103 280). || Additional formatting information is given by the Request Value Format.
|}

The RequestValue Format ID and format descriptions are given in annex C.

The Receiver is responsible for checking that the format of the RequestValue matches the format defined for the Request Value Format Type. If any of the RequestValues are not correctly formatted, the Action should be rejected.

==== 8.3.5.4 FormatType ====

A RequestValue FormatType uniquely identifies a particular Request Value Format. It can be used to retrieve the correct RequestValue Format definition for a RequestValues structure. It consists of the following fields.

{| class="wikitable"
|+ RequestValue FormatType
|-
! Field !! Format !! Description
|-
| FormatOwner || ShortString (see ETSI TS 103 280). || Name of the Owner of the Format definition. See below.
|-
| FormatName || ShortString (see ETSI TS 103 280). ||  Uniquely identifies the format definition within the Owner.
|}


A Format owner is specified by a string value. The following owners are defined by the present document:
* "ETSI": The Format is owned by ETSI, and defined in the present document in annex C.
* A valid ISO 3166-1 alpha-2 country code: The Format is owned and defined by the relevant national authority for the country specified by the country code.

A Format definition shall contain, at a minimum, the following information.

{| class="wikitable sortable"
|+ RequestValue Format Definition
|-
! Field !! Format !! Description
|-
| FormatOwner || ShortString (see ETSI TS 103 280). || Identifies the Owner of the Format definition. See below.
|-
| FormatName || ShortString (see ETSI TS 103 280). || Identifies the format, unique within the Format Owner.
|-
| Description || LongString (see ETSI TS 103 280). || Human-readable description associated with the Format.
|-
| Format || IEEE POSIX® 1003.1 ERE Regular Expression. || Regular expression defining the permissible contents of the field. If absent, any UTF-8 string is permitted, subject to the length restriction of the field.
|}

See annex C for the list of Request Value Formats defined by ETSI. Other definitions may be managed on a national basis.

=== 8.3.6 DeliveryDetails ===

==== 8.3.6.1 Overview ====
The LDTaskDeliveryDetails field indicates where disclosed product should be delivered.

The LDTaskDeliveryDetails field consists of a list of LDDeliveryDestination structures. Each entry in the list represents a desired destination for product related to the Task.

Limits on the type, number or combinations of LDDeliveryDestination for a given type of Task shall be specified by the relevant national profile.

==== 8.3.6.2 LDDeliveryDestination ====

The LDDeliveryDestination structure contains the following fields.

{| class="wikitable sortable"
|+ LDDeliveryDestination
|-
! Field !! Format !! Description
|-
| DeliveryAddress || DeliveryAddress (see clause 8.2.8.3). || The address to which the product for this Task should be delivered.
|-
| EncryptionDetails || NationalEncryptionDetails. || Details regarding the encryption to be applied to product delivered to this destination. Shall be defined by the relevant national profile.
|-
| HandoverFormat || LDHandoverFormat DictionaryEntry (see clause 8.3.6.3). || Specifies the handover format to be used.
|-
| DeliveryProfile || LDDeliveryProfile DictionaryEntry. || A dictionary entry which gives the name of a delivery profile that represents a set of configuration information associated with the destination and delivery of the product from this Task.

If used, the dictionary shall be defined by the relevant national profile.
|-
| NationalDeliveryParameters || See annex G. || See annex G.
|}

==== 8.3.6.3 HandoverFormat ====

The LDHandoverFormat dictionary is defined in table 8.24 (see annex F for more details on Dictionaries).

{| class="wikitable"
|+ LDHandoverFormat Dictionary
|-
! Dictionary Owner !! Dictionary Name
|-
| ETSI || LDHandoverFormat.
|}

{| class="wikitable sortable"
|+ Defined DictionaryEntries
|-
! Value !! Meaning
|-
| TS102657 || Handed over in ETSI TS 102 657 format, using HI-B as described in ETSI TS 102 657.
|-
| EncapsulatedTS102657 || Handed over as ETSI TS 102 657 format, using the DeliveryObject as described in clause 10.
|-
| TS103120 || Handed over using the DeliveryObject as described in clause 10.
|-
| TS103707 || Handed over as ETSI TS 103 707 [24], using the DeliveryObject as described in clause 10.
|}


=== 8.3.7 Flags ===
The Flags field allows a set of multiple flags to be associated with the LDTaskObject. Each flag is given as a LDTaskFlag Dictionary Entry. If a flag is present in the Flags field, then the meaning given as part of that flag's definition shall be taken to apply.

The LDTaskFlag Dictionary is defined in table 8.25 (see annex F for more details on Dictionaries).

{| class="wikitable"
|+ LDTaskFlag Dictionary
|-
! Dictionary Owner !! Dictionary Name
|-
| ETSI || LDTaskFlag.
|}

{| class="wikitable sortable"
|+ Defined DictionaryEntries
|-
! Value !! Meaning
|-
| IsTest || Indicates that the current Task is for test purposes. This may alter the process or documentation accompanying the authorization.
|-
| IsEmergency || Indicates if the LD Task was issued under nationally-defined emergency procedures. The circumstances and consequences for setting the field shall be defined by the relevant national profile (see clause B.1.3).
|-
| IsNonLocal || Indicates that the current Task shall disclose information about a non-local identity.
|-
| IsLocal || Indicates that the current Task shall disclose information about a local identity. If both the IsNonLocal and IsLocal flag are absent, the identity provided within the Task shall be considered as a local identity unless otherwise agreed.
|} 

<center>[[My 33.128 Notes|To My 33.128 Notes]]</center>