当5G UE通过公共WiFi热点等非可信非3GPP接入网络连接到5G核心网时,面临三个核心安全挑战:身份暴露风险、中间人攻击风险和密钥隔离问题。3GPP在TS 33.501中引入了N3IWF(Non-3GPP InterWorking Function)作为安全网关,通过IKEv2 + EAP-AKA'双重协议栈解决这些问题。
与3GPP接入直接使用5G-AKA不同,非可信非3GPP接入必须先建立IPsec隧道再承载NAS信令,这使得整个注册流程在信令层面呈现四层嵌套结构:IP → IKEv2 → EAP-AKA' → NAS。本文将逐层拆解这一复杂信令交互。
N3IWF在5G架构中引入了三个新的参考点:
| 参考点 | 连接 | 协议 | 功能 |
|---|---|---|---|
| Yu | UE ↔ N3IWF | IKEv2 / IPsec | 建立安全隧道,承载EAP-AKA'认证和NAS信令 |
| N2 | N3IWF ↔ AMF | NGAP | 传递NAS消息和NAS消息,等同于gNB与AMF间的N2 |
| N3 | N3IWF ↔ UPF | GTP-U | 用户面数据转发 |
graph TB
subgraph "非可信非3GPP接入域"
UE["UE<br/>(WiFi连接)"]
WiFi["WiFi AP<br/>(非可信)"]
end
subgraph "安全边界"
N3IWF["N3IWF<br/>EAP Authenticator<br/>IKEv2 Responder"]
end
subgraph "5G核心网"
AMF["AMF<br/>SEAF角色"]
AUSF["AUSF"]
UDM["UDM/ARPF<br/>SIDF"]
UPF["UPF"]
end
UE -->|"Yu: IKEv2/IPsec<br/>EAP-AKA'"| N3IWF
N3IWF -->|"N2: NGAP"| AMF
AMF -->|"Nausf: Auth"| AUSF
AUSF -->|"Nudm: Auth Get"| UDM
N3IWF -->|"N3: GTP-U"| UPF
UE -.->|"WiFi"| WiFi
style N3IWF fill:#ff6b6b,color:#fff
style UE fill:#4ecdc4,color:#fff
style AUSF fill:#ffe66d,color:#333
N3IWF同时扮演三种角色,这是理解其信令交互的关键:
设计意图:N3IWF将非3GPP接入的安全处理与5G核心网隔离。即使WiFi网络被攻破,攻击者也无法获取5G NAS层的任何信息,因为所有NAS消息都封装在IPsec隧道内。
以下是基于TS 23.502 Section 4.12.2.2和TS 33.501 Section 6.3.3的完整信令流程:
sequenceDiagram
participant UE
participant N3IWF
participant AMF
participant AUSF
participant UDM
Note over UE,N3IWF: Phase 1: IKE_SA_INIT
UE->>N3IWF: IKE_SA_INIT Request<br/>SAi1, KEi, Ni
N3IWF->>UE: IKE_SA_INIT Response<br/>SAr1, KEr, Nr, [Cookie]
Note over UE,N3IWF: Phase 2: IKE_AUTH + EAP-AKA'
UE->>N3IWF: IKE_AUTH Request<br/>IDi([email protected]...), SAi2, TSi, TSr
N3IWF->>UE: IKE_AUTH Response<br/>EAP-Request/AKA'-Start<br/>AT_KDF_INPUT, AT_KDF
UE->>N3IWF: IKE_AUTH Request<br/>EAP-Response/AKA'-Identity<br/>(SUCI)
N3IWF->>AMF: N2 NAS Transport<br/>NAS: Registration Request + EAP-5G(ID)
Note over AMF,UDM: Phase 3: 5G AKA via EAP-AKA'
AMF->>AUSF: Nausf_UEAuthentication_Auth<br/>SUCI, SNN
AUSF->>UDM: Nudm_UEAuthentication_Get<br/>SUCI, SNN
UDM->>AUSF: 5G AV(RAND, AUTN, KAUSF, XRES*)
AUSF->>AMF: RAND, AUTN, HXRES*
AMF->>N3IWF: N2 NAS Transport<br/>EAP-Request/AKA'-Challenge<br/>AT_RAND, AT_AUTN, AT_MAC
N3IWF->>UE: IKE_AUTH Response<br/>EAP-Request/AKA'-Challenge
Note over UE: UE验证AUTN<br/>计算RES*<br/>派生CK', IK', MK, MSK
UE->>N3IWF: IKE_AUTH Request<br/>EAP-Response/AKA'-Challenge<br/>AT_RES, AT_MAC
N3IWF->>AMF: N2 NAS Transport<br/>EAP-Response/AKA'-Challenge
AMF->>AUSF: Nausf_UEAuthentication_Auth<br/>RES*
AUSF->>AMF: Auth Success + KSEAF
AMF->>N3IWF: N2 NAS Transport<br/>EAP-Success + KSEAF
N3IWF->>UE: IKE_AUTH Response<br/>EAP-Success
Note over UE,N3IWF: Phase 4: IPsec Child SA + NAS Registration
N3IWF->>UE: IKE_AUTH Response<br/>IDr, AUTH, SAr2, TSi, TSr<br/>(IPsec Child SA建立)
UE->>N3IWF: NAS: Registration Complete<br/>(通过IPsec隧道)
N3IWF->>AMF: N2 NAS Transport<br/>NAS: Registration Complete
AMF->>N3IWF: N2 NAS Transport<br/>NAS: Registration Accept
N3IWF->>UE: NAS: Registration Accept<br/>(通过IPsec隧道)
IKE_SA_INIT阶段建立未认证的IKE SA,为后续EAP-AKA'提供加密传输通道。
UE → N3IWF: IKE_SA_INIT Request
| IE名称 | 说明 | 典型值 |
|---|---|---|
| SAi1 | 安全关联提案(加密/完整性/DH组) | ENCR-AES-CBC-256, AUTH-HMAC-SHA2-256, DH Group 14/19 |
| KEi | DH公共值 | 2048-bit MODP / 256-bit ECP |
| Ni | UE nonce | 16-256字节随机数 |
N3IWF → UE: IKE_SA_INIT Response
N3IWF选中一组算法并返回自己的DH值和nonce。可选返回Cookie用于DoS防护。
抓包识别:IKE_SA_INIT消息的UDP端口为500(NAT-T后续切换到4500)。IKE SA建立后的所有IKE_AUTH消息通过该IKE SA加密,但此时IKE SA尚未认证——认证在Phase 2的EAP-AKA'中完成。
这是整个流程的核心,IKE_AUTH阶段内嵌EAP-AKA'方法实现UE与5G核心网的双向认证。
UE发送IKE_AUTH Request,携带以下关键信息:
| IE名称 | 说明 | 编码格式 |
|---|---|---|
| IDi | UE身份标识 | NAI格式:[email protected]<MNC>.mcc<MCC>.3gppnetwork.org |
| SAi2 | IPsec SA提案 | ESP隧道模式,AES-GCM-256或AES-CBC+HMAC-SHA2-256 |
| TSi/TSr | 流量选择器 | 通常为动态地址(0.0.0.0),后续由N3IWF分配 |
| AUTH | 认证数据 | 空(使用EAP认证时AUTH省略) |
关键点:当使用EAP方法时,IKE_AUTH Request中不包含AUTH载荷。这是RFC 7296的规定——EAP方法负责后续认证,IKE_AUTH最终由N3IWF在EAP-Success后发送AUTH完成双向认证。
N3IWF回复IKE_AUTH Response,内含EAP-Request/AKA'-Start消息,触发EAP-AKA'流程。
EAP-Request/AKA'-Start关键属性(TS 33.501 Section 6.1.3.1):
| AT属性 | 用途 | 值 |
|---|---|---|
| AT_KDF_INPUT | 网络名称(SNN),用于密钥绑定 | "5G:mnc<MNC>.mcc<MCC>.3gppnetwork.org" |
| AT_KDF | 密钥派生函数标识 | KDF=1 (HMAC-SHA-256) |
EAP-AKA'与EAP-AKA的根本区别:EAP-AKA'通过AT_KDF_INPUT将密钥绑定到特定网络名称(SNN),实现密钥分离(Key Separation)。这意味着同一组CK/IK在不同网络中派生出的CK'/IK'完全不同,防止跨网络密钥重用攻击。
UE收到AKA'-Start后回复EAP-Response/AKA'-Identity,携带SUCI。N3IWF将SUCI通过N2接口转发给AMF。
AMF收到EAP-Identity后,触发5G AKA认证流程:
Nausf_UEAuthentication_Auth,携带SUCI和SNNNudm_UEAuthentication_Get,请求认证向量UDM侧密钥派生(TS 33.501 Annex A.2):
CK || IK = KDF_K(RES || CK || IK) -- 从USIM获取基础CK/IK
CK' || IK' = KDF(CK || IK, SNN) -- 绑定网络名称
KAUSF = KDF(CK' || IK', SQN ⊕ AK) -- 绑定序列号
AUSF使用CK'和IK'计算EAP-AKA'的MK(Master Key):
MK = PRF'(CK' || IK', <identity> || n)
MSK = MK[0..511] -- 512-bit MSK,用于IPsec密钥
EMSK = MK[512..1023] -- 512-bit EMSK,5G中不使用
AMF收到认证向量后,将RAND和AUTN通过EAP-Request/AKA'-Challenge发送给UE:
| AT属性 | 方向 | 说明 |
|---|---|---|
| AT_RAND | Network → UE | 128-bit随机数,用于USIM卡计算 |
| AT_AUTN | Network → UE | 128-bit认证令牌,含SQN和AMF字段 |
| AT_MAC | Network → UE | 消息认证码,由MK派生的K_aut密钥计算 |
UE侧处理: 1. 将RAND和AUTN传递给USIM 2. USIM验证AUTN(检查MAC和SQN freshness) 3. USIM返回RES、CK、IK 4. UE执行与网络侧相同的CK'/IK'/MK/MSK派生 5. UE发送EAP-Response/AKA'-Challenge,包含AT_RES和AT_MAC
AMF将RES转发给AUSF验证。AUSF比对XRES与RES后返回认证结果和KSEAF:
KSEAF = KDF(KAUSF, SNN || SQN ⊕ AK)
EAP认证成功后,N3IWF向UE发送最终的IKE_AUTH Response:
| IE名称 | 说明 |
|---|---|
| IDr | N3IWF身份 |
| AUTH | N3IWF认证数据(基于MSK计算,证明N3IWF合法) |
| SAr2 | IPsec ESP SA参数 |
| TSi/TSr | 流量选择器(N3IWF为UE分配的内网IP地址范围) |
| CP(CFG_REPLY) | UE内部IP地址、DNS服务器地址 |
关键设计:IPsec Child SA的密钥由EAP-AKA'产生的MSK通过IKEv2密钥材料推演得出,而非独立协商。这确保了IPsec隧道的安全性与EAP-AKA'认证绑定。
IPsec隧道建立后,NAS Registration Request在隧道内传输:
UE → IPsec隧道 → N3IWF → N2(NGAP) → AMF
NAS Registration流程与3GPP接入的Registration基本一致,但有以下差异:
| 差异点 | 3GPP接入 | 非可信非3GPP接入 |
|---|---|---|
| 接入类型 | 3GPP | Non-3GPP |
| NAS传输通道 | RRC + NGAP | IPsec + N2(NGAP) |
| 安全模式激活 | NAS SMC in 5G-AKA | 已在EAP-AKA'中完成 |
| AMF选择 | gNB基于GUAMI路由 | N3IWF基于SUCI中的PLMN选择 |
| TAI管理 | gNB广播TAI | N3IWF配置虚拟TAI |
非可信非3GPP接入的密钥层级是理解整个安全架构的核心。以下是基于TS 33.501 Section 6.2的完整密钥派生链:
graph TD
K["K<br/>永久密钥<br/>(USIM/UDM)"]
K -->|"f1-f5算法<br/>+ RAND"| AV["5G AV<br/>CK, IK, AUTN<br/>RAND, XRES*"]
AV --> CKIK["CK || IK"]
CKIK -->|"KDF(CK‖IK, SNN)"| CKP_IKP["CK' || IK'<br/>绑定SNN"]
CKP_IKP -->|"KDF(CK'‖IK',<br/>SQN⊕AK)"| KAUSF["KAUSF"]
KAUSF -->|"KDF(KAUSF,<br/>SNN‖SQN⊕AK)"| KSEAF["KSEAF"]
KAUSF -->|"MK = PRF'(CK'‖IK',...)"| MK["MK<br/>EAP-AKA'<br/>Master Key"]
MK --> MSK["MSK (512-bit)<br/>→ IPsec密钥"]
MK --> EMSK["EMSK (512-bit)<br/>5G未使用"]
KSEAF -->|"KDF(KSEAF,<br/>SUPI‖ABBA)"| KAMF["KAMF<br/>NAS根密钥"]
KAMF --> KNAS_INT["KNAS_int<br/>NAS完整性密钥"]
KAMF --> KNAS_ENC["KNAS_enc<br/>NAS加密密钥"]
MSK -->|"IKEv2 PRF+"| IPsec_KEYS["IPsec ESP SA密钥<br/>SK_e(入/出)<br/>SK_a(入/出)"]
style K fill:#e74c3c,color:#fff
style KAUSF fill:#f39c12,color:#fff
style KSEAF fill:#2ecc71,color:#fff
style KAMF fill:#3498db,color:#fff
style MSK fill:#9b59b6,color:#fff
| 密钥 | 派生位置 | 输入参数 | 用途 | 长度 |
|---|---|---|---|---|
| CK'/IK' | UE + UDM | CK, IK, SNN | 密钥分离,绑定网络名称 | 各128-bit |
| KAUSF | UE + AUSF | CK', IK', SQN⊕AK | AUSF级别密钥 | 256-bit |
| KSEAF | AUSF → AMF | KAUSF, SNN, SQN⊕AK | SEAF/AMF级别锚定密钥 | 256-bit |
| MK | UE + AUSF | CK', IK', Identity, n | EAP-AKA'主密钥 | 256-bit |
| MSK | UE + AUSF | 从MK截取 | IPsec SA密钥材料 | 512-bit |
| KAMF | AMF + UE | KSEAF, SUPI, ABBA | NAS层根密钥 | 256-bit |
| 特性 | 5G-AKA | EAP-AKA | EAP-AKA' |
|---|---|---|---|
| 规范 | TS 33.501 Sec 6.1.1 | RFC 4187 | RFC 9048 |
| 适用接入 | 3GPP接入 | 4G非3GPP | 5G非3GPP |
| EAP框架 | 否(直接NAS) | 是 | 是 |
| 密钥分离 | SNN绑定 | 无 | SNN绑定(AT_KDF_INPUT) |
| KDF | TS 33.501 Annex A | 无额外KDF | HMAC-SHA-256 (KDF=1) |
| 身份保护 | SUCI (ECIES) | IMPI明文 | SUCI (NAI格式) |
| 密钥输出 | KSEAF | MSK,EMSK | MSK,EMSK |
| 隐私保护 | 是(SUCI) | 否 | 是(SUCI) |
| 重放保护 | SQN + AUTN | SQN + AUTN | SQN + AUTN |
核心差异:EAP-AKA'通过AT_KDF_INPUT属性引入SNN绑定,使CK/IK → CK'/IK'的派生与特定PLMN绑定。攻击者即使获取了CK/IK也无法在不同PLMN中伪造密钥。
在IKEv2隧道内,N3IWF使用EAP-5G(TS 24.302 Section 7.2.3)作为NAS消息的封装协议,这是一个容易被忽视但至关重要的中间层:
graph TD
subgraph "IKE_AUTH载荷"
EAP5G["EAP-5G<br/>Type=55<br/>Vendor-Id=3GPP"]
subgraph "EAP-5G PDU"
ANQP["AN-Parameters<br/>(接入网参数)"]
NAS_PDU["NAS PDU<br/>(Registration Request等)"]
end
EAP5G --> ANQP
EAP5G --> NAS_PDU
end
subgraph "最终封装"
UDP["UDP 500/4500"]
IKE["IKEv2 HDR"]
ENC["SK{IKE_AUTH}"]
UDP --> IKE --> ENC --> EAP5G
end
EAP-5G消息格式:
| 字段 | 长度 | 说明 |
|---|---|---|
| Code | 1字节 | Request(1) / Response(2) |
| Identifier | 1字节 | 匹配Request/Response |
| Length | 2字节 | EAP消息总长度 |
| Type | 1字节 | 55 (EAP-5G Vendor-Specific) |
| Vendor-Id | 4字节 | 3GPP (10415) |
| Vendor-Type | 4字节 | 3 (EAP-5G) |
| AN-Parameters | 可变 | 接入网参数(如PLMN ID、NID) |
| NAS PDU | 可变 | 完整的NAS消息 |
注意:EAP-5G仅用于在IKEv2隧道内传输NAS消息,与EAP-AKA'是两个独立的EAP方法。EAP-AKA'负责认证,EAP-5G负责NAS消息封装。
# IKEv2协商阶段
udp.port == 500 || udp.port == 4500
# 过滤IKE_SA_INIT
ikev2 && ikev2.exchange_type == 34
# 过滤IKE_AUTH(含EAP-AKA')
ikev2 && ikev2.exchange_type == 35
# 过滤EAP-AKA'消息
eap.type == 55 && eap.subtype == 1 # AKA'-Start
eap.type == 55 && eap.subtype == 2 # AKA'-Challenge
# N2接口(NGAP)
ngap && ngap.procedureCode == 44 # UplinkNASTransport
| 故障阶段 | 现象 | 可能原因 | 排查方法 |
|---|---|---|---|
| IKE_SA_INIT | 无响应 | N3IWF不可达或端口被阻断 | ping N3IWF_IP,检查防火墙UDP 500/4500 |
| IKE_SA_INIT | NO_PROPOSAL_CHOSEN | 算法不匹配 | 检查UE和N3IWF的IKE/IPsec算法配置 |
| EAP-AKA' Identity | 超时 | AMF不可达 | 检查N3IWF与AMF的N2 SCTP连接 |
| AKA'-Challenge | USIM拒绝AUTN | SQN不同步 | 检查UDM侧SQN状态,触发USIM重新同步 |
| AKA'-Challenge | RES验证失败 | 密钥不匹配 | 检查USIM与UDM的K/OPc配置 |
| IPsec Child SA | 创建失败 | 密钥推演异常 | 抓包比较两侧MSK是否一致 |
| NAS Registration | 拒绝(5)#PLMN_NOT_ALLOWED | PLMN限制 | 检查N3IWF配置的PLMN ID |
| ## 9. 安全分析 |
这涉及协议设计的深层考量:
┌─────────────────────────────────────┐
│ IPsec ESP Tunnel │ ← MSK派生密钥保护
│ ┌───────────────────────────────┐ │
│ │ NAS Registration │ │ ← KAMF派生密钥保护
│ ┌───────────────────────────────┐ │
│ │ PDU Session User Data │ │ ← UPF N3隧道保护
│ └───────────────────────────────┘ │
└─────────────────────────────────────┘
这种嵌套模型确保:即使WiFi接入点被攻击者控制,IPsec隧道也能保护NAS信令和用户数据的机密性与完整性。
UE在非可信非3GPP接入注册过程中经历以下状态转换:
stateDiagram-v2
[*] --> WiFi_Connected: WiFi关联成功
WiFi_Connected --> IKE_SA_Init: 发起IKE_SA_INIT
IKE_SA_Init --> IKE_SA_Established: IKE SA建立成功
IKE_SA_Established --> EAP_AKA_Start: 发送IKE_AUTH(IDi)
EAP_AKA_Start --> EAP_AKA_Identity: 收到AKA'-Start
EAP_AKA_Identity --> EAP_AKA_Challenge: 发送Identity
EAP_AKA_Challenge --> EAP_AKA_Verifying: 收到Challenge
EAP_AKA_Verifying --> EAP_Success: USIM验证AUTN成功
EAP_AKA_Verifying --> EAP_Failure: AUTN验证失败
EAP_Success --> IPsec_Child_SA: 收到EAP-Success+AUTH
IPsec_Child_SA --> NAS_Registration: Child SA建立
NAS_Registration --> Registered: Registration Accept
Registered --> [*]: 注册完成
EAP_Failure --> [*]: 认证失败
IKE_SA_Init --> [*]: IKE超时
Q1: EAP-AKA'和EAP-AKA的核心区别是什么?
A: 核心区别在于密钥分离。EAP-AKA直接使用CK/IK,而EAP-AKA'通过AT_KDF_INPUT引入SNN(Serving Network Name),将CK/IK经过额外KDF推导为CK'/IK',使密钥与特定PLMN绑定。这防止了一个PLMN的密钥被用来伪造另一个PLMN的身份。此外,EAP-AKA'使用HMAC-SHA-256作为KDF(AT_KDF=1),而EAP-AKA不涉及额外KDF。
Q2: 为什么IKE_SA_INIT后还需要EAP-AKA'?IKEv2本身不够安全吗?
A: IKE_SA_INIT仅建立了未认证的IKE SA——Diffie-Hellman交换提供了前向安全性,但没有验证对端身份。EAP-AKA'通过与USIM/AUSF交互完成双向认证:网络验证UE(通过RES*),UE验证网络(通过AUTN中的MAC和SQN)。此外,EAP-AKA'产生的MSK作为IKEv2的认证密钥材料,使N3IWF能通过AUTH载荷证明自己确实与5G核心网通信。
Q3: N3IWF如何选择AMF?它没有gNB那样的NG Setup过程。
A: N3IWF在收到UE的SUCI后,从NAI中解析出PLMN ID(MCC/MNC),然后通过NRF发现或本地配置选择该PLMN的AMF。不同于gNB通过NG Setup建立与AMF的SCTP关联,N3IWF通常按需建立N2连接。部分实现中N3IWF会预先与一组AMF建立SCTP连接池。
Q4: 通过N3IWF注册的UE能否同时通过gNB注册?
A: 可以,这就是5G的多接入(Multi-Access)场景。TS 23.501允许UE通过3GPP和非3GPP接入同时注册到同一个PLMN,AMF通过注册类型和接入类型区分两个注册实例。3GPP Rel-16引入的ATSSS(Access Traffic Steering, Switching and Splitting)进一步支持两个接入间的流量聚合和分流。
Q5: 非可信和可信非3GPP接入在认证机制上有何不同?
A: 非可信接入(如公共WiFi)使用N3IWF,必须建立IKEv2+IPsec隧道,认证方法为EAP-AKA'。可信接入(如运营商WiFi)使用TNGF,UE与TNGF之间通过EAP-5G直接传输NAS消息,认证方法同样是EAP-AKA',但不需要IKEv2/IPsec层——因为接入网络本身被认为是安全的。此外,可信接入还支持EAP-TLS认证(用于NPN场景)。
本文由「51学通信」技术团队出品。51学通信由通信行业18年老兵爱卫生(微信ID: gprshome201101)维护,聚焦5G/6G核心网、3GPP标准解读、通信前沿技术深度分析。 出版作品有《5G核心网原理与实践》《IMS原理与实践》等4本通信专业书籍。知识星球「51学通信」提供深度技术答疑和行业洞察。
[!tip] 51学通信知识星球 星主:爱卫生(微信:gprshome201101)——公众号「51学通信」创办者,19 年通信行业运维与讲师经验,著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书(各大电商平台有售)。 星球定位:深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域,主打运维岗位与信令分析。 当前规模:5200 篇主题 / 990 个回答,198 元/年。 加入福利:加入星球后请加爱卫生微信,拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题,另有群内分享。 AI 加持:51学通信知识星球已作为 skill 接入 WorkBuddy,使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例,做总结、找文档和 PPT 等场景全覆盖。
