Security Capability Negotiation between SEPPs

The security capability negotiation allows the SEPPs to negotiate which security mechanism to use for protecting NF service related signalling over N32. There shall be an agreed security mechanism between a pair of SEPPs before conveying NF service related signalling over N32.

When a SEPP notices that it does not have an agreed security mechanism for N32 protection with a peer SEPP or if the security capabilities of the SEPP have been updated, the SEPP shall perform security capability negotiation with the peer SEPP in order to determine, which security mechanism to use for protecting NF service related signalling over N32.

A mutually authenticated TLS connection as defined in clause 13.1 shall be used for protecting security capability negotiation over N32. The TLS connection shall provide integrity, confidentiality and replay protection.

Figure 2-3 Security Capability Negotiation

1. The SEPP which initiated the TLS connection sends a SecNegotiateReqData message to the responding SEPP including the initiating SEPP's supported security mechanisms for protecting the NF service related signalling over N32 . The security mechanisms are ordered in initiating SEPP's priority order.
2. The responding SEPP compares the received security capabilities to its own supported security capabilities and selects, based on its local policy, a security mechanism, which is supported by both initiating SEPP and responding SEPP.
3. The responding SEPP sends a SecNegotiateRspData message to initiating SEPP including selected security mechanism for protecting the NF service related signalling over N32.