Generic Bootstrapping Architecture (GBA) ETSI TS 133.220
UE 用户设备
NAF: Network Application Function 网络应用功能，需要对UE认证的第3方服务
Bootstrapping Server Function 运营商提供的认证服务器
大致流程：
1. UE访问 NAF
携带自己的 X-3GPP-Intended-Identity 和/或 subscriber-id（IMSI)
2. 如果NAF要求使用 通过GBA方式获得的key, 而UE 的请求中没有包含
GBA相关的参数， NAF就应该回复一个 bootstrapping 初始化消息。
3. 当UE需要同NAF交互，并且它也知道需要bootstrapping过程。那么，
它应该首先执行一个 bootstrapping认证过程。
否则， 只有如下3种情况
1）当UE收到 “bootstrap初始化要求”消息时，
2） 来自NAF的bootstrap协商指示
3） UE里的key过期
它才会执行 bootstrap 认证。
4. 认证遵循的技术规范–TS 33.102 AKA , RFC 3310 HTTP digest AKA
4.1 UE发送请求(包含自己的identity,imsi或者mdn）给 BSF
4.2 BSF同 HSS沟通，拿到鉴权向量(AV)和用户profile
4.3 BSF发送 401 未授权响应 给UE, 响应中包括(RAND, AUTN)
4.4 UE 在USIM卡上运行 AKA算法， 验证AUTN， 并从RES中生成key
4.5 发送认证请求给BSF, 请求中带有RES
4.6 BSF检查RES是否正确， 生成B-TID标识和对应的生命周期
在UE向BSF请求的头部， user-agent必须使用
User-Agent: 3gpp-gba-tmpi
BSF给UE的响应中，也要带这个头部
5.1 UE发送给BSF的http请求中，如果同IMPI关联的TMPI,已经可以在UE中可用。那么
UE应该将此TMPI放到 username参数中，否则， UE应该将IMPI放到 username参数。
5.2 BSF可以从username参数识别出它是TMPI还是IMPI.
如果是TMPI, 它将被本地的数据库中查询对应的IMPI
如果BSF没有找到对应的IMPI, 它将返回一个错误信息给UE.
UE将删除此TMPI,并使用IMPI重发请求。
5.3 BSF从HSS获取一组 AV(rand, autn, xres, ck,ik), 并
用HTTP 401响应 转发 RAND和AUTH给UE, 响应中不含(CK, IK, XRES,这些是需要UE自己计算的）
5.4 UE检查AUTN, 验证网络是否靠谱。也用RAND计算出CK, IK， RES.
5.5 UE发送另外一个http请求，里面包含有 AKA响应（计算出的res)给BSF
5.6 BSF通过aka 响应认证这个UE
请注意：AKAv1的 HTTP Digest AKA里的password是二进制格式
5.7 BSF用CK和IK生成 Ks. B-TID应该用 NAI个格式， 并以rand来做base64：
bas64encode(RAND)@BSF_servers_domain_name
注意：如果HSS 使用了好的随机数生成器，B-TID冲突的可能性为0.
但万一冲突， 那么从NAF取得的key,可能同 UE生成的，不匹配。
这是， NAF会再次要求做bootstrap, 重建新的B-TID和Ks
5.8 BSF发送 200 OK响应，包含B-TID, 发送给UE,告诉他 认证成功。
5.9
Ks_NAF = KDF(Ks, “gba-me”, RAND, IMPI, NAF_Id)
这里 KDF, 是一个密钥生成算法
NAF_Id = NAF的FQDN || Ua 安全协议标志
3GPP TS 23.003 从 IMSI或者IMPI 生成 BSF的地址， 例如 ： bsf.mnc002.mcc460.pub.3gppnetwork.org
bootstrap 基于 HTTP Digest AKA算法
ETSI TS 124 109 V17.2.0 (2022-07) 第48页
The UE generates the HTTP request by calculating the Authorization header values using the bootstrapping
transaction identifier B-TID it received from the BSF as the username and the NAF specific key material
Ks_(ext)_NAF (base64 encoded) as the password, and sends the request to the AP.
B-TID 作为 username, Ks_NAF(用base64编码过）作为 password, 计算 HTTP Digest响应，并发送给AP
UE在http头部 将UserAgent设置为 3gpp-gba-tmpi ，来告诉BSF，自己是支持TMPI的
BSF也要在响应头部中，设置 “Server” 为 3gpp-gba-tmpi, 来告诉UE, 自己是支持 TMPI的
If the UE does not have an ISIM application with an IMPI, the IMPI will be constructed from IMSI,
according to 3GPP TS 23.003
如果SIM卡中没有ISAM的AID, 那么也就不存在IMPI文件，那么IMPI应该按照 TS 23.003 从 IMSI构造
在BSF阶段， username应为 IMPI 或者 TMPI
uri 可以为相对路径 “/”
The key material shall be derived from AKA parameters as specified in 3GPP TS 33.220
就是 CK/Ik的拼接
ETSI TS 124 109 V17.2.0 (2022-07) 第16页
NAF阶段
username 就是 boottrap返回的 B-TID
GBA_ME模式下， password就是Ks_NAF（ NAF specific key material）
Ks_NAF由Ks生成，算法在 3GPP TS 33.220 定义
The NAF specific key material (Ks_NAF）使用是要按照 RFC 4648 进行base64编码
GBA-ME情况下， realm的形式应该是 3GPP-bootstrapping@naf_FQDN
比如 “3GPP-bootstrapping@naf1.operator.com”
UE 和 NAF 使用 HTTPS 进行认证
在进行http通信前， 有三种认证方式
1） 基于共享密钥的UE认证（(HTTP Digest)，同时 基于证书的NAF认证(TLS)
2) UE和NAF 基于共享密钥的双向认证 (PSK TLS)
3) UE 和 AS 基于 证书的 双向认证
UE和NAF 应该支持在 3GPP TS 33.310 附录 E中 所指定的TLS版本
3GPP TS 33.222的 5.3.1 节 有对TLS的详细描述
第1种认证方式：
基于ME的应用所要求的认证机制，在ME中必须实现，在NAF中可选实现。
基于UICC的应用所要求的认证机制，在UICC和NAF中，都是可选实现。
（1）在UE同NAF通信时， 它应该同NAF建立一个TLS通道。
NAF 通过公钥证书向 UE 进行身份验证。 UE应验证 服务器证书 是否 它与之建立隧道的 NAF 的 FQDN是对应的。
没有 客户端身份验证 作为 TLS 的一部分执行（不需要客户端证书）。
（2）UE将在 TLS通道(https，也就是http over tls)发送 http请求给NAF, 这与前面讲的 http digest 认证是一样的
（3）NAF跟之前的一样，用 HTTP Digest 认证 UE的请求
第2种认证（共享密钥的双向认证）：
基于ME的应用，这第2种认证方式，在ME和NAF中都是可选的
基于UICC的， 第2种认证方式，在 UICC和NAF中也都是可选的
基于 PSK 的 TLS 身份验证 (PSK TLS) 可以与自举安全关联一起用作身份验证、机密性和完整性保护方法。 与 PSK TLS 一起使用的 TLS 和 TLS 扩展的配置文件在 3GPP TS 33.310 的附件 E 中定义
使用TLS 1.2的认证过程
（1）
….
nonce= base64(RAND + AUTN + server specific data)
The BSF generates the bootstrapping transaction identifier (B-TID) for the IMPI and stores the tuple
(b-tid,impi,ck,ik)
The key material Ks is generated in UE by concatenating CK and IK. In the case of GBA_ME, the ME stores
the tuple (B-TID,Ks)
The NAF specific key material (Ks_NAF in the case of GBA_ME), is derived from Ks during the Ua interface procedures, and is used for securing the Ua interface. In the case of GBA_ME, the ME stores the tuple (B-TID,Ks_NAF)
For detailed bootstrapping key material generation procedure for NAF specific key (Ks_NAF) see 3GPP TS 33.220
If the conversation is taking place inside a server-authenticated TLS tunnel, the options for the qop attribute can also contain “auth” meaning that the payload of the following HTTP requests and responses are not protected by HTTP Digest. The integrity protection is handled on the TLS layer instead.
The realm attribute contains two parts delimited by “@” sign. The first part is a constant string “3GPP-bootstrapping” instructing the UE to use a bootstrapped security association. The second part is the FQDN of the NAF.
————-
UE内NAF特定key的生成
UE verifies that the second part of the realm attribute does correspond to the server it is talking to. In
particular, if the conversation is taking place inside a server-authenticated TLS tunnel, the UE shall verify
that the server name in the server’s TLS certificate matches the server name in the realm attribute of the
WWW-Authenticate header.
UE验证realm属性的第二部分，是否与它正在交谈的服务器一致。特殊地，如果会话发生在 一个服务器认证了的TLS通道内， UE应该验证服务器的TLS证书的服务器名称， 与 WWW-Authenticate头部里的realm属性的服务器名称是否匹配。
UE derives the NAF specific key material Ks_(ext)_NAF as specified in 3GPP TS 33.220 .
—————————-
43页
UE generates the HTTP request by calculating the Authorization header values using the bootstrapping
transaction identifier B-TID it received from the BSF as the username and the NAF specific key material
Ks_(ext)_NAF (base64 encoded) as the password, and sends the request to NAF.
If the conversation is taking place inside a server-authenticated TLS tunnel, the qop attribute can be set to “auth” as well.
———–
The NAF also verifies that the DNS name in the realm attribute matches its own. If the conversation is taking
place inside a server-authenticated TLS tunnel, the NAF shall also verify that this DNS name is the same as
that of the TLS server certificate.
NAF也可以验证 UE发送过来的头部的realm属性的DNS名称是否同自己的匹配。
如果会话发生在 服务器认证了的TLS通道内， 那么NAF应该也验证 这个DNS名称是同 TLS证书的名称是一样的
——————-
The “X-3GPP-Intended-Identity” header is used optionally by the UE to indicate the user identity intended to be used
with the AS. It contains the user identity surrounded by quotation marks (“).
————–
In the following request to NAF the HTTPS client sends a response with an Authorization header field where
Digest is inserted using the B-TID as username.The NAF-specific key (Ks_(ext)_NAF in the case of ME-based
application (including GBA_Digest) or Ks_int_NAF in the case of UICC-based application) is used as password
in the Digest calculation.
——-
The Ua security protocol identifier to be used is (0x01,0x00,0x02,yy,zz) as specified in Annex H of 3GPP TS 33.220
, where yy and zz are the protection mechanism CipherSuite as specified in relevant TLS specifications by IETF.
HTML FORM is tunneled through TLS, therefore the first consideration might be to use the Ua security protocol identifier for Ua security protocols that are based on TLS (HTTP Digest with HTTPS and Pre-shared key TLS) that is already specified in Annex H of 3GPP TS 33.220 (0x01,0x00,0x01,yy,zz).
This protocol id is used when the NAF specific key is used as a password in the TLS tunneled HTTP Digest case. This is substantially different, for example, from the case where HTML FORM based authentication within TLS tunnel is used, therefore a different Ua protocol id is used.
3GPP TS 33.220 Annex H中规定使用的Ua安全协议标识符为(0x01,0x00,0x02,yy,zz)，其中yy和zz为IETF相关TLS规范中规定的保护机制CipherSuite。
当 NAF 特定密钥用作 TLS 隧道 HTTP 摘要案例中的密码时，将使用此协议 ID。 这与使用 TLS 隧道内基于 HTML FORM 的身份验证的情况有很大不同，因此使用了不同的 Ua 协议 id。
HTML FORM 是通过 TLS 传输的，因此首先要考虑的是使用 Ua 安全协议标识符，该标识符基于 3GPP 附件 H 中已经规定的基于 TLS（HTTP 摘要与 HTTPS 和预共享密钥 TLS）的 Ua 安全协议 TS 33.220 (0x01,0x00,0x01,yy,zz)。
Ua security protocol identifier can be derived from the used TLS ciphersuite.
FQDN of the NAF and the Ua security protocol identifier form the NAF_ID.