《WiMAX入网过程》PPT课件.ppt

wimax入网过程,Jade 2013,目录,概述 免认证入网 认证入网,Wimax网络架构,PSTN: Public Switched Telephone Network 公共交换电话网络 AAA: Authentication、Authorization、Accounting 认证鉴权计费服务器 ASN: Access Service Network 接入网(BS/MS/ASN GW) BS: Base station SS: Subscriber station,Wimax网络参考模型,ASN: Access Service Network; CSN: Connectivity Service Network/Core Network ASP: Application Service Provider NSP: Network Service Provider NAP: Network Access Provider Home NSP: Home Network Service Provider (可理解为用户所属的运营商) Visited NSP: Visited NSP(用户漫游到和Home NSP有漫游协议的NSP) Bearer plane: 承载平面，用户承载业务数据流 Control plane: 控制平面，用户逻辑实体间的信令交互 O&M plane：管理平面，用于逻辑实体操作维护信息的交互,网络参考模型定义各个逻辑功能实体的功能/以及他们直接按的参考接口 各个逻辑功能实体可能对应实际物理组网中一个或多个设备 从左图可以看到主要逻辑功能实体有ASN/CSN/MS(MS也可算ASN的一部分) 实际组网过程中，可能涉及终端用户/网络接入服务商/网络服务提供商/应用服务提供商 NAP/NSP/ASP等在wimax出现前已存在，wimax重点在于ASN 进一步请参考：WMF-T32-002-R010v05_Network-Stage2-Part1,ASN参考模型,BS: base station, 按照IEEE Std 802.16协议实现wimax MAC/PHY层的逻辑实体，功能包括但不限于对无线空口上下行资源的调度/管理，和ASN-GW业务连接的管理等。 ASN-GW: ASN网络对外接口功能实体，在网络上具有承上启下的作用，对内完成无线资源管理；对外完成相关控制面信令的承载/转发和业务面承载。 关于ASN侧完成的逻辑功能在BS和ASN-GW间的分解/分配请参考WMF-T32-003-R010v05_Network-Stage2-Part2中8. ASN Profile Introduction章节。,ASN网络由BS/ASN-GW/MS等实体组成 典型的MS初始接入涉及的接口为R1/R6口，R3/R4接口可能涉及，但不需重点关注 R1口为空口，为wimax协议的重中之重 进一步请参考WMF-T32-002-R010v05_Network-Stage2-Part1,接口协议栈,same,different,different,Convergence Sublayer(CS) The IEEE Std 802.16 defines multiple convergence sub layers. The network architecture framework SHALL support the following CS types: Ethernet CS and IPv4/IPv6 over Ethernet CS, IPv4 CS, IPv6 CS. 请参考WMF-T32-003-R010v05_Network-Stage2-Part1/Part2,R1接口参考模型,SAP: Service Access Point C-SAP: Control SAP M-SAP: Management SAP OFDM: orthogonal frequency division multiplexing OFDMA:orthogonal frequency division multiplex access OFDMA物理层和OFDM物理层最根本的区别在于前者 在上行和下行均支持子信道化,后者仅在上行方向支持子信道化 并且OFDMA在空口资源上分配方式更加灵活（右图）,Wimax标准定义了R1口的MAC层和PHY层 MAC层：包括CSCPSSS三个子层：CS执行外部网络数据的转换或映射到CPS子层；CPS执行MAC 核心功能，包括系统接入带宽分配连接建立与维护；SS子层主要完成安全相关功能，包括鉴权密钥交换加密。 PHY层：随着协议的演进，协议规定了3类主要的物理层技术： WirelessMAN-SC WirelessMAN-OFDM WirelessMAN-OFDMA 差别在于支持的频段是否支持移动空口性能，目前主流是支持移动的OFDMA技术 更多细节请参考IEEE Std 802.16e-2005, IEEE Standard for Local and metropolitan area networks Part 16: Air Interface for Fixed and Mobile Broadband Wireless Access Systems,目录,概述 免认证入网流程 认证入网,免认证入网流程,MS,BS,ASN-GW,DCD,UCD,DL-MAP,UL-MAP,1.MS侦听 周期广播,CDMA code,RNG-RSP(status:Continue),loop,CDMA code,RNG-RSP(status:Success),2.cdma码 调整测距,RNG-REQ,RNG-RSP,SBC-REQ,SBC-RSP,3.基本能力协商,REG-REQ,REG-RSP,DSA-REQ,DSA-RSP,DSA-ACK,loop,4.注册,5.建立业务流 连接,DHCP获取IP,MS_PreAttachment_Req,MS_PreAttachment_Rsp,MS_PreAttachment_Ack,MS_Attachment_Req,MS_Attachment_Rsq,MS_Attachment_Ack,RR_Req,RR_Rsp,RR_Ack,入网的5个步骤： 1. MS与BS取得同步 2. 初始测距 3. 基本能力协商（PHY层能力安全能力参数等等） 4. 注册（高层能力协商） 5. 建立业务流连接 message注释： D/DL代表Downlink U/UL 代表Uplink RNG: Ranging DCD: DL channel descriptor UCD: UL channel descriptor SBC:SS basic capability DSA: Dynamic service flow add,可选的认证流程,1. MS侦听下行广播,MS侦听BS下行广播信息目的： 和BS取得物理层同步 MS开机后扫描可能的连续下行频带，直到找到 一个正确的下行信道，和BS取得时间和频率上同步 和BS取得下行MAC层同步- Obtain DL parameters MS和BS取得物理层同步后，尝试搜索DL-MAP 和DCD消息，能够连续解出这2个消息将保持MAC 同步状态 取得上行通道参数- Obtain UL parameters 取得下行MAC层同步后，搜索UL-MAP和UCD消息， 获取上行发射参数，能够连续解出这2条消息将保持 同步状态 Ms和BS取得MAC层同步后，具备了发起Ranging的条件。 进一步参考IEEE Std 802.16e-2005, IEEE Standard for Local and metropolitan area networks中6.3.9.1-6.3.9.4节,MS,DCD （DIUC检索表/BSEIRP/TTG/RTG等）,UCD （UIUC检索表/上行接入的ranging相关信息等）,DL-MAP （物理帧symbol数/PHY同步信息/DCD count/BSID/DL_MAP IE等）,UL-MAP （物理帧symbol数/UCD count/UL_MAP IE等）,BS,图示说明： DIUC:DL interval usage code UIUC:UL interval usage code UIUC/DIUC分别对应上下行不同的调制/编码方式索引 EIRP：有效全向辐射功率 TTG：transmit/receive transition gap RTG：receive/transmit transition gap,2. cdma码调整测距,测距目的 不断调整SS的Timing offset/Freq offset/power offset，使得SS的发射和接收达到最优 过程要点 初始测距是一个反复的过程，Ms在上行ranging时机随机选择CDMA code，测量出MS的时偏/频偏/功率偏差等信道参数，然后响应RNG-RSP，告诉MS应该如何调整信道参数，如此反复，直到信道参数达到最优，在最后的RNG-RSP中携带给MS分配的相关资源 MS在得到分配的资源后，可以继续后续的接入流程 如果MS已经入过网且所在位置未变/BS侧配置未变时，MS复位，初始测距可能不需反复，一次可以成功（MS将相关信息记录到了FALSH中） 更多信息可参考IEEE Std 802.16e-2005, IEEE Standard for Local and metropolitan area networks中的6.3.9.5/6.3.10章节,MS,BS,RNG-REQ/CDMA code,RNG-RSP(status:Continue),loop,RNG-REQ/CDMA code,RNG-RSP(status:Success),RNG-REQ,RNG-RSP,CDMA code为一个特殊的消息序列，且任意2个序列之间不具有相关性,3.基本能力协商,目的 匹配MS和BS间的基本能力，包括PHY能力/安全能力 过程说明 MS将自身的基本支持能力通过SBC-REQ上报BS BS向ASN-GW发送消息（可携带需要到GW协商的能力），通知GW该MS入网 ASN-GW响应BS，BS将MS上报的支持能力和网络侧的支持能力取交集下发MS 更多信息可参考: IEEE Std 802.16e-2005, IEEE Standard for Local and metropolitan area networks中的6.3.9.7章节 WMF-T33-001-R015v03_Network-Stage3-Base中4.5节,MS,BS,ASN-GW,SBC-REQ,SBC-RSP,MS_PreAttachment_Req,MS_PreAttachment_Rsp,MS_PreAttachment_Ack,4.注册,目的 匹配MS和网络侧高层支持能力，包括CS支持能力/移动性参数/切换支持能力等 过程 MS通过REG-REQ携带自身的高层支持能力向BS发起注册请求 BS向ASN-GW发送消息（可携带需要到GW协商的能力），通知GW该MS发起注册，GW侧准备发起业务流建立 ASN-GW响应BS，BS将MS上报的支持能力和网络侧的支持能力取交集下发MS 更多信息可参考: IEEE Std 802.16e-2005, IEEE Standard for Local and metropolitan area networks中的6.3.9.7章节 WMF-T33-001-R015v03_Network-Stage3-Base中4.5节,MS,BS,ASN-GW,REG-REQ,REG-RSP,MS_Attachment_Req,MS_Attachment_Rsq,MS_Attachment_Ack,5. 业务流建立,目的 建立预配置业务流，即建立端到端的业务承载通道 过程 ASN-GW侧在收到MS的REG-REQ时，主动发起预配置业务流建立，携带业务流相关参数向BS下发RR_REQ消息 BS向MS下发DSA_REQ消息将业务流信息通知MS MS通过DSA_RSP响应BS，并向MS返回DSA_ACK BS向ASN-GW返回RR_RSP完成业务流建立 业务流建立完成后，可以进行业务，随后发起的DHCP过程即使用第一条预配置业务流（ISF）来承载 第一条建立的预置业务流成为初始业务流(ISF),用来承载对于时延不敏感的业务，比如随后的DHCP过程 ISF只有一条，除ISF外的预置业务流可以有多条,MS,BS,ASN-GW,DSA-REQ,DSA-RSP,DSA-ACK,loop,通过预配置业务流承载DHCP协议获取IP,RR_Req,RR_Rsp,更多信息可参考: IEEE Std 802.16e-2005, IEEE Standard for Local and metropolitan area networks中的6.3.14.7.1章节 WMF-T33-001-R015v03_Network-Stage3-Base中4.6.4.5.2节,目录,概述 免认证入网 认证入网,认证基础- EAP概述,EAP：Extensible Authentication Protocol 是一个认证框架，在此框架上可以支持或者说承载多种认证协议方法，比如EAP-TLSEAP-TTLS 交互方式采用lock-step，同时只能有一个报文在传输，等到对方响应后才可以发送下一个报文一般是request/response1，nsuccess/failure1 支持重传，但是不支持分片和重组 认证由server发起，而不是client 2. 通用包格式定义,Code：1byte, 目前只有4种定义： 1 Request 2 Response 3 Success 4 Failure Identifier : 1byte，认证双方通信时用的transId，匹配一个Request和Response Length: 2byte, 报文长度，从Code字段开始。 Data：报文内容，根据Code取值不同，需要进一步扩展。,认证消息交互基本框架,认证基础- EAP消息格式,Request和Response报文格式,进一步请参考RFC3748 Extensible Authentication Protocol,Type定义:,Type字段可以由EAP承载的认证协议扩展，比如EAP-TTLS，Type字段为21；EAP-TLS，Type取值为13. Nak用于接收方向发送方反馈，接收方不支持发送方指定的type，同时携带接收方支持的type通知发送方可以用这些type（下文设备认证将看到此应用）,Success和Failure报文格式,认证基础- EAP-TTLS概述,EAP-TTLS：Extensible Authentication Protocol Tunneled Transport Layer Security Authenticated Protocol Version 0 (EAP-TTLSv0) 是EAP承载的一种方法，其封装了TLS协议，认证过程划分为2个阶段： Phase1：Handshake，完成client和server的双向认证，或者只是完成server到client的认证，同时协商出2阶段tunnel使用的cipher suite，保障tunnel阶段数据的安全传输。 Phase2：Tunnel，通过TLS record layer建立的隧道在client和server间传输任意数据，完成特定的功能。包括client到server的认证，在Tunnel承载的认证协议可以是PAP, CHAP, MS-CHAP, or MS-CHAP-V2，MD5等。 CPE使用用户认证方式时，采用EAP-TTLS协议，第一阶段完成server到CPE的认证，第二阶段使用指定的认证承载协议（可配置为PAPCHAPMS-CHAPMS-CHAP-V2MD5）完成CPE到server的认证 2. 协议分层模型,进一步参考RFC5281 EAP-TTLS,AVP，attribute-value pairs，类似TLV,认证基础- EAP-TTLS消息格式,包格式,进一步参考RFC5281 EAP-TTLS,Code(Request/Response)IdentifierLengthType(21) 见EAP协议； Flags,Data,认证基础- EAP-TTLS 密钥(MSK)生成,Key Derivation,进一步参考RFC5281 EAP-TTLS,EAP-TTLS协商完毕后，将按如上算法生成MSKEMSK，此值将用于后续的密钥生成。 TLS PRF(pseudo-random function) function 参考rfc5216/rfc2246 .,认证基础- EAP-TLS,EAP承载的认证方法 支持client和server间基于证书的相互认证密钥生成 流程基本同EAP-TTLS，相比EAP-TTLS少了tunnel阶段，安全性略差，由于只支持基于证书的相互认证，CPE设备认证可以采用该协议，用户认证需要使用EAP-TTLS协议 进一步请参考RFC5216 EAP-TLS 左图为典型的交互流程：包含identify证书 交换密钥（premaster secret）交换等过程,进一步参考RFC5281 EAP-TTLS,认证基础-TLS概述,TLS: Transport Layer Security 提供Internet网络的传输安全，对于client和server间的数据传输提供了防窃听，防篡改，防伪造功能。 包括2层：the TLS Record Protocol and the TLS Handshake Protocol. TLS Record Layer用于封装各种高层协议（例如可以封装TLS Handshake Protocol），安全性说明： TLS Record Layer通过对称加密算法保证传输数据的私密性 通过MAC（message authentication code）保证传输数据的完整性，将待传输数据（压缩（可选）后加密前）联合密钥通过HASH算法（MD5/SHA）生成MAC code，供接收方校验完整性 TLS Handshake用于服务器和客户端相互认证和协商应用层协议的加密算法和加密密钥,进一步参考RFC2246 TLS1.0,认证基础-TLS安全参数,安全参数生成,加密算法：rc4, rc2, des, 3des, des40, idea, aes 可以为null,加密算法类型：block方式流方式,MAC算法：md5, sha,压缩算法，可以为空,双方共知的48byte secret,client端random,server端ramdom,进一步参考RFC2246 TLS1.0,block加密使用，non-export block ciphers 方式通过此方式生成，exportable block ciphers 方式需要进一步算法生成,认证基础-TLS通用包格式,TLS Record Layer 包格式,进一步参考RFC2246 TLS1.0,Type：承载的协议类型 change_cipher_spec: 20 alert: 21 handshake: 22 application_data: 23 version: 版本号 目前有1.0(RFC2246)/1.1(RFC4346)/1.2(RFC?)，抓包看到华为wimax是0301，对应1.0(RFC2246), 由于TSL基于SSL3.0演变而来，所以消息编码为3.1（0301）。 length：后续数据长度 fragment：协议报文 当fragment经过压缩/加密后，格式路略有变化，具体参考协议,认证基础-TLS通用包格式,TLS Record Layer 包格式,进一步参考RFC2246 TLS1.0,Type：承载的协议类型 change_cipher_spec: 20 alert: 21 handshake: 22 application_data: 23 version: 版本号 目前有1.0(RFC2246)/1.1(RFC4346)/1.2(RFC?)，抓包看到华为wimax是0301，对应1.0(RFC2246), 由于TSL基于SSL3.0演变而来，所以消息编码为3.1（0301）。 length：后续数据长度 fragment：协议报文 当fragment经过压缩/加密后，格式路略有变化，具体参考协议,认证基础-TLS Handshake Protocol,TLS Handshake Protocol 用于双方协商安全参数相互认证 包含3个子协议： Change cipher spec protocol 用于在安全参数协商过后，通知对方随后的交互将使用之前刚刚协商的安全参数进行加密处理 该子协议只包含change_cipher_spec(1)这1条消息 Alert protocol 传递告警信息 Handshake protocol 见下页,进一步参考RFC2246 TLS1.0,Handshake过程： 协商加密算法/交换random 交换信息双方生成一致的premaster secret 交换证书和加密信息并认证 生成Master secret 给record layer提供加密参数 验证双方生成了相同的安全参数,认证基础-TLS Handshake Protocol包格式,Handshake protocol用于协商安全参数 包格式定义：,进一步参考RFC2246 TLS1.0,包含的消息类型,认证基础-TLS hello message,Handshake type 之hello message 包括hello request / client hello / server hello 三个消息，这3个消息用于双方协商安全能力：加密能力/压缩能力 Hello request 只用于server请求client发送 client hello消息，即server要求client发起协商 Client hello 用于client主动向server发起协商流程 消息中包含random值（32byte（4byte GMT TIME+28byte random）client支持的CipherSuite listclient支持的压缩算法 Server hello server对client的hello消息的响应 消息中包含random值/server选择的CipherSuite/server选择的压缩算法以及分配的session id,进一步参考RFC2246 TLS1.0,认证基础-TLS Server certificate,Handshake type 之Server certificate Server发送证书给client 证书格式参考X.509v3 证书的key和签名必须 和hello协商的Ciphersuite 指定加密方式一致,进一步参考RFC2246 TLS1.0,认证基础-TLS Server key exchange message,Handshake type 之 Server key exchange message The server key exchange message is sent by the server only when the server certificate message (if sent) does not contain enough data to allow the client to exchange a premaster secret. This message conveys cryptographic information to allow the client to communicate the premaster secret：either an RSA public key to encrypt the premaster secret with, or a Diffie-Hellman public key with which the client can complete a key exchange 帮助client计算server的premaster值,进一步参考RFC2246 TLS1.0 和附录1 DH密钥交换算法,认证基础-TLS Certificate request,Handshake type 之 Certificate request 用于server向client请求证书（可选） 目前认证流程不涉及，进一步信息参考协议RFC2246 7.4.3,进一步参考RFC2246 TLS1.0,认证基础-TLS Server hello done,Handshake type 之 Server hello done The server hello done message is sent by the server to indicate the end of the server hello and associated messages. 目前认证流程不涉及，进一步信息参考协议RFC2246 7.4.3,进一步参考RFC2246 TLS1.0,认证基础-TLS Client certificate,Handshake type 之 Client certificate 发送client端证书 证书格式参考X.509v3,进一步参考RFC2246 TLS1.0,认证基础-TLS Client key exchange message,Handshake type 之 Client key exchange message With this message, the premaster secret is set, either though direct transmission of the RSA-encrypted secret, or by the transmission of Diffie-Hellman parameters which will allow each side to agree upon the same premaster secret. 用于client通知server 客户端的premaster secret，比如密钥交换算法选择RSA时，client用server段下发证书中的public key将自身产生的48byte的premaster secret加密，发给server；采用密钥交换算法采用DH时，client和server互换DH计算参数，从而双方生成一致的premaster secret,进一步参考RFC2246 TLS1.0,认证基础-TLS Certificate verify message,Handshake type 之 Certificate verify This message is used to provide explicit verification of a client certificate. When sent, it will immediately follow the client key exchange message. 包格式,进一步参考RFC2246 TLS1.0,认证基础-TLS Finished message,Handshake type 之 Finished A finished message is always sent immediately after a change cipher spec message to verify that the key exchange and authentication processes were successful. The finished message is the first protected with the just-negotiated algorithms, keys, and secrets. Recipients of finished messages must verify that the contents are correct.,进一步参考RFC2246 TLS1.0,认证基础-TLS Handshake message 总结,Handshake type 之 Finished 原则上述消息必须按照上文描述的顺序发送，只有2个例外： the Certificate message is used twice in the handshake (from server to client, then from client to server), but described only in its first position. The one message which is not bound by these ordering rules in the Hello Request message, which can be sent at any time, but which should be ignored by the client if it arrives in the middle of a handshake.,进一步参考RFC2246 TLS1.0,认证基础-MS-CHAP-V2,MS-CHAP-V2: Microsoft PPP CHAP Extensions, Version 2. MS基于PPP CHAP协议的扩展增强版本，主要增强了用户认证功能 通过3-way handshake验证peer的身份： 1. authenticators发送生成并发送challenge code（随机数），消息中携带了用户名 2. Client根据16-octet challenge Valueusernamepassword经过一定算法生成RADOM值（24byte），发送给authenticator 3. authenticator经过同样算法计算得到Hash值，与Client发来的RADOM值比较成功时，返回Success CPE采用用户认证方式时，由CPE发起Challenge，在该消息中，CPE根据CPE challenge值usernamepasspeer challenge值经过一定算法成生24byte的RADOM值，连同CPE challenge值usernamepeer challenge值一并发给server；server根据Challenge中的username获取到对应的密码，根据同样的算法生成RADOM值，和CPE发送来的RADOM比较，一致返回success，否则返回失败。,进一步参考RFC1994 CHAPRFC2433 MS-CHAPRFC2759 MS-CHAP-V2,CPE认证分类,认证的目的在于双方互相判断对方是否合法，同时协商加密信息，用于后续报文的安全传输。 认证分类： 免认证 用户认证 CPE认证AAA based on X.509 certificate AAA认证CPE基于用户名密码 CPE和AAA间基于EAP-TTLS认证协议 设备认证 CPE和AAA相互认证based on X.509 certificate CPE和AAA间基于EAP-TLS认证协议,认证协议栈,进一步请参考： 参考WMF-T32-001-R015v02_Network-Stage2-Base7.4节 参考RFC5281 EAP-TTLS,从协议栈可以看出，认证过程在MS和AAA间完成，中间网络节点提供EAP通道 在R1口EAP通过PKMV2（wimax定制）承载 EAP属于一个认证流程的处理框架，其上可以承载多种具体的安全协议/认证协议 CPE采用用户认证时，可以配置EAP具体承载的认证协议来安全的传输CPE的用户名和密码信息给AAA，支持如下5种协议： MS-CHAP/MS-CHAP V2 CHAP(Challenge Auth. Protocol) MD5 PAP(Password Auth. Protocol) CPE采用设备认证时，由于AAA使用证书认证CPE，不需传递用户名/密码，所以不需配置认证协议。,(用户认证) / EAP-TLS(设备认证）,设备认证不需要,安全子层,PKM： privacy key management 进一步请参考P80216Rev_037节,Traffic data:业务面加解密/业务面分包认证 Message Authentication Processing：控制面分包认证(HMAC/CMAC/short-HMACs) Control Message Processing:PKM消息分发处理 PKM Control Management：SS控制管理层，密钥生成分发 RSA-based Authentication：基于RSA的X.509数字证书的认证处理 Authorization/SA Control:认证状态机和业务加密密钥状态机控制 EAP Encapsulation/Decapsulation: EAP接口处理层 EAP参考前文认证基础 PKMv1 provides support for only Device Authentication whereas PKMv2 provides a flexible solution that supports device and user authentication between MS and home CSN.,WIMAX密钥体系一,进一步请参考P80216Rev_037节,MSK：经过EAP认证后网络侧和MS都生成了同样的MSK(Master session key) PMK：取MSK的160bit作为PMK(pairwise master key) PMK联合SSIDBSIDPMK生成AK(authorization key )，AK用于进一步派生其他密钥,WIMAX密钥体系二,进一步请参考P80216Rev_037节,MAC(message authentication code)模式:CMAC/HMAC分别是基于加密和基于hash方式生成MAC值 CMAC_PREKEY_U/D用于在CMAC模式生成MAC值 HMAC_KEY_U/D用于在HMAC模式生成MAC值 KEK(key encryption key)用于加密其他密钥，比如TEK(Traffic encryption key)/GTEK(group TEK) TEK(Traffic encryption key)用于业务面加密，MAC消息中通用头不加密，只有payload才会加密，由BS负责生成，下发MS。 其他非重要KEY参见协议,CPE认证配置说明,1. 业务面加密配置：业务面加密选项，wimax协议上有四种：DES-CBCASE-CCMAES-CBCASE-CTR，从配置上看，只能配置2种，具体使用哪种由BS配置给MS AES：advanced encryption standard CTR：counter mode encryption CBC：cipher block chaining CBC-MAC：cipher block chaining message authentication code CCM：CTR mode with CBC-MAC ECB： electronic code book 2. 密钥交换配置： AES-Key Wrap：是否使能AES key wrap algorithm，BS发送给CPE的业务面key将经过该算法处理， MS根据相同算法还原该key AES-ECB：BS发送给CPE的业务面KEY是否经过AES ECB加密 上述是TEK配置给MS时，BS侧采用的加密方式，协议上支持4种：3-DESRSAAES-ECBAES-Key Wrap，具体采用哪种由BS配置给MS。 EAP Mode： 认证承载协议 Internal Mode: 认证方法（用户认证时使用） Anonymous ID: NAI（Network access identifier）,用于认证时CPE上报AAA，帮助中继设备转发到合适的服务器。 3. 证书配置：用于CPE验证AAA下发的AAA证书是否合法 进一步参考WMF-T32-001-R015v02_Network-Stage2-Base7节,3,2,1,CPE认证配置说明,1. 业务面加密配置：业务面加密选项 AES：advanced encryption standard CTR：counter mode encryption CBC：cipher block chaining CBC-MAC：cipher block chaining message authentication code CCM：CTR mode with CBC-MAC ECB： electronic code book 2. 密钥交换配置： AES-Key Wrap：是否使能AES key wrap algorithm，BS发送给CPE的业务面key将经过该算法处理， MS根据相同算法还原该key AES-ECB：BS发送给CPE的业务面KEY是否经过AES ECB加密 EAP Mode： 认证承载协议 Internal Mode: 认证方法（用户认证时使用）,可以是PAP/CHAP/MSCHAPV2/MD5。 Anonymous ID: NAI（Network access identifier）,用于认证时CPE上报AAA，帮助中继设备转发到合适的服务器。 3. 证书配置：用于CPE验证AAA下发的AAA证书是否合法 进一步参考WMF-T32-001-R015v02_Network-Stage2-Base7节,3,2,1,wimax认证整体流程,CPE和AAA Server双向认证阶段： 双向认证完毕后，CPE和AAA S ERVER将生成相同的MSK和EMSK,SA生成阶段：CPE和GW 根据MSK，各自生成相同 的PMK，再由PMK联合MSIDBSID 生AK和AK上下文,AK由GW下发BS,密钥下发阶段：通过3次握手（6） 完成SAAK验证以及Primary SA的分配；同时通过（7）完成每 个SA关联的2个TEK(traffic encryption key)的生成和下发 CPE,进一步参考 7.3.10 和 PART16中7.3.10.2节,wimax认证流程-双向认证,进一步信息参考前文TLS协议,MS,BS,EAP request/Identify,ASN-GW,AAA,EAP response/Identify-NAI,EAP-reponse/identify over AAA,EAP request/TTLS-Start,EAP-request/TTLS-Start over AAA,EAP response/TTLS/ TLS: Client hello,EAP request/TTLS/ TLS: Server hello/ certificate Server key exchange/ Server hello done,EAP over AAA,EAPover AAA,EAP response/TTLS/ TLS: Client key exchange/ Change cipher spec/finished,EAP over AAA,EAP over AAA,EAP request/TTLS/ TLS: Change cipher spec/finished,EAP response/TTLS/ TLS: Peer response/challenge,EAP request/TTLS/ TLS: success/Authenticator response,EAP response/TTLS(no data),EAP over AAA,EAP over AAA,EAP Success,EAP over AAA,EAP over AAA,基本能力协商后，ASN-GW发起EAP Identify流程，MS将响应EAP Identify/NAI ,ASN-GW根据NAI指定的域名将消息转发 AAA，随后后续的流程实际上都是经过GW 透传给MS,1.MS和AAA通过TLS完成AAA到MS的 认证（采用数字证书方式），同时完成了 PRE MSK的交换（通过DH或RSA） 2. 左图为用户认证方式，如果为设备认证时 MS侧也需要将自己的证书发送发送AAA 完成MS到AAA的认证 3. 经过此步后，AAA和MS可以生成的 MSK/EMSK, AAA会将MSK下发给GW， GW进一步生成PMK/AK，并下发BS,1. 当认证方式为用户认证时，进一步通过认证 协议完成MS到AAA的认证（认证协议可以 是mschapv2/mschap/chap/md5/pap）, 当设备认证时，不含此步骤,wimax认证流程-用户认证双向认证实例,MS,BS,EAP request/Identify,ASN-GW,EAP response/Identify-NAI,EAP request/TTLS-Start,EAP response/TTLS/ TLS: Client hello,EAP request/TTLS/ TLS: Server hello/ certificate Server key exchange/ Server hello done,EAP response/TTLS/ TLS: Client key exchange/ Change cipher spec/finished,EAP request/TTLS/ TLS: Change cipher spec/finished,EAP response/TTLS/ TLS: Peer response/challenge,EAP request/TTLS/ TLS: succe