Content for TS 33.535 Word version: 18.4.0

D.1 General D.2 Requirements D.2.1 General D.2.2 Requirements on the UE D.2.3 Requirements on the AF D.2.4 Requirements on the OSCORE D.3 IETF OSCORE as an AKMA Ua* protocol D.3.1 General D.3.2 Procedures D.3.3 OSCORE Security context D.3.4 Refresh of OSCORE key material D.3.5 OSCORE Ua* protocol payload encoding

D (Normative) Ua* security protocol: Object Security for Constrained RESTful Environments (OSCORE) |R18| p. 31

D.1 General p. 31

This Annex describes how to secure access to an AF using Object Security for Constrained RESTful Environments (OSCORE) RFC 8613.

The specification of the OSCORE as an AKMA Ua* protocol follows the architecture of GBA OSCORE Ua protocol in TS 33.220, Annex P with the AF taking the role of the NAF.

D.2 Requirements p. 31

D.2.1 General p. 31

This Annex covers the aspects specific to the AKMA Ua* protocol based on OSCORE. This feature is optional to be supported for the UE and AF. If the feature is supported, the following clauses apply.

D.2.2 Requirements on the UE p. 31

To utilise AKMA as described in this document the UE shall be equipped with an CoAP capable client implementing the particular features of AKMA as specified in this document.

D.2.3 Requirements on the AF p. 31

To utilise AKMA as described in this document the AF shall support the features of AKMA as specified in this document.

D.2.4 Requirements on the OSCORE p. 31

The same requirements outlined in clause P.2.4 of TS 33.220 apply in this clause.

D.3 IETF OSCORE as an AKMA Ua* protocol p. 31

The IETF OSCORE as an AKMA Ua* protocol is specified in this clause by providing the details about the procedures, the OSCORE security context and how it is related to the AKMA KAF and the encoding of OSCORE messages using IETF CBOR specified in RFC 8949.

D.3.2 Procedures p. 31

The procedures for the AKMA OSCORE Ua* protocol are the same as the clause P.3.2 of TS 33.220 with the following changes.

In Step 1, the CoAP Client (UE) shall send a CoAP request to the AF. This is the Application Session Establishment Request in Step 1 in clause 6.2. The CoAP request shall consist of the following:
1. CoAP Method: POST.
2. URI of the AKMA resource on the AF. The URI shall have the format of <AF_IP_or_FQDN>/akma, where AF_IP_or_FQDN indicates the IP address or the FQDN of the host that hosts the AF.
  
  NOTE 1:
  It is assumed that the AF IP address or FQDN is already provisioned to the UE for AKMA purposes.
3. Payload: CoAP Security protocol identifer, A-KID, N1, AF-SID, ?OSC-INP
The parameters "CoAP Security protocol identifier", N1, AF-SID, ?OSC-INP have the same semantics as the corresponding parameters in clause Y.2.3 of TS 33.220. Step 1.
Steps 2-4 follow clause 6.2 in the present document.
The CoAP Server (AF) shall respond to the CoAP Client (UE) with a CoAP response. This is the Application Session Establishment Response in Step 5 in clause 6.2. The response shall have the following content:
1. Response Code: "Created".
2. Payload: N2, UE-SID.
The parameters N2, UE-SID have the same semantics as the corresponding parameters in clause P.2.3 of TS 33.220. Step 3.

D.3.3 OSCORE Security context p. 32

The OSCORE security context used in AKMA OSCORE Ua* protocol is similar to the GBA OSCORE security context specified in clause Y.3.3 of TS 33.220, with the following changes. The OSCORE security context for the OSCORE profile of Ua* shall have the following values:

OMS = OSCORE Master Secret = HKDF(KAF, "AKMA-OSCORE").
Master Salt = Request Payload | Response Payload.
UE Sender ID = UE-SID generated by CoAP Server and sent to the CoAP Client in the Application Session Establishment Response (Step 3 in clause D.3.2).
AF Sender ID = AF-SID generated by CoAP Client and sent to the CoAP Server in the Application Session Establishment Request(Step 1 in clause D.3.2).

where HKDF shall be the HMAC-based Key Derivation Function specified in RFC 5869.

D.3.4 Refresh of OSCORE key material p. 32

OSCORE allows both the communication endpoints (UE or AF) to renegotiate the OSCORE security context after the OSCORE security context is established, according to Appendix B.2 in RFC 8613, which is shown in the Figure D.3.4-1, Step 1.

Moreover even if KAF remains constant upon a new application session establishment (Step 1 in clause D.3.2) or a renegotiation of the OSCORE key material, the nonces N1, N2, used in OSCORE security context shall be (stochastically) different from the previous OSCORE security context negotiation to ensure that the OSCORE security context is different.

Reproduction of 3GPP TS 33.535, Fig. D.3.4-1: OSCORE key refresh

Figure D.3.4-1: OSCORE key refresh

D.3.5 OSCORE Ua* protocol payload encoding p. 33

IETF CoAP and OSCORE shall use the IETF Concise Binary Object Representation (CBOR) specified in the RFC 8949 for payload encoding for efficient information transfer between constrained IoT devices.

The CoAP media type for CBOR encoding shall be:

Media Type: application/cbor
CoAP Content-Format: 60

The Request Payload in the Application Session Request shall be formatted as a CBOR Array as follows:

Request Payload = [
A-KID : bstr,
      N1 : bstr, 
      AF-SID : bstr, 
      ? OSC-INP: bstr
]
A-KID = [
     RID : tstr,
     A-TID : bstr,
     HPLMN-ID : tstr
]
OSC-INP = {           ; CBOR Map
      ? 1 => int,     ; version 
      ? 3 => int,     ; hkdf 
      ? 4 => int,     ; alg 
      ? 5 => bstr,    ; salt 
      ? 6 => bstr     ; contextId
}

The Response Payload in the Application Session Response shall be formatted as a CBOR Array as follows:

Response Payload = [         ; CBOR Array
  N2 : bstr, 
  UE-SID : bstr
]