《《WiMAX入網(wǎng)過程》PPT課件》由會員分享，可在線閱讀，更多相關(guān)《《WiMAX入網(wǎng)過程》PPT課件（65頁珍藏版）》請在裝配圖網(wǎng)上搜索。

1、wimax入網(wǎng)過程入網(wǎng)過程Jade 2013目錄概述免認(rèn)證入網(wǎng)認(rèn)證入網(wǎng)Wimax網(wǎng)絡(luò)架構(gòu)PSTN:Public Switched Telephone Network 公共交換電話網(wǎng)絡(luò)AAA:Authentication、Authorization、Accounting 認(rèn)證鑒權(quán)計費服務(wù)器ASN:Access Service Network 接入網(wǎng)(BS/MS/ASN GW)BS:Base stationSS:Subscriber stationPSTNIP CoreSSSSSSPCMCIAASN GWWimax網(wǎng)絡(luò)參考模型ASN:Access Service Network;CSN:Conne

2、ctivity 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有漫游協(xié)議的NSP)Bearer plane:承載平面，用戶承載業(yè)務(wù)數(shù)據(jù)流 Control plane:控制平面，用戶邏輯實體間的信令交互O&M plane：管理平面

3、，用于邏輯實體操作維護(hù)信息的交互網(wǎng)絡(luò)參考模型定義各個邏輯功能實體的功能/以及他們直接按的參考接口各個邏輯功能實體可能對應(yīng)實際物理組網(wǎng)中一個或多個設(shè)備從左圖可以看到主要邏輯功能實體有ASN/CSN/MS(MS也可算ASN的一部分)實際組網(wǎng)過程中，可能涉及終端用戶/網(wǎng)絡(luò)接入服務(wù)商/網(wǎng)絡(luò)服務(wù)提供商/應(yīng)用服務(wù)提供商NAP/NSP/ASP等在wimax出現(xiàn)前已存在，wimax重點在于ASN進(jìn)一步請參考：WMF-T32-002-R010v05_Network-Stage2-Part1ASN參考模型BS:base station,按照協(xié)議實現(xiàn)wimax MAC/PHY層的邏輯實體，功能包括但不限于對無線空口

4、上下行資源的調(diào)度/管理，和ASN-GW業(yè)務(wù)連接的管理等。ASN-GW:ASN網(wǎng)絡(luò)對外接口功能實體，在網(wǎng)絡(luò)上具有承上啟下的作用，對內(nèi)完成無線資源管理；對外完成相關(guān)控制面信令的承載/轉(zhuǎn)發(fā)和業(yè)務(wù)面承載。關(guān)于ASN側(cè)完成的邏輯功能在BS和ASN-GW間的分解/分配請參考WMF-T32-003-R010v05_Network-Stage2-Part2中8.ASN Profile Introduction章節(jié)。ASN網(wǎng)絡(luò)由BS/ASN-GW/MS等實體組成典型的MS初始接入涉及的接口為R1/R6口，R3/R4接口可能涉及，但不需重點關(guān)注R1口為空口，為wimax協(xié)議的重中之重進(jìn)一步請參考WMF-T32-0

5、02-R010v05_Network-Stage2-Part1接口協(xié)議棧samedifferentdifferentConvergence 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_Netw

6、ork-Stage2-Part1/Part2R1接口參考模型SAP:Service Access Point C-SAP:Control SAP M-SAP:Management SAPOFDM:orthogonal frequency division multiplexingOFDMA:orthogonal frequency division multiplex accessOFDMA物理層和OFDM物理層最根本的區(qū)別在于前者在上行和下行均支持子信道化,后者僅在上行方向支持子信道化并且OFDMA在空口資源上分配方式更加靈活（右圖）Wimax標(biāo)準(zhǔn)定義了R1口的MAC層和PHY層MAC層：包

7、括CSCPSSS三個子層：CS執(zhí)行外部網(wǎng)絡(luò)數(shù)據(jù)的轉(zhuǎn)換或映射到CPS子層；CPS執(zhí)行MAC 核心功能，包括系統(tǒng)接入帶寬分配連接建立與維護(hù)；SS子層主要完成安全相關(guān)功能，包括鑒權(quán)密鑰交換加密。PHY層：隨著協(xié)議的演進(jìn)，協(xié)議規(guī)定了3類主要的物理層技術(shù)：WirelessMAN-SCWirelessMAN-OFDMWirelessMAN-OFDMA 差別在于支持的頻段是否支持移動空口性能，目前主流是支持移動的OFDMA技術(shù)更多細(xì)節(jié)請參考IEEE Std 802.16e-2005,IEEE Standard for Local and metropolitan area networks Part 16:

8、Air Interface for Fixed and Mobile Broadband Wireless Access Systems目錄概述免認(rèn)證入網(wǎng)流程認(rèn)證入網(wǎng)免認(rèn)證入網(wǎng)流程MSBSASN-GWDCDUCDDL-MAPUL-MAP偵聽周期廣播CDMA codeRNG-RSP(status:Continue)loopCDMA codeRNG-RSP(status:Success)碼調(diào)整測距RNG-REQRNG-RSPSBC-REQSBC-RSP3.基本能力協(xié)商REG-REQREG-RSPDSA-REQDSA-RSPDSA-ACKloop4.注冊5.建立業(yè)務(wù)流連接DHCP獲取IPMS_Pre

9、Attachment_ReqMS_PreAttachment_RspMS_PreAttachment_AckMS_Attachment_ReqMS_Attachment_RsqMS_Attachment_AckRR_ReqRR_RspRR_Ack入網(wǎng)的5個步驟：1.MS與BS取得同步2.初始測距3.基本能力協(xié)商（PHY層能力安全能力參數(shù)等等）4.注冊（高層能力協(xié)商）5.建立業(yè)務(wù)流連接message注釋：D/DL代表DownlinkU/UL 代表UplinkRNG:RangingDCD:DL channel descriptorUCD:UL channel descriptorSBC:SS ba

10、sic capabilityDSA:Dynamic service flow add可選的認(rèn)證流程1.MS偵聽下行廣播MS偵聽BS下行廣播信息目的：和和BS取得物理層同步取得物理層同步MS開機(jī)后掃描可能的連續(xù)下行頻帶，直到找到一個正確的下行信道，和BS取得時間和頻率上同步和和BS取得下行取得下行MAC層同步層同步-Obtain DL parametersMS和BS取得物理層同步后，嘗試搜索DL-MAP和DCD消息，能夠連續(xù)解出這2個消息將保持MAC同步狀態(tài)取得上行通道參數(shù)取得上行通道參數(shù)-Obtain UL parameters取得下行MAC層同步后，搜索UL-MAP和UCD消息，獲取上行發(fā)射

11、參數(shù)，能夠連續(xù)解出這2條消息將保持同步狀態(tài)Ms和BS取得MAC層同步后，具備了發(fā)起Ranging的條件。進(jìn)一步參考IEEE Std 802.16e-2005,IEEE Standard for Local and metropolitan area networks中節(jié)MSDCD（DIUC檢索表/BSEIRP/TTG/RTG等）UCD（UIUC檢索表/上行接入的ranging相關(guān)信息等）DL-MAP（物理幀symbol數(shù)/PHY同步信息/DCD count/BSID/DL_MAP IE等）UL-MAP（物理幀symbol數(shù)/UCD count/UL_MAP IE等）BS圖示說明：DIUC:DL

12、 interval usage codeUIUC:UL interval usage codeUIUC/DIUC分別對應(yīng)上下行不同的調(diào)制分別對應(yīng)上下行不同的調(diào)制/編碼方式索引編碼方式索引EIRP：有效全向輻射功率：有效全向輻射功率TTG：transmit/receive transition gapRTG：receive/transmit transition gap2.cdma碼調(diào)整測距測距目的不斷調(diào)整SS的Timing offset/Freq offset/power offset，使得SS的發(fā)射和接收達(dá)到最優(yōu)過程要點初始測距是一個反復(fù)的過程，Ms在上行ranging時機(jī)隨機(jī)選擇CDMA

13、code，測量出MS的時偏/頻偏/功率偏差等信道參數(shù)，然后響應(yīng)RNG-RSP，告訴MS應(yīng)該如何調(diào)整信道參數(shù)，如此反復(fù)，直到信道參數(shù)達(dá)到最優(yōu)，在最后的RNG-RSP中攜帶給MS分配的相關(guān)資源MS在得到分配的資源后，可以繼續(xù)后續(xù)的接入流程如果MS已經(jīng)入過網(wǎng)且所在位置未變/BS側(cè)配置未變時，MS復(fù)位，初始測距可能不需反復(fù)，一次可以成功（MS將相關(guān)信息記錄到了FALSH中）更多信息可參考IEEE Std 802.16e-2005,IEEE Standard for Local and metropolitan area networks中的章節(jié)MSBSRNG-REQ/CDMA codeRNG-RSP(

14、status:Continue)loopRNG-REQ/CDMA codeRNG-RSP(status:Success)RNG-REQRNG-RSPCDMA code為一個特殊的消息序列，且任意2個序列之間不具有相關(guān)性3.基本能力協(xié)商目的匹配MS和BS間的基本能力，包括PHY能力/安全能力過程說明MS將自身的基本支持能力通過SBC-REQ上報BSBS向ASN-GW發(fā)送消息（可攜帶需要到GW協(xié)商的能力），通知GW該MS入網(wǎng)ASN-GW響應(yīng)BS，BS將MS上報的支持能力和網(wǎng)絡(luò)側(cè)的支持能力取交集下發(fā)MS更多信息可參考:IEEE Std 802.16e-2005,IEEE Standard for L

15、ocal and metropolitan area networks中的章節(jié)WMF-T33-001-R015v03_Network-Stage3-Base中節(jié)MSBSASN-GWSBC-REQSBC-RSPMS_PreAttachment_ReqMS_PreAttachment_RspMS_PreAttachment_Ack4.注冊目的匹配MS和網(wǎng)絡(luò)側(cè)高層支持能力，包括CS支持能力/移動性參數(shù)/切換支持能力等過程MS通過REG-REQ攜帶自身的高層支持能力向BS發(fā)起注冊請求BS向ASN-GW發(fā)送消息（可攜帶需要到GW協(xié)商的能力），通知GW該MS發(fā)起注冊，GW側(cè)準(zhǔn)備發(fā)起業(yè)務(wù)流建立ASN-GW響

16、應(yīng)BS，BS將MS上報的支持能力和網(wǎng)絡(luò)側(cè)的支持能力取交集下發(fā)MS更多信息可參考:IEEE Std 802.16e-2005,IEEE Standard for Local and metropolitan area networks中的章節(jié)WMF-T33-001-R015v03_Network-Stage3-Base中節(jié)MSBSASN-GWREG-REQREG-RSPMS_Attachment_ReqMS_Attachment_RsqMS_Attachment_Ack5.業(yè)務(wù)流建立目的建立預(yù)配置業(yè)務(wù)流，即建立端到端的業(yè)務(wù)承載通道過程ASN-GW側(cè)在收到MS的REG-REQ時，主動發(fā)起預(yù)配置業(yè)務(wù)

17、流建立，攜帶業(yè)務(wù)流相關(guān)參數(shù)向BS下發(fā)RR_REQ消息BS向MS下發(fā)DSA_REQ消息將業(yè)務(wù)流信息通知MSMS通過DSA_RSP響應(yīng)BS，并向MS返回DSA_ACKBS向ASN-GW返回RR_RSP完成業(yè)務(wù)流建立業(yè)務(wù)流建立完成后，可以進(jìn)行業(yè)務(wù)，隨后發(fā)起的DHCP過程即使用第一條預(yù)配置業(yè)務(wù)流（ISF）來承載第一條建立的預(yù)置業(yè)務(wù)流成為初始業(yè)務(wù)流(ISF),用來承載對于時延不敏感的業(yè)務(wù)，比如隨后的DHCP過程ISF只有一條，除ISF外的預(yù)置業(yè)務(wù)流可以有多條MSBSASN-GWDSA-REQDSA-RSPDSA-ACKloop通過預(yù)配置業(yè)務(wù)流承載DHCP協(xié)議獲取IPRR_ReqRR_Rsp更多信息可參考

18、:IEEE Std 802.16e-2005,IEEE Standard for Local and metropolitan area networks中的章節(jié)WMF-T33-001-R015v03_Network-Stage3-Base中節(jié)目錄概述免認(rèn)證入網(wǎng)認(rèn)證入網(wǎng)認(rèn)證基礎(chǔ)-EAP概述EAP：Extensible Authentication Protocol是一個認(rèn)證框架，在此框架上可以支持或者說承載多種認(rèn)證協(xié)議方法，比如EAP-TLSEAP-TTLS交互方式采用lock-step，同時只能有一個報文在傳輸，等到對方響應(yīng)后才可以發(fā)送下一個報文一般是request/response1，ns

19、uccess/failure1支持重傳，但是不支持分片和重組認(rèn)證由server發(fā)起，而不是client2.通用包格式定義Code：1byte,目前只有4種定義：1 Request2 Response 3 Success4 FailureIdentifier:1byte，認(rèn)證雙方通信時用的transId，匹配一個Request和ResponseLength:2byte,報文長度，從Code字段開始。Data：報文內(nèi)容，根據(jù)Code取值不同，需要進(jìn)一步擴(kuò)展。認(rèn)證消息交互基本框架認(rèn)證基礎(chǔ)-EAP消息格式Request和Response報文格式進(jìn)一步請參考RFC3748 Extensible Auth

20、entication ProtocolType定義:Type字段可以由EAP承載的認(rèn)證協(xié)議擴(kuò)展，比如EAP-TTLS，Type字段為21；EAP-TLS，Type取值為13.Nak用于接收方向發(fā)送方反饋，接收方不支持發(fā)送方指定的type，同時攜帶接收方支持的type通知發(fā)送方可以用這些type（下文設(shè)備認(rèn)證將看到此應(yīng)用）Success和Failure報文格式認(rèn)證基礎(chǔ)-EAP-TTLS概述 EAP-TTLS：Extensible Authentication Protocol Tunneled Transport Layer Security Authenticated Protocol Ver

21、sion 0(EAP-TTLSv0)是EAP承載的一種方法，其封裝了TLS協(xié)議，認(rèn)證過程劃分為2個階段：Phase1：Handshake，完成client和server的雙向認(rèn)證，或者只是完成server到client的認(rèn)證，同時協(xié)商出2階段tunnel使用的cipher suite，保障tunnel階段數(shù)據(jù)的安全傳輸。Phase2：Tunnel，通過TLS record layer建立的隧道在client和server間傳輸任意數(shù)據(jù)，完成特定的功能。包括client到server的認(rèn)證，在Tunnel承載的認(rèn)證協(xié)議可以是PAP,CHAP,MS-CHAP,or MS-CHAP-V2，MD5等。

22、CPE使用用戶認(rèn)證方式時，采用EAP-TTLS協(xié)議，第一階段完成server到CPE的認(rèn)證，第二階段使用指定的認(rèn)證承載協(xié)議（可配置為PAPCHAPMS-CHAPMS-CHAP-V2MD5）完成CPE到server的認(rèn)證2.協(xié)議分層模型進(jìn)一步參考RFC5281 EAP-TTLSAVP，attribute-value pairs，類似TLV認(rèn)證基礎(chǔ)-EAP-TTLS消息格式包格式進(jìn)一步參考RFC5281 EAP-TTLSCode(Request/Response)IdentifierLengthType(21)見EAP協(xié)議；FlagsData認(rèn)證基礎(chǔ)-EAP-TTLS 密鑰(MSK)生成Key D

23、erivation進(jìn)一步參考RFC5281 EAP-TTLSEAP-TTLS協(xié)商完畢后，將按如上算法生成MSKEMSK，此值將用于后續(xù)的密鑰生成。TLS PRF(pseudo-random function)function 參考rfc5216/rfc2246.認(rèn)證基礎(chǔ)-EAP-TLSEAP承載的認(rèn)證方法支持client和server間基于證書的相互認(rèn)證密鑰生成流程基本同EAP-TTLS，相比EAP-TTLS少了tunnel階段，安全性略差，由于只支持基于證書的相互認(rèn)證，CPE設(shè)備認(rèn)證可以采用該協(xié)議，用戶認(rèn)證需要使用EAP-TTLS協(xié)議進(jìn)一步請參考RFC5216 EAP-TLS左圖為典型的交互

24、流程：包含identify證書交換密鑰（premaster secret）交換等過程進(jìn)一步參考RFC5281 EAP-TTLS認(rèn)證基礎(chǔ)-TLS概述TLS:Transport Layer Security提供Internet網(wǎng)絡(luò)的傳輸安全，對于client和server間的數(shù)據(jù)傳輸提供了防竊聽，防篡改，防偽造功能。包括2層：the TLS Record Protocol and the TLS Handshake Protocol.TLS Record Layer用于封裝各種高層協(xié)議（例如可以封裝TLS Handshake Protocol），安全性說明：TLS Record Layer通過對稱

25、加密算法保證傳輸數(shù)據(jù)的私密性通過MAC（message authentication code）保證傳輸數(shù)據(jù)的完整性，將待傳輸數(shù)據(jù)（壓縮（可選）后加密前）聯(lián)合密鑰通過HASH算法（MD5/SHA）生成MAC code，供接收方校驗完整性TLS Handshake用于服務(wù)器和客戶端相互認(rèn)證和協(xié)商應(yīng)用層協(xié)議的加密算法和加密密鑰進(jìn)一步參考認(rèn)證基礎(chǔ)-TLS安全參數(shù)安全參數(shù)生成加密算法：rc4,rc2,des,3des,des40,idea,aes可以為null加密算法類型：block方式流方式MAC算法：md5,sha壓縮算法，可以為空雙方共知的48byte secretclient端randomse

26、rver端ramdom進(jìn)一步參考block加密使用，non-export block ciphers方式通過此方式生成，exportable block ciphers方式需要進(jìn)一步算法生成認(rèn)證基礎(chǔ)-TLS通用包格式TLS Record Layer 包格式進(jìn)一步參考Type：承載的協(xié)議類型change_cipher_spec:20alert:21handshake:22application_data:23version:版本號目前有1.0(RFC2246)/1.1(RFC4346)/1.2(RFC?)，抓包看到華為wimax是0301，對應(yīng)1.0(RFC2246),由于TSL基于演變而來，所

27、以消息編碼為（0301）。length：后續(xù)數(shù)據(jù)長度fragment：協(xié)議報文當(dāng)fragment經(jīng)過壓縮/加密后，格式路略有變化，具體參考協(xié)議認(rèn)證基礎(chǔ)-TLS通用包格式TLS Record Layer 包格式進(jìn)一步參考Type：承載的協(xié)議類型change_cipher_spec:20alert:21handshake:22application_data:23version:版本號目前有1.0(RFC2246)/1.1(RFC4346)/1.2(RFC?)，抓包看到華為wimax是0301，對應(yīng)1.0(RFC2246),由于TSL基于演變而來，所以消息編碼為（0301）。length：后續(xù)數(shù)據(jù)

28、長度fragment：協(xié)議報文當(dāng)fragment經(jīng)過壓縮/加密后，格式路略有變化，具體參考協(xié)議認(rèn)證基礎(chǔ)-TLS Handshake ProtocolTLS Handshake Protocol 用于雙方協(xié)商安全參數(shù)相互認(rèn)證包含3個子協(xié)議：Change cipher spec protocol用于在安全參數(shù)協(xié)商過后，通知對方隨后的交互將使用之前剛剛協(xié)商的安全參數(shù)進(jìn)行加密處理該子協(xié)議只包含change_cipher_spec(1)這1條消息Alert protocol傳遞告警信息Handshake protocol見下頁進(jìn)一步參考Handshake過程：協(xié)商加密算法/交換random交換信息雙方生

29、成一致的premaster secret交換證書和加密信息并認(rèn)證生成Master secret給record layer提供加密參數(shù)驗證雙方生成了相同的安全參數(shù)認(rèn)證基礎(chǔ)-TLS Handshake Protocol包格式Handshake protocol用于協(xié)商安全參數(shù)包格式定義：進(jìn)一步參考包含的消息類型認(rèn)證基礎(chǔ)-TLS hello messageHandshake type 之hello message包括hello request/client hello/server hello 三個消息，這3個消息用于雙方協(xié)商安全能力：加密能力/壓縮能力Hello request只用于server請

30、求client發(fā)送 client hello消息，即server要求client發(fā)起協(xié)商Client hello用于client主動向server發(fā)起協(xié)商流程消息中包含random值（32byte（4byte GMT TIME+28byte random）client支持的CipherSuite listclient支持的壓縮算法Server helloserver對client的hello消息的響應(yīng)消息中包含random值/server選擇的CipherSuite/server選擇的壓縮算法以及分配的session id進(jìn)一步參考認(rèn)證基礎(chǔ)-TLS Server certificateHand

31、shake type 之Server certificateServer發(fā)送證書給client證書格式參考證書的key和簽名必須和hello協(xié)商的Ciphersuite指定加密方式一致進(jìn)一步參考認(rèn)證基礎(chǔ)-TLS Server key exchange messageHandshake type 之 Server key exchange messageThe server key exchange message is sent by the server only when the server certificate message(if sent)does not contain eno

32、ugh 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 exc

33、hange幫助client計算server的premaster值進(jìn)一步參考RFC2246 TLS1.0 和附錄1 DH密鑰交換算法認(rèn)證基礎(chǔ)-TLS Certificate requestHandshake type 之 Certificate request用于server向client請求證書（可選）目前認(rèn)證流程不涉及，進(jìn)一步信息參考協(xié)議進(jìn)一步參考認(rèn)證基礎(chǔ)-TLS Server hello doneHandshake type 之 Server hello doneThe server hello done message is sent by the server to indicate

34、the end of the server hello and associated messages.目前認(rèn)證流程不涉及，進(jìn)一步信息參考協(xié)議進(jìn)一步參考認(rèn)證基礎(chǔ)-TLS Client certificateHandshake type 之 Client certificate發(fā)送client端證書證書格式參考進(jìn)一步參考認(rèn)證基礎(chǔ)-TLS Client key exchange messageHandshake type 之 Client key exchange messageWith this message,the premaster secret is set,either though

35、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段下發(fā)證書中的public key將自身產(chǎn)生的48byte的premaster secret加密，發(fā)給server；采用密鑰交換算法采

36、用DH時，client和server互換DH計算參數(shù)，從而雙方生成一致的premaster secret進(jìn)一步參考認(rèn)證基礎(chǔ)-TLS Certificate verify messageHandshake type 之 Certificate verifyThis message is used to provide explicit verification of a client certificate.When sent,it will immediately follow the client key exchange message.包格式進(jìn)一步參考認(rèn)證基礎(chǔ)-TLS Finished

37、messageHandshake type 之 FinishedA 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

38、 finished messages must verify that the contents are correct.進(jìn)一步參考認(rèn)證基礎(chǔ)-TLS Handshake message 總結(jié)Handshake type 之 Finished原則上述消息必須按照上文描述的順序發(fā)送，只有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

39、 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.進(jìn)一步參考認(rèn)證基礎(chǔ)-MS-CHAP-V2MS-CHAP-V2:Microsoft PPP CHAP Extensions,Version 2.MS基于PPP CHAP協(xié)議的擴(kuò)展增強版本，主要增強了用戶認(rèn)證功能

40、通過3-way handshake驗證peer的身份：1.authenticators發(fā)送生成并發(fā)送challenge code（隨機(jī)數(shù)），消息中攜帶了用戶名2.Client根據(jù)16-octet challenge Valueusernamepassword經(jīng)過一定算法生成RADOM值（24byte），發(fā)送給authenticator3.authenticator經(jīng)過同樣算法計算得到Hash值，與Client發(fā)來的RADOM值比較成功時，返回SuccessCPE采用用戶認(rèn)證方式時，由CPE發(fā)起Challenge，在該消息中，CPE根據(jù)CPE challenge值usernamepasspeer

41、 challenge值經(jīng)過一定算法成生24byte的RADOM值，連同CPE challenge值usernamepeer challenge值一并發(fā)給server；server根據(jù)Challenge中的username獲取到對應(yīng)的密碼，根據(jù)同樣的算法生成RADOM值，和CPE發(fā)送來的RADOM比較，一致返回success，否則返回失敗。進(jìn)一步參考RFC1994 CHAPRFC2433 MS-CHAPRFC2759 MS-CHAP-V2CPE認(rèn)證分類認(rèn)證的目的在于雙方互相判斷對方是否合法，同時協(xié)商加密信息，用于后續(xù)報文的安全傳輸。認(rèn)證分類：免認(rèn)證用戶認(rèn)證CPE認(rèn)證AAA based on X.

42、509 certificateAAA認(rèn)證CPE基于用戶名密碼CPE和AAA間基于EAP-TTLS認(rèn)證協(xié)議設(shè)備認(rèn)證CPE和AAA相互認(rèn)證based on X.509 certificateCPE和AAA間基于EAP-TLS認(rèn)證協(xié)議認(rèn)證協(xié)議棧進(jìn)一步請參考：參考WMF-T32-001-R015v02_Network-Stage2-Base節(jié)參考RFC5281 EAP-TTLS從協(xié)議棧可以看出，認(rèn)證過程在MS和AAA間完成，中間網(wǎng)絡(luò)節(jié)點提供EAP通道在R1口EAP通過PKMV2（wimax定制）承載EAP屬于一個認(rèn)證流程的處理框架，其上可以承載多種具體的安全協(xié)議/認(rèn)證協(xié)議CPE采用用戶認(rèn)證時，可以配置

43、EAP具體承載的認(rèn)證協(xié)議來安全的傳輸CPE的用戶名和密碼信息給AAA，支持如下5種協(xié)議：MS-CHAP/MS-CHAP V2CHAP(Challenge Auth.Protocol)MD5PAP(Password Auth.Protocol)CPE采用設(shè)備認(rèn)證時，由于AAA使用證書認(rèn)證CPE，不需傳遞用戶名/密碼，所以不需配置認(rèn)證協(xié)議。設(shè)備認(rèn)證不需要安全子層PKM：privacy key management進(jìn)一步請參考P80216Rev_037節(jié)Traffic data.:業(yè)務(wù)面加解密/業(yè)務(wù)面分包認(rèn)證Message Authentication Processing：控制面分包認(rèn)證(HMAC

44、/CMAC/short-HMACs)Control Message Processing:PKM消息分發(fā)處理PKM Control Management：SS控制管理層，密鑰生成分發(fā)RSA-based Authentication：基于RSA的數(shù)字證書的認(rèn)證處理Authorization/SA Control:認(rèn)證狀態(tài)機(jī)和業(yè)務(wù)加密密鑰狀態(tài)機(jī)控制EAP Encapsulation/Decapsulation:EAP接口處理層EAP參考前文認(rèn)證基礎(chǔ)PKMv1 provides support for only Device Authentication whereas PKMv2 provides

45、 a flexible solution that supports device and user authentication between MS and home CSN.WIMAX密鑰體系一進(jìn)一步請參考P80216Rev_037節(jié)MSK：經(jīng)過EAP認(rèn)證后網(wǎng)絡(luò)側(cè)和MS都生成了同樣的MSK(Master session key)PMK：取MSK的160bit作為PMK(pairwise master key)PMK聯(lián)合SSIDBSIDPMK生成AK(authorization key)，AK用于進(jìn)一步派生其他密鑰WIMAX密鑰體系二進(jìn)一步請參考P80216Rev_037節(jié)MAC(mess

46、age 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)用于業(yè)務(wù)面加密，MAC消息中通用頭不加密，只有payload才會加密，由BS負(fù)責(zé)生成，下發(fā)MS。其他非重要KEY參見協(xié)議CPE認(rèn)證配置說明1.業(yè)務(wù)面加密配置：業(yè)務(wù)

47、面加密選項，wimax協(xié)議上有四種：DES-CBCASE-CCMAES-CBCASE-CTR，從配置上看，只能配置2種，具體使用哪種由BS配置給MSAES：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 book2.密鑰交換配置：AES-Key Wrap：是否使能AES k

48、ey wrap algorithm，BS發(fā)送給CPE的業(yè)務(wù)面key將經(jīng)過該算法處理，MS根據(jù)相同算法還原該keyAES-ECB：BS發(fā)送給CPE的業(yè)務(wù)面KEY是否經(jīng)過AES ECB加密上述是TEK配置給MS時，BS側(cè)采用的加密方式，協(xié)議上支持4種：3-DESRSAAES-ECBAES-Key Wrap，具體采用哪種由BS配置給MS。EAP Mode：認(rèn)證承載協(xié)議 Internal Mode:認(rèn)證方法（用戶認(rèn)證時使用）Anonymous ID:NAI（Network access identifier）,用于認(rèn)證時CPE上報AAA，幫助中繼設(shè)備轉(zhuǎn)發(fā)到合適的服務(wù)器。3.證書配置：用于CPE驗證AA

49、A下發(fā)的AAA證書是否合法進(jìn)一步參考WMF-T32-001-R015v02_Network-Stage2-Base7節(jié)321CPE認(rèn)證配置說明1.業(yè)務(wù)面加密配置：業(yè)務(wù)面加密選項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 book2.密鑰交換配置：AES-Key

50、Wrap：是否使能AES key wrap algorithm，BS發(fā)送給CPE的業(yè)務(wù)面key將經(jīng)過該算法處理，MS根據(jù)相同算法還原該keyAES-ECB：BS發(fā)送給CPE的業(yè)務(wù)面KEY是否經(jīng)過AES ECB加密EAP Mode：認(rèn)證承載協(xié)議 Internal Mode:認(rèn)證方法（用戶認(rèn)證時使用）,可以是PAP/CHAP/MSCHAPV2/MD5。Anonymous ID:NAI（Network access identifier）,用于認(rèn)證時CPE上報AAA，幫助中繼設(shè)備轉(zhuǎn)發(fā)到合適的服務(wù)器。3.證書配置：用于CPE驗證AAA下發(fā)的AAA證書是否合法進(jìn)一步參考WMF-T32-001-R015v

51、02_Network-Stage2-Base7節(jié)321wimax認(rèn)證整體流程CPE和AAA Server雙向認(rèn)證階段：雙向認(rèn)證完畢后，CPE和AAA SERVER將生成相同的MSK和EMSKSA生成階段：CPE和GW根據(jù)MSK，各自生成相同的PMK，再由PMK聯(lián)合MSIDBSID生AK和AK上下文,AK由GW下發(fā)BS密鑰下發(fā)階段：通過3次握手（6）完成SAAK驗證以及Primary SA的分配；同時通過（7）完成每個SA關(guān)聯(lián)的2個TEK(traffic encryption key)的生成和下發(fā)CPE進(jìn)一步參考 7.3.10 和 PART16中節(jié)wimax認(rèn)證流程-雙向認(rèn)證進(jìn)一步信息參考前文T

52、LS協(xié)議MSBSEAP request/IdentifyASN-GWAAAEAP response/Identify-NAIEAP-reponse/identify over AAAEAP request/TTLS-StartEAP-request/TTLS-Start over AAAEAP response/TTLS/TLS:Client hello EAP request/TTLS/TLS:Server hello/certificateServer key exchange/Server hello doneEAP over AAAEAPover AAAEAP response/TTL

53、S/TLS:Client key exchange/Change cipher spec/finished EAP over AAAEAP over AAAEAP request/TTLS/TLS:Change cipher spec/finishedEAP response/TTLS/TLS:Peer response/challengeEAP request/TTLS/TLS:success/Authenticator responseEAP response/TTLS(no data)EAP over AAAEAP over AAAEAP SuccessEAP over AAAEAP o

54、ver AAA基本能力協(xié)商后，ASN-GW發(fā)起EAP Identify流程，MS將響應(yīng)EAP Identify/NAI,ASN-GW根據(jù)NAI指定的域名將消息轉(zhuǎn)發(fā)AAA，隨后后續(xù)的流程實際上都是經(jīng)過GW透傳給MS和AAA通過TLS完成AAA到MS的認(rèn)證（采用數(shù)字證書方式），同時完成了PRE MSK的交換（通過DH或RSA）2.左圖為用戶認(rèn)證方式，如果為設(shè)備認(rèn)證時MS側(cè)也需要將自己的證書發(fā)送發(fā)送AAA完成MS到AAA的認(rèn)證3.經(jīng)過此步后，AAA和MS可以生成的MSK/EMSK,AAA會將MSK下發(fā)給GW，GW進(jìn)一步生成PMK/AK，并下發(fā)BS1.當(dāng)認(rèn)證方式為用戶認(rèn)證時，進(jìn)一步通過認(rèn)證協(xié)議完成MS

55、到AAA的認(rèn)證（認(rèn)證協(xié)議可以是mschapv2/mschap/chap/md5/pap）,當(dāng)設(shè)備認(rèn)證時，不含此步驟wimax認(rèn)證流程-用戶認(rèn)證雙向認(rèn)證實例MSBSEAP request/IdentifyASN-GWEAP response/Identify-NAIEAP request/TTLS-StartEAP response/TTLS/TLS:Client hello EAP request/TTLS/TLS:Server hello/certificateServer key exchange/Server hello doneEAP response/TTLS/TLS:Client

56、key exchange/Change cipher spec/finished EAP request/TTLS/TLS:Change cipher spec/finishedEAP response/TTLS/TLS:Peer response/challengeEAP request/TTLS/TLS:success/Authenticator responseEAP response/TTLS(no data)EAP Successserver的證書較長，再加上Server hello/Server key exchange/Server hello done等消息，需要2條消息交互F

57、inished是第一條使用剛剛協(xié)商后的加密參數(shù)加密的消息wimax認(rèn)證流程-設(shè)備認(rèn)證雙向認(rèn)證實例由于設(shè)備認(rèn)證時，認(rèn)證EAP-TLS，所以CPE響應(yīng)Nak,告知AAA側(cè)要使用EAP-TLS協(xié)議，后續(xù)流程全部用EAP-TLSserver發(fā)送證書/Server hello/Server key exchange/Server hello doneCPE發(fā)送證書/client key exchange/證書驗證/change cipher specwimax認(rèn)證流程-PKMV2三次握手MSPKMV2/SA-TEK ChallengeBSPKMV2/SA-TEK RequestPKMV2/SA-TEK

58、ResponseThe BS transmits the PKMv2 SA_TEK_Challenge message as a first step in the PKMv2 three-way handshake at initial network entry and at reauthentication.It identifies an AK to be used for the Security Association,and includes a unique challenge,i.e.,BS Random,that can either be a random number

59、or a counter.The MS responds with the PKMv2 SA_TEK_Req message after receipt and successful CMAC verification of aPKMv2 SA_TEK_Challenge from the BS.The PKMv2 SA_TEK_Req message contains the number,called MS-Random,which can also be either a random number or a counter.The PKMv2 SA_TEK_Req proves liv

60、eliness o f the Security Association in the MS and its possession of the valid AK.Since this message is being generated during initial network entry,it constitutes a request for S A-Descriptors identifying the primary and static SAs,an d GSAs the requesting SS is authorized to access,and their parti

61、cular propertiesAfter the successful completion of PKMv2 three-way handshake,the MS and the BS shall start using the newly acquired AK for MAC management messages protection(by CMAC)as per IEEE 802.16e specification.進(jìn)一步參考 7.3.10 和Wimax認(rèn)證流程-PKMV2 TEK下發(fā)MSPKMV2/Key RequestBSPKMV2/Key ResponseFor each S

62、A,the MS requests two TEKs from the BS.The TEKs are randomly created by the BS,encrypted using the KEK as the symmetric secret key,and are transferred to the MS.This step is repeated for each SA.進(jìn)一步參考 7.3.10 和附錄1：DH密鑰交換算法原理由Whitfield Diffie和Martin Hellman在1976年公布的一種密鑰一致性算法，算法用2個人的名字命名，原理說明：離散對數(shù)問題：若

63、p 是素數(shù)，p 已知，考慮方程 y=gx mod p，給定 g,x 求 y 是簡單的，但給定 y,g 求 x，即求 x=logg,py mod p，在計算上是不可行的。DH 密鑰交換算法的描述如下：已知公開的素數(shù) p 和 p 的本原根 1.用戶 A 選擇秘密的 Xap，計算 Ya=Xa mod p，將其發(fā)送給 B。2.用戶 B 選擇秘密的 Xbp，計算 Yb=Xb mod p，將其發(fā)送給 A。3.A 和 B 分別計算 Ka=(Yb)Xa mod p 和 Kb=(Ya)Xb mod p，就同時得到了共享的密鑰 K=Ka=Kb，然后就可以用 K 進(jìn)行加密傳輸了。DH 密鑰交換算法的優(yōu)點在于：雙方在

64、通信前不需要知道任何共享的密鑰，而是通過公開的 p 和 協(xié)商出一個密鑰來進(jìn)行加密通信。先看一下算法的正確性，Ka=Kb 是否成立：Ka=(Yb)Xa=(Xb)Xa=Xa*Xb(mod p)Kb=(Ya)Xb=(Xa)Xb=Xa*Xb(mod p)Bingo!Ka 和 Kb 是相同的。再來看一下算法的安全性，就是能否從公開的信息推導(dǎo)出 K 來：由于密鑰是 K=Xa*Xb，那么攻擊者必須知道 Xa 和 Xb 才能得到共享的密鑰 K，而公開的信息只有 Ya 和 Yb，由離散對數(shù)問題，從 Ya,Yb 求出 Xa,Xb 在計算上是不可行的，就保證了算法的安全性。參考自百度百科附錄2：RSA公鑰加密算法R

65、SA公鑰加密算法是1977年由Ron Rivest、Adi Shamirh和LenAdleman在（美國麻省理工學(xué)院）開發(fā)的。RSA取名來自開發(fā)他們?nèi)叩拿?。RSA是目前最有影響力的公鑰加密算法，它能夠抵抗到目前為止已知的所有密碼攻擊，已被ISO推薦為公鑰數(shù)據(jù)加密標(biāo)準(zhǔn)。RSA算法基于一個十分簡單的數(shù)論事實：將兩個大素數(shù)相乘十分容易，但那時想要對其乘積進(jìn)行因式分解卻極其困難，因此可以將乘積公開作為加密密鑰。RSA公開密鑰密碼體制。所謂的公開密鑰密碼體制就是使用不同的加密密鑰與解密密鑰，是一種“由已知加密密鑰推導(dǎo)出解密密鑰在計算上是不可行的”密碼體制。非對稱加密密碼算法，用公鑰加密，必須用密鑰解

66、密；反過來，用密鑰加密，必須用公鑰解密應(yīng)用場景：加解密server分發(fā)公鑰給client，自己保留密鑰，client用公鑰加密后的數(shù)據(jù)只能有server解密數(shù)字簽名server將用密鑰加密的簽名和原始簽名發(fā)送給client，client用公鑰解密簽名，和原始簽名一致時，認(rèn)為數(shù)字簽名有效，可以認(rèn)證該server。參考自百度百科附錄3：CBCcipher block chaining密碼段連接（CBC）是一種操作分段密碼的方式（在一段bit序列加密成一個單獨的單元或分成一個密鑰提供給整個部分）。密碼段連接使用一定長度初始化向量（IV）。他的一個主要特點是他完全依靠前面的密碼文段來譯碼后面的內(nèi)容。因此，整個過程的正確性決定于前面的部分。各部分的順序也必須保持正確。在面段連接中，每個文件部分先用前面的部分XOR化（參看XOR），然后加密。如果各部分順序沒變，使用相同的密鑰和初始化向量，只有同樣的密碼部分可以起作用。因為XOR過程隱藏了原文，密碼段連接要優(yōu)于電子密碼書模式。理論上，兩條信息使用相同的密鑰加密會產(chǎn)生不同的初始化向量。所以初始化向量不需要保密，這將極大方便某些場合的應(yīng)用。參考自百度百