The following clause provides the changes needed to adapt the Ua protocol given in clause 5.3 of TS 33.222
to work with a KAF
derived using the AKMA procedures.
The procedures follow those given in clause 5.3.0 of TS 33.222
with the AKMA AF taking the role of the NAF from GBA (see TS 33.220
), with the following changes.
At step 2, if the clients supports AKMA with this protocol then the client shall add the constant string "3gpp-akma"
to the "User-Agent"
HTTP header as product tokens as specified in RFC 7231
At step 3, if the AF selects AKMA for deriving the key, then the AF shall include the "3GPP-bootstrapping-akma"
within the WWW-Authenticate header field. If the AF has choice between GBA_Digest (see TS 33.220
) and AKMA keying, then the AF shall select AKMA over GBA_Digest (see TS 33.222
for similar consideration between GBA methods).
At step 4, on receiving the response from the AF, the client shall verify that the FQDN in the realm attribute corresponds to the FQDN of the AF it established the TLS connection with. If failure the client shall terminate the TLS connection with the AF.
At step 5 given AKMA has been selected for keying, the client shall send a response with an Authorization header field where Digest is inserted using the A-KID as username. KAF
shall be used as password in the Digest calculation.
At step 6 given AKMA has been selected for keying, the AF shall verify the value of the password attribute using KAF
retrieved from AAnF using the A-KID received as username attribute in the query. If the AF is not able to obtain the AF-specific key when using AKMA mode, the AF shall respond with an appropriate error message not containing the realm attributes from step 3.