Tech-invite3GPPspaceIETF RFCsSIP
Quick21222324252627282931323334353637384‑5x

Content for  TS 33.210  Word version:  17.1.0

Top   Top   Up   Prev   Next
0…   4…   5…   6…   A…

 

5  Key management and distribution architecture for NDS/IPp. 11

5.1  Security services afforded to the protocolsp. 11

IPsec offers a set of security services, which is determined by the negotiated IPsec security associations. That is, the IPsec SA defines which security protocol to be used, the mode and the endpoints of the SA.
For NDS/IP-networks the IPsec security protocol shall always be ESP. For NDS/IP-networks it is further mandated that integrity protection/message authentication together with anti-replay protection shall always be used.
The security services provided by NDS/IP:
  • data integrity;
  • data origin authentication;
  • anti-replay protection;
  • confidentiality (optional);
  • limited protection against traffic flow analysis when confidentiality is applied.
Up

5.2  Security Associations (SAs)p. 11

5.2.0  General |R11|p. 11

For NDS/IP-networks the key management and distribution between SEGs is handled by the protocol Internet Key Exchange Internet Key Exchange (IKEv2) (RFC 7296). The main purpose of IKEv2 is to negotiate, establish and maintain Security Associations between parties that are to establish secure connections. The concept of a Security Association is central to IPsec and IKEv2.
To secure a typical, bi-directional communication between two nodes using IKEv2 an IKE SA is established through which the Child Security associations i.e. IPsec security associations are established.
IPsec Security associations are uniquely defined by the following parameters:
  • A Security Parameter Index (SPI);
  • An IP Destination Address (this is the address of the ESP SA endpoint);
  • A security protocol identifier (this will always be the ESP protocol in NDS/IP).
With regard to the use of IPsec security associations in the network domain control plane of NDS/IP-networks the following is noted:
  • NDS/IP only requires support for ESP SAs;
The specification of IPsec SAs can be found in RFC 4301.
Up

5.2.1  Security Policy Database (SPD)p. 12

The Security Policy Database (SPD) is a policy instrument to decide which security services are to be offered and in what fashion.
The SPD shall be consulted during processing of both inbound and outbound traffic. This also includes traffic that shall not/need not be protected by IPsec. In order to achieve this, the SPD shall have unique entries for both inbound and outbound traffic such that the SPD can discriminate among traffic that shall be protected by IPsec, that shall bypass IPsec or that shall be discarded by IPsec.
The SPD plays a central role when defining security policies, both within the internal security domain and towards external security domains. The security policy towards external security domains will be subject to roaming agreements.
Up

5.2.2  Security Association Database (SAD)p. 12

The Security Association Database (SAD) contains parameters that are associated with the active security associations. Every SA has an entry in the SAD. For outbound processing, a lookup in the SPD will point to an entry in the SAD. If an SPD entry does not point to an SA that is appropriate for the packet, an SA shall be automatically created.

5.3  Profiling of IPsecp. 12

5.3.0  General |R11|p. 12

This section gives an overview of the features of IPsec that are used by NDS/IP. The overview given here defines a minimum set of features that shall be supported. In particular, this minimum set of features is required for interworking purposes and constitutes a well-defined set of simplifications.
The accumulated effect of the simplifications is quite significant in terms of reduced complexity. This is achieved without sacrificing security in any way. It shall be noted explicitly that the simplifications are specified for NDS/IP and that they may not necessarily be valid for other network constellations and usages.
Within their own network, operators are free to use IPsec features not described in this section although there should be no security or functional reason to do so.
Clause 5.3 contains the general 3GPP IPsec ESP profile. Other 3GPP specifications (e.g. TS 33.203, etc.) may point to clause 5.3. Thus parts of clause 5.3 may also apply to devices and network nodes as specified in other specifications. New specifications using ESP should refer to this profile with as few exceptions as possible. Unless explicitly stated otherwise, the 3GPP ESP profile apply for all uses of ESP to protect 3GPP interfaces.
Up

5.3.1  Support of ESPp. 12

When NDS/IP is applied, the ESP security protocol shall be used. IPsec ESP shall be supported according to RFC 4303. Extended sequence number may be supported. Usage guidance for the Implementation of Cryptographic Algorithm for ESP shall follow RFC 8221.

5.3.2  Support of tunnel modep. 12

Since security gateways are an integral part of the NDS/IP architecture, tunnel mode shall be supported. For NDS/IP inter-domain communication, security gateways shall be used and consequently only tunnel mode (RFC 4301) is applicable for this case.

5.3.3  Support of ESP encryption transformsp. 12

The implementation conformance requirements for ESP encryption transforms (including authenticated encryption transforms) in RFC 8221 shall be followed.
Only the ESP encryption algorithms (including authenticated encryption algorithms) mentioned in RFC 8221 shall be used. Algorithms marked with "MUST" shall be supported.

5.3.4  Support of ESP authentication transformsp. 13

The implementation conformance requirements for ESP authentication transforms in RFC 8221 shall be followed.
Only the ESP authentication algorithms mentioned in RFC 8221 shall be used. Algorithms marked with "MUST" shall be supported. AES-GMAC with AES-128 shall be supported.
ESP shall always be used to provide integrity, data origin authentication, and anti-replay services, thus the NULL authentication algorithm is explicitly not allowed for use, unless an authenticated encryption algorithm is used.
Up

5.3.5  Requirements on the construction of the IVp. 13

The following strengthening of the requirements on how to construct the IV shall take precedence over the description given in Section 3 of RFC 2451 and all other descriptions that allow for predictable IVs.
  • For CBC mode: the IV field shall be the same size as the block size of the cipher algorithm being used. The IV shall be chosen at random, and shall be unpredictable to any party other than the originator.
  • For CTR, GCM, CCM, and GMAC mode: the IV field shall be 8 octets. The IV shall be generated in a manner that ensures uniqueness. The same IV and key combination shall not be used more than once.
  • It is explicitly not allowed to construct the IV from the encrypted data of the preceding encryption process.
The common practice of constructing the IV from the encrypted data of the preceding encryption process means that the IV is disclosed before it is used. A predictable IV exposes IPsec to certain attacks irrespective of the strength of the underlying cipher algorithm. The second bullet point forbids this practice in the context of NDS/IP.
These requirements imply that the network elements shall have a capability to generate random data. RFC 4086 gives guidelines for hardware and software pseudorandom number generators.
Up

5.4  Profiling of IKEv2p. 13

5.4.0  General |R11|p. 13

Clause 5.4 contains the general 3GPP IKEv2 profile. Other 3GPP specifications point to clause 5.4. Thus parts of clause 5.4 may also apply to devices and network nodes as specified in other specifications. New specifications using IKE should refer to this profile with as few exceptions as possible. Unless explicitly stated otherwise, the 3GPP IKEv2 profile apply for all uses of IKEv2 to protect 3GPP interfaces.
Up

5.4.1Void

5.4.2  Profiling of IKEv2 |R8|p. 13

The Internet Key Exchange protocol IKEv2 shall be supported for negotiation of IPsec SAs. The following additional requirements apply.
General:
IKEv2 Configuration Payload as defined in RFC 7296 should be supported.
Protocol support for High Availability as defined in RFC 6311 should be supported.
For IKE_SA_INIT exchange:
The following algorithms are listed with their names according to [44].
Following algorithms shall be supported:
  • Confidentiality: AES-GCM with a 16 octet ICV with 128-bit key length;
  • Pseudo-random function: PRF_HMAC_SHA2_256;
  • Integrity: AUTH_HMAC_SHA256_128;
  • Diffie-Hellman group 19 (256-bit random ECP group) ;
Following algorithms should be supported:
  • Confidentiality: AES-GCM with a 16 octet ICV with 256-bit key length;
  • Pseudo-random function: PRF_HMAC_SHA2_384;
  • Diffie-Hellman group 20 (384-bit random ECP group).
  • Diffie-Hellman group 31 (Curve25519).
For security reasons, the use of Diffie-Hellman MODP groups less than 2048-bit shall not be supported.
For IKE_AUTH exchange:
  • Authentication method 2 - Shared Key Message Integrity Code shall be supported;
  • IP addresses and Fully Qualified Domain Names (FQDN) shall be supported for identification;
  • Re-keying of IPsec SAs and IKE SAs shall be supported as specified in RFC 7296.
  • In addition to the requirements defined in RFC 7296, rekeying shall not lead to a noticeable degradation of service.
For the CREATE_CHILD_SA exchange:
  • A DH key exchange should be used (giving Perfect Forward Secrecy)and the session keys should be changed frequently.
For reauthentication:
  • Reauthentication of IKE SAs as specified in Section 2.8.3 of RFC 7296 shall be supported;
  • A NE shall proactively initiate reauthentication of IKE SAs, and creation of its Child SAs, i.e. the new SAs shall be established before the old ones expire;
  • A NE shall destroy an IKE SA and its Child SAs when the authentication lifetime of the IKE SA expires;
  • In addition to the requirements defined in RFC 7296, reauthentication shall not lead to a noticeable degradation of service.
Up

5.4.3Void

5.5  Security policy granularityp. 14

The policy control granularity afforded by NDS/IP is determined by the degree of control with respect to the ESP Security Association between the NEs or SEGs. The normal mode of operation is that only one ESP Security Association is used between any two NEs or SEGs, and therefore the security policy will be identical to all secured traffic passing between the NEs.
This is consistent with the overall NDS/IP concept of security domains, which should have the same security policy in force for all traffic within the security domain. The actual inter-security domain policy is determined by roaming agreements when the security domains belong to different operators or may be unilaterally decided by the operator when the security domains both belong to him. IPsec security policy enforcement for inter-security domain communication is a matter for the SEGs of the communicating security domains.
Up

5.6  Network domain security key management and distribution architecture for native IP based protocolsp. 15

5.6.1  Network domain security architecture outlinep. 15

The NDS/IP key management and distribution architecture is based on the IKEv2 (RFC 7296) protocol. As described in the previous section a number of options available in the full IETF IPsec protocol suite have been considered to be unnecessary for NDS/IP. Furthermore, some features that are optional in IETF IPsec have been mandated for NDS/IP and lastly a few required features in IETF IPsec have been deprecated for use within NDS/IP scope. Sections 5.3 and 5.4 give an overview over the profiling of IPsec and IKEv2 in NDS/IP.
The compound effect of the design choices in how IPsec is utilized within the NDS/IP scope is that the NDS/IP key management and distribution architecture is quite simple and straightforward.
The basic idea to the NDS/IP architecture is to provide hop-by-hop security. This is in accordance with the chained-tunnels or hub-and-spoke models of operation. The use of hop-by-hop security also makes it easy to operate separate security policies internally and towards other external security domains.
In NDS/IP only the Security Gateways (SEGs) shall engage in direct communication with entities in other security domains for NDS/IP traffic. The SEGs will then establish and maintain IPsec secured ESP Security Association in tunnel mode between security domains. SEGs will normally maintain at least one IPsec tunnel available at all times to a particular peer SEG. The SEG will maintain logically separate SAD and SPD databases for each interface.
The NEs may be able to establish and maintain ESP Security Associations as needed towards a SEG or other NEs within the same security domain. All NDS/IP traffic from a NE in one security domain towards a NE in a different security domain will be routed via a SEG and will be afforded hop-by-hop security protection towards the final destination.
Operators may decide to establish only one ESP Security Association between two communicating security domains. This would make for coarse-grained security granularity. The benefits to this is that it gives a certain amount of protection against traffic flow analysis while the drawback is that one will not be able to differentiate the security protection given between the communicating entities. This does not preclude negotiation of finer grained security granularity at the discretion of the communicating entities.
Reproduction of 3GPP TS 33.210, Fig. 1: NDS architecture for IP-based protocols
Up
Additional guidelines on how to apply IPsec in SCTP are specified in RFC 3554. This RFC is optional for implementation unless otherwise explicitly indicated per reference point.

5.6.2  Interface descriptionp. 16

The following interfaces are defined for protection of native IP based protocols:
  • Za-interface (SEG-SEG)
    The Za-interface covers all NDS/IP traffic between security domains. On the Za-interface, authentication/integrity protection is mandatory and encryption is recommended. ESP shall be used for providing authentication/integrity protection and encryption. The SEGs use IKEv2 to negotiate, establish and maintain a secure ESP tunnel between them. The tunnel is subsequently used for forwarding NDS/IP traffic between security domain A and security domain B. Inter-SEG tunnels can be available at all times, but they can also be established as needed.
    One SEG of security domain A can be dedicated to only serve a certain subset of security domains that security domain A needs to communicate with. This will limit the number of SAs and tunnels that need to be maintained.
    All security domains compliant with the present document shall operate the Za-interface.
  • Zb-interface (NE-SEG / NE-NE)
    The Zb-interface is located between SEGs and NEs and between NEs within the same security domain. The Zb-interface is optional for implementation. If implemented, it shall implement ESP in tunnel mode and IKE as described in clause 5.4. The support of ESP in Transport mode is optional.
    On the Zb-interface, ESP shall always be used with authentication/integrity protection. The use of encryption is optional. The ESP Security Association shall be used for all control plane traffic that needs security protection.
    Whether the Security Association is established when needed or a priori is for the security domain operator to decide. The Security Association is subsequently used for exchange of NDS/IP traffic between the nodes.
Up

Up   Top   ToC