專利名稱：無線通信系統(tǒng)中數(shù)據(jù)優(yōu)化傳輸?shù)姆椒ê脱b置的制作方法
技術(shù)領(lǐng)域：
本發(fā)明涉及在通信系統(tǒng)中的功能和單元之間用于共享安全數(shù)據(jù)的裝置和方法，且尤其涉及用于確定保護數(shù)據(jù)有效性以及隨后基于該確定結(jié)果的數(shù)據(jù)共享的裝置和方法。

背景技術(shù)：
對于世界大部分人口來說，通信系統(tǒng)，且尤其是無線通信系統(tǒng)已經(jīng)變得日益可用并且負擔(dān)得起。這些無線通信系統(tǒng)的成功進而導(dǎo)致了適應(yīng)訂戶數(shù)量大規(guī)模增長的需求。處理適應(yīng)大規(guī)模增長需求的一個方法是使得無線通信系統(tǒng)可擴展。另一方法是優(yōu)化構(gòu)成無線通信系統(tǒng)的元件和功能。作為結(jié)果，通信系統(tǒng)的架構(gòu)框架已持續(xù)演進。
一個已經(jīng)演進的領(lǐng)域是無線通信系統(tǒng)中的認證架構(gòu)。在無線通信系統(tǒng)中，在進一步通信可發(fā)生之前，許多應(yīng)用在客戶端/用戶設(shè)備(UE)和應(yīng)用/應(yīng)用服務(wù)器之間共享對相互認證的需求。例子包括但不限于在客戶端和在線服務(wù)器(presence server)之間的通信、或者與內(nèi)容服務(wù)器的通信。因為許多應(yīng)用共享對對等(peer)認證機制的共同需求，所以已經(jīng)開發(fā)了通用認證框架(GAA)。
第三代合作伙伴計劃(3GPP)通用認證框架(GAA)的初始認證(即，引導(dǎo)(bootstrap))是基于AKA(認證和密鑰協(xié)定協(xié)議)的。在由第三代合作伙伴計劃(3GPP)所制作的文檔中描述了GAA架構(gòu)。該文檔參考是3GPP TS33.919“3rd Generation PartnershipProject；Technical Specification Group Services and System Aspects；3G security；Generic Authentication Architecture(GAA)；Systemdescription”，該文檔作為附錄A而附加于此，因而其內(nèi)容通過參考而引入。
GAA的一個顯著方面在于其包括獨立于應(yīng)用的機制，其向客戶端/UE和應(yīng)用/應(yīng)用服務(wù)器提供共有的共享秘密。該共享秘密隨后可用以認證客戶端/UE和應(yīng)用/應(yīng)用服務(wù)器之間的無線通信。在由第三代合作伙伴計劃(3GPP)所制作的文檔中描述了這個方面，而該文檔參考是3GPP TS33.220“3rd Generation Partnership Project；Technical Specification Group Services and System Aspects；3Gsecurity；Generic Authentication Architecture(GAA)；Genericbootstrapping architecture(Release7)”，該文檔作為附錄B而附加于此，而“3GPP TS29.1093rd Generation Partnership Project；TechnicalSpecification Group Core Networks and Terminals；GenericAuthentication Architecture(GAA)；Zh and Zn Interfaces based on theDiameter protocol；Stage3(Release7)”，該文檔作為附錄C而附加于此，因而其內(nèi)容通過參考而引入。


發(fā)明內(nèi)容
根據(jù)本發(fā)明的一個實施方式，提供了一種用于在通信系統(tǒng)中共享數(shù)據(jù)的裝置，包括配置為傳送第一消息的引導(dǎo)服務(wù)器功能(BSF)，其中第一消息包括對應(yīng)于在BSF中所存儲的通用引導(dǎo)架構(gòu)用戶安全設(shè)置(GUSS)的時間戳參數(shù)。歸屬用戶服務(wù)器(HSS)配置為接收第一消息，用以將對應(yīng)于存儲在BSF中的GUSS的時間戳參數(shù)與對應(yīng)于存儲在HSS中的GUSS的時間戳參數(shù)進行比較，以及用以在當(dāng)BSF和HSS的GUSS時間戳參數(shù)相等的時候，將不包括GUSS的第二消息傳送回BSF。
根據(jù)本發(fā)明的一個實施方式，提供了一種用于在通信系統(tǒng)中共享數(shù)據(jù)的方法，包括將第一消息從引導(dǎo)服務(wù)器功能(BSF)傳送到歸屬用戶服務(wù)器(HSS)，其中第一消息包括對應(yīng)于在BSF中所存儲的通用引導(dǎo)架構(gòu)用戶安全設(shè)置(GUSS)的時間戳參數(shù)；將對應(yīng)于存儲在BSF中的GUSS的時間戳參數(shù)與對應(yīng)于存儲在HSS中的GUSS的時間戳參數(shù)進行比較；以及在當(dāng)BSF和HSS的GUSS時間戳參數(shù)相等的時候，將不包括GUSS的第二消息傳送回BSF。
根據(jù)本發(fā)明的一個實施方式，提供了一種包含在計算機可讀介質(zhì)中的計算機程序，以提供在通信系統(tǒng)中共享數(shù)據(jù)，包括將第一消息從引導(dǎo)服務(wù)器功能(BSF)傳送到歸屬用戶服務(wù)器(HSS)，其中消息包括對應(yīng)于在BSF中所存儲的通用引導(dǎo)架構(gòu)用戶安全設(shè)置(GUSS)的時間戳參數(shù)；將對應(yīng)于存儲在BSF中的GUSS的時間戳參數(shù)與對應(yīng)于存儲在HSS中的GUSS的時間戳參數(shù)進行比較；以及在當(dāng)BSF和HSS的GUSS時間戳參數(shù)相等的時候，將不包括GUSS的第二消息傳送回BSF。
根據(jù)本發(fā)明一個實施方式，提供了一種用于通信系統(tǒng)的裝置，該通信系統(tǒng)包括網(wǎng)絡(luò)應(yīng)用功能(NAF)；用戶設(shè)備，配置為與NAF通信并且用以傳送針對認證信息的請求；以及引導(dǎo)服務(wù)器功能(BSF)，配置為接收請求并傳送第一消息。第一消息包括對應(yīng)于在BSF中所存儲的通用引導(dǎo)架構(gòu)用戶安全設(shè)置(GUSS)的時間戳參數(shù)。歸屬用戶服務(wù)器(HSS)配置為接收第一消息，用以將對應(yīng)于存儲在BSF中的GUSS的時間戳參數(shù)與對應(yīng)于存儲在HSS中的GUSS的時間戳參數(shù)進行比較，以及在當(dāng)BSF和HSS的GUSS的時間戳參數(shù)相等的時候，將不包括GUSS的第二消息傳送回BSF。



包括的附圖用以對本發(fā)明提供進一步的理解并且結(jié)合于此構(gòu)成此說明書的一部分，示意了本發(fā)明的實施方式，其與說明書一起用于解釋本發(fā)明的原理，其中 圖1示出了根據(jù)本發(fā)明一個實施方式的提供針對網(wǎng)絡(luò)應(yīng)用服務(wù)器的通用機制的裝置； 圖2是在引導(dǎo)服務(wù)器功能和歸屬用戶服務(wù)器之間傳輸信息的例子的一個實施方式；以及 圖3A和圖3B示出了根據(jù)本發(fā)明一個實施方式的一種方法，該方法提供了用以最小化流量負載的通用引導(dǎo)架構(gòu)用戶安全設(shè)置時間戳。

具體實施例方式 現(xiàn)在將在下文中參考附圖來更全面地描述本發(fā)明，其中示出了本發(fā)明的某些但并非所有實施方式。實際上，這些發(fā)明可以實現(xiàn)為許多不同的形式并且不應(yīng)理解為構(gòu)成對在此闡明的實施方式的限制；相反，提供這些實施方式以便本公開滿足適用的法律要求。貫穿全文，相同的標號表示相同的元件。
3GPP GBA是提議(3GPP TS 33.220作為附錄B附加于此，而3GPP TS 29.209作為附錄C附加于此，因而其內(nèi)容通過參考引入)的認證架構(gòu)。可以使用此架構(gòu)以使得在網(wǎng)絡(luò)側(cè)的和在用戶側(cè)的應(yīng)用功能能夠在網(wǎng)絡(luò)側(cè)和用戶側(cè)不能另外進行通信的情況下來通信。此功能稱為“應(yīng)用安全性的引導(dǎo)”，或者更通常地簡化為“引導(dǎo)”。
引導(dǎo)的一般原則是，通用引導(dǎo)服務(wù)器功能(BSF)允許用戶設(shè)備(UE)與之認證，并就會話密鑰達成協(xié)定。這種認證可以基于認證和密鑰協(xié)定(AKA)。通過運行AKA，移動終端和網(wǎng)絡(luò)彼此相互認證并且就密鑰達成協(xié)定，特別是機密性密鑰(CK)和完整性密鑰(IK)。在此認證之后，UE和網(wǎng)絡(luò)應(yīng)用功能(NAF)(其還可稱為服務(wù)提供商)可以運行一些應(yīng)用專用協(xié)議，其中消息的認證是基于在UE和BSF之間達成協(xié)定的會話密鑰。
引導(dǎo)功能并不旨在于依賴任何特定網(wǎng)絡(luò)應(yīng)用功能。實現(xiàn)引導(dǎo)功能的服務(wù)器必須受到歸屬運營商的信任以處理認證向量。在運營商的歸屬網(wǎng)絡(luò)、受訪網(wǎng)絡(luò)、或者第三方網(wǎng)絡(luò)中可以支持網(wǎng)絡(luò)應(yīng)用功能。
圖1示出了根據(jù)本發(fā)明一個實施方式的示范性網(wǎng)絡(luò)架構(gòu)。網(wǎng)絡(luò)架構(gòu)包括用戶設(shè)備(UE)100、至少一個網(wǎng)絡(luò)應(yīng)用功能(NAF)102、引導(dǎo)服務(wù)器功能(BSF)104、以及歸屬用戶系統(tǒng)(HSS)106。BSF104和HSS106形成歸屬移動網(wǎng)絡(luò)運營商(MNO)108的一部分。UE100根據(jù)公知的移動通信技術(shù)而連接到MNO108。
例如，NAF102在MNO108控制之下被主控于網(wǎng)元中，而BSF104也在MNO108控制之下被主控于網(wǎng)元中。由此，為了實踐目的，NAF102和BSF104的每個可以認為是網(wǎng)元。另外，MNO108可以包括控制器(未示出)以執(zhí)行將在圖3A和圖3B中描述的操作。控制器可以包括永久的或者可移除的存儲器，諸如磁盤和光盤、RAM、ROM等，在其上可以存儲和分布本發(fā)明的處理和數(shù)據(jù)結(jié)構(gòu)。
如在圖1中所示，UE100通過Ua接口110與NAF102通信。UE100通過Ub接口112與BSF104通信。NAF102通過Zn接口114與BSF104通信。BSF104通過Zh接口116與HSS106通信。
在進一步分離的網(wǎng)絡(luò)中可以提供NAF102。例如，如圖1中所示，提供了一個示范性網(wǎng)絡(luò)架構(gòu)，其中NAF102位于受訪網(wǎng)絡(luò)之中。在當(dāng)UE100接觸NAF102(其在歸屬網(wǎng)絡(luò)以外的其它網(wǎng)絡(luò)中操作)的情況下，此受訪NAF102可以使用NAF網(wǎng)絡(luò)的直徑代理(D-Proxy)來與訂戶的BSF(即，歸屬BSF)104通信。然后NAF102將通過至D-Proxy的Zn接口114并且通過至BSF104的Zn接口120來與BSF104通信。
對于圖1，引導(dǎo)的原理在于，UE100和引導(dǎo)服務(wù)器功能彼此互相認證，例如使用AKA協(xié)議，并且就主共享秘密達成協(xié)定。之后，使用主共享的秘密來得出一個或者多個網(wǎng)絡(luò)應(yīng)用功能專用共享的秘密，該秘密應(yīng)用在UE100和所討論的特定NAF之間。特別地，針對每個網(wǎng)絡(luò)應(yīng)用功能而獨立地生成NAF專用共享秘密密鑰資料。在已經(jīng)完成引導(dǎo)操作之后，UE100和網(wǎng)絡(luò)應(yīng)用功能可以運行某些專用協(xié)議，其中消息的安全將基于在UE100和引導(dǎo)服務(wù)器功能之間的相互認證期間所生成的那些密鑰。由此，密鑰可以用于認證和完整性保護并用于機密性。然后，網(wǎng)絡(luò)應(yīng)用功能能夠獲取NAF專用共享秘密，該專用共享秘密從在用戶設(shè)備和引導(dǎo)服務(wù)器功能之間建立的主共享秘密中得出。
此外，通信Ub接口112支持引導(dǎo)認證和密鑰協(xié)定協(xié)議，以在UE100和BSF104之間提供相互認證和密鑰協(xié)定。Zh接口116允許BSF104從HSS106取得任何所需的認證信息和訂戶配置信息(例如，認證矢量，AV)。訂戶的用戶安全性設(shè)置(USS)集是訂戶的GUSS的一部分，其可以存儲在HSS中。在一個人具有多個訂制的情況下，即在通用移動通信系統(tǒng)集成電路卡(UICC)上有多個IP多媒體子系統(tǒng)訂戶識別模塊卡(ISIM)或者通用訂戶識別模塊卡(USIM)應(yīng)用的情況下，HSS106將包含可映射到任何一個或者多個標識上的一個或者多個GUSS，該標識例如是IP多媒體私有標識(IMPI)和國際移動訂戶標識-IMSI。Ua接口110支持任何應(yīng)用專用協(xié)議，其使用NAF專用共享秘密(根據(jù)由Ub接口112所支持的協(xié)議，從UE100和BSF104之間達成協(xié)定的主共享秘密所獲取)來保護。NAF102使用Zn接口114從BSF104獲取從主共享的秘密中所得到的NAF專用共享秘密，其中該主共享秘密在Ub接口112上支持的協(xié)議中達成協(xié)定。Zn接口114還可以用以從BSF104獲取訂戶配置信息。
從BSF104傳送到NAF102的消息包括引導(dǎo)信息。引導(dǎo)信息可以包括事務(wù)標識符、NAF專用共享秘密、以及訂戶配置信息(“prof_naf”或者“任何NAF特定USS”)。
此外，通用引導(dǎo)架構(gòu)用戶安全設(shè)置(GUSS)集還可以包括在引導(dǎo)信息和所有應(yīng)用專用USS集中。通常，BSF請求用于特定訂戶的AV，然后還接收隨被請求AV一起的訂戶的GUSS。在操作期間，BSF104能夠在一時間通過Zh(來自BSF104的HSS接口)從HSS106取回單一認證矢量(AV)，因而當(dāng)UE100由BSF104引導(dǎo)的時候，使BSF104通過來自HSS106的GUSS的新副本來更新存儲在其中的GUSS。因此，如果NAF102需要從BSF104獲取一個或多個更新的USS，則NAF102需要請求UE100以通過BSF104進行引導(dǎo)，即重新協(xié)商，而在NAF102下一次從BSF104請求特定GUSS的時候，NAF102知道GUSS是更新過的。
然而，此更新過程使HSS106在每次請求新AV的時候發(fā)送GUSS，而無論從BSF104最后一次接收到GUSS以來在HSS106中GUSS是否已經(jīng)更新。在更新過程期間，通過發(fā)送帶有GUSS的AV，由于GUSS的尺寸可以很大，這使得在BSF104和HSS106之間的流量負載很大。即使在BSF104已經(jīng)具有相同GUSS副本的情況下，也向BSF104發(fā)送GUSS是不必的，而這將導(dǎo)致帶寬和計算機資源的浪費。因而，需要將從HSS106向BSF104傳送GUSS的次數(shù)最小化。
為此，本發(fā)明的裝置和方法配置并傳送GUSS，以包括從HSS106到BSF104的時間戳，以將關(guān)于在BSF104和HSS106之間的GUSS傳輸過程的流量負載最小化。因而，本發(fā)明的裝置和方法通過確定各種安全數(shù)據(jù)的有效性并且隨后根據(jù)確定結(jié)果來共享數(shù)據(jù)而允許在通信系統(tǒng)中的功能和元件之間共享受保護的數(shù)據(jù)，。
根據(jù)本發(fā)明的實施方式，僅當(dāng)請求或者接收網(wǎng)元對在傳輸或者源網(wǎng)元上存在的完全相同的數(shù)據(jù)不具有副本或不能訪問的時候，傳輸網(wǎng)元或者源網(wǎng)元(例如GBA中的HSS106)中的數(shù)據(jù)被傳送至或由請求網(wǎng)絡(luò)或者接收網(wǎng)元(例如GBA中的BSF104)共享。
因而，GUSS時間戳添加到每個GUSS，指示GUSS何時最后一次由HSS106所改變。此時間戳用以優(yōu)化HSS106和BSF104之間的GUSS傳送策略。如果BSF104在其需要獲取用于訂戶的新認證矢量(AV)的時候在存儲器中具有訂戶的GUSS，則它還將GUSS時間戳包括在請求中。一旦接收到GUSS時間戳，HSS106將該時間戳與其數(shù)據(jù)庫中所存儲的GUSS時間戳進行比較。如果時間戳相等，則由于BSF104已經(jīng)具有GUSS的副本，因而HSS106不將GUSS發(fā)送到BSF104。如果時間戳不相等，則因為BSF104具有需要被更新的無效GUSS，因而HSS106發(fā)送GUSS。如果HSS106不具有GUSS，例如因為已經(jīng)使用HSS的管理接口刪除了GUSS，則HSS106將不發(fā)送GUSS消息到BSF104，而BSF104將刪除舊的GUSS。
圖2示出了根據(jù)本發(fā)明一個實施方式的、在包括GUSS時間戳的HSS106和BSF104之間的通信。在操作150處，UE100發(fā)布針對新引導(dǎo)的請求，該引導(dǎo)包括涉及UE100的用戶身份信息。當(dāng)BSF104正在取回或者請求來自HSS106的新AV的時候，在操作152處，如果GUSS已經(jīng)存在、或者已經(jīng)存儲在BSF104的存儲器中(即，BSF存儲器)，則針對新AV的請求還將包括GUSS時間戳。一旦接收到GUSS時間戳，則HSS106檢查并且將該GUSS時間戳與在其中提供的存儲器(即，HSS存儲器)中所存儲的GUSS時間戳進行比較。在操作154處，如果從BSF104所接收到的GUSS時間戳和在HSS106中所存儲的GUSS時間戳不同，則HSS106將更新的GUSS，針對該更新的GUSS的GUSS時間戳以及所請求的新AV包括在一起。如果GUSS時間戳相同，即，BSF104存儲器中的GUSS和HSS106中的GUSS相同，則并不將GUSS隨同所請求的新AV發(fā)送到BSF104。
自然，僅當(dāng)BSF104在BSF存儲器中具有針對特定訂戶的GUSS的時候，GUSS時間戳可以從BSF104發(fā)送到HSS106。在此例中，GUSS時間戳不發(fā)送到HSS106，而HSS106將訂戶專用GUSS從其中的數(shù)據(jù)庫返回到BSF104。
在操作156處，BSF104在消息中將隨機質(zhì)詢數(shù)據(jù)(RAND)和認證標志(AUTN)轉(zhuǎn)發(fā)到UE100，用以請求UE100自身對其認證。在操作158處，關(guān)聯(lián)于UE100的客戶端運行認證和密鑰協(xié)定(AKA)算法、校驗AUTN、并且獲得認證結(jié)果(RES)。UE100還計算機密性密鑰(CK)、完整性密鑰(IK)和RES，這將在BSF104和UE100兩者中得到相同的會話密鑰IK和CK。在操作160處，UE100將包含使用RES計算出來的AKA響應(yīng)的超文本傳輸協(xié)議(HTTP)請求發(fā)送到BSF104。在操作162處，BSF104通過校驗AKA響應(yīng)來認證UE100。在操作164處，BSF104通過串接(concatenate)CK和IK來生成密鑰資料(Ks)。在操作166處，BSF104將OK消息和引導(dǎo)事務(wù)標識符(B-TID)以及密鑰Ks的壽命發(fā)送到UE100以指示認證成功。另外，在操作168處，UE100以與BSF104在操作164中相同的生成方式來生成密鑰資料(Ks)，并且存儲Ks.B-TID以及Ks的壽命。
因而，HSS106中的每個GUSS包括新的時間戳參數(shù)，例如標記的GUSSTIMESTAMP(GUSS時間戳)。GUSS的GUSSTIMESTAMP由HSS106來設(shè)置，而GUSSTIMESTAMP是指示當(dāng)HSS106修改GUSS時的最后時間的數(shù)字或者字符參數(shù)。GUSSTIMESTAMP參數(shù)還可以指示GUSS數(shù)據(jù)的版本。GUSSTIMESTAMP在GUSS內(nèi)容變化的時候變化。即，如果在HSS106中的GUSS被修改或者更新，則HSS106為更新的GUSS分配新的GUSSTIMESTAMP。
GUSSTIMESTAMP還可以以與存儲GUSSTIMESTAMP的方式等效或者不同的形式(例如，數(shù)字或者字符)來存儲或傳送，或者連同GUSS存儲在HSS106中。然而，如果以不同形式存儲或者傳送，則GUSSTIMESTAMP的這種改變的形式可以轉(zhuǎn)換回到HSS106中GUSSTIMESTAMP的原始表示。例如，當(dāng)需要比較多個GUSSTIMESTAMP的時候，執(zhí)行這種轉(zhuǎn)換。
根據(jù)本發(fā)明的一個方面，BSF104從HSS106接收GUSS或者其等同物，并且在BSF存儲器中存儲GUSS。當(dāng)BSF104從HSS106中請求AV的時候，而其先前已經(jīng)接收到對應(yīng)的GUSS時，則請求可以包括GUSSTIMESTAMP。HSS106將所接收的GUSSTIMESTAMP與已經(jīng)存儲在HSS106中的GUSSTIMESTAMP進行比較，并且只有在兩個GUSSTIMESTAMP不同的時候在回復(fù)中包括GUSS。兩個GUSSTIMESTAMP可能不同，例如，當(dāng)BSF104具有無效或者過時的GUSS時。如果GUSSTIMESTAMP相等，則HSS106將不會將GUSS隨AV發(fā)送到BSF104。
圖3A示出了根據(jù)本發(fā)明實施方式的用以創(chuàng)建和修改GUSSTIMESTAMP的方法。GUSSTIMESTAMP的初始化發(fā)生在當(dāng)創(chuàng)建特定的GUSS的時候。在操作200處，HSS106創(chuàng)建GUSS。在操作210處，HSS106初始化GUSSTIMESTAMP。無論何時特定的GUSS被修改，都將執(zhí)行GUSSTIMESTAMP的更新操作。在操作220處，HSS106修改GUSS。在操作230處，HSS106更新GUSSTIMESTAMP。
可存在多個方法，用以在針對HSS中特定GUSS指定GUSSTIMESTAMP參數(shù)的值。在本發(fā)明的一個實施方式中，可以由單調(diào)增加序列或者單調(diào)減小序列來指定GUSSTIMESTAMP。例如，當(dāng)?shù)谝淮蝿?chuàng)建GUSS的時候，可以將GUSSTIMESTAMP指定或初始為某數(shù)字值，或者指定或初始為由HSS106中的時鐘所指示的時間和/或日期。每次修改GUSS，則因而成為一個新的版本，例如GUSSTIMESTAMP可以1遞增或者遞減或者變化到由HSS106中的時鐘所指示的當(dāng)前時間和/或日期。在另一實施方式中，GUSS可以指定為這樣的GUSSTIMESTAMP值，該值是GUSS的特定實例的哈?；蛘吖５囊徊糠郑T如SHA-1或者MD5。
圖3B示出了根據(jù)本發(fā)明實施方式的一種方法，該方法提供了用以最小化流量負載的通用引導(dǎo)架構(gòu)用戶安全設(shè)置時間戳。在操作300處，該方法在BSF104處準備針對認證矢量-AV的請求。在操作310處，在BSF104處確定GUSS是否已經(jīng)存儲在BSF存儲器中。如果該方法確定已經(jīng)存儲了GUSS，則在操作320處，方法在BSF104處讀取關(guān)聯(lián)于在BSF104中所存儲的GUSS的GUSSTIMESTAMP，并且利用請求來包括GUSSTIMESTAMP。然而，如果方法確定在BSF104中未存儲GUSS，則在操作330處，方法在BSF104處向HSS106發(fā)送請求。
在操作340處，方法在HSS106處接收來自BSF104的請求。在操作350處，由HSS106確定在請求中是否存在GUSSTIMESTAMP。如果方法確定在請求中存在GUSSTIMESTAMP，則在操作360處，方法在HSS106處確定從BSF104所接收的GUSSTIMESTAMP和在HSS106中所存儲的GUSSTIMESTAMP是否相等。否則，如果方法確定在請求中不存在GUSSTIMESTAMP，則在操作350之后，方法前進到操作380，這將在下文中描述。
在操作360處，如果方法確定從BSF104所接收的GUSSTIMESTAMP和在HSS106中存儲的GUSSTIMESTAMP相等，則方法前進到操作380，否則方法前進到操作370。在操作370處，方法將存儲在HSS106中的GUSS包括在響應(yīng)中并且前進到操作380。
在操作380處，該方法將HSS106配置為向BSF104發(fā)送響應(yīng)。在操作390處，BSF104從HSS106接收響應(yīng)。在操作400處，方法在BSF104處確定在響應(yīng)中是否存在GUSS。如果在響應(yīng)中存在GUSS，則在操作410處，方法在BSF104處確定在BSF104中是否已經(jīng)存在GUSS。否則，方法前進到操作440，這將在下文中描述。如果方法確定在BSF104中存在GUSS，則方法前進到操作420。否則，方法前進到操作430，這將在下文中描述。
在操作420處，該方法在BSF104處刪除在BSF104中所存儲的GUSS，并且前進到操作430。在操作430處，該方法在BSF104處存儲所接收的GUSS，而在操作440處，BSF104存儲所接收的AV。
應(yīng)理解，在本發(fā)明的實施方式中以示出的序列和方式執(zhí)行操作，盡管某些操作等可以有所變化而并不背離本發(fā)明的精神和范圍。
因而，本發(fā)明提供了向在BSF和HSS之間交換的每個GUSS增加GUSS時間戳，該時間戳指示了HSS何時最后改變GUSS。GUSS時間戳將BSF和HSS之間的數(shù)據(jù)傳輸策略優(yōu)化。具體而言，當(dāng)通過用戶設(shè)備從訂戶請求用以獲取新認證矢量的請求的時候，如果BSF具有關(guān)聯(lián)于在存儲器中所存儲的訂戶的數(shù)據(jù)，則新AV請求還包括與在BSF的存儲器中存儲的GUSS相關(guān)聯(lián)的GUSS時間戳。一旦接收到GUSS時間戳，則HSS將GUSS時間戳與在HSS存儲器中存儲的GUSS時間戳進行比較。如果GUSS時間戳相同或者相等，則由于BSF已經(jīng)具有GUSS的副本因而HSS不向BSF發(fā)送GUSS。如果GUSS時間戳不相等，則由于BSF具有需要更新的無效GUSS，因而HSS發(fā)送GUSS。
另外，盡管在本發(fā)明的說明中已經(jīng)使用了分組和數(shù)據(jù)報這樣的術(shù)語，但本發(fā)明對許多類型的網(wǎng)絡(luò)數(shù)據(jù)都很重要。為了本發(fā)明的目的，術(shù)語分組包括分組、單元、幀、數(shù)據(jù)報、橋接協(xié)議數(shù)據(jù)單元分組、分組數(shù)據(jù)及其任意等同物。
從詳細說明書中，本發(fā)明的許多特征和優(yōu)點都變得清楚明了，且由此所附權(quán)利要求書旨在于覆蓋落入本發(fā)明的精神和范圍之內(nèi)的本發(fā)明的所有這樣的特征和優(yōu)點。此外，由于對于本領(lǐng)域技術(shù)人員容易做出許多修改和變化，因而并不期望將本發(fā)明的范圍限制到所示出和描述的精確架構(gòu)和操作，因而可以采取的所有適當(dāng)?shù)男薷暮偷韧锒悸淙氡景l(fā)明的范圍之中。
附錄A 3GPP TR33.919V6.2.0(2005-03) 技術(shù)報告 第三代伙伴計劃； 技術(shù)規(guī)范組服務(wù)和系統(tǒng)方面； 3G安全； 通用認證架構(gòu)(GAA)； 系統(tǒng)描述 (版本6) 本文檔已經(jīng)在第三代伙伴計劃(3GPPTM)中開發(fā)并且可以針對3GPP的意圖進一步詳細闡述。
本文檔還沒有經(jīng)過3GPP組織伙伴的任何同意處理過程并且尚未被實現(xiàn)。
提供此規(guī)范僅在3GPP內(nèi)部用于進一步的開發(fā)工作。組織伙伴不接受對于使用此規(guī)范的任何義務(wù)。
對于3GPPTM系統(tǒng)實現(xiàn)的規(guī)范和報告應(yīng)該通過3GPP組織伙伴的出版辦公室獲得。
關(guān)鍵字 UMTS，認證，安全，GAA 3GPP 通信地址 3GPP支持辦公室地址 650Route des Lucioles-Sophia AntipolisValbonne-FRANCE TeI.+33492944200Fax+33493654716 因特網(wǎng) http://www.3gpp.org 版權(quán)聲明 除了通過書面許可的授權(quán)之外沒有部分可以復(fù)制。
版權(quán)和前述限制擴展到所有媒體中的復(fù)制。
_2005，3GPP Organizational Partners(AR1B，ATIS，CCSA，ETSI，TTA，TTC)。
All Right reserved 3GPP 目錄 前言........................................................4 介紹........................................................4 1范圍.........................................................5 2參考.........................................................5 3定義和縮略語................................................6 3.1定義.......................................................6 3.2縮略語....................................................6 4通用認證架構(gòu)................................................7 4.1GAA概述..................................................7 4.2使用共享秘密認證.........................................7 4.3基于(公有，私有)密鑰對和證書的認證........................7 5發(fā)布認證憑證...............................................8 5.1示意性概述................................................8 5.2GBA發(fā)放共享秘密的機制....................................8 5.3SSC發(fā)放用戶證書的機制...................................8 6GAA結(jié)構(gòu)模塊................................................9 6.1GAA結(jié)構(gòu)總覽................................................9 6.2GAA.......................................................9 6.3GBA......................................................9 6.4SSC.....................................................10 6.5使用HTTPS訪問網(wǎng)絡(luò)應(yīng)用功能................................10 6.5.1有鑒權(quán)代理的HTTPS.......................................10 6.5.2無鑒權(quán)代理的HTTPS......................................10 7使用GAA的應(yīng)用指南...........................................11 7.1共享秘密和GBA的使用......................................12 7.2證書的使用................................................12 附錄A更改歷史...............................................13 前言 此技術(shù)報告已經(jīng)由第三代伙伴計劃(3GPP)制作。
本文檔的內(nèi)容服從TSG中的連續(xù)工作并且可以隨著正式的TSG同意改變。一旦TSG修改本文檔的內(nèi)容，TSG將通過帶有發(fā)布日期和如下增加的版本號的可識別變化來對其進行重新發(fā)布 版本x.y.z x第一個數(shù)字 1呈現(xiàn)給TSG用于信息 2呈現(xiàn)給TSG用于同意 3或者更大指示修改控制下的TSG同意文檔 y第二個數(shù)字增大用于所有實質(zhì)的修改，即技術(shù)增強、修正、更新等。
z當(dāng)僅編輯性修改已經(jīng)合并于該文檔中時第三個數(shù)字增大。
介紹 此節(jié)提供關(guān)于GAA上下文的介紹以及一些為何撰寫此TR的解釋(帶有一些對于三個相關(guān)技術(shù)規(guī)范的參考)。

圖1GAA的示意圖 很多應(yīng)用都需要在進一步的通信前，在客戶端(即UE)和應(yīng)用服務(wù)器之間進行雙向認證。例子包括(但不限于)客戶端和在線服務(wù)器(可能通過認證代理)間的通信，客戶端申請數(shù)字證書時與PKI端口的通信，與內(nèi)容服務(wù)器、BM-SC等等的通信。
由于許多應(yīng)用都需要同級別的認證機制，定義一種通用認證架構(gòu)(GAA)已經(jīng)被認為是有用的。此GAA描述了一種用于可以優(yōu)先服務(wù)任何(現(xiàn)在和將來)的應(yīng)用的同級通用認證架構(gòu)。
此TR可以被考慮作為如圖1中說明的通用認證架構(gòu)的框架文檔。GBA、AP和證書是GAA的構(gòu)造模塊并且它們被指定在每個分離的TS中。它們在GAA中怎樣組合在本文檔中解釋。
1范圍 此3GPP技術(shù)報告目的是給出移動應(yīng)用可以依靠的用于在服務(wù)器和客戶端(即UE)之間進行認證的不同機制的概述。另外，它提供了關(guān)于GAA的使用以及在給定情況中并且用于給定應(yīng)用的認證機制的選擇的引導(dǎo)。
為此，TR將關(guān)于同級認證的不同GAA規(guī)范放到前瞻中。澄清了用于具有三個技術(shù)規(guī)范的邏輯，擬定了它們的內(nèi)容并且解釋這三個TS和它們與此TR的關(guān)系間的相互聯(lián)系。
圖1描述了GAA接口上使用的協(xié)議和不同GAA規(guī)范間的關(guān)系。當(dāng)它們有效時，新的GAA規(guī)范將被添加到該圖。將來也可以添加其它協(xié)議。特別是，將來可以添加Ua接口的新種類并且然后在Ua接口下面可以添加其他協(xié)議。

GAA在Ua接口上能潛在支持許多協(xié)議。一個例子是HTTP摘要。
圖2GAA規(guī)范與GAA接口使用的協(xié)議之間的關(guān)系 2參考 下列文檔包含通過此文本中的參考的規(guī)定，組成本文檔的規(guī)定。
●參考是特定的(由出版日期、印刷號、版本號等識別)或非特定的。
●對于特定參考，后續(xù)修改不適用。
●對于非特定參考，應(yīng)用最新版本。在參考3GPP文檔(包括GSM文檔)的情況中，非特定參考隱含地指與當(dāng)前文檔具有相同版本的文檔的最新版本。
[1]3GPP TS33.102″3rd Generation Partnership Project；Tcchnical Specification Group Servicesand System Aspects；3G Security；Security srchitocture″. [2]3GPP TS33.220″3rd Generation Partnership Project；Technical Specification Group Servicesand System Aspccis；3G Security；Generic Aulhenlicalion Architccture(GAA)；Genericbooistrapping architecture″. [3]3GPP TS33.221″3rd Generation Partnership Project；Technical Spccification Group Serviccsand System Aspects；3G Security；Generic Authcntication Archilecture(GAA)；Support forsubscribcr certificates″. [4]3GPP TS33.222″3rd Gencration Partnership Project；Technical Group Servicesand System Aspects；3G Security；Gencric Authentication Architecture(GAA)；Access to networkapplication using secure hypcrtcxt transfer protocol(HTTPS)″. [5][ETF RFC2818；″HTTP Over TLS″. [6]3GPP TS29.109″3rd Gencrailon Partnership Project；Technical Specification Group CoreNetwork；Gencric Authentication Architecture(GAA)；Zh and Zn Interfaces based on theDiameter protocol；Protocol details″. [7]3GPP″TS24.109″3rd Generation Partnership Project；Technical Specification Group CoreNetwork；Bootstrapping Interface(Ub)and Network application function interface(Ua)；Protocoldetails″. [8]3GPP TS29.198-03″3rd Generation Partnership Project；Technical Specification Group CoreNetwork；Open Service Access(OSA)；Applicatiot Programmlng Interface(API)；Part3Framework″. [9]3GPP TS29.199-01″3rd Generation Partnership Project；Technical Specification Group CoreNetwork；Open Service Access (OSA)；Parlay X web services；Part l；Common″. 3定義和縮略語 3.1定義 出于本文檔的目的，應(yīng)用下列術(shù)語和定義。
用戶證書基于他/她的訂閱，由移動網(wǎng)絡(luò)運營商向用戶發(fā)放的證書。它包含用戶擁有的公有密鑰和可能的其他信息，例如某些形式的用戶身份。
3.2縮略語 出于本文檔的目的，應(yīng)用下列縮略語。
AKA認證和密鑰協(xié)定 AP認證代理 AS應(yīng)用服務(wù)器 BSF引導(dǎo)服務(wù)器功能 GAA通用認證架構(gòu) GBA通過引導(dǎo)架構(gòu) HSS歸屬用戶系統(tǒng) NAF網(wǎng)絡(luò)應(yīng)用功能 NE網(wǎng)元 PKI公有密鑰基礎(chǔ)結(jié)構(gòu) SSC對于用戶證書的支持 UE用戶設(shè)備 4通用認證架構(gòu) 4.1GAA概述 一般來說存在兩種認證機制。一種基于通信實體間的共享秘密，另一種基于(公有，私有)密鑰對和數(shù)字證書。如圖3所示，在GAA中這個兩個對于移動應(yīng)用而言可優(yōu)先應(yīng)用的選項。

圖3GAA示意概述 4.2使用共享秘密的認證 存在基于通信實體間預(yù)共享秘密的若干個認證協(xié)議。常有的例子包括HTTP摘要，具有預(yù)共享秘密IKE和基于用戶名和密碼的任何現(xiàn)有機制。
這些機制的主要問題在于如何在該預(yù)共享秘密上達成一致。5.2節(jié)和GBA TS33.220[2]描述了如何在移動的上下文環(huán)境中使用基于AKA的機制為兩個通信實體提供預(yù)共享秘密。
4.3基于(公有，私有)密鑰對和證書的認證 對于使用共享秘密認證外可選的是依靠非對稱密碼。這假設(shè)需要認證的實體(通信單方或者雙方)擁有(公有，私有)密鑰對以及相應(yīng)的數(shù)字證書。后者驗證該密鑰對并將該密鑰對綁定到其合法擁有者。眾所周知的基于(公有，私有)密鑰對認證的協(xié)議包括PGP和TLS上的HTTP，RFC2818[5](后者常用其協(xié)議標識符“HTTPS”稱呼)。
這類認證的主要缺點在于需要PKI并且非對稱的密鑰密碼操作經(jīng)?；旧媳葘ΨQ的密鑰操作需要更多的計算開銷。5.3節(jié)和SSCTS33.221[3]描述了移動運營商如何能夠給其用戶頒發(fā)數(shù)字證書(因而提供基本PKI)。
5發(fā)布認證憑證 5.1示意性概述
注用于發(fā)放認證憑證的其他機制可以存在，但都超出本TR的范圍。
圖4發(fā)放認證憑證機制的示意圖 圖3說明了本TR與TS33.220[2]以及TS33.221[3]之間的關(guān)系。一方面，存在基于共享秘密和GBA的認證方法，描述于TS33.220[2]中，指定了一種向通信方提供這樣的共享秘密的機制。另一方面，存在依靠(公有，私有)密鑰對和數(shù)字證書以及SSC的認證方法，描述于TS33.221[3]中，指定了如何向移動用戶發(fā)放證書。
5.2GBA發(fā)放共享秘密的機制 TS33.220[2]指定了基于3GPP AKA機制的一種獨立于應(yīng)用的機制，以向客戶端和應(yīng)用服務(wù)器提供公共的共享秘密。隨后，該共享秘密可以用于認證客戶和應(yīng)用服務(wù)器之間的通信。
5.3SSC發(fā)放用戶證書的機制 TS33.221[3]，指定了向移動用戶發(fā)放數(shù)字證書的機制。
一旦移動用戶擁有(公有，私有)密鑰對并且已為其獲得證書，則他可以一起使用該證書和相應(yīng)的密鑰以在例如移動電子商務(wù)應(yīng)用中創(chuàng)建數(shù)字簽名而且也可以向服務(wù)器認證(如TLS中)。
6GAA結(jié)構(gòu)模塊 6.1GAA結(jié)構(gòu)概述
圖5GAA結(jié)構(gòu)模塊的相互關(guān)系詳細總覽 本節(jié)給出了不同GAA文檔的內(nèi)容的高級概述，并描述了這些文檔如何適應(yīng)在一起。
6.2GAA GAA是指描述了通用認證框架的通用框架的此TR。
6.3GBA 如5.2節(jié)指示的概要，GBA基于3GPP AKA提供通用機制以在UE和服務(wù)器間安裝共享秘密。
AKA是移動網(wǎng)絡(luò)所用的一種非常強大的機制。GBA得到本機制的益處并且重用AKA以引導(dǎo)應(yīng)用安全。GBA引入了一個稱作引導(dǎo)服務(wù)器功能(BSF)的新網(wǎng)元(NE)。該BSF具有與HSS的接口。UE通過BSF使用HSS運行AKA。根據(jù)該結(jié)果(CK、IK)，在BSF和UE中產(chǎn)生一個會話密鑰。應(yīng)用服務(wù)器(在TS33.220[2]中稱為網(wǎng)絡(luò)應(yīng)用功能(NAF))可以從BSF獲得該會話密鑰和用戶檔案信息。以這種方式，應(yīng)用服務(wù)器(NAF)和UE共享密鑰，該共享密鑰可以隨后用于應(yīng)用安全，特別是在應(yīng)用會話的開始時用于認證UE和NAF(也可能用于完整性保護和/或機密性保護，盡管完整性保護和機密性保護可能在GAA的范圍中不嚴格)。UE和BSF之間和NAF和BSF之間以及BSF和HSS之間的通信是獨立于應(yīng)用，并在TS33.220[2]中描述。
以下觀點導(dǎo)致了新NE(BSF)的引入 將從HSS檢索AV的所有不同類型的NE的數(shù)量以及NE的總數(shù)量保持最小。
一個用于不同應(yīng)用的通用機制避免了機制間的大的差異性并且允許以一致的方式一次闡述安全問題。
6.4SSC 如果一個客戶想使用非對稱加密技術(shù)，他需要一個由認證機構(gòu)(CA)創(chuàng)建的數(shù)字證書。這樣的數(shù)字證書將公開密鑰綁定到其合法擁有者的身份上，并且證明該公開密鑰的合法性。如果移動用戶想擁有并且使用(公有，私有)密鑰對，該密鑰對和證書應(yīng)該被預(yù)先加載或該用戶必須具有生成或獲取密鑰對并且動態(tài)地獲得相應(yīng)的數(shù)字證書的方法。如5.3節(jié)中所是概要描述，SSC指定機制以動態(tài)地向移動用戶發(fā)布數(shù)字證書。
為動態(tài)地獲得數(shù)字證書，UE必須發(fā)送適當(dāng)?shù)淖C書請求到他歸屬運營商的PKI入口，并且該PKI入口必須認證該證書請求。證書注冊過程即發(fā)放證書給用戶和在UE和PKI入口之間的相應(yīng)通信會話事實上是移動應(yīng)用實例。就如很多移動應(yīng)用，它需要通信實體的認證，在此情況下是UE和PKI入口(后者扮演應(yīng)用服務(wù)器的角色)。對于任何其他應(yīng)用，對于此認證存在兩個選項基于預(yù)共享秘密或者基于非對稱密碼以及證書。后者是當(dāng)從PKI入口請求新證書時而另一個仍舊有效的證書已經(jīng)加載在UE中時僅有的選項。前一方法在PKI入口和UE之間需要共享秘密。如果該共享秘密不是提前配置的，則GBA可以被使用以獲得這樣共享秘密。
如圖4所示，描述于SSC TS33.221[2]中的向移動用戶發(fā)放證書的處理過程的結(jié)果是UE加載相應(yīng)有對應(yīng)于其(公有，私有)密鑰對的證書。這由綠色向上的箭頭所示。
一旦該證書就緒，它可以用于(和相應(yīng)的(公有，私有)密鑰對一起)認證該UE。這由連接證書到下面應(yīng)用(圖4中的HTTS和SSC)的黑色虛線所示。(公有，私有)密鑰對和相應(yīng)的數(shù)字證書也可以用于完整性保護(或極少用于機密性)，但這些都不是GAA范圍的一部分。6.5使用HTTPS訪問網(wǎng)絡(luò)應(yīng)用功能 可以想象，HTTPS(或HTTP/TLS)可以用在大量服務(wù)中以保護UE和應(yīng)用服務(wù)器之間的應(yīng)用會話(TS33.222中的Ua接口，見TS33.222[4])。TS33.222[4]描述了當(dāng)HTTPS用于UE和應(yīng)用服務(wù)器之間時的可能的認證選項的細節(jié)。任何已有或?qū)淼幕贖TTPS的應(yīng)用就認證的細節(jié)以及安全HTTPS會話的建立可以參考TS33.222[4]。6.5.1有認證代理的HTTPS TS33.222[4]描述了其中在UE和AS之間使用反向代理(稱為認證代理(AP))的一種機制。
AP是TLS的端點并且UE應(yīng)能同時連接到位于一個AP之后的不同AS。AP應(yīng)能使用GAA的方式認證UE，并且應(yīng)該發(fā)送認證過的UE身份給AS。如果UE認證是基于共享秘密的，那么AP在GAA架構(gòu)和術(shù)語中擔(dān)任NAF。
使用這樣的AP的可能優(yōu)勢可以包括減少認證矢量的消耗，最小化SQN同步失敗以及減少UE需要建立和保持的TLS會話的數(shù)目。
6.5.2無認證代理的HTTPS 基于HTTP的應(yīng)用服務(wù)也可以在沒有使用認證代理的情況下進行部署。在該情況下，HTTPS(或TLS)會話位于UE和AS之間。在該情況下，AS應(yīng)該能夠使用GAA的方式認證UE。如果UE的認證是基于共享秘密的，那么AS在GAA架構(gòu)和術(shù)語中擔(dān)任NAF。
7使用GAA的應(yīng)用指南 GAA向AS或AP提供了不同選擇以執(zhí)行用戶認證(即如TS 33.220[2]中所描述的強迫UE使用BSF運行AKA或使用基于用戶證書的機制)。還在GAA下，AS可以明白該用戶請求已經(jīng)由認證代理認證。
在TR中描述的GAA不具有將任何一種認證機制強加到應(yīng)用上的意圖。而它的目的是作為開發(fā)者部署的工具，他們可以按照其利益來使用。通過使用GAA代替設(shè)計和實現(xiàn)應(yīng)用專用的認證機制，應(yīng)用開發(fā)者可以節(jié)省開發(fā)時間。GAA機制的額外優(yōu)勢是它們可以提供從GSM/UMTS繼承覆蓋繼承而來的全球覆蓋。
依靠運營商的網(wǎng)絡(luò)配置和策略，AS或AP將能夠使用由GAA提供的任何選項，或者甚至3GPP之外指定的其他用戶認證機制，如果這樣的機制處于它們的部屬。因此，假設(shè)AS和AP應(yīng)該能夠決定使用GAA的哪些部分(如果存在的話)。
本章試圖給出可以在認證機制的選擇中扮演角色的觀點的概述。認證機制的選擇依賴于 1.相關(guān)于需要認證的用戶/服務(wù)器/應(yīng)用/設(shè)備的需要/策略。這也許是處于兩個方向上(相互認證)，但通常強調(diào)的是用戶到服務(wù)器的認證。
2.用戶配置里所定義的設(shè)備和服務(wù)的特征，用戶能力和優(yōu)選項。
3.提供傳輸服務(wù)的網(wǎng)絡(luò)以及應(yīng)用的服務(wù)提供商的策略。
與認證相關(guān)的需求/策略將依賴于是否存在下列需要 a)設(shè)備認證設(shè)備真實有效而非克隆，即(U)SIM認證質(zhì)詢響應(yīng). b)完整性保護例子是UTRAN接入中的信令保護。GSM的弱點是對于中間人非常容易操縱信令消息例如密碼模式命令以及阻止它被威脅的方式是使用設(shè)備認證，并通過對特定信令消息上的加密MAC(消息認證碼)達到的完整性保護。
c)應(yīng)用認證將經(jīng)常需要驗證應(yīng)用軟件的確實性。例子是TS29.198-03[8]和TS29.199-01[9]。然而應(yīng)用認證在GAA的范圍之外。
d)用戶認證這這是指終端用戶、正在使用終端用戶設(shè)備的人的認證。做到此認證的一個方式是邏輯上通過用戶PIN輸入，或物理上通過移除或插入策略來使得USIM可用性依賴于設(shè)備/協(xié)議/應(yīng)用。也可以在訪問前要求PIN的輸入，其對于特定應(yīng)用是允許的。
e)事務(wù)認證和反抵賴性對于一些使用移動設(shè)備進行的商業(yè)事務(wù)，有必要使用用戶的私有密鑰對該交易進行數(shù)字簽名，尤其是其中存在對于反抵賴性的需要以阻止下列情況時 -消息發(fā)送(SENDING)的欺詐否認，如“我從未發(fā)送過它” -消息的內(nèi)容(CONTENT)，如“我說過你應(yīng)出售，而不是買” -消息的時間(TIME)，如“我在不同時間發(fā)送了它” 注意諸如3GPP AKA的許多認證技術(shù)都是基于在網(wǎng)絡(luò)和用戶間共享的單一密鑰。這對于發(fā)送者和接收者之間的認證是可行的(OK)，但可以向第三方證明的反抵賴可以要求使用公有密鑰技術(shù)，其中私有密鑰僅由發(fā)送者擁有。
圖5示出了設(shè)備和業(yè)務(wù)特征如何影響從認證機制的范圍中進行特定技術(shù)的選擇。
X客戶特征不滿足認證要求。
圖5認證特征比較 7.1共享秘密和GBA的使用 其中來自于GBA的革新的共享密鑰的一些實例可以被使用的是 -對稱加密和完整性密鑰的分發(fā)，這些密鑰能保護運行在網(wǎng)絡(luò)中的UE和服務(wù)器之間的應(yīng)用的安全。可以用于保護應(yīng)用安全并且需要共享密秘的例子協(xié)議包括HTTP摘要、共享秘密TLS和IPsec； -用于第三方應(yīng)用的口令和PIN的分發(fā)； -用于保護UE和認證機構(gòu)(CA)之間證書的分發(fā)。
7.2證書的使用 其中證書可以用于認證的一些實例是 -當(dāng)必須驗證終端用戶的身份時； -當(dāng)應(yīng)用安全協(xié)議與(公有，私有)密鑰對認證合作川頁利并且用戶證書是有效的(例如，正常TLS)時； -其中存在對于反抵賴性的需要，并且由于諸如3GPP AKA的很多認證技術(shù)是基于單一密鑰的，所以用戶被要求使用用戶的私有密鑰對交易進行數(shù)字簽名，該單一密鑰在網(wǎng)絡(luò)和用戶間共享。可向第三方證明的反抵賴性可以要求使用公有密鑰技術(shù)，其中私有密鑰僅由發(fā)送者擁有。
附錄A更改歷史 附錄B 3GPP TS33.220V7.1.1(2005-10) 技術(shù)報告 第三代伙伴計劃； 技術(shù)規(guī)范組服務(wù)和系統(tǒng)方面； 通用認證架構(gòu)(GAA)； 通用引導(dǎo)架構(gòu) (版本7) 本文檔已經(jīng)在第三代伙伴計劃(3GPPTM)中開發(fā)并且可以針對3GPP的意圖進一步詳細闡述。
本文檔還沒有經(jīng)過3GPP組織伙伴的任何同意處理過程并且尚未被實現(xiàn)。
提供此規(guī)范僅在3GPP內(nèi)部用于進一步的開發(fā)工作。組織伙伴不接受對于使用此規(guī)范的任何義務(wù)。
對于3GPPTM系統(tǒng)實現(xiàn)的規(guī)范和報告應(yīng)該通過3GPP組織伙伴的出版辦公室獲得。
關(guān)鍵字 UMTS，訪問，安全，IP，多媒體，SIP 3GPP 通信地址 3GPP支持辦公室地址 650Route des Lucioles-Sophia Antipolis Valbonne-FRANCE TeI.+334929442 00Fax+334936547 16 因特網(wǎng) http://www.3gpp.org 版權(quán)聲明 除了通過書面許可的授權(quán)之外沒有部分可以復(fù)制。
版權(quán)和前述限制擴展到所有媒體中的復(fù)制。
_2005，3GPP Organizational Partners(AR1B，ATIS，CCSA，ETSI，TTA，TTC)。
All Right reserved 3GPP 目錄 前言.......................................................6 1范圍.......................................................8 2參考.......................................................8 3定義、縮略語符號和約定.....................................10 3.1定義....................................................10 3.2縮略語符號..............................................11 3.3符號....................................................11 3.4約定....................................................11 4通用引導(dǎo)架構(gòu).............................................12 4.1參考模型..............................................12 4.2網(wǎng)元..................................................13 4.2.1引導(dǎo)服務(wù)器功能(BSF)................................13 4.2.2網(wǎng)絡(luò)應(yīng)用功能(NAF)..................................14 4.2.2a直徑協(xié)議(D代理)...............................14 4.2.3HSS.................................................14 4.2.4UE...................................................15 4.2.5SLF................................................15 4.3引導(dǎo)架構(gòu)和參考點.......................................16 4.3.1參考點Ub............................................16 4.3.2參考點Ua............................................16 4.3.3參考點Zh............................................16 4.3.4參考點Zn............................................16 4.3.5參考點Dz............................................16 4.4引導(dǎo)的要求和原理.......................................16 4.4.1接入獨立性...........................................17 4.4.2認證方法..........................................17 4.4.3漫游...............................................17 4.4.4參考點Ub的要求......................................17 4.4.5參考點Zh的要求......................................17 4.4.6參考點Zn的要求......................................18 4.4.7引導(dǎo)事物標示符的要求.................................19 4.4.8UICC應(yīng)用的選擇和相關(guān)密鑰的要求......................19 4.4.9參考點Ua的要求.....................................20 4.4.10參考點Dz的要求......................................21 4.5過程...................................................21 4.5.1引導(dǎo)的初始化.........................................21 4.5.2引導(dǎo)過程.............................................21 4.5.3使用引導(dǎo)安全關(guān)聯(lián)的過程...............................23 4.5.4涉及服務(wù)發(fā)現(xiàn)的過程....................................26 5基于UICC增強的通用引導(dǎo)架(GBAJU).............................26 5.1用于帶有基于UICC增強的引導(dǎo)的架構(gòu)和參考點................26 5.2帶有基于UICC增強的引導(dǎo)的要求和原理........................26 5.2.1UE的要求................................................26 5.2.2BSF的要求.............................................27 5.3用于帶有基于UICC增強的引導(dǎo)的過程..........................27 5.3.1引導(dǎo)的初始化............................................27 5.3.2引導(dǎo)過程................................................27 5.3.3使用引導(dǎo)安全關(guān)聯(lián)的過程.................................29 5.3.4涉及服務(wù)發(fā)現(xiàn)的過程.....................................32 附錄A空.....................................................33 附錄B(標準化的)密鑰衍生函數(shù)KDF的規(guī)范........................34 B.I介紹.......................................................34 B.2通用密鑰衍生函數(shù).........................................34 B.2.I輸入?yún)?shù)編碼............................................34 B.3GBA和GBA U中NAF專用密鑰衍生.................................35 附錄C空.....................................................36 附錄D(資料性的)GBA中使用的UICC應(yīng)用的用戶選擇的對話框?qū)嵗?....37 附錄E(標準化的)用于保證Zn的參考點安全的TLS簡檔......................38 附錄F(資料性的)TLS證書的處理.......................................39 F.I TLS證書注冊.....................................................39 F.2TLS證書撤銷......................................................39 附錄G(標準化的)GBA_U UICC-ME接口....................................40 G.I GBA_U引導(dǎo)過程....................................................40 G.2GBA_U NAF衍生過程..................................................40 附錄H(標準化的)Ua安全協(xié)議標示符.....................................42 H.I定義..............................................................42 H.2組織八位字 節(jié)..............................................42 H.3用于3GPP指定協(xié)議的Ua安全協(xié)議標示符..................................42 附錄I(標準化的)2G GBA..............................................44 1.1參考模型...........................................................44 1.2網(wǎng)元...............................................................44 1.2.1引導(dǎo)服務(wù)器功能(BSF)...............................................44 1.2.2網(wǎng)絡(luò)應(yīng)用功能(NAF)..................................................44 I.2.2a直徑協(xié)議(D代理)..........................................45 1.2.3HSS...............................................................45 1.2.4UE..................................................................46 1.3引導(dǎo)架構(gòu)和參考點......................................................46 1.3.1參考點Ub...........................................................46 1.3.2參考點Ua..........................................................46 1.3.3參考點Zh...........................................................46 1.3.4參考點Zn...........................................................46 1.4引導(dǎo)的要求和原理....................................................46 1.4.1接入獨立性.......................................................47 1.4.2認證方法.........................................................47 1.4.3漫游............................................................47 1.4.4參考點Ub的要求......................................47 1.4.5參考點Zh的要求......................................47 1.4.6參考點Zn的要求.....................................48 1.4.7引導(dǎo)事物標示符的要求................................49 1.4.8UICC應(yīng)用的選擇和SIM卡的求............................49 1.4.9參考點Ua的要求.......................................50 1.5過程....................................................50 1.5.1引導(dǎo)的初始化.........................................50 1.5.2引導(dǎo)過程.............................................50 1.5.3使用引導(dǎo)安全關(guān)聯(lián)的過程...............................53 1.5.4涉及服務(wù)發(fā)現(xiàn)的過程...................................55 1.6TLS簡檔................................................55 1.6.1保護機制............................................56 1.6.2BSF的認證...........................................56 1.6.3UE的認證............................................56 1.6.4安全參數(shù)的建立.......................................56 附錄J(資料性的)BSF中帶有本地策略加強的USS的使用.........57 J.I綜述....................................................57 J.2使用場景57 J.2.1場景1NAF不使用USS，BSF不具有用于NAF的本地策略...58 J.2.2場景2NAF不使用USS，BSF具有用于NAF的本地策略...58 J.2.3場景3NAF使用USS，BSF不具有用于NAF的本地策略...58 32.4場景4NAF使用USS，BSF具有用于NAF的本地策略..........59 附錄K(資料性的)更改歷史.................................60 前言 此技術(shù)報告已經(jīng)由第三代伙伴計劃(3GPP)制作。
本文檔的內(nèi)容服從TSG中的連續(xù)工作并且可以隨著正式的TSG同意改變。一旦TSG修改本文檔的內(nèi)容，TSG將通過帶有發(fā)布日期和如下增加的版本號的可識別變化來對其進行重新發(fā)布 版本x.y.z x第一個數(shù)字 1呈現(xiàn)給TSG用于信息 2呈現(xiàn)給TSG用于同意 3或者更大指示修改控制下的TSG同意文檔 y第二個數(shù)字增大用于所有實質(zhì)的修改，即技術(shù)增強、修正、更新等。
z當(dāng)僅編輯性修改已經(jīng)合并于該文檔中時第三個數(shù)字增大。
1范圍 本文檔描述了安全特征和引導(dǎo)認證的機制以及來自于3GPP AKA機制的用于應(yīng)用安全的密鑰協(xié)定。使用此引導(dǎo)機制的候選應(yīng)用包括但不限于用戶證書分發(fā)TS33.221[5]。用戶證書支持其提供得到移動運營商輔助得服務(wù)，以及移動運營商提供的服務(wù)。
此規(guī)范的范圍包括通用AKA引導(dǎo)功能、架構(gòu)概述和如何引導(dǎo)憑證的詳細過程。
此規(guī)范的第4章描述了稱作GBA_ME的機制，以引導(dǎo)認證以及密鑰協(xié)議，其不需要對UICC進行任何改變。此規(guī)范的第5章描述了稱作GBA_U的機制以引導(dǎo)認證以及密鑰協(xié)議，其盡管需要對UICC進行改變，但是通過在UICC上存儲特定衍生密鑰來提供增強的安全性。
2參考 下列文檔包含通過此文本中的參考的規(guī)定，這些規(guī)定組成本文檔的規(guī)定。
●參考是特定的(由出版日期、印刷號、版本號等識別)或非特定的。
●對于特定參考，后續(xù)修改不適用。
●對于非特定參考，應(yīng)用最新版本。在參考3GPP文檔(包括GSM文檔)的情況中，非特定參考隱含地指與當(dāng)前文檔具有相同版本的文檔的最新版本。
[1]3GPP TS31.102″3rd Generation Partnership Project；Technical Specification Group Terminals；Characteristics of the USIM application″. [2]3GPP TS33.1.02″3rd Generation Partnership Project；Technical Specification Group Servicesand System Aspects；3G Security；Security architecture″. [3]Franks J.，et at.″HTTP AuthenticationBasic and Digest Access Authentication″，RFC 2617，June1999. [4]A.Niemi，et al，″Hypertext Transfer Protocol(HTTP)Digest Authentication Using Authenticationand Key Agrecment(AKA)″，RFC 3310，September2002. [5]3GPP TS33.221″3rd Generation Partnership Project；Technical Speclfication Group Servicesand System Aspects；Generic Authentication Architecture(GAA)；Support for SubscriberCertificates″. [6]T.Dierks，et al，″The TLS Protocol Vcrsion 1.0″，RFC 2246.January 1999. [7]OMA″Provisioning Content Version 1.1″，Verslon 13-Aug-2003.Open Mobile Alliance. [8]3GPP TS23.228″3rd Generation Partnership Project；Technical Specification Group Servicesand System Aspects；IP Multimedia Subsystem(IMS)；Stage 2(Release 6)″ [9]1ETF RFC35.46(2003)″Transport Layer Security (TLS)Extensions″. [10]3GPP TS31.103″3rd Generation Partnership Project；Technical Specification Group Terminals；Characteristics of the IP Multimedia Services Idcntity Module(ISIM)application″. [11]3GPP TS23.003″3rd Generation Partnership Project；Technical Specification Group CoreNetwork；Numbering.addressing and identication″. [12]IETF RFC3548(2003)″The Base16，Base32，and64 Data Encodings″. [13]3GPP TS33.210″3rd Generation Partncrship Project；Technical Specification Group Servlcesand System Aspects；3G Securlty；Network domaln security；IP network layer security″. [14]IETF RFC3588(2003)″Diamcter Base Protocol″. [15]3GPP TS31.101″3rd Generation Project；Technical Spccification Group Terminals；UICC-terminal interface；Physical and logical characteristics″. [16]3GPP TS33.203″3rd Gencration Partnership Project；Technical Speclfication Group Servicesand System Aspects；3G securlty；Access security for IP-based services″. [17]IETF RFC 3280(2002)″Internet X.509 Public Key Infrastructure Certificate and CertificateRevocation Llst(CRL)Profile″. [18]IETF RFC 2818(2000)″HTTP over TLS″. [19]3GPP TS33.310″3rd Generation Partnership Project；Technical Specification Group Service andSystem Aspects；Network Domain Security (NDS)；Authentication Framework(AF) [20]1ETF RFC2560(1999)″X.509 Internet Public Key Infrastructure Online Cartificate StatusProtocol-OCSP″. [21]FIPS PUB180-2(2002)″Secure Hash Standard″. [22]IETF RFC2104(1997)″HMACKeyed-Hashing for Message Authentication″. [23]ISO/IEC10118-32004；″Information Technology-Security technlques-Hash-functions-Part3Dedlcated hash-functions″. [24]IETF RFC 3629(2003)″UTF-8，a transformation format of ISO 10646″. [25]3GPP TS 33.222″3rd Generation Partnership Project；Technical Specification Group Servicesand System Aspects；Ganeric Authentication Architecture (GAA)；Access to network applicationfunctions using Hypertexi Transfer Protocol over Transport Layer Security(HTTPS)″. [26]3GPP TS33.246″3G Security；Security of Multimedie Broaocast/Multicast Service (MBMS)″. [27]IETF Internet-Droft；″Pre-Shared Key Ciphersuites for Transport Layer Security(TLS)″.December2005，URLhttp://www.ietf.org/internet-drafts/draft-lctf-tis-psk-09.txt. [28]IETF RFC2246(1999)″The TLS Protocol Version 1″. [29]3GPP TS 24.1093rd Generation Partncrship Project；Technical Specification Group CoreNetwork and Terminals；Bootstrapping interface(Ub)and network application function interface [30]OMA WAP-219-TLS，4.11.2001http://www.openmboilealtiance.org/tech/affliates/wap/wap-219-tis-20010411-a.pdf. [31]OMA WAP-211-WAPCert，22.5.2001http://www.openmobilealliance.org/tech/affiliates/wap/wap-211-wapcert-20010522-a.pdf. 3定義、縮略語符號和約定 3.1定義 出于本文檔的目的，應(yīng)用下列術(shù)語和定義。
應(yīng)用此文檔中的所有地方，其中使用術(shù)語應(yīng)用指由MNO或者第三方向移動用戶提供的服務(wù)，那么，它總是表示應(yīng)用的類型而不是安裝在應(yīng)用服務(wù)器上的應(yīng)用的實例。
引導(dǎo)服務(wù)器功能BSF在MNO、BSF、HSS的控制下駐留在網(wǎng)元中，并且UE參與GBA，在該GBA中通過運行引導(dǎo)過程在網(wǎng)絡(luò)和UE間建立共享密鑰。該共享密鑰可以在NAF和UE間使用，例如，用于認證目的。
引導(dǎo)使用過程在Ua參考點上使用引導(dǎo)安全關(guān)聯(lián)的過程。
GBA功能在使用BSF(即，支持Ub參考點)執(zhí)行引導(dǎo)過程并且將安全關(guān)聯(lián)提供給Ua應(yīng)用以運行引導(dǎo)使用過程的ME上的功能。當(dāng)Ua應(yīng)用想使用引導(dǎo)的安全關(guān)聯(lián)時，GBA功能由Ua應(yīng)用調(diào)用。
基于ME的GBA在GBA_ME中，所有GBA專用功能在ME中執(zhí)行。UICC是不察覺GBA的。如果術(shù)語GBA用于本文檔中而沒有任何進一步的條件，那么總是代表GBA_ME，見本規(guī)范第4章。
基于UICC的GBA這是具有基于UICC增強的GBA。在GBA_U中，GBA專用功能在ME和UICC之間被分開，見本規(guī)范第5章。
網(wǎng)絡(luò)應(yīng)用功能NAF駐留于網(wǎng)元中。GBA可以在NAF和UE間為了認證的目，以及為了保證UE和NAF之間的通信路徑安全而使用。
引導(dǎo)事務(wù)標識符引導(dǎo)事務(wù)標識符(B-TID)被用于將用戶身份綁定到參考點Ua、Ub和Zn中的加密資料上。
GBA用戶安全設(shè)置GUSS包含BSF特定信息元素和所有應(yīng)用專用的USS的集合。
GUSS時間戳GUSS的時間戳由HSS建立。無論HSS何時修改GUSS，其都發(fā)生改變。
NAF組NAF分組以允許將不同USS分配到代表相同應(yīng)用的NAF。此分組在每個歸屬網(wǎng)絡(luò)中分開完成，即，一個聯(lián)系在不同歸屬網(wǎng)絡(luò)中的BSF的NAF屬于每一個歸屬網(wǎng)絡(luò)中的不同組。
NAF_IdNAF的全DNS名稱與Ua安全協(xié)議標識符連接。
Ua應(yīng)用意圖使用NAF來運行引導(dǎo)使用過程的ME上的應(yīng)用。
Ua安全協(xié)議標識符與Ua上的安全協(xié)議相關(guān)聯(lián)的標識符。
用戶安全設(shè)置USS是應(yīng)用和用戶指定參數(shù)集合，其定義了兩部分，認證部分包含應(yīng)用需要的用戶身份列表(例如，IMPU、MSISDN、假名)，和授權(quán)部分包含用戶許可標記(例如對允許應(yīng)用的訪問，可以發(fā)布的證書類型)。另外，USS可以包含密鑰選擇指示，其用于GBA_U情況中以托管(mandate)基于ME的密鑰(KS_(ext)_NAF)或者基于UICC的密鑰(KS_int_NAF)或者以上兩者的使用。有時也稱作應(yīng)用專用的用戶安全設(shè)置。USS從HSS傳遞到BFS作為GUSS的一部分，并且如果NAF請求則從BSF傳遞到NAF。
3.2縮略語 出于本文檔的目的，應(yīng)用下列縮略語 AK匿名密鑰 AKA認證和密鑰協(xié)議 B-TID引導(dǎo)事務(wù)標識符 BSF引導(dǎo)服務(wù)器功能 CA證書機構(gòu) FQDN全資格域名 GAA通用認證架構(gòu) GBA通用引導(dǎo)架構(gòu) GBA_ME基于ME的GBA GBAJJ具有基于U1CC增強的GBA GUSSGBA用戶安全設(shè)置 HSS歸屬用戶系統(tǒng) IK完整性密鑰 KDF密鑰衍生函數(shù) Ks_int_NAFUICC上保留的GBA-U中的衍生密鑰 Ks_ext_NAFGBAJJ中衍生密鑰 MNO移動網(wǎng)絡(luò)運營商 NAF網(wǎng)絡(luò)應(yīng)用功能 PKI公有密鑰基礎(chǔ)結(jié)構(gòu) SLF用戶定位功能 USS用戶安全設(shè)置 3.3符號 出于本文檔的目的，應(yīng)用下列縮略語 ||連接 _異或 3.4約定 此規(guī)范中的所有數(shù)據(jù)變量使用左手側(cè)的最高位子串和右手側(cè)最低位子串表示。子串可能是比特、八位字節(jié)或者其他任意長度的比特串。當(dāng)變量被分解成大量子串時，最左(最高)子串編號為0，次高位編號為1，依次類推直到最低位。
4通用引導(dǎo)架構(gòu) 3GPP認證基礎(chǔ)設(shè)施包括了3GPP認證中心(AuC)、USIM或ISIM，以及運行在它們之間的3GPP AKA協(xié)議，并且是3GPP運營商非常有價值的資產(chǎn)。已經(jīng)認識到此基礎(chǔ)設(shè)施有助于支持網(wǎng)絡(luò)中的應(yīng)用功能并且在用戶側(cè)建立共享密鑰。因此，3GPP可以通過定義基于AKA協(xié)議的通用引導(dǎo)架構(gòu)(GBA)來提供“應(yīng)用安全的引導(dǎo)”以認證用戶。
4.1參考模型 圖4.1示出了包含在引導(dǎo)方法中實體的簡單網(wǎng)絡(luò)模型和它們之間使用的參考點。

圖4.1引導(dǎo)的簡單網(wǎng)絡(luò)模型 圖4.1示出當(dāng)網(wǎng)絡(luò)應(yīng)用功能位于拜訪網(wǎng)絡(luò)中時包含實體的簡單網(wǎng)絡(luò)模型。

注意Zn’參考點不同于Zn參考點，其中它被用在運營商之間。
圖4.1a拜訪網(wǎng)絡(luò)中引導(dǎo)的簡單網(wǎng)絡(luò)模型 4.2網(wǎng)元 4.2.1引導(dǎo)服務(wù)器功能(BSF) 通用引導(dǎo)服務(wù)器功能(BSF)和UE應(yīng)該利用AKA協(xié)議進行相互認證，并且與后來應(yīng)用在UE和網(wǎng)絡(luò)應(yīng)用功能(NAF)之間的會話密鑰達成協(xié)議。BSF應(yīng)該通過利用如附錄B中指定的密鑰衍生過程來限制對于特定NAF的密鑰資料的適用性。密鑰衍生過程在密鑰資料的生存期期間被用于多個NAF。根據(jù)BSF的本地策略設(shè)置密鑰資料的生存期。在4.5.2節(jié)中指定了密鑰資料的生成。
BSF應(yīng)該能夠從HSS獲取GBA用戶安全設(shè)置(GUSS)。
BSF應(yīng)該能夠保持一個列表，其將NAF分配到NAF組。這個列表用來選擇在GUSS中哪一個應(yīng)用專用的USS以及是否有應(yīng)用專用的應(yīng)用的USS對于特定NAF是有效的。
注意1運營商分配NAF到NAF組。HSS中的NAF組定義以及所有連接的屬于相同運營商網(wǎng)絡(luò)的BSF都應(yīng)該是相等的。由于這些網(wǎng)元屬于相同運營商網(wǎng)絡(luò)，所以NAF組定義自己的標準化在3GPP中不是必要的。
注意2NAF分組可以是例如“歸屬”和“拜訪”。它允許BSF例如，在歸屬網(wǎng)絡(luò)和拜訪網(wǎng)絡(luò)中發(fā)送USS用于具有例如對于不同NAF的不同授權(quán)標記的相同應(yīng)用。例如在拜訪網(wǎng)絡(luò)中，NAF僅指示請求的應(yīng)用，但是不會察覺用戶的歸屬網(wǎng)絡(luò)中的分組。
4.2.2網(wǎng)絡(luò)應(yīng)用功能(NAF) 已經(jīng)完成引導(dǎo)之后，UE和NAF可以運行一些應(yīng)用專用協(xié)議，其中消息的認證將基于UE和BSF間相互認證期間生成的那些會話密鑰。
對于NAF功能性的通常假設(shè)在于 -在UE和NAF之間沒有先前的安全關(guān)聯(lián)； -NAF應(yīng)該能夠定位并且與用戶的BSF進行安全的通信。
-NAF在應(yīng)用專用協(xié)議的運行期間，應(yīng)該能夠獲得UE和BSF之間建立的共享密鑰資料。
-NAF應(yīng)該能夠通過BSF從HSS獲得零個或多個應(yīng)用專用的USS； -NAF應(yīng)該能夠根據(jù)本地策略設(shè)定共享密鑰資料的本地有效條件。
-在GBA_U的情況中，NAF應(yīng)該能夠通過使用NAF中的本地策略或者應(yīng)用專用USS中的密鑰選擇指示確定應(yīng)該使用哪個密鑰(即，Ks_ext_NAF或者Ks_int_NAF或者以上兩者)。如果NAF已經(jīng)接收了包含密鑰選擇指示應(yīng)用專用USS，則這應(yīng)該忽略NAF中的本地策略 -NAF應(yīng)該能夠檢測共享密鑰資料的生存期和本地有效條件。
注意沒有額外方法的情況下，GBA不保證密鑰的刷新，某種意義上，Ks(_int/ext)_NAF不保證密鑰沒有被用于Ua協(xié)議的之前運行中。UE和NAF可以采取的以保證GBA中的密鑰刷新的額外的方法是 1)在衍生新Ks_NAF之前，強制Ub協(xié)議的新運行。
2)存儲以前使用的密鑰Ks(_int/ext)_NAF，或者相應(yīng)的密鑰標識符B-TID，直到它們生存期結(jié)束。
支持Ua協(xié)議(在協(xié)議的無連接運行上不提供回放保護)的UE和NAF將需要采取相應(yīng)行動以避免回放攻擊(如果需要的話)。
4.2.2a直徑(diameter)協(xié)議(D-Proxy) 在其中UE已經(jīng)連接到操作于另一個網(wǎng)絡(luò)而不是歸屬網(wǎng)絡(luò)的NAF的情況中，此拜訪NAF應(yīng)該使用NAF網(wǎng)絡(luò)的直徑協(xié)議(D-Proxy)以與用戶的BSF(即，歸屬BSF)進行通信。
注意D-Proxy功能性可以作為分離的網(wǎng)元來實現(xiàn)，或者作為拜訪網(wǎng)絡(luò)中實現(xiàn)直徑代理功能性的任何NE的一部分(這樣NE的例子是拜訪NAF所屬網(wǎng)絡(luò)的BSF或者AAA-服務(wù)器)。
D-Proxy功能性的一般要求是 D-Proxy應(yīng)該能夠在拜訪NAF和用戶的歸屬BSF之間起到代理的功能； D-Proxy應(yīng)該能夠定位用戶的歸屬BSF并且在安全信道上與它通信； D-Proxy應(yīng)該能夠驗證拜訪NAF被授權(quán)加入GBA，并且應(yīng)該能夠向用戶的歸屬BSF聲明拜訪的NAF DNS名稱。D-Proxy還應(yīng)該能夠向BSF聲明拜訪的NAF被授權(quán)請求包含在NAF請求中的GBA特定用戶簡檔。
D-Proxy的物理安全級別不應(yīng)該低于與之接口連接的NAF的最高級別。
4.2.3HSS 所有用戶安全設(shè)置的集合(USS)，即GUSS，存儲在HSS中。在其中用戶具有多個訂閱，即UICC上的多個ISIM或者USIM應(yīng)用的情況中，HSS應(yīng)該包含可以映射到一個或者多個私有身份，即IMPI和IMSI的一個或者多個GUSS。
HSS的要求是 -HSS應(yīng)該僅對于GUSS提供永久性存儲； -GUSS應(yīng)該以這樣的方式定義，即對于標準化應(yīng)用簡檔不同運營商的交互是可能的。
-GUSS應(yīng)該以這樣的方式定義，即不需要這些元素的標準化而支持運營商指定應(yīng)用的簡檔和對于現(xiàn)存應(yīng)用的擴展。
-GUSS應(yīng)該能夠包含應(yīng)用專用USS，該USS包含由一個或者多個NAF主持的一個或多個應(yīng)用的標識或者鑒權(quán)信息、GBA_U情況中的密鑰選擇指示(即，是否NAF應(yīng)該使用Ks_ext_NAF或者Ks_int_NAF)的相關(guān)參數(shù)。任何其他類型的參數(shù)在應(yīng)用專用USS中不允許。
注意1可以使用由應(yīng)用專用USS提供的身份信息通過NAF直接從HSS或者從它的本地數(shù)據(jù)庫中獲取必要的用戶簡檔數(shù)據(jù)。
注意2如果臨時從用戶撤銷服務(wù)，則HSS可以從GUSS中臨時移除這個應(yīng)用專用USS。
-GUSS應(yīng)該能夠包含針對BSF使用的參數(shù) -發(fā)布給用戶的UICC的類型(即是否支持GBA_U功能)； -用戶特定的密鑰生存期。
-可選擇地，指示GUSS已經(jīng)由HSS最后修改的時間的時間戳。
注意3這些參數(shù)是可選的，如果用戶的GUSS缺少它們或者用戶沒有GUSS，那么BSF將使用由特別MNO定義的BSF本地策略中的缺省值。
HSS應(yīng)該能夠分配應(yīng)用專用USS到NAF組。這將以這樣的方式定義，即對于相同應(yīng)用，但是不同NAF組的不同USS是可能的。每GUSS的USS的數(shù)量限制依靠通過運營商的NAF分組使用。
-如果沒有針對這個應(yīng)用定義NAF組，那么每個應(yīng)用最多有一個USS存儲在GUSS中。
-如果針對這個應(yīng)用定義了NAF組，那么每個應(yīng)用最多有一個USS和NAF組存儲在GUSS中。
-HSS中的NAF組定義和所有連接的屬于相同運營商網(wǎng)絡(luò)的BSF應(yīng)該是相等的。
4.2.4UE 要求的UE功能性是 -支持HTTP摘要AKA協(xié)議； -在引導(dǎo)中使用USIM和ISIM兩者的能力； -當(dāng)USIM和ISIM都存在時，選擇在引導(dǎo)中使用USIM還是ISIM的能力； -對于ME上的Ua應(yīng)用，向ME上的GBA功能指示UICC應(yīng)用的類型或者名稱以在引導(dǎo)中使用的能力； -從CK和IK衍生新的將和Ua接口上的協(xié)議一起使用的密鑰資料的能力； -支持NAF專用應(yīng)用協(xié)議(例子見TS33.221[5])。
GBA察覺的ME應(yīng)該支持如5.2.1節(jié)中指定的GBA_U和4.5節(jié)中指定的GBA_ME兩者。
4.2.5SLF 該SLF -由BSF連同Zh接口操作查詢以得到包含所需用戶特定數(shù)據(jù)的HSS的名稱。
-通過Dz接口由BSF訪問。
在單獨HSS環(huán)境中不要求SLF。當(dāng)配置/管理BSF以使用預(yù)定義的HSS時不要求使用SLF。
4.3引導(dǎo)架構(gòu)和參考點 4.3.1參考點Ub 參考點Ub處于UE和BSF之間。參考點Ub提供UE和BSF間的相互認證。它允許UE基于3GPP AKA基礎(chǔ)結(jié)構(gòu)引導(dǎo)會話密鑰。
指定于RFC3310[4]中的HTTP摘要AKA協(xié)議用在參考點Ub上。它是基于3GPP AKA TS33.102[2]協(xié)議的。到USIM的接口如TS31.102[1]中指定并且到ISIM的接口如TS31.103[10]中指定的。
4.3.2參考點Ua 參考點Ua承載應(yīng)用協(xié)議，其是利用作為參考點Ub上運行HTTP摘要AKA的結(jié)果的UE與BSF之間協(xié)商的密鑰資料來保證安全的。例如，在支持用戶證書TS33.221[5]情況下，它是允許用戶從NAF請求證書的協(xié)議。在這種情況下，NAF將是PKI入口。
4.3.3參考點Zh 使用于BSF和HSS之間的參考點Zh允許BSF從HSS獲得必要的認證信息和所有的GBA用戶安全設(shè)置。到3G認證中心的接口是HSS內(nèi)部的，并且不需要作為此架構(gòu)的一部分進行標準化。
4.3.4參考點Zn 參考點Zn由NAF使用以獲取之前HTTP摘要AKA協(xié)議從UE到BSF在參考點Ub上運行期間協(xié)商的密鑰資料。如果其被NAF請求，則它也被用于從BSF獲取應(yīng)用專用的用戶安全設(shè)置。
4.3.5參考點Dz 使用于BSF和SLF之間的參考點Dz允許BSF獲得包含所需用戶特定數(shù)據(jù)的HSS的名稱。
4.4引導(dǎo)的要求和原理 下面的要求與原理可應(yīng)用于引導(dǎo)過程 -引導(dǎo)功不應(yīng)該依賴特定的NAF； -實現(xiàn)引導(dǎo)功能的服務(wù)器需要被歸屬運營商所信任以處理認證向量； -實現(xiàn)NAF的服務(wù)器僅需要被歸屬運營商所信任以處理衍生的密鑰資料； -在運營商的歸屬網(wǎng)絡(luò)和拜訪網(wǎng)絡(luò)中支持NAF應(yīng)該是可能的； -該架構(gòu)不應(yīng)該排除在第三網(wǎng)絡(luò)中對網(wǎng)絡(luò)應(yīng)用功能的支持； -在可能的程度上，應(yīng)該重新利用現(xiàn)存協(xié)議和基礎(chǔ)設(shè)施； -為了確保寬廣的適用性，所有相關(guān)協(xié)議優(yōu)選運行于IP上； -應(yīng)該阻止正在使用GBA的一個NAF中的安全漏洞被攻擊者用來對使用GBA的其它NAF實施成功的攻擊。
-攻擊者應(yīng)該不能夠通過Ua使用一個安全協(xié)議中的漏洞來達到對Ua上不同安全協(xié)議實施成功的攻擊。
4.4.1接入獨立性 引導(dǎo)過程是接入獨立的。引導(dǎo)過程序要來自于UE的IP連接。
4.4.2認證方法 在沒有有效的蜂窩訂閱的情況下，UE與BSF之間的認證應(yīng)該是不可能的。認證應(yīng)該基于3GPP AKA協(xié)議。
4.4.3漫游 漫游的要求 -漫游用戶應(yīng)該能夠利用歸屬網(wǎng)絡(luò)中的引導(dǎo)功能。用戶應(yīng)該能夠利用處于拜訪網(wǎng)絡(luò)中的網(wǎng)絡(luò)應(yīng)用功能； -歸屬網(wǎng)絡(luò)應(yīng)該能夠控制它的用戶是否被授權(quán)以使用拜訪網(wǎng)絡(luò)中的服務(wù)。
4.4.4參考點Ub的要求 參考點Ub的要求是 -BSF應(yīng)該能夠識別UE； -BSF和UE應(yīng)該能夠基于AKA彼此認證； -BSF應(yīng)該能夠發(fā)送引導(dǎo)事務(wù)標識符到UE； -UE和BSF應(yīng)該建立共享密鑰； -BSF應(yīng)該能夠向UE指示密鑰資料的生存期。由BSF通過Ub發(fā)送的密鑰生存期將指示密鑰的到期時間。
注意這并排除UE根據(jù)UE的本地策略在到期時間之前刷新密鑰。
4.4.5參考點Zh的要求 參考點Zh的要求是 -相互認證，應(yīng)該提供保密性和完整性； 注意1如果BSF和HSS位于相同運營商網(wǎng)絡(luò)內(nèi)，此要求可以通過物理的或者專有的安全方式來滿足。
-BSF應(yīng)該能夠發(fā)送關(guān)于用戶的引導(dǎo)信息請求； -選擇性地，BSF可以具有能夠?qū)⒂脩舻腉BA用戶安全設(shè)置的時間戳發(fā)送到HSS(時間戳選項)的能力； -HSS應(yīng)該能夠每次發(fā)送一個3GPP AKA向量到BSF； -HSS應(yīng)該能夠為了安全目的的需要將用戶的GBA用戶安全設(shè)置的完整集合發(fā)送到BSF；選擇性地，HSS可以具有向BSF指示BSF是否已經(jīng)基于GUSS時間戳(時間戳選項)具有GUSS的最新副本的能力。
注意2如果用戶的GUSS在HSS中進行了更新，則此其不傳送至BSF。作為引導(dǎo)過程的一部分，當(dāng)BSF下次通過Zh參考點從HSS獲取認證向量和GUSS的時候，BSF中的GUSS會被更新。
-在HSS中將不需要關(guān)于引導(dǎo)的狀態(tài)信息； -參考點Zh上的所有過程應(yīng)該由BSF初始化的； -到HSS的不同接口的數(shù)量應(yīng)該最少。
4.4.6參考點Zn的要求 參考點Zn的要求是 -相互認證，應(yīng)該提供保密性和完整性； 如果BSF和NAF位于相同的運營商的網(wǎng)絡(luò)內(nèi)，則Zn參考點應(yīng)該根據(jù)NDS/IP[13]受到保護； -如果BSF和NAF位于不同的運營商的網(wǎng)絡(luò)中，在D-Proxy和BSF之間的Zn’參考點應(yīng)該使用如RFC2246[6]中指定的TLS來保證安全； 注意1附錄E指定TLS簡檔用于保證Zn’參考點的安全。
-BSF應(yīng)該驗證請求NAF被授權(quán)以獲得密鑰資料或者密鑰資料和被請求的USS； -NAF應(yīng)該能夠發(fā)送密鑰資料請求到BSF，包含由UE的相應(yīng)請求使用的NAF的公共主機名。BSF應(yīng)該能夠驗證NAF被授權(quán)以使用此主機名，即，當(dāng)它聯(lián)系NAF時，UE使用的FQDN； -BSF應(yīng)該能夠發(fā)送密鑰資料到NAF； -NAF應(yīng)該能夠根據(jù)BSF的策略以及來自于Zn上的NAF的請求中指示的應(yīng)用從BSF獲得應(yīng)用專用USS選擇的集會； -NAF應(yīng)該能夠向BSF指示其需要USS所針對的單個應(yīng)用或幾個應(yīng)用； 注意2如果一些應(yīng)用只需要應(yīng)用專用的USS的子集，例如，僅一個IMPU，則NAF從發(fā)送自BSF的完整USS集合中選擇這個子集。
-如果私有用戶身份和應(yīng)用專用的USS可以被發(fā)送至NAF，則BSF應(yīng)該能夠在每個NAF或每個應(yīng)用的基礎(chǔ)之上配置； 注意3如果BSF沒有將IMPI或者USS中的任何其它用戶身份發(fā)送到NAF，則用戶向NAF保持匿名；或者更精確地，B-TID功能作為臨時用戶假名。
-如果NAF向BSF請求USS并且它們沒有出現(xiàn)在用戶的GUSS中，它不應(yīng)引起一個錯誤，假設(shè)滿足提供的BSF本地策略的條件。然后，BSF應(yīng)該僅將請求的和發(fā)現(xiàn)的USS發(fā)送到NAF； -如下配置本地策略是可能的BSF可以要求一個或者多個應(yīng)用專用的USS存在于用于特定的請求NAF的特定用戶的GUSS中，并且如果不滿足條件，則拒絕來自于NAF的請求。為了滿足這個本地策略，NAF不需要通過Zn參考點請求USS，BSF要求其存在于GUSS中，更確切地說BSF檢查USS的本地存在已經(jīng)足夠了。以沒有USS被要求用于請求NAF這樣的方式配置BSF是可能的； 注意4關(guān)于本地策略使用的更多信息，見附錄J -BSF應(yīng)該能夠向NAF指示引導(dǎo)的時間和密鑰資料的生存期。由BSF通過Zn發(fā)送的密鑰生存期應(yīng)該指示密鑰的到期時間，并且應(yīng)該與由BSF通過Ub發(fā)送到UE的密鑰的生存期一致。
注意5這不能排除NAF根據(jù)NAF的本地策略在到期時間之前刷新密鑰。
注意6如果一個或者多個已經(jīng)發(fā)送到NAF的USS已經(jīng)在HSS中的用戶GUSS中更新了，則此變化在下次它通過Zn參考點從BSF獲取USS時告知NAF(假設(shè)BSF已經(jīng)通過Zh參考點從HSS更新了用戶的GUSS)。
4.4.7引導(dǎo)事物標識符的要求 引導(dǎo)事務(wù)標識符(B-TID)應(yīng)該用于將用戶身份綁定到參考點Ua，Ub和Zn中的密鑰資料。
B-TID的要求是 -B-TID應(yīng)該是全局唯一的； -B-TID應(yīng)該在參考點Ua中使用的協(xié)議內(nèi)可用作密鑰標識符； -NAF應(yīng)該能夠從B-TID中檢測UE的歸屬網(wǎng)絡(luò)和BSF。
注意1密鑰已經(jīng)無效之后，NAF可以基于刪除條件移除安全關(guān)聯(lián)。
注意2不得不注意UE和NAF之間的GBA和非GBA認證的并行使用例如，在命名空間中不導(dǎo)致沖突。這種潛在的沖突不能以通用的方式解決，因為它依靠于UE和應(yīng)用服務(wù)器之間使用的特定協(xié)議和認證機制。因此，它處于本規(guī)范的范圍之外。
對于UE和NAF之間使用的HTTP摘要認證的例子，如下應(yīng)用的并行使用是可能的<用戶名，密碼>對對于僅一個域必須是唯一的。由于NAF控制域名，所以它必須確保只有基于GBA的域才能以保留的3GPP域名命名。在NAF希望允許基于非GBA的認證也處于GBA域中的特殊的情況下，它必須確保沒有B-TID格式的用戶名被用在基于GBA的認證之外。
4.4.8UICC應(yīng)用的選擇和相關(guān)密鑰的要求 當(dāng)幾個應(yīng)用存在于UICC之上時，它們能夠運行AKA，那么ME應(yīng)該選擇這些UICC應(yīng)用的一個用于以下列優(yōu)選項順序執(zhí)行本文檔中規(guī)定的GBA的過程 1.UE確定包括哪個UICC應(yīng)用 a.ME上需要Ks_NAF的應(yīng)用(Ua應(yīng)用)可以向GBA支持功能(GBA功能)指示UICC應(yīng)用的類型或名字沒有優(yōu)先級，USIM，ISIM，或者UICC應(yīng)用的“標簽”(見TS31.101[15]中的定義)。
如果ME上的應(yīng)用指示UICC應(yīng)用的“標簽”，則執(zhí)行下面的步驟b。
如果ME上的應(yīng)用指示UICC應(yīng)用的類型應(yīng)該是 -UICC上的USIM；略過下面的步驟b并且在步驟c和d中的僅考慮USIM應(yīng)用。
-UICC上的ISIM；略過下面的步驟b，并且在步驟c和d中的僅考慮ISIM應(yīng)用。
如果ME上的應(yīng)用沒有指示優(yōu)選項，則略過下面的步驟b并且如下描述，從步驟c開始執(zhí)行選擇過程。
b.如果在步驟a中指示了“標簽”，則GBA功能應(yīng)該選擇(見TS31.102[1]中的定義)具有指示的“標簽”的UICC應(yīng)用；如果此UICC應(yīng)用的選擇不成功，則選擇過程失敗。
c.如果在步驟a中沒有指示“標簽”，則GBA功能應(yīng)該在激活的UICC應(yīng)用中選擇；如果存在多于一個的激活的UICC應(yīng)用，則GBA功能可以向終端用戶示出選擇對話的UICC應(yīng)用(該列表包含來自于UICC應(yīng)用列表的“標簽”)，從中終端用戶可以選擇將要被選擇的UICC應(yīng)用；如果沒有示出會話，則GBA功能應(yīng)該選擇“上次選擇的”活動的UICC應(yīng)用；如果Ua應(yīng)用指示了“無優(yōu)先級”并且“上次選擇的”USIM和“上次選擇的”ISIM處于活動狀態(tài)，那么“上次選擇的”USIM被選擇。
d.如果不存在活動的UICC應(yīng)用 -如果僅存在一個UICC應(yīng)用，如果可能，則GBA功能選擇它； -如果存在多于一個的UICC應(yīng)用，則GBA功能可以向終端用戶示出選擇對話的UICC應(yīng)用(該列表包含來自于UICC應(yīng)用列表的“標簽”)，從中終端用戶可以選擇將被選擇的UICC應(yīng)用。如果沒有示出會話，如果肯能，則GBA功能應(yīng)該選擇“上次選擇的”UICC應(yīng)用； e.如果指示于步驟a中并且使用于步驟d中的類型是ISIM，但是不存在ISIM供選擇，那么使用類型USIM重復(fù)步驟d；否則選擇過程失敗。
注意1步驟e被要求用于下列情況可以使用UICC上的USIM應(yīng)用來認識如TS33.203[16]中定義的ISIM。
2.如果已經(jīng)存在從UICC應(yīng)用衍生的密鑰Ks，則UE采用此密鑰以衍生Ks_NAF。
3.如果不存在這樣的密鑰Ks，則UE首先運行包含選擇的UICC應(yīng)用的Ub協(xié)議，然后到步驟2。
如果選擇了USIM，則從如TS22.003[11]13.3節(jié)中指定的那樣存儲在USIM上的IMSI獲得的IMPI被用于運行在Ub上的協(xié)議中。
注意2嚴格地講，IMPI，以及如TS23.003[11]來自于IMSI的IMPI的衍生僅在IMS的上下文中定義。然而，出于規(guī)范的目的，如TS23.003[11]13.3章中指定的從IMSI獲得的標識符也稱為IMPI，即使用戶沒有IMS訂閱。
如果選擇了ISIM，則儲存在ISIM上的IMPI被用于運行在Ub上的協(xié)議中。
不論何時UICC應(yīng)用被成功地選擇或者終止，用于選擇UICC應(yīng)用的本節(jié)中的規(guī)則是重復(fù)應(yīng)用的，并且因此，為GBA選擇的UICC應(yīng)用可以改變。
不論何時UICC應(yīng)用被終止，則通過Ub參考點(根據(jù)4.5.2和5.3.2節(jié))在協(xié)議中從其建立的共享密鑰Ks應(yīng)該被刪除。
注意3在任一時刻，最多存在一個UICC應(yīng)用，用于執(zhí)行GBA過程。
注意4在直到密鑰的生存期到期，在共享密鑰Ks已經(jīng)被刪除之后，Ua應(yīng)用可以繼續(xù)使用衍生的NAF特定密鑰(Ks(ext/int)NAF)。
4.4.9參考點Ua的要求 參考點Ua的一般要求是 -UE和NAF應(yīng)該能夠使用基于GBA的共享秘密保證參考點Ua的安全； 注意1保證參考點Ua安全的確切方法依靠參考點Ua上使用的應(yīng)用協(xié)議。
-在GBA_U的情況中，UE和NAF應(yīng)該能夠就密鑰(即，Ks_ext_NAF或者Ks_int_NAF或者以上兩者)達成一致，作為基于GBA的共享秘密使用，如果兩個密鑰可以被使用。
注意2有兩種方式在UE和NAF之間就使用哪個密鑰(Ks_(ext)或Ks_int或二者)達成一致 1)在一般情況中，其中在參考點Ua上使用的協(xié)議可以被用于不同應(yīng)用(例如，HTTPS)，協(xié)議應(yīng)該能夠指示應(yīng)該使用哪個密鑰。
2)在特定應(yīng)該中，其中協(xié)議是應(yīng)用專用的(流入，MBMS中的MIKEY)，協(xié)商可以基于隱性知識。
-Ua上的任何安全協(xié)議應(yīng)該關(guān)聯(lián)于Ua安全協(xié)議標識符。此標識符將指定于此規(guī)范的附錄H中。
-NAF應(yīng)該能夠向UE指示應(yīng)該使用的基于GBA的共享秘密； -NAF應(yīng)該能夠向UE指示已經(jīng)到期的當(dāng)前共享秘密并且UE應(yīng)該與NAF使用較新的共享秘密。
-當(dāng)在Ua應(yīng)用規(guī)范中沒有指定時，NAF專用密鑰資料Ks_(ext/int)_NAF的默認生命期應(yīng)該等于Ks的生命期。Ks_(ext/int)_NAF的默認生命期應(yīng)該不超過于相應(yīng)的Ks的生命期。
-UE和NAF可以使密鑰資料Ks_(ext/int)_NAF適應(yīng)參考點Ua的特定需要。此適應(yīng)處于此規(guī)范的范圍之外。當(dāng)在Ua應(yīng)用規(guī)范中沒有指定時，適應(yīng)的密鑰資料的默認生命期應(yīng)該等于Ks_(ext/int)_NAF的生命期。適應(yīng)的密鑰資料的生命期不應(yīng)該超過相應(yīng)Ks(ext/int)NAF的生命期。
4.4.10參考點Dz的要求 BSF和SLF之間的這個接口被用于檢索保持給定用戶的訂閱的HSS的地址。在單個HSS環(huán)境中此接口不是必需的。
4.5過程 這一節(jié)詳細指定由不同應(yīng)用進一步利用的引導(dǎo)過程的格式。它包含使用BSF的AKA認證，以及密鑰資料的產(chǎn)生過程。
4.5.1引導(dǎo)的初始化 在UE和NAF間的通信可以開始之前，UE和NAF首先必須協(xié)商是否使用GBA。當(dāng)如果UE希望與NAF交互時，但是它不知道NAF是否需要使用通過GBA方式獲得的共享密鑰，這時，UE應(yīng)該為了進一步指示聯(lián)系NAF(見圖4.2)。

圖4.2引導(dǎo)的初始化 1.UE通過參考點Ua發(fā)起與NAF的通信而沒有任何GBA相關(guān)參數(shù)。
2.如果NAF需要使用通過GBA方式獲得的共享密鑰，但是來自UE的請求中不包括GBA相關(guān)參數(shù)，則NAF使用引導(dǎo)初始化信息進行回復(fù)。這種指示方式可以依靠于特定的參考點Ua并且在相關(guān)的階段3規(guī)范中指定。
4.5.2引導(dǎo)過程 當(dāng)UE希望與NAF交互，并且它知道需要引導(dǎo)過程時，它將首先執(zhí)行引導(dǎo)認證(見圖4.3)。否則，僅當(dāng)它已經(jīng)接收到引導(dǎo)初始化要求消息或者來自NAF的引導(dǎo)協(xié)商指示時，或者當(dāng)UE中的密鑰生存期已經(jīng)到期時，UE應(yīng)該執(zhí)行引導(dǎo)認證。(協(xié)議4.5.3子節(jié))。
注意1來自于規(guī)范TS33.102[2]的AKA協(xié)議以及RFC3310[4]中的HTTP摘要AKA協(xié)議中的主要的步驟為了讀者的方便在圖3中重復(fù)。假如存在任何潛在的沖突，以TS33.102[2]和RFC3310[4]中的規(guī)范優(yōu)先。

圖4.3引導(dǎo)過程 1.UE向BSF發(fā)送HTTP請求。
2.BSF通過參考點Zh從HSS檢索GBA用戶的安全設(shè)置的完整集合和一個認證向量(AV，AV＝RAND||AUTN||XRES||CK||IK)。
如果BSF實現(xiàn)時間戳選項并且具有在以前引導(dǎo)過程期間從HSS已經(jīng)獲得的用戶的GUSS的本地副本，并且此GUSS包括時間戳，則BSF可以在請求消息中包括GUSS時間戳。當(dāng)接收那個時間戳?xí)r，如果HSS實現(xiàn)了時間戳選項，則HSS可以將其與存儲在HSS中的GUSS時間戳比較。在此情況中，如果并且僅如果HSS已經(jīng)完成比較并且時間戳是相等的，那么HSS應(yīng)該發(fā)送“GUSS時間戳相等”指示到BSF。在任何其他情況中，HSS應(yīng)該發(fā)送GUSS(如果有效)到BSF。如果BSF接收到“GUSS時間戳相等”的指示，它將保留GUSS的本地副本。在任何其他情況中，BSF應(yīng)該刪除GUSS的本地副本，并且存儲接收的GUSS(如果發(fā)送了)。
注意2在多個HSS的環(huán)境中，BSF不得不獲取HSS的地址，其中在步驟2之前，通過查詢SLF存儲用戶的訂閱。
3.然后，BSF在401消息中將RAND和AUTN(沒有CK、IK和XRES)轉(zhuǎn)發(fā)到UE。這是要求UE認證自己。
4.UE檢查AUTN以驗證質(zhì)詢來自于授權(quán)網(wǎng)絡(luò)；UE還計算出CK，IK和RES。這將導(dǎo)致會話密鑰IK和CK在BSF和UE兩者中。
5.UE發(fā)送另一個包含摘要AKA響應(yīng)(使用RES計算)的HTTP請求到BSF。
6.BSF通過驗證摘要AKA響應(yīng)來對UE進行認證。
7.BSF通過連接CK和IK來生成密鑰資料Ks。通過采用來自于步驟3的base64編碼的[12]RAND值和BSF服務(wù)器名，即base64encode(RAND)@BSF_servers_domain_name以NAI的格式生成B-TID值。
8.BSF應(yīng)發(fā)送包括B-TID的200OK消息到UE以指示認證成功。另外，在這個200OK消息中，BSF應(yīng)該提供密鑰Ks的生存期。在UE中通過連接CK和IK生成密鑰資料Ks。
9.在如4.5.3節(jié)中指定的過程期間，UE和BSF兩者都應(yīng)該使用Ks以衍生密鑰資料Ks NAF。Ks NAF應(yīng)該用于保證參考點Ua的安全。
如以Ks_NAF＝KDF(Ks，″gba-me″，RAND，IMPI，NAF_Id)計算Ks NAF，其中KDF是附錄B中定義的密鑰衍生函數(shù)，并且密鑰衍生參數(shù)由用戶的IMPI、NAF_Id和RAND組成。NAF_Id由NAF的全DNS名組成，與附錄H中指定的Ua安全協(xié)議標識符連接。KDF應(yīng)該在ME中實現(xiàn)。
注意3為了允許基于UE和BSF中NAF名稱的一致密鑰衍生，應(yīng)滿足下列三個前提條件中的至少一個 (1)在DNS中，NAF僅在一個域名下(FQDN)是已知的，即，沒有兩個不同域名指向NAF的IP地址。這必須通過管理方式完成。這個前提條件不指定于3GPP，因為在其他環(huán)境下也是必須的，例如對于沒有使用通配符(wildcard)或多名證書的TLS V1.0。
(2)NAF的每個DNS入口指向不同的IP地址。NAF響應(yīng)所有這些IP地址。每個IP地址通過NAF配置綁定到相應(yīng)的FQDN。NAF可以從IP地址看到哪個FQDN用于密鑰衍生。
(3)Ua使用傳輸主機名(UE使用的NAF的FQDN)到NAF的協(xié)議(例如帶有強制主機請求報頭字段的HTTP/1.1)。這需要NAF檢查主機名的有效性，在與適當(dāng)UE的所有通信中使用這個名字，并且將這個名字傳送給BSF以允許Ks_NAF的正確衍生。
在TLS隧道的情況下，這需要多身份證書或RFC3546[9]或者帶有類似目的的其他的協(xié)議方法的部署。
UE和BSF應(yīng)該存儲帶有相關(guān)B-TID的密鑰Ks用于將來的使用，直到Ks的生存期已經(jīng)到期，或者直到密鑰Ks被更新。
4.5.3使用引導(dǎo)安全關(guān)聯(lián)的過程 在UE和NAF可以開始通信之前，UE和NAF首先必須協(xié)商是否使用通過GBA方式獲得的共享密鑰。如果UE不知道是否與NAF使用GBA，則它使用4.5.1節(jié)中描述的引導(dǎo)初始化過程。
一旦UE和NAF已經(jīng)建立它們希望使用的GBA，那么每次UE希望與NAF交互，則執(zhí)行圖4.4中描述的下列步驟。
1.UE通過參考點Ua與NAF開始通信 -通常，UE和NAF將尚未共享要求的密鑰以保護參考點Ua。如果它們已經(jīng)共享了該密鑰(即，如果用于相應(yīng)的密鑰衍生參數(shù)NAF_Id密鑰Ks_NAF已經(jīng)是有效的)，則UE和NAF就可以立刻開始安全的通信。如果UE和NAF還沒有共享密鑰，UE如下繼續(xù)執(zhí)行 -如果UE中用于選擇的UICC應(yīng)用的密鑰Ks是有效的，則如4.5.2節(jié)制定的UE從Ks衍生密鑰Ks_NAF； -如果UE中沒有用于選擇的UICC應(yīng)用的密鑰Ks是有效的，則UE首先通過參考點Ub與BSF就新密鑰Ks達成一致，并且然后進行衍生Ks_NAF的過程； 注意1如果對于UE來說不希望使用用于被選的UICC應(yīng)用的相同Ks密鑰來衍生出多于一個Ks_NAF，那么UE就應(yīng)該首先通過參考點Ub與BSF就新的密鑰Ks達成一致，然后進行衍生Ks_NAF的過程。
-如果NAF與UE共享密鑰，但是NAF要更新該密鑰，例如，因為密鑰的生存期已經(jīng)到期或者很快將到期，或者該密鑰不能滿足NAF本地有效條件，則它將發(fā)送合適的引導(dǎo)的重協(xié)商請求到UE，見圖4.5。如果密鑰的生存期已經(jīng)到期，則參考點Ua上使用的協(xié)議將被終止。這個指示的形式依靠參考點Ua上使用的特定協(xié)議。如果UE接收了引導(dǎo)重認證請求，則它為了獲得新密鑰Ks，如4.5.2節(jié)指定的，開始參考點Ub上協(xié)議的的運行。
注意2為了允許UE和BSF中的一致密鑰衍生，兩者都必須使用相同的FQDN進行衍生(見4.5.2節(jié)的注意2)。如果只有4.5.2節(jié)的注意1的(1)和(2)被允許用于NAF，或者如果在Ua上使用的協(xié)議也將通過UE用于密鑰衍生的FQDN傳送到NAF，則對于每個使用在Ua上的協(xié)議，它將被指定。
注意3如果UE和NAF之間的共享密鑰是無效的，則NAF就可以為后續(xù)刪除設(shè)置相應(yīng)安全關(guān)聯(lián)的刪除條件。
-UE以4.3.2節(jié)中指定的格式向NAF提供B-TID，以允許NAF從BSF獲取相應(yīng)的密鑰。
注意4UE可以使密鑰資料Ks_NAF適應(yīng)參考點Ua的特定需要。此適應(yīng)在本規(guī)范的范圍之外。
-ME中GBA相關(guān)密鑰的密鑰管理(即Ks和Ks_NAF) -當(dāng)插入不同UICC時，所有GBA相關(guān)密鑰應(yīng)該從ME刪除。因此ME需要在非易失性存儲器中存儲最新插入的UICC身份以能夠?qū)⑵渑c在UICC插入和打開電源時使用的UICC身份進行比較。
-ME關(guān)閉電源時，密鑰Ks應(yīng)該從ME刪除。
-ME關(guān)閉電源時，所有其他GBA相關(guān)密鑰可從ME刪除。如果ME沒有在關(guān)閉電源時刪除GBA密鑰，那么GBA密鑰需要保存在非易失性存儲器中。
-當(dāng)通過參考點Ub就新Ks達成一致并且衍生于一個NAF_Id的密鑰Ks_NAF被更新時，衍生于不同NAF_Id并存儲在UE上的其他Ks_NAF將不會受到影響。
注意5根據(jù)4.5.2節(jié)和4.5.3節(jié)中定義的過程，在UE中存在每NAF_Id最多一個存儲的Ks_NAF。
2.NAF通過參考點Zn與BSF開始通信， -NAF請求對應(yīng)于由UE通過參考點Ua提供給NAF的B-TID的密鑰資料。如果NAF具有幾個可以與本規(guī)范聯(lián)合使用的FQDN，那么NAF應(yīng)該通過Zn在請求中傳輸用在Ua上的相同F(xiàn)QDN(見本節(jié)中關(guān)于密鑰衍生的注意2)； -UE也可以請求一個或者多個應(yīng)用專用USS用于應(yīng)用，其通過Ua從UE接收的請求可以訪問； -通過密鑰資料請求，NAF將提供UE已經(jīng)使用去訪問NAF的公共主機名到BSF，并且BSF將能夠驗證該NAF被授權(quán)使用該主機名。
3.BSF從密鑰Ks和密鑰衍生參數(shù)中衍生出對在參考點Ua上使用的協(xié)議進行保護所要求的密鑰，如4.5.2節(jié)中指定的，并且如果在用戶GUSS中它們是有效的并且如果NAF被授權(quán)接收所請求的USS，則向NAF提供請求的密鑰Ks_NAF以及引導(dǎo)時間和密鑰的生存期，以及請求的應(yīng)用專用USS和潛在的NAF組專用USS。如果由NAF所提供的B-TID所標識的密鑰在BSF是無效的，則BSF將對NAF的回復(fù)中指示。那么，NAF向UE指示引導(dǎo)重協(xié)商請求。
注意6NAF可以根據(jù)本地策略，例如Ks_NAF重用次數(shù)限制，來進一步設(shè)置Ks_NAF的本地有效條件。
注意7NAF將使用與UE同樣的方式使Ks_NAF適應(yīng)于參考點Ua的特定需要。該適應(yīng)在本規(guī)范的范圍之外。
-BSF可以要求在用戶的GUSS內(nèi)存在用于NAF的一個或多個應(yīng)用專用以及潛在的NAF組專用USS(見4.4.6節(jié))。如果GUSS缺少一個或多個這些要求的設(shè)置，則BSF將在對NAF的回復(fù)中指示這一點。
-BSF還可能根據(jù)BSF的策略將私有用戶標識(IMPI)和所請求的USS發(fā)送給NAF。
4.NAF通過參考點Ua上使用的協(xié)議繼續(xù)與UE交互。
一旦在參考點Ua上使用協(xié)議的運行完成，則達到了引導(dǎo)的目的，因為它使UE和NAF能夠以安全的方式使用參考點Ua。
msg是應(yīng)用專用數(shù)據(jù)集 Prof是用戶簡檔的應(yīng)用專用部分
圖4.4引導(dǎo)使用過程
圖4.5引導(dǎo)重協(xié)商請求 4.5.4涉及服務(wù)發(fā)現(xiàn)的過程 UE應(yīng)該從UICC應(yīng)用相關(guān)身份信息發(fā)現(xiàn)BSF的地址(UICC應(yīng)用在引導(dǎo)過程期間使用)既，用于USIM的IMSI或用于ISIM的IMPI。BSF的地址如3GPP TS23.003[11]中指定的被衍生。
5基于UICC的增強的通用引導(dǎo)架構(gòu)(GBA-U) 假設(shè)本節(jié)指定的過程中包括的UICC，BSF和HSS能夠處理GBA_U特定增強。如果NAF不是GBA_U察覺的，本節(jié)中指定的也可以應(yīng)用。
5.1用于帶有基于UICC增強的引導(dǎo)的架構(gòu)和參考點 本規(guī)范的4.4節(jié)的文本也應(yīng)用于此，另外ME與UICC之間的接口如TS31.102[1]和TS31.103[10]中定義的需要使用GBA_U特定命令增強。這些命令的要求可以在5.2.2.1中找到，過程的細節(jié)在5.3節(jié)中。
5.2帶有基于UICC增強的引導(dǎo)的要求和原理 4.3節(jié)的要求和原理也應(yīng)用于此并且?guī)в邢铝懈郊觾?nèi)容 5.2.1UE的要求 Ub上參考點的協(xié)議運行產(chǎn)生的3G AKA密鑰CK和IK不應(yīng)該離開UICC。
UICC應(yīng)該能夠在針對GBA_U的認證請求和針對其他3G認證域的認證請求間進行區(qū)分。
在認證請求來自ME時(UICC知道其與GBA_U相關(guān))UICC應(yīng)該衍生引導(dǎo)密鑰。
在請求來自ME時，UICC應(yīng)該能夠從存儲在UICC上的衍生密鑰進一步衍生NAF專用的密鑰。
所有GBA察覺的ME應(yīng)該支持前面兩種請求的過程。
5.2.2BSF的要求 BSF應(yīng)該支持GBA_U和GBA_ME兩種引導(dǎo)過程。關(guān)于運行一個或其他的決定應(yīng)該基于訂閱信息(即UICC能力)。
BSF應(yīng)該能夠從HSS獲取作為GBA用戶安全設(shè)置的一部分的GBA相關(guān)的UICC能力。
5.3帶有基于UICC增強的引導(dǎo)的過程 5.3.1引導(dǎo)的初始化 本文檔的4.5.1節(jié)的文本也應(yīng)用于此。
5.3.2引導(dǎo)過程 在本節(jié)中指定的過程不同于UE和BSF中密鑰和認證向量的本地處理中4.5.2節(jié)指定的過程。通過Ub參考點交換的消息對于兩個過程是一致的。
當(dāng)UE要與NAF進行交互，并且它知道需要引導(dǎo)過程時，則它將首先執(zhí)行引導(dǎo)認證(見圖5.1)。否則，僅當(dāng)UE已經(jīng)接收到來自NAF的要求引導(dǎo)初始化消息或者引導(dǎo)重認證指示時，或者當(dāng)UE內(nèi)的密鑰生存期已經(jīng)到期時，UE將執(zhí)行引導(dǎo)認證。
注意為了方便讀者，TS33.102[2]中AKA協(xié)議的規(guī)范和RFC3310[4]中的HTTP摘要AKA協(xié)議的規(guī)范的主要步驟在圖5中重復(fù)。如果存在任何潛在沖突，TS33.102[2]和RFC3310[4]中的規(guī)范優(yōu)先。

圖5.1帶有UICC增強的引導(dǎo)過程 1.ME向BSF發(fā)送HTTP請求。
2.BSF通過Zh參考點從HSS獲得GBA用戶安全設(shè)置和一個認證向量(AV，AV＝RAND||AUTN||XRES||CK||IK)。
如果BSF實現(xiàn)時間戳選項并且具有在以前引導(dǎo)過程期間從HSS已經(jīng)獲得的用戶的GUSS的本地副本，并且此GUSS包括時間戳，則BSF可以在請求消息中包括GUSS時間戳。當(dāng)接收那個時間戳?xí)r，如果HSS實現(xiàn)了時間戳選項，則HSS可以將其與存儲在HSS中的GUSS時間戳進行比較。在此情況中，如果并且僅如果HSS已經(jīng)完成比較并且時間戳是相等的，那么HSS應(yīng)該發(fā)送“GUSS時間戳相等”指示到BSF。在任何其他情況中，HSS應(yīng)該發(fā)送GUSS(如果有效)到BSF。如果BSF接收“GUSS時間戳相等”的指示，它將保留GUSS的本地副本。在任何其他情況中，BSF應(yīng)該刪除GUSS的本地副本，并且存儲接收的GUSS(如果發(fā)送了)。
然后，BSF可以基于用戶安全設(shè)置(USS)決定執(zhí)行GBA_U。在此情況下，BSF按照以下方式來進行 -BSF計算MAC*＝MAC_Trunc(SHA-1(IK)) 注意1Trunc表示在SHA1[21]所輸出的160比特中，編號為
到[63]的64比特用在對MAC的*操作中。
BSF在去掉(flip)最低有效位后，存儲XRES。
注意2在多個HSS環(huán)境中，在步驟2之前，BSF必須通過查詢SLF獲得其中存儲用戶的訂閱的HSS的地址。
3.BSF將RAND和AUTN*(其中AUTN*＝SQN_AK||AMF||MAC*)在401消息中轉(zhuǎn)發(fā)給UE(沒有CK、IK和XRES)。這需要UE認證自己的要求。
4.ME將RAND和AUTN*發(fā)送到UICC。UICC計算IK和MAC(通過執(zhí)行MAC＝MAC*_Trunc(SHA-1(IK)))。然后UICC通過檢查AUTN(即SQN_AK||AMF||MAC)以驗證該質(zhì)詢來自于授權(quán)網(wǎng)絡(luò)；UICC也計算出CK和RES。這將導(dǎo)致會話密鑰CK和IK在BSF和UICC兩者中。然后UICC將RES(去掉最低有效位后)傳輸?shù)組E并且存儲Ks，其是UICC上CK和IK的串接。
5.ME發(fā)送另外一個包含摘要AKA響應(yīng)(利用RES計算)的HTTP請求到BSF。
6.BSF通過驗證摘要AKA來響應(yīng)認證ME。
7.BSF通過連接CK和IK生成密鑰Ks。通過采用來自于步驟3的base64編碼的RAND值以NAI的格式生成B-TID值以及BSF服務(wù)器名，即，base64encode(RAND)@BSF_servers_domain_name。
8.BSF將向UE發(fā)送包含B-TID的200OK消息以指示認證的成功。另外，在這個200OK消息中，BSF將提供密鑰Ks的生存期。
9.如果可應(yīng)用，UICC和BSF兩者將會在5.3.3節(jié)中指定的過程期間使用Ks衍生NAF專用密鑰Ks_ext_NAF和Ks_int_NAF。Ks_ext_NAF和Ks_int_NAF被用于保證Ua參考點的安全。
Ks_ext_NAF在UICC中以Ks_ext_NAF＝KDF(Ks，″gba-me″，RAND，IMPI，NAF_Id)計算，并且Ks_int_NAF在UICC中以Ks_int_NAF＝KDF(Ks，″gba-u，RAND，IMPI，NAF_Id)計算，其中KDF是附錄B中指定的密鑰衍生函數(shù)，并且密鑰衍生參數(shù)包括用戶的IMPI、NAF_Id和RAND。與附錄H中指定的Ua安全協(xié)議標識符連接的NAF_Id由NAF的全DNS名組成。用于Ks_ext_NAF衍生的密鑰衍生參數(shù)必須與那些用于Ks_int_NAF衍生的不同。這通過在Ks_ext_NAF中添加靜態(tài)字符串″gba-me″并且在Ks_int_NAF中添加靜態(tài)字符串″gba-u″作為到衍生函數(shù)的輸入?yún)?shù)來完成。
注意34.5.2節(jié)的注意3同樣應(yīng)用于此。
UICC和BSF為了能進一步使用存儲帶有相關(guān)B-TID的Ks，直到Ks的生存期到期，或者直到密鑰Ks被更新。
5.3.3使用引導(dǎo)安全關(guān)聯(lián)的過程 在UE和NAF可以開始通信之前，UE和NAF首先必須協(xié)商是否使用通過GBA方式獲得的共享密鑰。如果UE不知道與NAF是否使用GBA，它使用5.3.1節(jié)中描述的引導(dǎo)初始化過程。
一旦UE和NAF已經(jīng)建立它們希望使用的GBA，那么每次UE希望與NAF交互，則執(zhí)行圖5.3中描述的下列步驟。
接下來，UE和NAF必須協(xié)商使用哪種類型的密鑰，Ks_ext_NAF或者Ks_int_NAF，或者以上兩者。默認僅使用Ks_ext_NAF。ME和NAFs也支持這個使用，其是GBA_U不察覺的。如果Ks_int_NAF，或者Ks_ext_NAF和Ks_int_NAF兩者都被使用，則這個使用必須是UE和NAF間在本5.3.3節(jié)后面的部分中描述的過程執(zhí)行之前協(xié)商好的。任何這樣的協(xié)商否決(overrule)了密鑰的默認使用。應(yīng)該用在Ua參考點的密鑰(即Ks_int_NAF或Ks_ext_NAF)的密鑰選擇指示可以存在于階段3規(guī)范中定義的應(yīng)用專用USS中。如果該指示存在，NAF應(yīng)該使用指示的密鑰。如果在USS中指示了Ks_int_NAF密鑰，則UE試圖使用Ks_ext_NAF密鑰，則NAF應(yīng)該終止與UE的通信。
注意1這個協(xié)商可以由定義UE和NAF之間Ua參考點的規(guī)范來規(guī)定，例如用于MBMS中GBA的使用的TS33.246，或者由NAF和UE通過Ua參考點協(xié)商，或者通過配置達到。
通常，UE和NAF仍將不共享保護Ua參考點所要求的密鑰。如果它們沒有這樣做，則UE如下執(zhí)行 -如果需要Ks_ext_NAF，并且UICC中用于選擇的UICC應(yīng)用的密鑰Ks是有效的，則ME如5.3.2節(jié)中指定的請求UICC從Ks衍生密鑰Ks_ext_NAF。
-如果需要Ks_int_NAF，并且UICC中用于選擇的UICC應(yīng)用的密鑰Ks是有效的，則ME如5.3.2節(jié)中指定的請求UICC從Ks衍生密鑰Ks_int_NAF。
注意2如果UE不希望使用相同的用于選擇的UICC應(yīng)用的Ks來衍生多于一個Ks_ext/int_NAF，那么如5.3.2節(jié)指定的，UE首先應(yīng)該通過Ub參考點與BSF就新的密鑰Ks達成一致，并且然后按照要求進行衍生Ks_ext_NAF或者Ks_int_NAF，或者兩者。
如果用于選擇的UICC應(yīng)用的Ks在UE中不是有效的，如5.3.2節(jié)指定的，UE首先通過Ub參考點與BSF就新的密鑰Ks達成一致，并且然后按照要求進行衍生Ks_ext_NAF或者Ks_int_NAF，或者兩者。
如果NAF與UE共享密鑰，但是NAF需要這個密鑰的更新，則它將向UE發(fā)送合適的引導(dǎo)重協(xié)商請求。如果密鑰的生存期已經(jīng)到期，則參考點Ua上使用的協(xié)議也將終止。這個指示的形式依靠Ua上參考點使用的具體的協(xié)議。如果UE接收到引導(dǎo)重協(xié)商請求，則它將如5.3.2節(jié)中指定的為了獲得新的密鑰開始Ub上協(xié)議的運行。
注意3如果UE和NAF之間共享的密鑰成為無效，則NAF可以設(shè)置用于后續(xù)移除的相應(yīng)安全關(guān)聯(lián)的刪除條件。
注意4如果NAF不希望使用相同Ks衍生多于一個的Ks_int/ext_NAF，那么NAF應(yīng)該總是通過將密鑰更新請求發(fā)送到UE來回復(fù)由UE發(fā)送的第一請求。
1.UE和NAF現(xiàn)在可以按照要求，使用Ks_ext_NAF或者Ks_int_NAF，或者兩者通過Ua參考點開始與NAF通信。它們執(zhí)行如下 -如5.3.2節(jié)中指定的，UE將B-TID提供到NAF以允許NAF從BSF獲取相應(yīng)密鑰。
注意5為了允許BSF和UE中的一致密鑰衍生，兩者必須使用相同F(xiàn)QDN用于衍生(比較4.5.2節(jié)的注意2)。對于Ua上使用的每個協(xié)議，如果僅4.5.2節(jié)的注意2的情況(1)和(2)被允許用于NAF或者如果Ua上使用的協(xié)議也應(yīng)該通過UE將用于密鑰衍生的FQDN傳送到NAF，則它應(yīng)該被說明。
注意6UE可以使Ks_ext_NAF或者Ks_int_NAF適應(yīng)Ua參考點的特定需要。此適應(yīng)處于本規(guī)范范圍之外。
-ME中GBA相關(guān)密鑰的密鑰管理(即Ks和Ks_NAF) -當(dāng)插入不同UICC時，所有GBA相關(guān)密鑰應(yīng)該從ME刪除。因此ME需要在非易失性存儲器中存儲最新插入的UICC身份以能夠?qū)⑵渑c在UICC插入和打開電源時使用的UICC身份進行比較。
-當(dāng)ME關(guān)閉電源時，所有其他GBA相關(guān)密鑰可從ME刪除。如果ME沒有在關(guān)閉電源時刪除GBA密鑰，那么GBA密鑰需要保存在非易失性存儲器中。
-當(dāng)ME關(guān)閉電源時，UICC中的所有GBA相關(guān)密鑰不需要被刪除。
注意7在參考點Ub上每次運行了協(xié)議以后，根據(jù)5.3.2節(jié)，與新B-TID相關(guān)的新密鑰Ks在UE中衍生，從而不會發(fā)生帶有不同B-TID的密鑰Ks同時存在于UE中。
-當(dāng)通過Ub參考點就新的密鑰Ks達成一致并且需要衍生新的NAF專用的密鑰用于NAF_Id時，那么Ks_ext_NAF和Ks_int_NAF(如果存在)應(yīng)該針對此NAF_Id更新，但是其它相關(guān)于其它NAF_Id的Ks_ext_NAF或Ks_int_NAF可以存儲在UE上。以上兩種情況不應(yīng)該受到影響。
注意8根據(jù)5.3.2節(jié)和5.3.3節(jié)定義的過程，UE中存在根據(jù)NAF_Id存儲的最多一個Ks_int_NAF/Ks_ext_NAF密鑰對。
注意9這個規(guī)則保證了在UE和NAF處密鑰Ks_ext_NAF和Ks_int_NAF總是同步的。
2.NAF現(xiàn)在通過參考點Zn與BSF開始通信。
-NAF向BSF請求與B-TID相應(yīng)的密鑰，其由UE通過Ua參考點提供到NAF。如果NAF是GBA_U不察覺的，則它通過在請求中包括標記來對齊進行指示。如果NAF具有幾個可以與本規(guī)范中協(xié)同使用的FQDN，那么NAF應(yīng)該通過Zn在請求中發(fā)送用在Ua上的相同的FQDN(見本節(jié)中以上關(guān)于密鑰衍生的注意)。
-NAF也可以請求一個或者多個與用于應(yīng)用的應(yīng)用專用USS，通過Ua從UE接收的該請求可以訪問。
-通過Zn參考點上的密鑰請求，NAF應(yīng)該向BSF提供UE已經(jīng)使用以訪問NAF的NAF的公共主機名，并且BSF應(yīng)該能夠驗證NAF被授權(quán)使用這個主機名。
3.BSF如5.3.2節(jié)指定地衍生密鑰Ks_ext_NAF和Ks_int_NAF(如果額外需要)。如果NAF在它的請求中指示它是GBA_U察覺的，則BSF向NAF提供兩個密鑰，Ks_ext_NAF和Ks_int_NAF，否則BSF只提供Ks_ext_NAF。如果在用戶GUSS中它們是有效的并且如果NAF被授權(quán)接收所請求的USS，則BSF提供這些密鑰的引導(dǎo)時間和生存期時間，以及請求的應(yīng)用專用和潛在的NAF組專用USS。如果由NAF所提供的B-TID所標識的密鑰在BSF是無效的，則BSF應(yīng)該在對NAF的回復(fù)中指示此情況。那么，NAF向UE指示引導(dǎo)重協(xié)商請求。(見圖4.5)。
注意10NAF可以根據(jù)本地策略進一步設(shè)置Ks_NAF的本地有效條件，例如Ks_NAF的重用次數(shù)的限制。
注意11NAF以與UE同樣的方式來使Ks_ext_NAF和Ks_int_NAF，適應(yīng)Ua參考點的特定需要。此適應(yīng)處于本規(guī)范的范圍之外。
-BSF可以要求用戶的GUSS內(nèi)存在針對NAF的一個或多個與應(yīng)用專用USS和潛在的NAF組專用USS(見4.4.6節(jié))如果GUSS缺少一個或多個這些要求的設(shè)置，則BSF應(yīng)該在向NAF回復(fù)中指示這一點。
-BSF也可以根據(jù)BSF的策略將私有用戶身份(IMPI)和所請求的USS發(fā)送到NAF。
4.NAF現(xiàn)在使用Ua參考點上使用的協(xié)議繼續(xù)與UE交互。
-如果NAF從BSF請求了應(yīng)用專用USS并且該USS被返回到NAF，則NAF應(yīng)該檢查此USS是否包含了密鑰選擇指示。如果存在密鑰選擇指示，則NAF應(yīng)該僅使用指示的密鑰。如果通過Ua使用不同的密鑰，那么參考點Ua上使用的協(xié)議應(yīng)該被終止。
一旦完成了在Ua參考點上使用協(xié)議的運行，則由于它使UE和NAF能夠以安全的方式使用Ua參考點，則實現(xiàn)了引導(dǎo)的目的。

msg 是應(yīng)用專用數(shù)據(jù)集 Prof 是用戶簡檔的應(yīng)用專用部分 圖5.3帶有基于UICC增強的引導(dǎo)使用過程 5.3.4涉及服務(wù)發(fā)現(xiàn)的過程 本文檔4.5.4節(jié)的文本也應(yīng)用于此。
附錄A空 附錄B(標準化的) 密鑰衍生函數(shù)KDF的規(guī)范 B.1介紹 本附錄指定了密鑰衍生函數(shù)(KDF)，其用在GBA(即GBA_ME)和GBA_U兩者中的NAF專用密鑰衍生中。定義在本附錄中的該密鑰衍生函數(shù)采用下列假設(shè) 1.密鑰衍生函數(shù)的輸入?yún)?shù)是八位字節(jié)字符串-不是任意長度的比特字符串。
2.單個輸入?yún)?shù)將具有不大于65535個八位字節(jié)的長度。
B.2通用密鑰衍生函數(shù) 輸入?yún)?shù)和它們的長度應(yīng)該如下連接到字符串S中 1.八位字節(jié)中每個輸入?yún)?shù)的長度應(yīng)該編碼為兩個八位字節(jié)字符串 a)輸入?yún)?shù)Pi中每個八位字節(jié)的數(shù)量表示為范圍
的數(shù)目k。
b)那么，Li是數(shù)目k的兩個八位字節(jié)的表示，其中Li的第一八位字節(jié)的最高比特等于k的最高比特，并且Li的第二八位字節(jié)的最低比特等于k的最低比特， 例子如果Pi包含258個八位字節(jié)，那么Li將是雙八位字節(jié)字符串0x01 0x02。
2.字符串S應(yīng)該從n個如下的輸入?yún)?shù)構(gòu)造 S＝FC||P0||L0||P1||L1||P2||L2||P3||...||Pn||Ln 其中 FC是用于在算法的不同實例間區(qū)分的單個八位字節(jié)， P0是靜態(tài)ASCII編碼字符串， L0是P0長度的兩個八位字節(jié)表示， P1...Pn是n個輸入?yún)?shù)，并且 L1...Ln是相應(yīng)輸入?yún)?shù)的雙八位字節(jié)表示。
3.最終輸出，即衍生的密鑰等于使用密鑰Key針對字符串S計算的HMAC-SHA-256(在[22]和[23]中指定的) 衍生密鑰＝HMAC-SHA-256(Key，S) B.2.1輸入?yún)?shù)編碼 將根據(jù)IETF RFC3629[24]中規(guī)定的UTF-8編碼規(guī)則來將字符串編碼為八位字節(jié)串。
B.3GBA和GBA_U中NAF專用密鑰衍生 在GBA和GBA_U中，用于密鑰衍生函數(shù)的輸入?yún)?shù)應(yīng)該如下 -FC＝0x01， -P1＝RAND， -L1＝RAND的長度是16個八位字節(jié)(即0x00 0x10)， -P2＝使用UTF-8編碼(見B.2.1節(jié))將IMPI編碼為八位字節(jié)字符串， -L2＝IMPI的長度是可變的(不大于65535)， -P3＝使用UTF-8編碼(見B.2.1節(jié))將NAF_ID編碼為八位字節(jié)字符串， -L3＝NAF_ID的長度是可變的(不大于65535)， 第4章中指定的Ks_NAF以及第5章中指定的Ks_ext_NAF的密鑰衍生中， -P0＝“gba-me”(即0x67 0x62 0x61 0x2d 0x6d 0x65)，以及 -L0＝P0的長度是6個八位字節(jié)(即，0x00 0x06)。
在第5章中指定的Ks_int_NAF的密鑰衍生中， -P0＝“gba-u”(即0x67 0x62 0x61 0x2d 0x2d 0x75)，以及 -L0＝P0的長度是5個八位字節(jié)(即，0x00 0x06)。
用在密鑰衍生中的Key應(yīng)該是 -在第4和第5章中指定的Ks(即CK||IK連接的)， 注意在該規(guī)范中，此函數(shù)被表示為 Ks_NAF＝KDF(Ks，“gba-me”，RAND，IMPI，NAF_Id)， Ks_ext_NAF＝KDF(Ks，“gba-me”，RAND，IMPI，NAF_Id)， 以及 Ks_int_NAF＝KDF(Ks，“gba-u”，RAND，IMPI，NAF_Id)。
附錄C空 附錄D(資料性的) GBA中使用的UICC應(yīng)用用戶選擇的對話框?qū)嵗? 對于特定情況，4.4.8節(jié)指定用于GBA過程的UICC應(yīng)用選擇中的用戶參與。這樣包含的一個對話框窗口描述如下 -對話框的標題“認證請求”。
-解釋“服務(wù)要求你去認證，請選擇你的身份” -身份列表UICC上的可選擇的應(yīng)用列表。每個應(yīng)用的可見文本從UICC上應(yīng)用列表的“標簽”域中摘錄出來的。
-按鈕“選擇”和“取消”。
附錄E(標準化的) 用于保證Zn的參考點安全的TLS簡檔 保護參考點Zn′安全的TLS簡檔在RFC3588[14]13.2部分有詳細說明。
另外，D-Proxy證書，即，用于TLS握手中使用的客戶端證書應(yīng)該包含RFC3280[17]中指定的subjectAltName擴展。subjectAltName擴展應(yīng)該包含一個或者多個dNSName名。dNSName名可以包含通配符‘*’以及如RFC2818[18]3.1部分指定的執(zhí)行匹配。
注意D-Proxy證書應(yīng)該包含所有NAF的DNS名，NAF可以通過D-Proxy向用戶的歸屬BSF發(fā)送針對NAF專用共享秘密的請求。如果添加了新的NAF，則新的DNS名通過通配符方式(例如″*.operator.com″)被覆蓋于證書中，或者需要向證書添加新的dNSName名。在后面的情況下，D-Proxy需要新的證書。
附錄F(資料性的) TLS證書的處理 對于IPsec[19]有效的認證框架對于TLS證書無效。這個附錄的目的是在用于TLS證書的框架不存在的情況中，針對Zn′參考點上的使用，提供TLS證書處理的指導(dǎo)。
本附錄中，使用下面的縮略語CAA是A網(wǎng)絡(luò)中的證書機構(gòu)，CAB是B網(wǎng)絡(luò)中的證書機構(gòu)。CertA是A的證書，CertB是B的證書。IA是A用來識別朝向BSF的NAF的標識符集合。TB是B所信任的對等實體的集合。
F.1TLS證書注冊 TLS中的相互認證是基于公有密鑰技術(shù)和證書達到的。TLS對等A和B都需要包含證書存儲，并且應(yīng)該存在至少一個證書機構(gòu)(CA)，該CA可以在A和B是其一部分的安全域內(nèi)發(fā)布證書。CertA包含A的標識符集合IA。每個標識符是全資格域名(FQDN)的形式。類似的，B的證書是CertB。
B存儲中的證書定義B所信任的對等實體的組TB。證書的創(chuàng)建與注冊存在幾個選擇，其中三個描述如下。
1.在第一選擇中，證書機構(gòu)CAB僅存在于B的網(wǎng)絡(luò)中。CAB向B發(fā)放證書CertB并且向A發(fā)放證書CertA。證書以安全方式“帶外方式”從CAB傳送到A和B。然后，A和B兩者都通過將對等實體證書插入證書存儲中將它們的對等實體添加到它們所信任的對等實體組中A將CertB插入到A的證書存儲中并且B將CertA插入到B的證書存儲中。這個插入是典型手動的，并且細節(jié)依靠到證書存儲的管理接口的實現(xiàn)。
2.在另一個選擇中，A和B兩者的網(wǎng)絡(luò)分別包含證書機構(gòu)CAB和CAA。CAB向B發(fā)放證書CertB并且CAA向A發(fā)放證書CertA。證書以安全方式“帶外方式”從CAB傳送到A并且從CAA傳送到B。然后，A和B兩者都通過將對等實體證書插入證書存儲中將它們的對等實體添加到它們所信任的對等實體組中A將CertB插入到A的證書存儲中并且B將CertA插入到B的證書存儲中。
3.在第三選擇中，交換兩邊的CA證書CAB的證書以安全的方式“帶外方式”傳送給A并且CAA的證書以安全的方式“帶外方式”傳送給B，插入到證書存儲中，并且標記為可信任。TLS握手期間換的CertA和CertB的確認是基于證書存儲中相應(yīng)CA證書的存在的。
注意在選擇1和2中，如果對等實體生成自簽名的證書，并且以安全的方式交換它們，則可以避免對于證書機構(gòu)的需要。而且，在那些選擇中可以“帶外方式”交換證書指紋以代替證書本身。
F.2TLS證書撤銷 在PKI-撤消接口不存在的情況下，證書的撤消需要手動執(zhí)行。撤消操作包括將A從B所信任的對等實體組TB中移除。在上面描述的前兩個注冊選擇中，通過B將A的證書CertA從它的證書存儲中移除進行撤銷。這個移除可以手動完成。在第三選擇中，A的證書CertA不在B的證書存儲中。由于這個原因，B必須具有通過證書的發(fā)放者檢查CertA的合法性的方法(同樣在前兩個注冊選擇中，如果B和證書發(fā)放者可以檢查CertA的合法性，則手動維持操作的量將減少)。這種檢查可以通過使用在線證書狀態(tài)協(xié)議(OCSP)來完成，或者通過使用由CertA證書發(fā)放者公布的證書撤消列表(CRL)來完成。
附錄G(標準化的) GBA_U UICC-ME接口 本附錄描述了當(dāng)GBA_U察覺的UICC是激活的并且ME被包含于GBA引導(dǎo)過程中時，UICC-ME接口將被使用。當(dāng)UICC應(yīng)用不是GBA_U察覺的，如TS31.102[1]和TS31.103[10]中指定的，ME在非GBA_U的安全上下文中使用AUTHENTICATE命令(即如果是USIM應(yīng)用則使用UMTS安全上下文，如果是ISIM應(yīng)用，則使用IMS安全上下文)。
G.I GBA_U引導(dǎo)過程 這個過程是5.3.2節(jié)中描述的引導(dǎo)過程的一部分。
ME將RAND和AUTN發(fā)送到UICC，其如5.3.2節(jié)描述的執(zhí)行Ks衍生。
然后，UICC儲存Ks。UICC也儲存使用的RAND以識別當(dāng)前引導(dǎo)的值。UICC中的RAND值通過ME是可進一步可訪問的。
然后，ME最后確定下引導(dǎo)過程，并且在UICC中存儲事務(wù)標識符(B-TID)和與之前引導(dǎo)的密鑰(即Ks)相關(guān)的密鑰生存期。UICC中的存儲事務(wù)標識符和密鑰生存時間通過ME應(yīng)該是進一步可訪問的。
在GBA_U引導(dǎo)的結(jié)尾，UICC存儲Ks、事務(wù)標識符、密鑰生存時間和RAND。
UICC將RES發(fā)送到ME。
新引導(dǎo)過程取代之前引導(dǎo)過程的Ks，、B-TID、密鑰生存時間和RAND。

圖G.1GBA_U引導(dǎo)過程 G.2GBA_U NAF衍生過程 這個過程是使用5.3.3節(jié)描述的引導(dǎo)安全關(guān)聯(lián)過程的一部分。
ME將NAF_ID和IMPI發(fā)送到UICC。然后，UICC如5.3.3節(jié)描述地執(zhí)行Ks_ext_NAF和Ks_int_NAF衍生。UICC使用來自于之前引導(dǎo)過程存儲的RAND和Ks值。UICC返回Ks_ext_NAF到ME，并且一起存儲Ks_int_NAF和相關(guān)的B-TID以及NAF_Id。
注意之前需要采取之前的GBA_U引導(dǎo)。如果UICC中的Ks不是有效的，則命令將使用合適的錯誤信息應(yīng)答。

E.2GBA_U NAF衍生過程 附錄H(標準化的) Ua安全協(xié)議標識符 H.1定義 Ua安全協(xié)議標示符是五個八位字節(jié)的字符串。第一八位字節(jié)表示制定Ua安全協(xié)議的組織。剩下的四個八位字節(jié)表示組織責(zé)任內(nèi)特定的安全協(xié)議。
對于由3GPP指定的所有Ua協(xié)議，本附錄將包含這些協(xié)議的完整列表。對于由其他組織指定的所有Ua協(xié)議，本附錄將僅指定Ua安全協(xié)議標識符的組織八位字節(jié)。兩個組織八位字節(jié)為特殊使用而保留。
H.2組織八位字節(jié) 組織八位字節(jié)表示指定特別協(xié)議的組織。每個想要指定Ua安全協(xié)議標識符的組織應(yīng)該向3GPP申請以接收組織八位字節(jié)值，其將在本附錄中注冊。下面是注冊組織八位字節(jié)的列表 “0x00”作為第一八位字節(jié)是協(xié)議沒有另行指定的默認值。當(dāng)八位字節(jié)“0x00”被用作第一八位字節(jié)時，僅Ua安全協(xié)議標識符(0x00，0x00，0x00，0x00，0x00)將被使用。
注意所有具有Ua安全協(xié)議標識符的協(xié)議不能彼此分開。
“0x01”..“0xFE”作為第一八位字節(jié)表示制定Ua安全協(xié)議標識符的組織。
“0xFF”作為第一八位字節(jié)表示Ua安全協(xié)議標識符的私有范圍。
注意具有“0xFF”作為第一八位字節(jié)的標識符可以用于定義局部/實驗協(xié)議而不需要注冊。然而，當(dāng)使用這樣的標識符時，可以發(fā)生攻擊者可以使用Ua上一個安全協(xié)議中的安全漏洞在Ua上的不同安全協(xié)議上實施成功的攻擊。
組織的下列值被分配 “0x01”3GPP 注意具有組織八位字節(jié)“0x01”的所有協(xié)議在附錄H.3中指定。
“0x02”3GPP2 “0x03”開放移動聯(lián)盟 “0x04”GSMA H.3用于3GPP指定協(xié)議的Ua安全協(xié)議標示符 下列Ua安全協(xié)議標識符由3GPP指定 (0x01，0x00，0x00，0x00，0x00)根據(jù)TS33.221[5]的Ua安全協(xié)議。
(0x01，0x00，0x00，0x00，0x01)根據(jù)TS33.246[26]的Ua安全協(xié)議。注意TS33.246[26]提供HTTP摘要和MIKEY協(xié)議中使用的密鑰間的密鑰分離。
(0x01，0x00，0x00，0x00，0x02)根據(jù)TS24.109[29]的Ua安全協(xié)議HTTP摘要認證，除非HTTP摘要認證被用在另一個Ua安全協(xié)議的上下文中，其已經(jīng)在本附錄中的其他地方被覆蓋。
(0x01，0x00，0x01，yy，zz)根據(jù)TS33.222[25]用于“使用基于證書的NAF認證的共享基于密鑰的UE認證”的Ua安全協(xié)議，或者根據(jù)TS33.222[25]的用于“UE和NAF間的共享基于密鑰德相互認證”的Ua安全協(xié)議。這里，“yy，zz”是根據(jù)針對TLS V1.0中TLS Ciphersuites定義的值以及針對TLS[27]的PSK Ciphersuite的保護機制Ciphersuite代碼。
注意例子RFC2246[28]CiphersuiteTLS_RSA_WITH_3DES_EDE_CBC_SHA具有代碼＝{0x00，0x0A}，因此相應(yīng)協(xié)議標識符應(yīng)該是(0x01，0x00，0x01，0x00，0x0A)。
附錄I(標準化的) 2G GBA 本附錄指定實現(xiàn)選項以允許用于GBA的UICC上的SIM卡或者SIM的使用。本附錄中指定的過程被稱作2G GBA。2G GBA允許以比使用口令或者使用無增強的GSM更安全的的方式訪問應(yīng)用。它對于仍舊沒有全面部署USIM的運營商是有用的。
I.1參考模型 參考模型與4.1節(jié)中描述的相同。
I.2網(wǎng)元 I.2.1引導(dǎo)服務(wù)器功能(BSF) 通用引導(dǎo)服務(wù)器功能(BSF)和UE將使用2G AKA協(xié)議和TLS協(xié)議相互認證，并且就向后應(yīng)用于UE和網(wǎng)絡(luò)應(yīng)用功能(NAF)之間的會話密鑰達成一致。BSF將通過使用附錄B中執(zhí)行的密鑰衍生過程限制密鑰資料到特定NAF的適用性。密鑰衍生過程可以在密鑰資料的生存期與多個NAF使用。密鑰資料的生存期根據(jù)BSF的本地策略被設(shè)置。密鑰資料的生成在I.5.2節(jié)中指定。
BSF將能夠從HSS獲取GBA用戶安全設(shè)置(GUSS)。
BSF將能夠從由HSS發(fā)送的認證向量的類型發(fā)現(xiàn)用戶是2G用戶還是3G用戶。
BSF應(yīng)該能夠保留列表，其分配NAF到NAF組。這個列表用來選擇在GUSS中哪一個應(yīng)用專用的USS以及是否有應(yīng)用專用的USS對于特定NAF是有效的。
注意1運營商分配NAF到NAF組。HSS中的NAF組定義以及所有連接的屬于相同運營商網(wǎng)絡(luò)的BSF都應(yīng)該是相等的。由于這些網(wǎng)元屬于相同運營商網(wǎng)絡(luò)，所以在3GPP中不必對NAF組定義自身進行標準化。
注意2NAF分組可以是例如“歸屬”和“拜訪”。它允許BSF例如在歸屬網(wǎng)絡(luò)或拜訪網(wǎng)絡(luò)中發(fā)送USS用于具有例如不同授權(quán)標記的相同應(yīng)用到不同的NAF。例如在拜訪網(wǎng)絡(luò)中，NAF僅指示請求的應(yīng)用，但是不會察覺用戶的歸屬網(wǎng)絡(luò)中的分組。
I.2.2網(wǎng)絡(luò)應(yīng)用功能(NAF) 已經(jīng)完成引導(dǎo)之后，UE和NAF可以運行一些應(yīng)用專用協(xié)議，其中消息的認證將基于UE和BSF間相互認證期間生成的那些會話密鑰。
對于NAF功能性的通常假設(shè) -在UE和NAF之間不需要存在預(yù)先的安全關(guān)聯(lián)； -NAF應(yīng)該能夠定位并且與用戶的BSF進行安全的通信。
-在應(yīng)用專用協(xié)議的運行期間，NAF能夠獲得UE和BSF之間建立的共享密鑰資料。
-NAF能夠通過BSF從HSS獲得零個或多個應(yīng)用專用的USS； -NAF能夠根據(jù)本地策略設(shè)定共享密鑰資料的本地有效條件。
-NAF能夠檢查共享密鑰資料的生存期和本地有效條件。
-NAF能夠具有是否接受2G用戶的策略。
注意沒有額外測量的情況下，GBA不保證密鑰的刷新，某種意義上，Ks(_int/ext)_NAF不保證密鑰沒有被用于Ua協(xié)議的之前運行中。UE和NAF可以采取的以保證GBA中的密鑰刷新的額外的方法是 1)在衍生新Ks_NAF之前，強制Ub協(xié)議的新運行(從而產(chǎn)生新Ks)。
2)存儲以前使用的密鑰Ks(_int/ext)_NAF，或者相應(yīng)的密鑰標識符B-TID，直到它們生存期結(jié)束。
支持Ua協(xié)議(其在協(xié)議的無連接運行上不提供回放保護)的UE和NAF在需要的時候?qū)⑿枰扇∠鄳?yīng)行動以避免回放攻擊。
I.2.2a直徑協(xié)議(D代理) 來自于4.2.2a節(jié)的文本也應(yīng)用于此。
1.2.3HSS 所有用戶安全設(shè)置的集合(USS)，即GUSS，存儲在HSS中。
HSS的要求是 -HSS應(yīng)該僅對于GUSS提供永久性存儲； -GUSS應(yīng)該以這樣的方式定義，即對于標準化應(yīng)用簡檔不同運營商的交互是可能的。
-GUSS應(yīng)該以這樣的方式定義，即不需要這些元素的標準化而支持運營商指定應(yīng)用和對于現(xiàn)存應(yīng)用簡檔的擴展。
-GUSS應(yīng)該能夠包含應(yīng)用專用USS，該USS包含GBA_U情況中的密鑰選擇指示(即，是否NAF應(yīng)該使用Ks_ext_NAF或者Ks_int_NAF)、由一個或者多個NAF主持的一個或多個應(yīng)用的標識或者鑒權(quán)信息的相關(guān)參數(shù)。任何其他類型的參數(shù)在應(yīng)用專用USS中不允許。
注意1可以由NAF直接從HSS獲取必要的用戶簡檔數(shù)據(jù)，或可以利用應(yīng)用專用USS提供的身份信息從其本地數(shù)據(jù)庫獲取。
注意2如果臨時從用戶撤銷服務(wù)，則HSS可以從GUSS中臨時移除這個應(yīng)用專用USS。
-GUSS應(yīng)該能夠包含針對BSF使用的參數(shù) -用戶特定的密鑰生存期。
-可選擇的，時間戳指示GUSS已經(jīng)由HSS最后修改的時間。
注意3這些參數(shù)是可選的，如果用戶的GUSS缺少它們或者用戶沒有GUSS，那么BSF將使用由特別MNO定義的BSF本地策略中的缺省值。
HSS應(yīng)該能夠分配應(yīng)用專用USS到NAF組。這將以這樣的方式定義，即對于相同應(yīng)用，但是不同NAF組的不同USS是可能的。每GUSS的USS的數(shù)量限制依賴于通過運營商的NAF分組使用。
-如果沒有針對這個應(yīng)用定義NAF組，那么每個應(yīng)用最多有一個USS存儲在GUSS中。
-如果針對這個應(yīng)用定義了NAF組，那么每個應(yīng)用最多有一個USS和NAF組存儲在GUSS中。
-HSS中的NAF組定義和所有連接的屬于相同運營商網(wǎng)絡(luò)的BSF應(yīng)該是相等的。
-對于2G用戶而言，關(guān)于UICC類型和密鑰選擇的信息是不要求的。
2G GBA被認作基于ME。
I.2.4UE 從UE要求的功能性是 -支持HTTP摘要AKA協(xié)議； -支持TLS； -在引導(dǎo)中使用SIM的能力； -對于ME上的Ua應(yīng)用，向ME上的GBA功能指示是否SIM被允許用在引導(dǎo)中的能力(見I.4.8節(jié))； -從Kc、RAND、SRES和Ks-輸入衍生將和Ua接口上的協(xié)議一起使用的新密鑰資料的能力； -支持NAF應(yīng)用專用協(xié)議(例子見TS33.221[5])。
2G GBA察覺的ME應(yīng)該支持如5.2節(jié)中指定的3G GBA_U和如4.5節(jié)中指定的3G GBA_ME兩者。
I.3引導(dǎo)架構(gòu)和參考點 I.3.1參考點Ub 參考點Ub處于UE和BSF之間。參考點Ub提供UE和BSF間的相互認證。它允許UE基于2G AKA基礎(chǔ)結(jié)構(gòu)引導(dǎo)會話密鑰。
I.3.2參考點Ua 參考點Ua承載應(yīng)用協(xié)議，使用作為參考點Ub上協(xié)議運行的結(jié)果的UE與BSF之間協(xié)商的密鑰資料保證其安全。
I.3.3參考點Zh 使用于BSF和HSS之間使用的參考點Zh允許BSF從HSS獲得必要的認證信息和所有的GBA用戶安全設(shè)置。到2G認證中心的接口是HSS內(nèi)部的，并且不需要作為此架構(gòu)的一部分進行標準化。
I.3.4參考點Zn 參考點Zn由NAF使用以獲取之前協(xié)議從UE到BSF在參考點Ub上運行期間協(xié)商的密鑰資料。如果NAF請求，它也被用于從BSF獲取應(yīng)用專用的用戶安全設(shè)置。
I.4引導(dǎo)的要求和原理 下面的要求與原理可應(yīng)用于引導(dǎo)過程 -引導(dǎo)功不依賴特定的NAF； -實現(xiàn)引導(dǎo)功能的服務(wù)器需要被本地運營商所信任以處理認證向量； -實現(xiàn)NAF的服務(wù)器需要被本地運營商所信任以處理衍生的密鑰資料； -可以在運營商的本地網(wǎng)絡(luò)和拜訪網(wǎng)絡(luò)中支持NAF； -該架構(gòu)不排除在第三網(wǎng)絡(luò)中對網(wǎng)絡(luò)應(yīng)用功能的支持； -在可能的程度上，應(yīng)該重新利用現(xiàn)存協(xié)議和基礎(chǔ)設(shè)施； -為了確保寬廣的適用性，所有相關(guān)協(xié)議優(yōu)選運行于IP上； -應(yīng)該阻止正在使用GBA的一個NAF中的安全漏洞被攻擊者用來對使用GBA的其它NAF實施成功的攻擊。
-UICC上的現(xiàn)存SIM卡以及它們的規(guī)范不應(yīng)該被影響。
-如果USIM和ISIM是有效的，則它們應(yīng)該如第4和5章中指定的適用，并且不應(yīng)該使用2G GBA。
-2G GBA不應(yīng)該影響如第4和5章中指定的基于USIM/ISIM的GBA。
-2G GBA不應(yīng)該減少USIM/ISIM用戶的安全性。
-2G GBA應(yīng)該最小化對于第4章中指定的基于USIM/ISIM的GBA的改變。
-2G GBA應(yīng)該提供方法以減輕GSM的已知弱點。
I.4.1接入獨立性 引導(dǎo)過程是接入獨立的。引導(dǎo)過程需要來自于LUE的IP連接。
I.4.2認證方法 在沒有有效的蜂窩訂閱的情況下，UE與BSF之間的認證應(yīng)該是不可能的。認證應(yīng)該基于GSM認證(也稱作2G AKA)協(xié)議。另外，BSF認證應(yīng)該是附加地基于帶有服務(wù)器證書的TLS。
I].4.3漫游 來自于4.4.3節(jié)的文本也應(yīng)用于此。
I.4.4參考點Ub的要求 參考點Ub的要求是 -BSF應(yīng)該能夠識別UE； -BSF和UE應(yīng)該能夠基于I.4.2中的方法彼此認證； -BSF應(yīng)該能夠發(fā)送引導(dǎo)事務(wù)標識符到UE； -UE和BSF應(yīng)該建立共享密鑰； -BSF應(yīng)該能夠向UE指示密鑰資料的生存期。由BSF通過Ub發(fā)送的密鑰生存期將指示密鑰的到期時間。
注意這并未排除UE根據(jù)UE的本地策略在到期時間之前刷新密鑰。
I.4.5參考點Zh的要求 參考點Zh的要求是 -應(yīng)該提供相互認證、保密性和完整性； 注意1如果BSF和HSS位于相同運營商網(wǎng)絡(luò)內(nèi)，此要求可以通過物理的或者專有的安全方式來滿足。
-BSF應(yīng)該能夠發(fā)送關(guān)于用戶的引導(dǎo)信息請求； -可選擇地，BSF可以具有能夠?qū)⒂脩舻腉BA用戶安全設(shè)置的時間戳發(fā)送到HSS(時間戳選項)的能力； -HSS應(yīng)該能夠發(fā)送2GP AKA向量到BSF； -HSS應(yīng)該能夠為了安全目的的需要將用戶的GBA用戶安全設(shè)置的完整集合發(fā)送到BSF；可選擇地，HSS可以具有向BSF指示BSF是否已經(jīng)基于GUSS時間戳(時間戳選項)具有GUSS的最新副本的能力。
注意2如果用戶的GUSS在HSS中進行了更新，則此消息不傳送至BSF。作為引導(dǎo)過程的一部分，當(dāng)BSF下次通過Zh參考點從HSS獲取認證向量和GUSS的時候，BSF中的GUSS會被更新。
-在HSS中不需要關(guān)于引導(dǎo)的狀態(tài)信息； -參考點Zh上的所有過程應(yīng)該由BSF初始化的； -到HSS的不同接口的數(shù)量應(yīng)該最少。
I.4.6參考點Zn的要求 參考點Zn的要求是 -應(yīng)該提供相互認證、保密性和完整性； -如果BSF和NAF位于相同的運營商的網(wǎng)絡(luò)內(nèi)，則Zn參考點應(yīng)該根據(jù)NDS/IP[13]受到保護； -如果BSF和NAF位于不同的運營商的網(wǎng)絡(luò)中，則在D-Proxy和BSF之間的Zn’參考點應(yīng)該使用如RFC2246[6]中指定的TLS來保證安全； 注意1附錄E指定用于保證Zn’參考點的安全的TLS簡檔。
-BSF應(yīng)該驗證請求NAF被授權(quán)以獲得密鑰資料或者密鑰資料和請求的USS； -NAF應(yīng)該能夠發(fā)送密鑰資料請求到BSF，包含由UE的相應(yīng)請求使用的NAF的公共主機名。BSF應(yīng)該能夠驗證NAF被授權(quán)以使用此主機名，即，當(dāng)它聯(lián)系NAF時，由UE使用FQDN； -BSF應(yīng)該能夠發(fā)送密鑰資料到NAF； -NAF應(yīng)該能夠從BSF獲得應(yīng)用專用USS選擇的集合，根據(jù)BSF的策略以及來自于Zn上的NAF的請求中指示的應(yīng)用； -NAF應(yīng)該能夠向BSF指示需要USS的單個應(yīng)用或幾個應(yīng)用； 注意2如果一些應(yīng)用只需要應(yīng)用專用的USS的子集，則NAF從發(fā)送自BSF的完整USS集合中選擇這個子集。
-如果私有用戶身份和應(yīng)用專用的USS可以被發(fā)送至NAF，則BSF應(yīng)該能夠在每個NAF或每個應(yīng)用基礎(chǔ)之上配置； -如果NAF從BSF請求USS并且它們沒有出現(xiàn)在用戶的GUSS中，它不應(yīng)引起錯誤，假設(shè)滿足BSF本地策略的條件。然后，BSF應(yīng)該僅將請求的和發(fā)現(xiàn)的USS發(fā)送到NAF； -如下配置本地策略是可能的BSF可以要求一個或者多個應(yīng)用專用的USS存在于用于特定的請求NAF的特定用戶的GUSS中，并且如果不滿足條件，則拒絕來自于NAF的請求。為了滿足這個本地策略，NAF不需要通過Zn參考點請求USS，BSF要求其存在于GUSS中，更確切地說BSF檢查USS的本地存在已經(jīng)足夠了。以沒有USS被要求用于請求NAF這樣的方式配置BSF也應(yīng)該可能的； -BSF應(yīng)該能夠向NAF指示引導(dǎo)的時間和密鑰資料的生存期。由BSF通過Zn發(fā)送的密鑰生存期應(yīng)該指示密鑰的到期時間，并且應(yīng)該與由BSF通過Ub發(fā)送到UE的密鑰的生存期一致。
注意3這不能排除NAF根據(jù)NAF的本地策略在到期時間之前刷新密鑰。
注意4如果一個或者多個已經(jīng)發(fā)送到NAF的USS已經(jīng)在HSS中的用戶GUSS中更新了，則此變化在下次它通過Zn參考點從BSF獲取USS時傳送至NAF(假設(shè)BSF已經(jīng)通過Zh參考點從HSS更新了用戶的GUSS)。
-BSF應(yīng)該將信息發(fā)送到NAF表明用戶是2G用戶。如果沒有這樣的信息被發(fā)送，則NAF將假設(shè)用戶是3G用戶。
注意5此要求使NAF能夠根據(jù)它的本地策略接受2G用戶。第二句保證了與本規(guī)范的第4和5章中指定的過程向后兼容。還要注意在GUSS中包含有關(guān)用戶類型的信息將不足以滿足此要求，因為GUSS不為每個用戶而存在。
-BSF可以根據(jù)它的本地策略確定NAF將不服務(wù)于2G用戶。如果是這樣的情況，BSF不發(fā)送密鑰到NAF。
注意6此要求允許控制BSF的運營商確定哪個應(yīng)用將僅使用3G安全。此要求對于NAF也是必需的，其不能夠評估關(guān)于由BSF發(fā)送的訂閱類型的信息，例如，預(yù)發(fā)布7NAF。
I.4.7引導(dǎo)事物標示符的要求 引導(dǎo)事務(wù)標識符(B-TID)應(yīng)該用于將用戶身份綁定到參考點Ua，Ub和Zn中的密鑰資料。
B-TID的要求是 -B-TID應(yīng)該是全局唯一的； -B-TID應(yīng)該是可用為用在參考點Ua上的協(xié)議中的密鑰標識符； -NAF應(yīng)該能夠從B-TID中檢測UE的歸屬網(wǎng)絡(luò)和BSF。
注意1密鑰已經(jīng)無效之后，NAF可以基于刪除條件移除安全關(guān)聯(lián)。
注意2不得不注意UE和NAF之間的GBA和非GBA認證的并行使用不導(dǎo)致沖突，例如，在命名空間中。這種潛在的沖突不能以通用的方式解決，因為它依靠于UE和應(yīng)用服務(wù)器之間使用的專用協(xié)議和認證機制。因此，它處于本規(guī)范的范圍之外。
對于UE和NAF之間使用的HTTP摘要認證的例子，如下應(yīng)用的并行使用是可能的<用戶名，密碼>對對于僅一個域必須是唯一的。由于NAF控制域名，則它必須確保只有基于GBA的域才能以保留的3GPP域名命名。在NAF希望允許基于非GBA的認證也處于GBA域中的特殊的情況下，它必須確保沒有B-TID格式的用戶名被用在基于GBA的認證之外。
I.4.8UICC應(yīng)用的選擇和SIM卡的要求 如果UE中存在UICC，包含USIM或ISIM，那么USIM或ISIM將如4.4.8節(jié)中指定的被使用。否則將使用SIM。
如果沒有UICC，但是UE中存在SIM卡，則將使用SIM卡。
I.4.9參考點Ua的要求 來自于4.4.9節(jié)的文本也應(yīng)用于此。
I.5過程 本章詳細指定由不同應(yīng)用進一步利用的2G GBA引導(dǎo)過程的格式。它包含使用BSF的認證過程，以及密鑰資料生成過程。
I.5.1引導(dǎo)的初始化 在UE和NAF間的通信可以開始之前，UE和NAF首先必須協(xié)商是否使用GBA。當(dāng)如果UE希望與NAF交互時，但是它不知道NAF是否需要使用通過GBA方式獲得的共享密鑰，這時，UE將聯(lián)系NAF以獲得進一步的指示(見圖I.2)。

圖I.2引導(dǎo)的初始化 1.UE通過參考點Ua發(fā)起與NAF的通信而沒有任何GBA相關(guān)參數(shù)。
2.如果NAF需要使用通過GBA獲得的共享密鑰，但是來自UE的請求中不包括GBA相關(guān)參數(shù)，則NAF使用引導(dǎo)初始化消息進行回復(fù)。這種指示方式可以依靠于特定的參考點Ua并且在相關(guān)的階段3規(guī)范中指定。
I.5.2引導(dǎo)過程 當(dāng)UE希望與NAF交互，并且它知道需要引導(dǎo)過程時，那么它將首先執(zhí)行引導(dǎo)認證(見圖I.3)。否則，僅當(dāng)它已經(jīng)接收引導(dǎo)初始化要求消息或者來自NAF的引導(dǎo)協(xié)商指示時，或者當(dāng)UE中的密鑰生存期已經(jīng)到期時，UE應(yīng)該執(zhí)行引導(dǎo)認證。(協(xié)議I.5.3子節(jié))。

圖I.3引導(dǎo)過程 1.UE與BSF建立保密保護的TLS隧道。在TLS隧道建立中，UE應(yīng)該通過BSF提供的證書來認證BSF。UE應(yīng)該檢查包含存在于BSF提供的證書中的BSF的相同F(xiàn)QDN的“域”屬性。所有ME和BSF間的進一步通信通過此TLS隧道發(fā)送。UE現(xiàn)在發(fā)送初始HTTPS請求。
2.BSF通過Zh從HSS請求認證向量和GUSS。HSS通過Zh參考點返回GBA用戶的安全設(shè)置(GUSS)的完整集合和一個2G認證向量(AV＝RAND，SRES，Kc)。BSF通過觀察認證向量類型發(fā)現(xiàn)UE配備有2G SIM。
如果BSF實現(xiàn)時間戳選項并且具有在以前引導(dǎo)過程期間從HSS已經(jīng)獲得的用戶的GUSS的本地副本，并且此GUSS包括時間戳，則BSF可以在請求消息中包括GUSS時間戳。當(dāng)接收那個時間戳?xí)r，如果HSS實現(xiàn)了時間戳選項，則HSS可以將其與存儲在HSS中的GUSS時間戳進行比較。在此情況中，如果并且僅如果HSS已經(jīng)完成比較并且時間戳是相等的，那么HSS應(yīng)該發(fā)送“GUSS時間戳相等”指示到BSF。在任何其他情況中，HSS應(yīng)該發(fā)送GUSS(如果有效)到BSF。如果BSF接收到“GUSS時間戳相等”的指示，它將保留GUSS的本地副本。在任何其他情況中，BSF應(yīng)該刪除GUSS的本地副本，并且存儲接收的GUSS(如果發(fā)送了)。
BSF將一個2G認證向量(RAND，SRES，Kc)轉(zhuǎn)換到參數(shù)RES。
-RES＝KDF(key，“3gpp-gba-res”，SRES)，截取128比特，其中key＝Kc||Kc||RAND并且KDF是TS33.220的附錄B中指定的密鑰衍生函數(shù)。
BSF也應(yīng)該選擇128比特隨機數(shù)“Ks-輸入”并且在HTTP摘要AKA的aka-nonce中設(shè)置服務(wù)器專用數(shù)據(jù)＝Ks-輸入，參考[4]。
注意“截取128比特”意味著從KDF的256比特輸出中，使用編號為
到[127]的128比特。
3.BSF將在401消息中將RAND和服務(wù)器專用數(shù)據(jù)轉(zhuǎn)發(fā)到UE(沒有RES)。這是要求UE認證自己。BSF應(yīng)該在www-認證頭中設(shè)置qop＝int(比較[3])。
4.UE從消息中抽取RAND并且計算相應(yīng)Kc和SRES值。然后，它如步驟2中指定的從這些值計算參數(shù)RES。
5.UE發(fā)送另一個包含摘要AKA響應(yīng)(使用RES作為口令來計算)和cnonce(參考[3])的HTTP請求到BSF。
6.BSF通過驗證摘要AKA響應(yīng)來對UE進行認證。如果認證失敗，則BSF將不在任何進一步的通信中重用認證向量。
7.BSF通過計算Ks＝KDF(key，Ks-輸入，“3gpp-gba-res”，SRES)生成密鑰資料Ks。通過采用來自于步驟3的base64編碼的[12]RAND值和BSF服務(wù)器名，即 base64encode(RAND)@BSF_servers_domain_name以NAI的格式生成B-TID值。
8.BSF應(yīng)付發(fā)送包括B-TID和authentication-info頭(參考[3])的200OK消息到UE以指示認證成功。另外，在這個200OK消息中，BSF應(yīng)該提供密鑰Ks的生存期。
9.如果根據(jù)[3]服務(wù)器認證失敗，則UE應(yīng)該放棄過程。如果成功了，則UE應(yīng)該以與BSF相同的方式生成密鑰資料Ks。
10.UE和BSF兩者都應(yīng)該使用Ks以衍生密鑰資料Ks_NAF，從而與如I.5.3節(jié)中指定的過程一起使用。Ks_NAF應(yīng)該用于保證參考點Ua的安全。
以Ks_NAF＝KDF(Ks，″gba-me″，RAND，IMPI，NAF_Id)計算Ks_NAF，其中KDF是附錄B中指定的密鑰衍生函數(shù)，并且密鑰衍生參數(shù)包括用戶的IMPI，NAF_Id和RAND。NAF_Id包括NAF的全DNS名，與附錄H中指定的Ua安全協(xié)議標識符連接。KDF應(yīng)該在ME中實現(xiàn)。
注意3為了允許基于UE和BSF中NAF名稱的一致密鑰衍生，應(yīng)滿足下列三個前提條件中的至少一個 (1)在DNS中，已知NAF僅在一個域名下(FQDN)，即，沒有兩個不同域名指向NAF的IP地址。這必須通過管理裝置完成。
(2)NAF的每個DNS入口指向不同的IP地址。NAF響應(yīng)所有這些IP地址。每個IP地址通過NAF配置綁定到相應(yīng)的FQDN。NAF可以從IP地址看到哪個FQDN用于密鑰衍生。
(3)Ua使用傳輸主機名(UE使用的NAF的FQDN)到NAF的協(xié)議(例如帶有強制主機請求頭域的HTTP/1.1)。這需要NAF檢查主機名的有效性，以在適當(dāng)?shù)臅r候在與UE的所有通信中使用這個名字，并且將這個名字傳送給BSF以允許Ks_NAF的正確衍生。
在Ua上TLS隧道的情況下，這需要用于NAF的多身份證書或Ua上的RFC3546[9]或者Ua上帶有類似目的的其他的協(xié)議方法的部署。
UE和BSF應(yīng)該存儲帶有相關(guān)B-TID的密鑰Ks用于將來的使用，直到Ks的生存期已經(jīng)到期，或者直到密鑰Ks被更新。
I.5.3使用引導(dǎo)安全關(guān)聯(lián)的過程 在UE和NAF可以開始通信之前，UE和NAF首先必須協(xié)商是否使用通過GBA獲得的共享密鑰。如果UE不知道與NAF是否使用GBA，它使用I.5.1節(jié)中描述的引導(dǎo)初始化過程。
一旦UE和NAF已經(jīng)建立它們希望使用的GBA，那么每次UE希望與NAF交互，則執(zhí)行圖I.4中描述的下列步驟。
1.UE通過參考點Ua與NAF開始通信 -通常，UE和NAF將不共享保護參考點Ua所要求的密碼。如果它們已經(jīng)共享了該密鑰(即，如果用于相應(yīng)的密鑰衍生參數(shù)NAF_Id密鑰Ks_NAF已經(jīng)是有效的)，則UE和NAF就可以立刻開始安全的通信。如果UE和NAF還沒有共享密鑰，則UE如下繼續(xù)執(zhí)行 -如果UE中用于選擇的UICC應(yīng)用的密鑰Ks是有效的，則如I.5.2節(jié)制定的UE從Ks衍生密鑰Ks_NAF； -如果UE中沒有用于選擇的UICC應(yīng)用的密鑰Ks是有效的，則UE首先通過參考點Ub與BSF協(xié)商新密鑰Ks，并且然后進行衍生Ks_NAF的過程； 注意1對于，如果UE不希望使用用于UICC應(yīng)用的相同Ks密鑰衍生多于一個Ks_NAF，那么UE就應(yīng)該首先通過參考點Ub與BSF協(xié)商新的密鑰Ks，然后進行衍生Ks_NAF的過程。
-如果NAF與UE共享密鑰，但是NAF要其更新該密鑰，例如，因為密鑰的生存期已經(jīng)到期或者很快將到期，或者該密鑰不能滿足NAF本地有效條件，則它應(yīng)該發(fā)送合適的引導(dǎo)的重協(xié)商請求到UE，見圖I.5。如果密鑰的生存期已經(jīng)到期，則通過參考點Ua使用的協(xié)議將被終止。這個指示的形式依靠參考點Ua上使用的特定協(xié)議。如果UE接收了引導(dǎo)重認證請求，則它為了獲得新密鑰Ks，如I.5.2節(jié)指定的，開始參考點Ub上協(xié)議的的運行。
注意2為了允許UE和BSF中的一致密鑰衍生，兩者都必須使用相同的FQDN進行衍生(見I.5.2節(jié)的注意2)。如果只有I.5.2節(jié)的注意1的(1)和(2)被允許用于NAF，或者如果Ua上使用的協(xié)議也將通過UE到NAF傳輸用于密鑰衍生的FQDN，則對于每個使用在Ua上的協(xié)議，它將被指定。
注意3如果UE和NAF之間的共享密鑰是無效的，則NAF就可以為后續(xù)刪除設(shè)置相應(yīng)安全關(guān)聯(lián)的刪除條件。
-UE以I.3.2節(jié)中指定的格式向NAF提供B-TID，以允許NAF從BSF獲取相應(yīng)的密鑰。
注意4UE可以使密鑰資料Ks_NAF適應(yīng)于參考點Ua的特定需要。此適應(yīng)在本規(guī)范的范圍之外。
-ME中GBA相關(guān)密鑰的密鑰管理(即Ks和Ks_NAF) -當(dāng)插入不同UICC或SIM卡時，所有GBA相關(guān)密鑰應(yīng)該從ME刪除。因此ME需要在非易失性存儲器中存儲最新插入的UICC身份或SIM卡身份以能夠?qū)⑵渑c在UICC插入和打開電源時使用的UICC身份或SIM卡身份進行比較。
-ME關(guān)閉電源時，密鑰Ks應(yīng)該從ME刪除。
-ME關(guān)閉電源時，所有其他GBA相關(guān)密鑰可從ME刪除。如果ME沒有在關(guān)閉電源時刪除GBA密鑰，那么GBA密鑰需要保存在非易失性存儲器中。
-當(dāng)通過參考點Ub協(xié)商出新Ks并且衍生于一個NAF_Id的密鑰Ks_NAF被更新時，衍生于不同NAF_Id的存儲在UE上的其他Ks_NAF將不會受到影響。
注意5根據(jù)I.5.2節(jié)和I.5.3節(jié)中定義的過程，在UE中針對每個NAF-Id最多存儲一個Ks_NAF。
2.NAF通過參考點Zn與BSF開始通信， -NAF請求對應(yīng)于由UE通過參考點Ua提供給NAF的B-TID的密鑰資料。如果NAF具有幾個可以與本規(guī)范聯(lián)合使用的FQDN，那么NAF應(yīng)該通過Zn在請求中傳輸用在Ua上的相同F(xiàn)QDN(見本節(jié)中關(guān)于密鑰衍生的注意2)； -UE也可以請求一個或者多個應(yīng)用專用USS用于應(yīng)用，其通過Ua從UE接收的請求可以訪問； -通過密鑰資料請求，NAF應(yīng)該提供UE已經(jīng)使用去訪問NAF的主機名到BSF，并且BSF應(yīng)能夠驗證該NAF被授權(quán)使用該主機名。
3.BSF從密鑰Ks和密鑰衍生參數(shù)衍生保護參考點Ua上使用的協(xié)議所要求的密鑰，如I.5.2節(jié)中指定的，并且如果在用戶GUSS中它們是有效的并且如果NAF被授權(quán)接收所請求的USS，則向NAF提供被請求的密鑰Ks NAF以及引導(dǎo)時間和密鑰的生存期，以及請求的應(yīng)用專用和潛在的NAF組專用USS。另外，BSF應(yīng)該向NAF指示用戶是2G用戶。如果由NAF所提供的B-TID所標識的密鑰在BSF是無效的，則BSF將在對NAF的回復(fù)中對此進行指示。那么，NAF向UE指示引導(dǎo)重協(xié)商請求。
注意6NAF可以根據(jù)本地策略，進一步設(shè)置Ks_NAF的本地有效條件。例如Ks_NAF重用次數(shù)限制。
注意7NAF將使用與UE同樣的方式使Ks_NAF適應(yīng)參考點Ua的指定要求。該適應(yīng)在本規(guī)范的范圍之外。
-BSF可以要求在用戶的GUSS內(nèi)存在用于NAF的一個或多個應(yīng)用專用USS以及潛在的NAF組專用USS(見I.4.6節(jié))。如果GUSS缺少一個或多個這些要求的設(shè)置，則BSF將在對NAF的回復(fù)中指示這一點。
-BSF還可能根據(jù)BSF的策略將私有用戶標識(IMPI)和所請求的USS發(fā)送給NAF。
-如果BSF或者NAF根據(jù)它們的本地策略確定NAF不服務(wù)于2G用戶，則NAF應(yīng)該終止參考點Ua上的協(xié)議。
4.NAF通過參考點Ua上使用的協(xié)議繼續(xù)與UE交互。
一旦在參考點Ua上使用協(xié)議的運行完成，則達到了引導(dǎo)的目的，因為它使UE和NAF能夠以安全的方式使用參考點Ua。

msg是應(yīng)用專用數(shù)據(jù)集 Prof是用戶簡檔的應(yīng)用專用部分 圖I.4引導(dǎo)使用過程
圖I.5引導(dǎo)重協(xié)商請求 I.5.4涉及服務(wù)發(fā)現(xiàn)的過程 UE將從SIM上的IMSI發(fā)現(xiàn)BSF的地址。將使用4.5.4節(jié)中指定的相同的發(fā)現(xiàn)過程。
I.6TLS簡檔 UE和NAF將支持RFC2246[6]和WAP-219-TLS[30]中指定的TLS版本或者更高的版本。
注意1根證書的管理處于此技術(shù)規(guī)范的范圍之外。
注意2證書的撤消處于此技術(shù)規(guī)范的范圍之外。然而，如果BSF證書可以折中，應(yīng)該注意對于BSF證書選擇短的生存期可以顯著減少風(fēng)險。
I.6.1保護機制 UE應(yīng)該使用CipherSuite TLS_RSA_WITH_3DES_EDE_CBC_SHA或CipherSuiteTLS_RSA_WITH_AES_128_CBC_SHA。
BSF應(yīng)該支持CipherSuiteTLS_RSA_WITH_3DES_EDE_CBC_SHA以及CipherSuite TLS_RSA_WITH_AES_128_CBC_SHA。
I.6.2BSF的認證 BSF由客戶端如WAP-219-TLS[30]中指定的被認證，其進而基于RFC2246[6]。
BSF證書簡檔應(yīng)該基于WAP證書和CRL簡檔，如WAP211WAPCert[31]定義的。
I.6.3UE的認證 BSF不應(yīng)該在服務(wù)器你好消息中從UE請求證書。BSF應(yīng)該認證UE，如本規(guī)范I.5.2節(jié)指定的。
I.6.4安全參數(shù)的建立 TLS握手協(xié)議協(xié)商會話，其通過會話ID標識?？蛻舳撕虰SF應(yīng)該允許重新利用會話。會話ID的生存期服從UE和BSF的本地策略。推薦的生存期是五分鐘。指定的最大生存期是24小時。
注意，如果BSF堅持推薦的生存期，那么在引導(dǎo)重協(xié)商的情況下，UE必然能夠重新利用TLS會話。
附錄J(資料性的) BSF中帶有本地策略加強的USS的使用 本附錄描述了BSF中本地策略加強如何被用在NAF和BSF之間以控制密鑰傳遞到NAF。
J.1綜述 BSF可以具有用于零個或多個NAF的本地策略，其中用于NAF的策略可以聲明用戶的GUSS應(yīng)該包括一個或多個由GSID標識的USS。換句話說，對于特定的NAF，BSF可以要求再多一個的USS存在于用戶GUSS中。
通常，具有兩個網(wǎng)元，其中基于某本地策略的訪問控制被加強，即NAF和BSF。因此必須覆蓋具有基于USS的訪問控制的兩個階段 1)NAF內(nèi)用于Ua請求的訪問控制在NAF中決定(并且可能在USS的幫助下)是否允許用戶訪問服務(wù)在NAF。在從UE接收B-TID時，NAF從BSF獲取NAF專用的共享密鑰(Ks_(ext/int)_NAF)，并且選擇性地獲取USS，其典型地包含NAF專用的永久用戶身份以及授權(quán)標記?；贜AF中的本地策略，其可以包括評估USS的內(nèi)容，NAF決定用戶是否被允許訪問服務(wù)。
2)BSF內(nèi)用于Zn請求的訪問控制在特定情況中，運營商可以希望實現(xiàn)BSF中的訪問控制。此功能可以與任何NAF使用，但是具有這個的主要原因是為了在NAF處于拜訪網(wǎng)絡(luò)中的情況中實現(xiàn)歸屬運營商控制。
本附錄更詳細地描述了BSF內(nèi)用于Zn請求的訪問控制情況。
在使用本附錄時應(yīng)該注意下列事實 -此訪問控制是完全本地于BSF運營商的網(wǎng)絡(luò)(即用戶的歸屬運營商)。這隱含了對于此訪問控制的實現(xiàn)不需要運營商間的協(xié)議。
-BSF的本地策略可以是基于NAF名和NAF組的。為了簡便，下列描述中僅提及NAF。
J.2使用場景 可以確定BSF中的本地策略將如何工作的四個不同場景 1)NAF不使用USS(即它不從BSF請求USS)，并且BSF不具有用于此NAF的本地策略。
2)NAF不使用USS(即它不從BSF請求USS)，并且BSF具有用于此NAF的本地策略。
3)NAF使用USS(即它從BSF請求一個或多個USS)，并且BSF不具有用于此NAF的本地策略。
4)NAF使用USS(即它從BSF請求一個或多個USS)，并且BSF具有用于此NAF的本地策略。
在這些場景中的每一個中執(zhí)行的步驟在下列子節(jié)中更詳細地描述。
在所有場景中，NAF已經(jīng)在下列步驟執(zhí)行之前通過Ua從UE參考點接收了B-TID。步驟僅描述了關(guān)于USS存在的相關(guān)于BSF中本地策略加強的過程。而且，不相關(guān)于此訪問控制的其他信息元素的傳遞未被提及(例如，密鑰生存期、私有用戶身份)。
J.2.1場景1NAF不使用USS，BSF不具有用于NAF的本地策略 在此場景中，NAF不使用USS并且BSF不具有用于此NAF的本地策略。
1.NAF從BSF請求NAF專用的共享密鑰。其在請求中不包括任何GSID。
2.BSF使用B-TID在它的本地存儲器中定位用戶信息。
3.BSF檢查是否存在用于NAF的本地策略-在此場景中不存在本地策略，即對于此特定NAF，BSF不要求任何USS(由GSID標識的)存在于用戶的GUSS中。
4.BSF衍生NAF專用的共享密鑰，并且在響應(yīng)中將它們發(fā)送到NAF。
5.NAF接收帶有NAF專用的共享密鑰的響應(yīng)。
在接收到NAF專用的共享密鑰之后，NAF可以根據(jù)它自己的策略執(zhí)行對服務(wù)的訪問控制并且繼續(xù)與UE通信。
J.2.2場景2NAF不使用USS，BSF具有用于NAF的本地策略 在此場景中，NAF不使用USS并且BSF具有用于此NAF的本地策略。
1.NAF從BSF請求NAF專用的共享密鑰。在請求中不包括任何GSID。
2.BSF使用B-TID在它的本地存儲器中定位用戶信息。
3.BSF檢查是否存在用于NAF的本地策略-在此場景中，存在用于此NAF的本地策略，即對于此特定NAF，BSF不要求任何USS(由GSID標識的)存在于用戶的GUSS中。
BSF檢查是否所有由GSID標識的要求的USS都存在于用戶的GUSS中如果是，BSF從步驟4繼續(xù)。如果不是，則BSF將錯誤消息發(fā)送到NAF。
4.BSF衍生NAF專用的共享密鑰，并且在響應(yīng)中將它們發(fā)送到NAF。
5.NAF接收帶有NAF專用的共享密鑰的響應(yīng)。
在接收到NAF專用的共享密鑰之后，NAF可以根據(jù)它自己的策略執(zhí)行對服務(wù)的訪問控制并且繼續(xù)與UE通信。
如果NAF接收到“未授權(quán)”的錯誤消息，他可以將此消息通過Ua參考點向UE指示。在任何情況中，UE和NAF間基于GAA的安全建立將失敗，因為NAF沒有得到NAF專用的共享密鑰。
J.2.3場景3NAF使用USS，BSF不具有用于NAF的本地策略 在此場景中，NAF使用USS并且BSF不具有用于此NAF的本地策略。
1.NAF從BSF請求NAF專用的共享密鑰。在請求中包括它需要的GSID。
2.BSF使用B-TID在它的本地存儲器中定位用戶信息。
3.BSF檢查是否存在用于NAF的本地策略-在此場景中不存在本地策略，即對于此特定NAF，BSF不要求由GSID標識的USS存在于用戶的GUSS中。
4.BSF衍生NAF專用的共享密鑰，并且在響應(yīng)中將它們和由GSID標識的USS發(fā)送到NAF。如果在用戶的GUSS中沒有發(fā)現(xiàn)特定的USS，或者NAF未被授權(quán)去接收特定的USS，則這些USS從響應(yīng)中忽略。
5.NAF接收帶有NAF專用的共享密鑰的響應(yīng)，并且那些請求的USS是有效的(即，在用戶的GUSS中發(fā)現(xiàn)的病情BSF允許由NAF接收的)。
在接收到NAF專用的共享密鑰和有效USS之后，NAF可以根據(jù)它自己的策略執(zhí)行對服務(wù)的訪問控制(例如USS要求或不要求需要的授權(quán)標記)并且繼續(xù)與UE通信。
J.2.4場景4NAF使用USS，BSF具有用于NAF的本地策略 在此場景中，NAF使用USS并且BSF具有用于此NAF的本地策略。
1.NAF從BSF請求NAF專用的共享密鑰。在請求中包括它需要的GSID。
2.BSF使用B-TID在它的本地存儲器中定位用戶信息。
3.BSF檢查是否存在用于NAF的本地策略-在此場景中存在用于此NAF的本地策略，即由GSID標識的一個或多個USS應(yīng)該存在于用戶的GUSS中。
BSF檢查是否所有由GSID標識的要求的USS都存在于用戶的GUSS中如果是，BSF從步驟4繼續(xù)。如果不是，則BSF將錯誤消息發(fā)送到NAF。
4.BSF衍生NAF專用的共享密鑰，并且在響應(yīng)中將它們和由GSID標識的USS發(fā)送到NAF。如果在用戶的GUSS中沒有發(fā)現(xiàn)特定的USS，或者NAF未被授權(quán)去接收特定的USS，則這些USS從響應(yīng)中忽略。
5.NAF接收帶有NAF專用的共享密鑰的響應(yīng)，并且那些請求的USS是有效的(即，在用戶的GUSS中發(fā)現(xiàn)的病情BSF允許由NAF接收的)。
在接收到NAF專用的共享密鑰和有效USS之后，NAF可以根據(jù)它自己的策略執(zhí)行對服務(wù)的訪問控制(例如USS要求或不要求需要的授權(quán)標記)并且繼續(xù)與UE通信。
如果NAF接收到“未授權(quán)”的錯誤消息，可以將此消息通過Ua參考點向UE指示。在任何情況中，UE和NAF間基于GAA的安全建立將失敗，因為NAF沒有得到NAF專用的共享密鑰。
附錄K(資料性的)更改歷史 附錄C 3GPP TS29.109V7.0.0(2005-09) 技術(shù)報告 第三代伙伴計劃； 技術(shù)規(guī)范組核心網(wǎng)和終端； 通用認證架構(gòu)(GAA)； 基于直徑協(xié)議的Zh和Zn接口；階段3 (版本7) 本文檔已經(jīng)在第三代伙伴計劃(3GPPTM)中開發(fā)并且可以針對3GPP的意圖進一步詳細闡述。
本文檔還沒有經(jīng)過3GPP組織伙伴的任何同意處理過程并且尚未實現(xiàn)。
提供此規(guī)范僅在3GPP內(nèi)部用于進一步的開發(fā)工作。組織伙伴不接受對于使用此規(guī)范的任何義務(wù)。
對于3GPPTM系統(tǒng)實現(xiàn)的規(guī)范和報告應(yīng)該通過3GPP組織伙伴的出版辦公室獲得。
關(guān)鍵字 UMTS，網(wǎng)絡(luò)，協(xié)議 3GPP 通信地址 3GPP支持辦公室地址 650Route des Lucioles-Sophia Antipolis Valbonne-FRANCE Tel.+33492944200Fax+33493654716 因特網(wǎng) http://www.3gpp.org 版權(quán)聲明 除了通過書面許可的授權(quán)沒有部分可以復(fù)制。版權(quán)和前述限制擴展到所有媒體中的復(fù)制。
_2005，3GPP Organizational Partners(AR1B，ATIS，CCSA，ETSI，TTA，TTC)。
All rights reserved 目錄 1范圍.......................................................4 2參考.......................................................7 3定義、符號和縮略語.........................................7 3.1定義...................................................7 3.2符號...................................................8 3.3縮略語..................................................9 4GBA引導(dǎo)Zh接口.............................................10 4.1通用引導(dǎo)網(wǎng)絡(luò)架構(gòu)........................................10 4.2BSF和HSS間的協(xié)議Zh......................................10 5GBA應(yīng)用Zh接口.............................................14 5.1應(yīng)用的網(wǎng)絡(luò)架構(gòu)..........................................14 5.2BSF和HSS間的協(xié)議Zn......................................14 6用于Zh和Zn接口的直徑協(xié)議..............................17 6.1命令碼值................................................17 6.2結(jié)果碼值................................................17 6.2.1成功.................................................17 6.2.2永久性失敗...........................................18 6.2.2.1DIAMETER_ERROR_IMPI_UNKNOWN(5401)..........18 6.2.2.2DIAMETER_ERROR_NOT_AUTHORIZED(5402).......18 6.2.2.3DIAMETER_ERROR_TRANSACTION_IDENTIFIER_INVALID(5403)...18 6.2.2.4空...................................................18 6.2.2.5空...................................................18 6.2.2.6空..................................................18 6.2.2.7空..................................................18 6.3AVP........................................................19 6.3.1公共AVP...................................................19 6.3.1.1GBA-UserSecSettings AVP...........................19 6.3.1.2事務(wù)-標識符AVP......................................19 6.3.1.3NAF-主機名......................................19 6.3.1.4GAA-服務(wù)-標識符AVP................................20 6.3.1.5密鑰-到期時間AVP.................................20 6.3.1.6ME-密鑰-資料AVP...................................20 6.3.1.7UICC-密鑰-資料AVP..................................20 6.3.1.8GBA_U-察覺-指示符..................................20 6.3.1.9BootstrapInfoCreationTime AVP...................20 6.3.1.10GUSS-時間戳AVP....................................20 6.4到HSS的用戶身份解析......................................20 7名字空間的使用..........................................22 7.1AVP代碼................................................22 7.2實驗性-結(jié)果-碼AVP值....................................22 7.3命令碼值..................................................22 附錄A(標準化的)GBA-UserSecSettings XML定義...............23 附錄B(標準化的)GAA服務(wù)類型碼.............................26 附錄C(標準化的)GAA授權(quán)標記碼.............................26 附錄D(資料性的)更改歷史..................................27 前言 此技術(shù)報告已經(jīng)由第三代伙伴計劃(3GPP)制作。
本文檔的內(nèi)容服從TSG中的連續(xù)工作并且可以隨著正式的TSG同意改變。一旦TSG修改本文檔的內(nèi)容，TSG將通過帶有發(fā)布日期和如下增加的版本號的可識別變化來對其進行重新發(fā)布 版本x.y.z x第一個數(shù)字 1呈現(xiàn)給TSG用于信息 2呈現(xiàn)給TSG用于同意 3或者更大指示修改控制下的TSG同意文檔 y第二個數(shù)字增大用于所有實質(zhì)的修改，即技術(shù)增強、修正、更新等。
z當(dāng)僅編輯性修改已經(jīng)合并于該文檔中時第三個數(shù)字增大。
1范圍 本第3階段規(guī)范定義了用于引導(dǎo)BSF的HSS解析的Zh接口(BSF-HSS)和Dz接口(BSF-SLF)的基于直徑的實現(xiàn)，以及通用認證架構(gòu)(GAA)中的GAA應(yīng)用Zn接口(BSF-NAF)。該定義包含過程、消息內(nèi)容和編碼。用于引導(dǎo)的過程和引導(dǎo)的安全關(guān)聯(lián)的使用定義于TS33.221[5]中。
此規(guī)范是通用認證架構(gòu)(GAA)規(guī)范系列的一部分。
基于直徑的最初實現(xiàn)是基于CSCF和HSS間Cx接口多媒體-Auth-請求/應(yīng)答消息的重用。這些消息定義于3GPP TS29.229[3]。3GPP IMS移動性管理使用CSCF和HSS間的相同定義。本文檔定義定義的消息如何與引導(dǎo)和GAA應(yīng)用過程(例如，用戶證書)以及GAA網(wǎng)元中(BSF、HSS和NAF)需要的應(yīng)用邏輯一起使用。
圖1.1描述了這些規(guī)范與其他規(guī)范的關(guān)系。

圖1.1與其他規(guī)范的關(guān)系 圖1.2提供了GAA系統(tǒng)中整個信令過程的非正式全面快速介紹。重要標識符以粗體標記，并且可選日期條目是斜體的。沒有定義于此TS中的Ub和Ua接口被簡化。

粗體＝重要身份。斜體＝可選條目。Ub和Ua接口被簡化。
圖1.2GAA系統(tǒng)中整個信令過程 2參考 下列文檔包含通過此文本中的參考的規(guī)定，組成本文檔的規(guī)定。
參考是特定的(由出版日期、印刷號、版本號等識別)或非特定的。
對于特定參考，后續(xù)修改不適用。
對于非特定參考，應(yīng)用最新版本。在參考3GPP文檔(包括GSM文檔)的情況中，非特定參考隱含地指與當(dāng)前文檔具有相同版本的文檔的最新版本。
[1]IETF RFC3588，″Dlameler Base Protocol″. [2]3GPP TS29.228″IP Multimedie (1M)Subsystem Cx and Dx Interfaces；Signalling flows andmessage contents″. [3]3GPP TS29.229″Cx and Dx Interfaces based on the Diameter protocol″. [4]3GPP TR33.919″Generic Authentication Architecture(GAa)；System Description(rel-6)″. [5]3GPP TS33.220″Generic Authentlcation Architecture(GAA)；Generic Bootstrapping Architecturc(rel-6)″. [6]3GPP TS33.21″Generlc Authcntication Architecture(GAA)；Support for Subscrlber Certificates(rel-6)″. [7]3GPP TS24.109″Bootstrapping interface(Ub)and Network application function interface(Ua)；Protocol details″. [8]3GPP TS29.230″Diamcter applications；3GPP speclfic codes and identifiers(rel-6)″ [9]IETF RFC3589″Diameter Command Codes for Third Generation Partnership Project(3GPP)Rclease5″. [10]3GPP TS23.008″Organisation of subscrlber data″ [11]3GPP TS33.222″Generic Authentication Architecture(GAA)；Access to netword applicationfunctions using secure hypertext transfor protocol(HTTPS)(rel-6)″. [12]3GPP TS23.228″IP Multimedla Subsystem(IMS)；Stage2″ 3定義、符號和縮略語 3.1定義 出于本文檔的目的，3GPP TS23.008[10]、3GPP TR33.919[4]、3GPPTS33.220[5]中給出的術(shù)語和定義與下列增加一起應(yīng)用。
引導(dǎo)信息BSF中的引導(dǎo)信息(引導(dǎo)的數(shù)據(jù))包括引導(dǎo)事務(wù)標識符(B-TID)、密鑰資料(Ks)、密鑰生存期(到期時間)、boostrapinfo創(chuàng)建時間、IMPI和帶有BSF控制信息的GUSS(如果從HSS接收了)。
GAA應(yīng)用GAA應(yīng)用是使用由GBA引導(dǎo)過程創(chuàng)建的安全關(guān)聯(lián)的應(yīng)用。
GAA服務(wù)GAA服務(wù)是使用由GBA引導(dǎo)過程創(chuàng)建的安全關(guān)聯(lián)的運營商特定終端用戶服務(wù)。GAA服務(wù)通過GAA服務(wù)標識符進行標識。GAA服務(wù)使用一些由GAA應(yīng)用類型定義的標準化的或者專有GAA應(yīng)用。
NAF專用引導(dǎo)信息從BSF傳輸?shù)絅AF的NAF專用引導(dǎo)信息包含NAF和它的來自于引導(dǎo)的數(shù)據(jù)的服務(wù)特定部分以及衍生自引導(dǎo)數(shù)據(jù)的所需密鑰信息。
服務(wù)/應(yīng)用術(shù)語服務(wù)在此使用它的普通含義。服務(wù)是MNO提供給用戶的事物。GAA服務(wù)通過GAA服務(wù)標識符(GSID)標識。在階段2文檔([4]、[5]、[6]和[11])中，術(shù)語應(yīng)用以相同的含義使用，即MNO向用戶提供應(yīng)用。存在一個原因避免這里的術(shù)語應(yīng)用的使用。在直徑中，應(yīng)用已經(jīng)是保留術(shù)語。在直徑中，應(yīng)用通過應(yīng)用標識符標識。
3.2符號 出于本文檔的目的，在3GPP TS23.008[10]中給出術(shù)語和定義。
3.3縮略語 出于本文檔的目的，應(yīng)用下列縮略語 AK匿名密鑰 AKA認證和密鑰協(xié)議 AUTN認證記號 AV認證向量。3GPP AV＝[RAND，AUTN，XRES，CK，IK]. AVP直徑消息中的屬性-值-對 BIA BootstrappingInfo-應(yīng)答消息 BIR BootstrappingInfo-請求消息 BS引導(dǎo)過程 BSF引導(dǎo)服務(wù)器功能 BSF是在MNO的控制下受網(wǎng)元主控。
B-TID引導(dǎo)事務(wù)標識符 CA證書機構(gòu) CK機密性密鑰 FQDN URI中的全資格域名(例如http://FQDN80) GAA通用認證架構(gòu) GBA通用引導(dǎo)架構(gòu) GSID GAA服務(wù)標識符 GUSS GBA用戶安全設(shè)置 HSS歸屬用戶系統(tǒng) IK完整性密鑰 IMPIIP多媒體私有身份 IMPU IP多媒體公有身份 Ks密鑰資料 Ks_ext_NAF用于特定NAF的基于ME的密鑰 MNO移動網(wǎng)絡(luò)運營商 NAF運營商-控制的網(wǎng)絡(luò)應(yīng)用功能功能性 NAF是在MNO的控制下網(wǎng)元中的主機。
RAND認證中的隨機質(zhì)詢 REQ在直徑頭中指示消息是請求 SCTP流控制傳輸協(xié)議 SLF訂閱位置功能 SSC用戶證書功能 Ua用于GAA應(yīng)用的UE-NAF接口 Ub用于引導(dǎo)的UE-BSF接口 UE用戶設(shè)備 Ks_int_NAF用于特定NAF的基于UICC的密鑰 USS用戶安全設(shè)置(GUSS的一部分) XRES認證中的期望響應(yīng) Zh用于引導(dǎo)過程的BSF-HSS接口 Zn用于應(yīng)用的GAA BSF-NAF接口 4GBA引導(dǎo)Zh接口 4.1通用引導(dǎo)網(wǎng)絡(luò)架構(gòu) 引導(dǎo)過程的網(wǎng)絡(luò)架構(gòu)呈現(xiàn)于圖4.1中。接口Ub(引導(dǎo))定義于3GPPTS24.109[7]中并且接口Zh在此規(guī)范中。

圖4.1引導(dǎo)過程的網(wǎng)絡(luò)架構(gòu) 引導(dǎo)過程中Zh接口的協(xié)議棧呈現(xiàn)于圖4.2中。直徑基礎(chǔ)協(xié)議定義于[1]中并且直徑應(yīng)用在3GPP TS29.229[3]中。對于Zh接口的要求定義于3GPP TS33.220[5]中
圖4.2Zh接口的協(xié)議棧 4.2BSF和HSS間的協(xié)議Zh 對于Zh接口的要求定義于3GPP TS33.220[5]中。
引導(dǎo)Zh接口從HSS執(zhí)行認證向量和可能GBA用戶安全設(shè)置的獲取。全面引導(dǎo)過程在圖4.3中描述?；具^程是 A)通過協(xié)議Ub，UE開始與給出用戶的IMPI的BSF的引導(dǎo)過程(見3GPP TS24.109[7])。
B)BSF開始與用戶的HSS開始協(xié)議Zh ·BSF請求用戶的認證向量和對應(yīng)于IMPI的GBA用戶安全設(shè)置(GUSS)。
·HSS向BSF提供請求的認證向量和GUSS(如果有) 注意如果網(wǎng)絡(luò)內(nèi)部署有多于一個的HSS，則在向HSS發(fā)送信息的請求之前BSF必須使用Dz接口聯(lián)系SLF(見6.4節(jié))。
C)BSF繼續(xù)與UE的協(xié)議Ub(見3GPP TS24.109[7])。

圖4.3GBA引導(dǎo)過程 圖4.3中的引導(dǎo)過程的步驟是 步驟1 BSF應(yīng)該以多媒體-Auth-請求(MAR)消息的格式將下列引導(dǎo)-請求發(fā)送到HSS。下面以與3GPP TS29.229[3]中相同的格式給出了消息內(nèi)容。大括號指示了強制的AVP。方括號指示可選的AVP?！暗牡刂贰敝溉Y格主機名(FQDN)。
<Multimedia-Auth-Request>＝<Diameter Header303，REO，PXX，16777221> <Session-Id> {Vendor-Speclfic-Application-Id} [Auth-Session-State]；NO_STATE_MAINTAINED [Origin-Host] ；Address of BSF {Origin-Realm} ；Realm of BSF {Cestination-Realn} ；Realm of HSS [Destination-Hoat] ；Address of the HSS [User-Name] ；IMPI from UE [GUSS-Tinestamp]；Timestamp of GUSS in BSF *[AVP] *[Proxy-Infc] *[Route-Record] 根據(jù)[1]的強制的供應(yīng)商-特定-應(yīng)用-ID內(nèi)容是 <Vendor-Specific-Application-Id>＝<AVP header260> 1*[vendor-Id] ；3GPP is 10415 0*1[Auth-Application-Id]；16777221 0*1{Acct-Application-Id}；Omitted 當(dāng)確定目的地-主機AVP的值時，如果需要，BSF可以使用轉(zhuǎn)向器(redirector)功能(SLF)以解析HSS的地址(見3GPP TS29.229[3])。根據(jù)3GPP TS29.229[3]BSF應(yīng)該將Auth會話狀態(tài)設(shè)置為NO_STATE_MAINTAINED以通知HSS不需要為此會話保持任何狀態(tài)信息。用戶-名是如3GPP TS29.228[2]中要求的IMS私有用戶身份(IMPI)。如果BSF支持GUSS時間戳機制并且具有GUSS的本地副本(其具有時間戳)，則BSF可以包括GUSS-時間戳AVP。在此情況中，GUSS-時間戳AVP應(yīng)該包含來自于用戶的GUSS的時間戳。否則GUSS-時間戳AVP將不存在。
步驟2 當(dāng)HSS接收到MAR消息時，HSS將根據(jù)IMPI衍生用戶認證向量(AV)信息并且將它裝入在3GPP TS29.229[3]中定義的SIP-Auth-數(shù)據(jù)AVP中。如果存在用于IMPI的GUSS，則HSS應(yīng)該完成下列之一 1.如果BSF支持GUSS時間戳機制并且在MAR消息中接收了GUSS-時間戳AVP，那么它將把HSS中的GUSS時間戳與接收的時間戳進行比較。
-如果時間戳相等，那么它應(yīng)該將靜態(tài)字符串“GUSS時間戳相等”裝入GBA-UserSecSettings AVP。
-如果沒有接收到GUSS-時間戳AVP，或者時間戳不相等，那么它應(yīng)該使用GUSS裝入GBA-UserSecSettings AVP。
2.如果HSS不支持GUSS時間戳機制，它將使用GUSS裝入GBA-UserSecSettings AVP。
Zh接口中的MAR/MAA序列絕對不能改變HSS中可能同時進行的IMS MM應(yīng)用會話的可能狀態(tài)信息。
如果來自于BSF的用戶-名(IMPI)對于HSS全部未知，則出現(xiàn)錯誤情況5401。
步驟3 HSS將以多媒體-Auth-應(yīng)答(MAA)消息的格式將下列引導(dǎo)-應(yīng)答消息發(fā)回到BSF。
<Multimedia-Auth-Answer>＝<Diameter Header；303，PXY，16777221> <Session-Id> {Vendor-Speclfic-Appllcation-Id} [Result-Code] [Experimentsl-Result] [Auth-Session-State] ；NO_STATE_MAINTAINED [Origin-Host]；Address of HSS [Origln-Realm] ；Realm of HSS [Dser-Name] ；IMPI *[SIP-Auth-Data-Item] [GSA-UserSecSettings]；GDSS *[AVP] *[Proxy-Info] *[Route-Reoord] HSS應(yīng)該設(shè)置強制Auth-會話-狀態(tài)AVP為NO_STATE_MAINTAINED，因為HSS不保留關(guān)于此會話的任何狀態(tài)信息并且BSF不需要發(fā)送任何會話終止請求3GPP TS29.229[3]。用戶-名AVP(IMPI)可以被發(fā)送回去用于檢查。要求的認證向量在SIP-Auth-數(shù)據(jù)-條目AVP中發(fā)送。用戶的所有GAA應(yīng)用的安全設(shè)置在GBA-UserSecSettings AVP中發(fā)送。
步驟4 當(dāng)BSF接收到MAA消息時，BSF從機密性密鑰(CK)和完整性密鑰(IK)如3GPP TS33.220[5]中描述的生成需要的密鑰資料(Ks)并且為臨時存儲元組<IMPI，Ks，GBA-UserSecSettings>以供GAA應(yīng)用中進一步的使用。Ub接口中的引導(dǎo)過程的剩余部分也將稍后將引導(dǎo)事務(wù)標識符(B-TID)添加到元組作為密鑰和密鑰生存期(到期時間)。如果BSF在步驟1中發(fā)送GUSS-時間戳AVP，并且如果GBA-UserSecSettings AVP包含靜態(tài)字符串“GUSS時間戳相等”，那么BSF中的GUSS本地副本應(yīng)該保存。如果GBA-UserSecSettings AVP不存在于MAA消息中，則GUSS的本地副本應(yīng)該刪除。如果GBA-UserSecSettings AVP包含新的GUSS，則GUSS的本地副本應(yīng)該刪除，并且在BSF中應(yīng)該存儲新的GUSS。
5GBA應(yīng)用Zh接口 5.1應(yīng)用的網(wǎng)絡(luò)架構(gòu) GAA應(yīng)用過程的網(wǎng)絡(luò)架構(gòu)呈現(xiàn)于圖5.1中。3GPP GAA應(yīng)用列出于附錄B中。不同的GAA應(yīng)用可以以不同的方式實現(xiàn)Ua接口。Zn接口在此規(guī)范中定義。

圖5.1GAA應(yīng)用的網(wǎng)絡(luò)架構(gòu) 用于GAA應(yīng)用的Zn接口的協(xié)議棧呈現(xiàn)于圖5.2中。直徑基礎(chǔ)協(xié)議定義于[1]中并且直徑應(yīng)用定義在3GPP TS29.229[3]中。對于Zn接口的要求定義于3GPP TS33.220[5]中。

圖5.2Zn接口的協(xié)議棧 5.2BSF和HSS間的協(xié)議Zn 對于Zn接口的要求定義于3GPP TS33.220[5]中。
協(xié)議Zn通過NAF從BSF檢索密鑰資料和可能的用戶安全設(shè)置數(shù)據(jù)。在UE使用BSF被認證后，每次UE希望與UE交互，則如圖5.3中描述的執(zhí)行下列步驟?；具^程是 A)UE開始協(xié)議Ua(見3GPP TS33.220[5]) 通常UE和NAF仍將不共享保護協(xié)議Ua所要求的密鑰。如果它們已經(jīng)共享了，則不需要NAF調(diào)用協(xié)議Zn。
假設(shè)UE向NAF提供足夠的信息，即引導(dǎo)事務(wù)標識符(B-TID)，以允許NAF從BSF檢索特定的密鑰資料(例如，GBA_ME情況中的Ks_NAF，以及Ks_ext_NAF或者Ks_int_NAF或者GBA_U的情況中的兩者)。
UE從密鑰資料衍生保護協(xié)議Ua所要求的密鑰。
B)NAF與BSF開始協(xié)議Zn NAF請求NAF專用密鑰資料，該密鑰資料對應(yīng)于在協(xié)議Ua的開始時UE向NAF提供的信息(即引導(dǎo)事務(wù)標識符)。
BSF生成并向NAF提供請求的NAF專用密鑰資料、到期時間、bootstrapinfo創(chuàng)建時間和定義用于接收的應(yīng)用標識符的適當(dāng)?shù)挠脩舭踩O(shè)置。
C)NAF與UE繼續(xù)協(xié)議Ua(見3GPP TS33.221[6]) 一旦協(xié)議Ua的運行完成，就達到了引導(dǎo)的目的，因為它使UE和NAF能夠以安全的方式運行協(xié)議Ua。
普通GAA應(yīng)用過程呈現(xiàn)于圖5.3中。

圖5.3GAA應(yīng)用過程 圖5.3中GAA應(yīng)用過程的步驟是 步驟1 NAF應(yīng)該將引導(dǎo)-Info-請求消息(BIR)發(fā)送到BSF。在這里，消息的內(nèi)容以與3GPP TS29.229[3]中相同的格式給出。大括號指示強制AVP。方括號指示可選AVP。地址指全資格主機名(FQDN)。
<Bootstrapping-Info-Request>＝<Diameter Header310，REO，PXX，16777220> <Session-Id> {Vondor-Speclfic-Application-Id} {Origin-Host} ；Address of NAF {Origin-Realm} ；Ream of NAF {Dastination-Realm} ；Realm of BSF {Destination-Host} ；Address of the BSF *{GAA-Service-Identifier} ；Sevice identifiers {Tranaaction-Identifiar}；B-TID {NAF-Hostname} ；FODN of NAF as seen by UE {GBA_U-Awareness-Indicator} ；GBA_U awareness of the NAF *{AVP} *[Proxy-Info] *[Route-Record] 根據(jù)[1]的提供商-特定-應(yīng)用-ID內(nèi)容是 <Vendor-Specific-Application-Id>-<AVP header260> 1*[Vendor-Id] ；3GPP is 10415 0*1[Auth-Application-Id)；167722O 0*1[Acct-Application-Id]；Cmitted 設(shè)置目的地-域AVP為用戶的BSF。BSF的地址從B-TID提取。
注意在其中用戶已經(jīng)聯(lián)系了位于拜訪網(wǎng)絡(luò)中的NAF的情況中，NAF通過位于與NAF相同的網(wǎng)絡(luò)中的直徑-代理(D-Proxy)聯(lián)系用戶的歸屬BSF。本地BSF和D-Proxy可以共同定位。見3GPP TS33.220[6]。
NAF指示了由GAA-服務(wù)-標識符AVP針對其獲取信息的GAA服務(wù)。引導(dǎo)事務(wù)標識符定義更早的引導(dǎo)過程執(zhí)行。
步驟2 在成功的情況中，BSF具有由引導(dǎo)事務(wù)標識符(B-TID)標識的元組<B-TID，IMPI，Ks，密鑰生存期，Bootstrapinfo創(chuàng)建時間，GBA-UserSecSettings>。當(dāng)BSF接收到請求時，它檢查用于給定B-TID元組的存在和有效性。如果檢查失敗，則BSF發(fā)送帶有實驗性-結(jié)果集合的應(yīng)答消息以指示錯誤類型5403。如果用于B-TID的元組存在，但是到期了，則還發(fā)送錯誤類型5403以指示對于引導(dǎo)過程恢復(fù)的需要。在成功的情況中，結(jié)果-碼被設(shè)置為定義于[1]中的2xxx。
BSF根據(jù)B-TID衍生用于ME的密鑰資料(即GBA ME情況中的Ks_NAF，GBA_U情況中的Ks_ext_NAF)和用于UICC的可能密鑰資料(即GBA_U情況中的Ks_int_NAF)，并且將它們打包到ME-密鑰-資料AVP和可能的UICC-密鑰-資料AVP中。ME-密鑰-資料包含Ks_(ext)NAF并且UICC-密鑰-資料AVP包含Ks_int_NAF密鑰。根據(jù)對GBA-UserSecSettings AVP請求的GAA-服務(wù)-標識符AVP，BSF選擇正確的用戶安全設(shè)置。如果NAF分組由運營商使用并且存在-個或多個相應(yīng)于請求的GSID的USS，那么還檢查USS的nafGroup屬性。如果NAF已經(jīng)發(fā)送了不具有相應(yīng)用戶安全設(shè)置的GAA-服務(wù)-標識符，并且本地配置BSF以拒絕那些來自于NAF的請求，那么出現(xiàn)錯誤5402。如果NAF已經(jīng)發(fā)送了具有相應(yīng)用戶安全設(shè)置的GAA-服務(wù)-標識符，但是本地配置BSF以拒絕那些來自于NAF的請求，那么也出現(xiàn)錯誤5402。
可以通過不同的FQDN從UE對NAF進行尋址。BSF應(yīng)該檢查此NAF-主機名是否被允許用于NAF。如果在BSF中配置的由它的起源-主機AVP標識的NAF沒有被授權(quán)使用給定的NAF-主機名，則BSF可以出現(xiàn)錯誤5402。也可以配置BSF以便特定NAF不被授權(quán)使用特定的GAA-服務(wù)-標識符。這個情況也可以由錯誤碼5402指示。
步驟3 在那之后BSF將引導(dǎo)-Info-應(yīng)答消息(BIA)發(fā)回到NAF。
<Boostrapping-Info-Answer>＝<Diameter Header；310，PXY，16777220> <Seasion-Id> {Vendor-Speclfic-Application-Id} [Reault-Code] [Experimental-Result] [Origin-Host] ；Addreas of BSF [Origln-Realm] ；Realm of BSF [User-Name]；IMPI [HE-Key-Material] ；Required [UICC-Key-Material]；Conditional [Key-ExpiryTime] ；Time of expiry [BootstrapInfoCreationTime]；Bootstrapinfo creation time [GBA-UserSecSettings] ；Selectad USSs *[AVP] *[Proxy-Info] *[Route-Record] 根據(jù)它的配置，BSF可以或者可以不發(fā)送用戶-名AVP(IMPI)。
帶有ME(Ks_NAF或者Ks_ext_NAF)的強制普通密鑰資料在ME-密鑰-資料AVP中發(fā)送。僅當(dāng)來自于HSS的bsfInfo中的“uicc類型”標簽被設(shè)置為“GBA_U”時，帶有UICC(Ks_int_NAF)的普通密鑰資料才在UICC-密鑰-資料AVP中發(fā)送。
根據(jù)它的配置，密鑰-到期時間AVP包含BSF中的引導(dǎo)信息的到期時間。根據(jù)以自從1900年1月1日0起UTC已經(jīng)經(jīng)過的秒的直徑時間數(shù)據(jù)格式表示到期時間。如果特殊的密鑰生存期值在引導(dǎo)過程中的來自于HSS的bsfInfo內(nèi)的“生存時間”標簽中給出，當(dāng)計算到期時間時，則它被使用以代替BSF默認配置值。
BootstrapInfoCreationTime AVP包含bootstrapinfo創(chuàng)建時間，即，BSF中的引導(dǎo)信息創(chuàng)建時間。Bootstrapinfo創(chuàng)建時間以自從1900年1月1日00:00:00.000UTC已經(jīng)經(jīng)過的秒表示。
BSF根據(jù)請求消息中的GBA-服務(wù)-標識符從引導(dǎo)信息中存儲的GAA-UserSecSettings選擇針對GBA-UserSecSettings AVP的適當(dāng)?shù)挠脩舭踩O(shè)置(如果有的話)。
當(dāng)接收到BIA時，NAF中的過程描述于3GPP TS33.220[5]、3GPPTS33.222[11]并且可選擇在GAA服務(wù)類型特定TS中。
6用于Zh和Zn接口的直徑協(xié)議 6.1命令碼值 Zn接口分配新的命令-碼310。
Zn接口中的消息使用與3GPP TS29.229[3]中定義的用于Cx接口的多媒體-Auth-請求/應(yīng)答消息相同的命令-碼值303。
6.2結(jié)果碼AVP值 本節(jié)定義了由所有符合本規(guī)范的直徑實現(xiàn)肯定支持的新的結(jié)果碼值。當(dāng)在此定義的結(jié)果碼值的一個包括于相應(yīng)中時，它應(yīng)該在實驗性-結(jié)構(gòu)AVP內(nèi)部并且結(jié)果-碼AVP應(yīng)該不存在。
6.2.1成功 落在成功類別內(nèi)的錯誤被用于通知同等實體已經(jīng)成功完成請求。
在3GPP TS29.229[3]中定義的用于Cx接口的成功類別結(jié)果碼是無用的并且因此在Zh和Zn接口中不需要。
6.2.2永久性失敗 落在永久性失敗類別內(nèi)的錯誤被用于通知同等實體請求失敗，并且不應(yīng)該再次嘗試。
在3GPP TS29.229[3]中定義的用于Cx接口的永久性失敗類別結(jié)果碼是無用的并且因此在Zh和Zn接口中不需要。
6.2.2.1DIAMETER_ERROR_IMPI_UNKNOWN(5401) 對于未知的IMPI，由HSS接收到的消息。
6.2.2.2DIAMETER_ERROR_NOT_AUTHORIZED(5402) 由BSF接收的BSF不能授權(quán)的消息。在此情況中，NAF應(yīng)該向UE指示服務(wù)不被允許。
6.2.2.3 DIAMETER_ERROR_TRANSACTION_IDENTIFIER_INVALID(5403) 對于無效(例如未知或到期)的引導(dǎo)事務(wù)標識符(B-TID)由BSF接收的消息。在此情況中，NAF應(yīng)該向UE請求再次引導(dǎo)。
6.2.2.4空 6.2.2.5空 6.2.2.6空 6.2.2.7空 6.3AVP 在3GPP TS29.229[3]中定義的用于3GPP IMS Cx接口多媒體-Auth-請求/應(yīng)答消息的AVP如其所是地使用。
下列表格描述了用于Zh和Zn接口協(xié)議、它們的AVP碼值、類型、可能標記值和AVP是否可以被加密定義的額外的新的直徑AVP。所有定義與本規(guī)范中的AVP的提供商-Id頭應(yīng)該被設(shè)置為3GPP(10415)。
表6.1新的直徑多媒體應(yīng)用AVP 6.3.1公共AVP 6.3.1.1GBA-UserSecSettings AVP GBA-UserSecSettings AVP(AVP碼400)是OctetString類型。如果在Zh接口上傳輸，它包含GBA用戶安全設(shè)置(GUSS)。如果在Zn接口上傳輸，它僅包含相關(guān)USS。GBA-UserSecSettings AVP的內(nèi)容是定義于附錄A中的XML文檔。
6.3.1.2事務(wù)-標識符AVP 事務(wù)-標識符AVP(AVP碼402)是OctetString類型。此AVP包含引導(dǎo)事務(wù)標識符(B-TID)。
6.3.1.3NAF-主機名 NAF-主機名AVP(AVP碼402)是OctetString類型。此AVP包含UE使用的NAF的全資格域名(FQDN)?？梢允桥cBSF知道NAF的不同的域名。
6.3.1.4GAA-服務(wù)-標識符AVP GAA-服務(wù)-標識符AVP(AVP碼403)是OctetString類型。此AVP通知BSF關(guān)于通過NAF的GAA-服務(wù)支持。根據(jù)此AVP，BSF可以選擇正確的用戶安全設(shè)置。
對于3GPP標準化服務(wù)(例如，PKI端口)，GAA-服務(wù)-標識符(GSID)應(yīng)該在0到999999范圍內(nèi)，并且對于GSID的當(dāng)前標準化值應(yīng)該是特定服務(wù)的GAA-應(yīng)用-類型-碼。用于3GPP標準化服務(wù)的GAA服務(wù)類型碼定義于附錄B中。
注意未來，與GAA服務(wù)類型碼不同的標準化GSID值可以標準化(例如，為了在服務(wù)“MBMS流”和“MBMS下載”間區(qū)分)。
例子對于所有PKI-端口GSID是“1”，并且對于所有MBMS服務(wù)GSID是“4”。
6.3.1.5密鑰-到期時間AVP 密鑰-到期時間AVP(AVP碼404)是時間類型。此AVP通知NAF關(guān)于密鑰的到期時間。
6.3.1.6ME-密鑰-資料AVP 所要求的ME-密鑰-資料AVP(AVP碼405)是OctetString類型。NAF正在與移動設(shè)備(ME)共享此密鑰資料(GBA_ME情況中的Ks_NAF或GBA_U情況中的Ks_ext_NAF)。
6.3.1.7UICC-密鑰-資料AVP 條件UICC-密鑰-資料AVP(AVP碼406)是OctetString類型。NAF可以與UICC中的安全元素(例如USIM、ISIM等)共享此密鑰資料(GBA_U情況中的Ks_int_NAF)。僅一些GAA應(yīng)用使用此有條件的AVP。
6.3.1.8GBA_U-察覺-指示符 有條件的GBA_U-察覺-指示符AVP(AVP碼407)是枚舉類型的。定義了下列值。
NO(0)發(fā)送節(jié)點不是GBA_U察覺的 YES(0)發(fā)送節(jié)點是GBA_U察覺的 默認值是0即此AVP的缺少指示發(fā)送節(jié)點不是GBA_U察覺的。
6.3.1.9BootstrapInfoCreationTime AVP BootstrapInfoCreationTime AVP(AVP碼408)是時間類型的。此AVP通知NAF關(guān)于密鑰的bootstrapinfo創(chuàng)建時間。
6.3.1.10GUSS-時間戳AVP GUSS-時間戳AVP(AVP碼409)是時間類型的。如果傳輸了，則此AVP通知HSS關(guān)于BSF中存儲的GUSS的時間戳。
6.4用戶身份到HSS的解析 當(dāng)網(wǎng)絡(luò)運營商已經(jīng)部署了多個并且可以分別尋址的HSS時，用戶身份到HSS解析機制使BSF能夠發(fā)現(xiàn)用于給定用戶的用戶數(shù)據(jù)的HSS的地址。在利用單個HSS的網(wǎng)絡(luò)中或者當(dāng)BSF被配置使用預(yù)定義的HSS時，不需要解析機制。
解析機制是基于訂閱定位符功能(SLF)的，并且等效于描述的用于3GPP TS23.228[12]中描述的Cx/Dx接口。BSF通過Dz接口訪問訂閱定位符。Dz接口總是結(jié)合Zh接口一起使用。Dz接口是基于直徑。它的功能性通過由增強直徑重定向代理提供的路由機制方式實現(xiàn)的，其能夠從接收的請求中提取用戶身份。
為了得到HSS地址，BSF向SLF發(fā)送指向HSS的Zh請求。在從SLF接收HSS地址時，BSF應(yīng)該將Zh請求發(fā)送到HSS。BSF可以存儲HSS地址并且在與相同用戶相關(guān)的進一步請求中使用它。
在網(wǎng)絡(luò)中，其中需要使用用戶身份到HSS解析機制并且不配置BSF使用預(yù)定義的HSS，每個BSF通過實現(xiàn)此解析機制的SLF的地址/名稱來配置。
7名字空間(namespace)的使用 本章包含已經(jīng)在此3GPP規(guī)范中或者在3GPP規(guī)范3GPP TS29.229[3]中創(chuàng)建的，或者分配給由IANA管理的現(xiàn)存名字空間的值的名字空間。
7.1AVP代碼 本規(guī)范保留3GPP提供商特定值10415400-499并且時間從用于3GPP直徑應(yīng)用([8])的3GPP AVP碼名字空間中為GAA分配值10415400-408。3GPP提供商專用AVP碼空間由3GPP CN4管理。見本規(guī)范中針對名字空間的分配的第6章。
除了直徑基礎(chǔ)協(xié)議AVP[1]，此規(guī)范重用下列來自于3GPP TS29.229[3]的AVP認證-會話-狀態(tài)、用戶-名、SIP-Auth-數(shù)據(jù)-條目和SIP-號-Auth-條目。
7.2實驗性-結(jié)果-碼AVP值 本規(guī)范保留驗性-結(jié)果-碼AVP值104152401-2409和104155401-5409。見6.2節(jié)。
7.3命令碼值 本規(guī)范中僅使用來自于3GPP TS29.229[3]的命令-碼310和303。
本規(guī)范僅重用命令-碼值，而不是原規(guī)范的內(nèi)容。在TS29.229[3]中定義為要求但是在Zh或Zn接口中不需要的AVP被移除，并且因此在Zh或Zn接口消息中不要求。所有用于GAA的新的AVP被定義為可選，盡管它們在GAA觀點中可以是強制的。
本規(guī)范不分配新命令碼給3GPP TS29.229[3]。
附錄A(標準化的) GBA-UserSecSettings XML定義 本附錄包含用于承載Zh和Zn接口中的GBA-UserSecSettings AVP內(nèi)的GBA用戶安全設(shè)置的XML文檔的XML模式定義。
注意復(fù)合類型中的<xs任何>元素允許未來版本中的兼容擴展。該值是 ·元素“guss”中的屬性“id”的值與用戶-名AVP中使用的用戶的IM私有身份(IMPI)相同。
·元素“guss”中的元素“時間戳”的值與GUSS-時間戳AVP中使用的GUSS-時間戳是相同類型并且指示GUSS的時間戳。時間戳值應(yīng)該以UTC形式表示，由緊跟著該值的時間部分的時區(qū)指示符“Z”指示。
·元素“guss”中的屬性“id”的值與GAA-服務(wù)-標識符AVP中使用的服務(wù)標識符(GSID)相同。
·元素“bsfInfo”中的元素“uicc類型”的值是 GBA，以指示基本情況，或者 GBA_U，以指示BSF中也要求Ks_int_NAF的生成。
默認值是GBA。
·元素“bsfInFo”中的元素“生存時間”的值只是用戶特定密鑰生存時間(以秒計的持續(xù)時間)。如果缺少生存時間元素，則在BSF中使用默認值。
·元素“uss”中的屬性“類型”的值是附錄B中定義的GAA服務(wù)類型碼。
·元素“uss”中的屬性“nafGroup”的值是用于USS是有效的NAF組的運營商內(nèi)部組指示符。如果缺少此屬性，那么僅屬性“id”用于此元素的選擇。
·元素“uid”的值是來自于HSS的用戶的公有認證身份。
·元素“標記”的值是用于父母uss元素中的類型屬性中指示的GAA服務(wù)類型來自HSS的用戶授權(quán)標記碼。如果授權(quán)標記存在，則NAF具有給出相應(yīng)服務(wù)的許可，否則沒有。
·元素“uss”中的元素“密鑰選擇”的值是“ME-based-密鑰”，即，應(yīng)該使用Ks_NAF或Ks_ext_NAF，或者“UICC-based-密鑰”， 即應(yīng)該使用Ks_int_NAF或者“ME-UICC-based-密鑰”，即，可以使用Ks_ext_NAF或Ks_int_NAF。此屬性的值向NAF指示應(yīng)該使用哪個密鑰。如果缺少密鑰選擇屬性，那么NAF應(yīng)該使用默認的“ME-based-密鑰”. 在下列說明性例子中，值是斜體的和下劃線的。一個用戶安全設(shè)置的內(nèi)容被框起來。
<guss id＝″358500004836551@ims.mnc050.mcc358.3gppnetwork.org″> <bsfInfo> <lifeTime>86400</1ifeTime> </bsfInfo> <ussList> … </ussList> </guss> 上面用于用戶“358500004836551@ims.mnc050.mcc358.3gppnetwork.org”的GAA用戶安全設(shè)置的例子定義了對于PKI一端口(GAA服務(wù)類型碼是1)服務(wù)被允許用于用戶身份“tel358504836551”和lauri.laitinen@nokia.com，并且允許認證(存在標記1)但是對于提供由“1”GAA服務(wù)標識符標識的GAA服務(wù)的NAF反拒認不被允許(缺少標記2)。BSF將不生成UICC-Ks，因為uicc類型缺少。特定的密鑰生存期定義了在其之后密鑰到期的athe持續(xù)時間是86400秒，。
附錄B(標準化的)GAA服務(wù)類型碼 GAA服務(wù)類型碼值被用在GAA中以指示闡明、編碼和GAA服務(wù)類型特定數(shù)據(jù)的使用。
例如，每個GAA服務(wù)類型可以擁有它們自己的授權(quán)標記集合。這些標記的含義和譯碼在附錄C中定義。隨著未來它們自己的定義，也可以存在專用的GAA服務(wù)類型。
碼值0-999999是為標準化GAA服務(wù)類型保留的。
定義下列值用于隨3GPP規(guī)范的標準化GAA服務(wù)類型 0非特定服務(wù) 1PKI-端口 2認證代理 3在線 4MBMS 默認值是0。非特定服務(wù)可以或可以不具有包含或不包含公有身份列表的用戶安全設(shè)置。非特定服務(wù)不能具有特定的授權(quán)標記或者其他服務(wù)類型特定數(shù)據(jù)。
附錄C(標準化的)GAA授權(quán)標記碼 對于具有定義特殊授權(quán)標記碼的集合的GAA服務(wù)，保持下列原則僅當(dāng)用戶的用戶安全設(shè)置保護那個標記的時候，由GAA授權(quán)標記碼指定的服務(wù)被允許用于用戶。
在之前附錄B中列出的下列標準化的GAA服務(wù)類型具有下列特殊授權(quán)標記碼 PKI-端口(1) 1允許認證 2允許反拒認 附錄D(資料性的) 更改歷史
權(quán)利要求
1.一種用于在通信系統(tǒng)中共享數(shù)據(jù)的裝置，包括
引導(dǎo)服務(wù)器功能(BSF)，配置為發(fā)送第一消息，其中所述第一消息包括對應(yīng)于在所述BSF中所存儲的通用引導(dǎo)架構(gòu)用戶安全設(shè)置(GUSS)的時間戳參數(shù)；以及
歸屬用戶服務(wù)器(HSS)，配置用以接收所述第一消息，將對應(yīng)于在BSF中所存儲的所述GUSS的所述時間戳參數(shù)與對應(yīng)于在所述HSS中所存儲的GUSS的時間戳參數(shù)進行比較，以及在當(dāng)所述BSF和所述HSS的GUSS的所述時間戳參數(shù)相等的時候，將不包括所述GUSS的第二消息發(fā)送回所述BSF。
2.根據(jù)權(quán)利要求1所述的裝置，其中所述HSS配置為，當(dāng)所述BSF和所述HSS的GUSS的所述時間戳參數(shù)不相等的時候，向所述BSF發(fā)送包括GUSS和所述對應(yīng)時間戳參數(shù)的所述第二消息。
3.根據(jù)權(quán)利要求1所述的裝置，其中對應(yīng)于特定GUSS的所述時間戳參數(shù)是相同GUSS的一部分。
4.根據(jù)權(quán)利要求2所述的裝置，其中所述BSF配置用以接收來自所述HSS的所述第二消息、所述GUSS以及關(guān)聯(lián)于所述GUSS的所述時間戳參數(shù)，并且用以更新來自所述HSS的所述GUSS和所述時間戳參數(shù)。
5.根據(jù)權(quán)利要求1所述的裝置，其中所述第一消息包括針對認證矢量(AV)的請求。
6.根據(jù)權(quán)利要求1所述的裝置，其中所述HSS配置為向所述GUSS指定所述時間戳參數(shù)。
7.根據(jù)權(quán)利要求6所述的裝置，其中所述HSS配置為，當(dāng)所述GUSS的所述數(shù)據(jù)已經(jīng)被修改的時候改變用于所述GUSS的所述時間戳參數(shù)。
8.根據(jù)權(quán)利要求6所述的裝置，其中所述HSS配置為以單調(diào)增加序列或者單調(diào)減小序列來為所述GUSS指定所述時間戳參數(shù)。
9.根據(jù)權(quán)利要求6所述的裝置，其中所述HSS配置為將用于GUSS的所述時間戳參數(shù)指定為所述BSF和所述HSS的GUSS的特定實例的哈?；蛘吖５囊徊糠?。
10.根據(jù)權(quán)利要求1所述的裝置，其中所述BSF配置為以與所述HSS中所存儲的所述時間戳參數(shù)不同的數(shù)字或者字符形式來存儲所述時間戳參數(shù)。
11.根據(jù)權(quán)利要求1所述的裝置，其中所述BSF配置為以與所述HSS的所述時間戳參數(shù)不同的數(shù)字或者字符形式來傳輸所述時間戳參數(shù)。
12.根據(jù)權(quán)利要求6所述的裝置，其中當(dāng)所述GUSS第一次創(chuàng)建的時候，所述時間戳被初始化為數(shù)字值、或者初始化為指示由所述HSS中的時鐘所指示的時間和/或日期的值。
13.根據(jù)權(quán)利要求6所述的裝置，其中每次修改所述GUSS時，所述GUSS變成新版本，并且所述時間戳以1遞增或者遞減，或者所述時間戳變化到由所述HSS中的時鐘所指示的當(dāng)前時間和/或日期。
14.根據(jù)權(quán)利要求6所述的裝置，其中所述GUSS指定為是所述GUSS的特定實例的哈?；蛘咚龉５囊徊糠值乃鰰r間戳值。
15.一種用于在通信系統(tǒng)中共享數(shù)據(jù)的方法，包括
從引導(dǎo)服務(wù)器功能(BSF)向歸屬用戶服務(wù)器(HSS)發(fā)送第一消息，其中所述第一消息包括對應(yīng)于在所述BSF中所存儲的通用引導(dǎo)架構(gòu)用戶安全設(shè)置(GUSS)的時間戳參數(shù)；
將對應(yīng)于在所述BSF中所存儲的所述GUSS的所述時間戳參數(shù)與對應(yīng)于在所述HSS中所存儲的GUSS的時間戳參數(shù)進行比較；以及
當(dāng)所述BSF和所述HSS的GUSS的所述時間戳參數(shù)相等時，將不包括所述GUSS的第二消息發(fā)送回所述BSF。
16.根據(jù)權(quán)利要求15所述的方法，進一步包括
當(dāng)所述BSF和所述HSS的GUSS的所述時間戳參數(shù)不相等時，從所述HSS向所述BSF傳送包括所述GUSS和所述對應(yīng)時間戳參數(shù)的所述第二消息。
17.根據(jù)權(quán)利要求16所述的方法，進一步包括
在所述BSF處接收來自所述HSS所述第二消息、所述GUSS以及關(guān)聯(lián)于所述GUSS的所述時間戳參數(shù)；以及
在所述BSF中更新來自所述HSS的所述時間戳參數(shù)和所述GUSS。
18.根據(jù)權(quán)利要求15所述的方法，其中發(fā)送所述第一消息包括發(fā)送針對認證矢量(AV)的請求。
19.根據(jù)權(quán)利要求15所述的方法，其中針對用于所述GUSS的所述時間戳的指定以單調(diào)增加序列或者單調(diào)減小序列來執(zhí)行。
20.根據(jù)權(quán)利要求15所述的方法，其中以作為所述BSF和所述HSS的GUSS的特定實例的哈?；蛘吖５囊徊糠謥韴?zhí)行針對所述GUSS的所述時間戳參數(shù)的指定。
21.根據(jù)權(quán)利要求15所述的方法，進一步包括
以與所述HSS中所存儲的所述時間戳參數(shù)不同的數(shù)字或者字符形式來存儲所述BSF的時間戳參數(shù)。
22.根據(jù)權(quán)利要求15所述的方法，進一步包括
以不同的數(shù)字或字符形式來傳送所述BSF的所述時間戳參數(shù)和所述HSS的時間戳參數(shù)。
23.根據(jù)權(quán)利要求15所述的方法，進一步包括
將所傳輸?shù)乃鰰r間戳參數(shù)的不同數(shù)字或者字符形式轉(zhuǎn)換回其初始形式。
24.根據(jù)權(quán)利要求15所述的方法，進一步包括
以單調(diào)增加序列或者單調(diào)減小序列來向所述時間戳指定值。
25.根據(jù)權(quán)利要求15所述的方法，進一步包括
當(dāng)?shù)谝淮蝿?chuàng)建所述GUSS的時候，將所述時間戳初始化為數(shù)字值或由所述HSS中的時鐘所指示的時間和/或日期。
26.根據(jù)權(quán)利要求15所述的方法，進一步包括
將所述時間戳以1遞增或者遞減，或者每次修改所述GUSS時增加或減小所述時間戳，由此所述時間戳成為例如可以是GUSSTIMESTAMP的新版本。
27.根據(jù)權(quán)利要求15所述的方法，進一步包括
每次修改所述GUSS時，將所述時間戳改變到所述時間戳的當(dāng)前時間和/或日期。
28.根據(jù)權(quán)利要求15所述的方法，進一步包括
指定時間戳值給GUSS，所述時間戳值是所述GUSS的特定實例的哈?；蛘咚龉５囊徊糠?。
29.一種包含在計算機可讀介質(zhì)中的計算機程序，用以在通信系統(tǒng)中提供數(shù)據(jù)共享，包括
從引導(dǎo)服務(wù)器功能(BSF)向歸屬用戶服務(wù)器(HSS)發(fā)送第一消息，其中所述消息包括對應(yīng)于在所述BSF中所存儲的通用引導(dǎo)架構(gòu)用戶安全設(shè)置(GUSS)的時間戳參數(shù)；
將對應(yīng)于在所述BSF中所存儲的所述GUSS的所述時間戳參數(shù)與對應(yīng)于在所述HSS中所存儲的GUSS的時間戳參數(shù)進行比較；以及
當(dāng)所述BSF和所述HSS的GUSS的所述時間戳參數(shù)相等的時候?qū)⒉话ㄋ鯣USS的第二消息發(fā)送回所述BSF。
30.根據(jù)權(quán)利要求29所述的計算機程序，進一步包括
當(dāng)所述BSF和所述HSS的GUSS的所述時間戳參數(shù)不相等的時候，從所述HSS向所述BSF發(fā)送包括所述GUSS和所述對應(yīng)時間戳參數(shù)的所述消息。
31.，根據(jù)權(quán)利要求29所述的計算機程序，進一步包括
BSF接收來自所述HSS的所述消息、所述GUSS以及關(guān)聯(lián)于所述GUSS的所述時間戳參數(shù)；以及
在所述BSF中更新來自所述HSS的所述時間戳參數(shù)和所述GUSS。
32.根據(jù)權(quán)利要求29所述的計算機程序，其中發(fā)送所述第一消息包括發(fā)送針對認證矢量(AV)的請求。
33.根據(jù)權(quán)利要求29所述的計算機程序，其中以單調(diào)增加序列或者單調(diào)減小序列來執(zhí)行針對所述GUSS的所述時間戳參數(shù)的指定。
34.根據(jù)權(quán)利要求29所述的計算機程序，其中以作為所述BSF和所述HSS的GUSS的特定實例的哈?；蛘吖５囊徊糠謥韴?zhí)行針對所述GUSS的所述時間戳參數(shù)的指定。
35.根據(jù)權(quán)利要求29所述的計算機程序，進一步包括
以與所述HSS中所存儲的所述時間戳參數(shù)不同的數(shù)字或者字符形式來存儲所述BSF的時間戳參數(shù)。
36.根據(jù)權(quán)利要求29所述的計算機程序，進一步包括
以不同的數(shù)字或字符形式來傳送所述BSF的所述時間戳參數(shù)和所述HSS的時間戳參數(shù)。
37.根據(jù)權(quán)利要求29所述的計算機程序，進一步包括
以單調(diào)增加序列或者單調(diào)減小序列來向所述時間戳指定值。
38.根據(jù)權(quán)利要求29所述的計算機程序，進一步包括
當(dāng)?shù)谝淮蝿?chuàng)建所述GUSS的時候，初始化所述時間戳為數(shù)字值或由所述HSS中的時鐘所指示的時間和/或日期。
39.根據(jù)權(quán)利要求29所述的計算機程序，進一步包括
將所述時間戳以1遞增或者遞減，或者每次修改所述GUSS時增加或減小所述時間戳，并且所述時間戳成為新版本。
40.根據(jù)權(quán)利要求29所述的計算機程序，進一步包括
每次修改所述GUSS時，將所述時間戳改變到當(dāng)前時間和/或日期。
41.根據(jù)權(quán)利要求29所述的計算機程序，進一步包括
指定時間戳值給GUSS，所述時間戳值是所述GUSS的特定實例的哈?；蛘咚龉５囊徊糠帧?br> 42.一種通信系統(tǒng)，包括
網(wǎng)絡(luò)應(yīng)用功能(NAF)；
用戶設(shè)備，配置為與NAF通信并且用以傳送針對認證信息的請求；
引導(dǎo)服務(wù)器功能(BSF)，配置為接收請求并傳送第一消息，其中所述消息包括對應(yīng)于在所述BSF中所存儲的通用引導(dǎo)架構(gòu)用戶安全設(shè)置(GUSS)的時間戳參數(shù)；以及
歸屬用戶服務(wù)器(HSS)，配置為接收所述第一消息，用以將對應(yīng)于存儲在所述BSF中的所述GUSS的所述時間戳參數(shù)與對應(yīng)于存儲在所述HSS中的GUSS的時間戳參數(shù)進行比較，以及當(dāng)所述BSF和所述HSS的所述GUSS的時間戳參數(shù)相等的時候，將不包括所述GUSS的第二消息傳送回所述BSF。
全文摘要
一種用于在通信系統(tǒng)中共享數(shù)據(jù)的裝置和方法，包括配置為發(fā)送第一消息的引導(dǎo)服務(wù)器功能(BSF)。第一消息包括對應(yīng)于在BSF中所存儲的通用引導(dǎo)架構(gòu)用戶安全設(shè)置(GUSS)的時間戳參數(shù)。歸屬用戶服務(wù)器(HSS)，配置用以接收第一消息，用以將對應(yīng)于在BSF中所存儲的GUSS的時間戳參數(shù)與對應(yīng)于在HSS中所存儲的GUSS的時間戳參數(shù)進行比較，以及在當(dāng)BSF和HSS的GUSS的時間戳參數(shù)相等的時候用以將不包括GUSS的第二消息發(fā)送回BSF。
文檔編號H04W12/06GK101156486SQ200680010534
公開日2008年4月2日 申請日期2006年1月11日 優(yōu)先權(quán)日2005年2月14日
發(fā)明者P·萊蒂南, P·金斯伯格 申請人:諾基亞公司