4 Architectural features

32.3753GPPFile integrity solutionSecurity services for Integration Reference Point (IRP)Telecommunication managementTS

The overall architectural feature of Security Service is specified in 3GPP TS 32.372 [5]. This clause specifies features that are specific to the File integrity solution.

4.1 Principles of IRP Security Services

Figure 4.1 shows that Security Services are between IRP Application layer and Transport layer. Security Attributes which are attached to network management information are transferred between IRPManager and IRPAgent to address Authentication, Authorization, Activity Log and file integrity requirements.

Figure 4.1 : Principles of IRP Security Service

The basic idea of these Security Services is as follows:

  • IRP Security Services on IRPManager side and IRP Security Services on IRPAgent side co-operate to provide Security Services for IRP.
    This avoids modifying IRPManager and IRPAgent much.
  • When the IRPManager and/or IRPAgent send network management information to each other, the IRP Security Service (on IRPManager and/or IRPAgent side) attaches Security Attributes to the network management information. The receiver works with the attached Security Attributes to implement the IRP security requirement.

The present document addresses File integrity solution by using the XML Signature Mechanism defined by [9].

Table 4.1 identifies the use of File Integrity solution to realize File Integrity Security Service.

Table 4.1 : File Integrity solution and Security Service relationship

Authentication Security Service

Authorization Security Service

Activity Log Security Service

File Integrity Security Service

File Integrity solution


NOTE: "X" indicates which CORBA solution exchanges Security Attributes are relevant to which Security Service.

4.2 XML Signature Recommendation

This clause introduces the concept of XML Signature detailed in [9]. It is used to transfer XML Signature over Itf-N to provide the File Integrity Security Service.

Based on [9], data to be signed is canonicalized by using a specific method, i.e. using a unique form to represent XML files with the same semantic content but different text. The canonicalized data may be transformed before it is digested by using a specific method. The digest value is encrypted by using a specific signature method. The key information used to verify the signed value of signed data may be included in the XML Signature.

As shown in [9], XML digital signatures are represented by the Signature element which has the following structure (where "?" denotes zero or one occurrence; "+" denotes one or more occurrences; and "*" denotes zero or more occurrences):

<Signature ID?>




(<Reference URI? >








(<Object ID?>)*