Roaming：一種安全的實現

今天要講的內容比較有特點，大家可以體會下

這種實現方式叫HOKEY

縮略語：

EAP：Extensible Authentication Protocol

MSK：Master Session Key

EMSK：Extended Master Session Key

ERP：EAP Re-authentication Protocol

RFC3748講述了EAP，即The Extensible Authentication Protocol，它支持多種認證方法，例如，我們熟知的EAP-TLS、EAP-PEAP等。EAP的主要功能是實現網路的接入控制，同時，它另外一個重要功能就是通過認證產生會話密鑰（其實質也是加強對網路的接入控制），EAP可以產生兩種基礎密鑰：MSK和EMSK。

根據RFC3748的描述，MSK產生自EAP peer和server之間，EAP server將傳送這個MSK給相應的authenticator，從協議描述可以看出，MSK適用於單個設備的單一目的。幸運的是，協議定義了另外一種基礎密鑰，EMSK。

協議中關於EMSK的描述只用了一句話：The EMSK is reserved for future uses that are not defined yet。

本文要介紹的EAP的重認證和預認證就是使用EMSK作為基礎密鑰，展開得到了所需要的各種各樣的密鑰類型。

Additional keying material derived between the EAP client and server that is exported by the EAP method. The EMSK is at least 64 octets in length. The EMSK is not shared with the authenticator or any other third party. The EMSK is reserved for future uses that are not defined yet.

為什麼要引入EAP的重認證和預認證？

降低漫遊的時延

無論使用哪種EAP的認證方法，我們都很清楚，都需要peer和server之間交互多個消息，如下，peer發送的消息到達server，server回應一個消息，這兩個消息放在一起稱為一個round trip，任何EAP的認證方法在成功認證之前，都需要多個round trip的過程。

這裡問題就來了，當移動終端想要發生漫遊行為的時候，最簡單、最直接的實現是和新的authenticator進行一次完整的EAP過程，但是這樣的實現雖然直接，卻是不合理的；因為現有的任何一種EAP方法（包括密鑰的生成），若要進行完整的EAP過程都需要多個round trip，將耗費大量的時間，對於時延敏感的業務是萬萬不能接受的。

於是，就有了ERP和pre-EAP

ERP要解決的問題只有一個：降低peer的漫遊時延；那麼可行的途徑似乎也只有一個了，減少EAP過程中的round trip

我們的目標是：在不犧牲安全的前提下，將round trip減少到最少；多少是最少？

很顯然，一個round trip的交互過程是最少的。

Peer通過完整的EAP過程

（1）接入SAP，然後漫遊到TAP，通過ERP方式

（2）完成認證並得到密鑰。

傳送已有的密鑰素材給TAP，即TAP是如何得到數據加密key的，實現起來有兩種方式，水平方式和垂直方式。

水平方式：即SAP直接傳送key素材給TAP，這種方式是不推薦使用的，因為其實現機制可能會發生一個TAP的泄密，從而導致其他TAP也被泄密。

這一點在RFC4962中被詳細描述。

垂直方式：這種方式和重新得到一個全新的key素材是類似的，因為它的機制是通過一個成功的認證從一個被信任的server直接傳送key給TAP。

解決時延的最佳解決方案是最優的方案是ERP和本文討論的early authentication.

ERP：RFC5296，2008.8

ERP：EAP Extensions for EAP Re-authentication Protocol，它支持獨立的EAP重認證的方法，使用已經完成的EAP認證所得到的key素材，實現的結果是當peer在漫遊接入的時候只需要一趟round trip即可。

ERP消息交互說明：

（1）Auth可以通過送出EAP-Initiate/Re-auth-Start消息來啟動ERP過程，Peer通過應答EAP-Initiate/Re-auth消息來啟動ERP過程。

（2）Peer送出一個包含了keyName-NAI的EAP-Initiate/Re-auth消息，以此來確定ER server的domain和所使用的rIK，同時有一個順序號作為replay保護使用。

（3）Server發送一個EAP-Finish/Re-auth消息，這個消息也被rIK加密保護。Server將在這個消息中傳送rMSK給Auth。rMSK的傳遞和一個完整的EAP認證通過EAP-Success傳送MSK是類似的。

（4）Peer驗證replay保護和消息的完整性。然後用EAP-Finish/Re-auth消息中的順序號計算rMSK。底層安全關聯協議在此之後就可以觸發了。

ERP消息交互補充說明：

（1）Peer初始化ERP過程，也可以是響應auth的消息，即ERP過程可以是peer或者auth觸發。任何一方在沒有得到對方響應的情況下都應該後退到EAP認證。

（2）EAP-Initiate/Re-auth消息被rIK完整的保護。auth根據keyName-NAI給出的域信息給相應的ER server發送消息；Server根據keyName來尋找確定使用的rIK，Server完成驗證rIK後，就由rRK和順序號作為輸入產生重認證的MSK；Server將更新順序號，將其加1保存。

（3）如果Peer請求了rMSK的生存周期，ER server在EAP-Finish/Re-auth消息中攜帶。

ERP消息格式：ERP中定義了兩種新的EAP code，分別是EAP-Initiate和EAP-Finish，格式和RFC3748中定義的沒有區別。

Code的含義：5 Initiate，6 Finish

專有術語：

ER Server：一個能夠執行ERP認證功能的邏輯試實體，它可以是一個EAP Server，也可以不是一個EAP Server。

ER Server本身有兩種形式，Home ER Server和Local ER Server，兩者的區別是前者必須和Auth在同一個Home Domain內，同時是一個EAP Server，能夠進行完整的EAP過程。

Domain：對應於ER Server也有Home domain和Local Domain之分，前者是最初的Key管理Domain，即Peer與其執行過完整的EAP交互過程；後者可能只是Peer與其進行ERP的過程。

Bootstrap：如果Peer不知道Domain的名字，它應該初始ERP bootstrap交換(ERP exchange with the bootstrap flag turned on)，並且通過Home ER server獲得Domain的名字。

Peer也可以通過初始bootstrapping來獲取一些其他信息，例如rRK的生存周期。

ERP的密鑰分發是個很重要的內容，參考RFC5749。

rRK - re-authentication Root Key, derived from the EMSK or DSRK.

rIK - re-authentication Integrity Key, derived from the rRK.

rMSK - re-authentication MSK. This is a per-authenticator key, derived from the rRK.

DSRK - Domain-Specific Root Key（Local Domain）, which itself is derived from the EMSK.

密鑰體系：

rMSKn適用於多個認證者。

Early Authentication：RFC5836

Early Authentication：EAP預認證，目標是當Peer移動之前完成AAA業務，即EAP過程。預認證的使用範圍被限定在預想的環境，在這裡候選Auth（CAP）能夠被發現，並且移動的行為能夠被很容易的確定。

Early Authentication模型：

MD：mobile device，即Peer。

對於以上Early Authentication的模型，從SAP的角度考慮，依據其行為可以抽取出三種實現模式，如下

Direct pre- authentication usage model：SAP與Early Authentication無關。

Indirect pre-authentication usage model：SAP與CAP是相互聯繫的。

The authenticated anticipatory keying usage model：SAP與AAA Server是直接聯繫的。

下面分別介紹這三種實現模式。

The Direct Pre-Authentication Model

在這種模型中，SAP和EAP的交互過程是無關的，僅僅轉發預認證消息，和轉發其他數據消息是一樣的。

這種模式建立的基礎是：MD能夠發現候選auth並且能夠與其建立直接的IP通信。

The Indirect Pre-Authentication Usage Model

SAP在此模型中的角色是轉發EAP重認證信令在MD和CAP之間；CAP的角色是轉發EAP重認證信令在peer和EAP server之間（是經過SAP的）。

此種模型的基礎是：假定目前使用的網路和候選網路是互相信任的關係。如果peer不能發現候選auth或者不能與其直接進行通信，這個模式是必須選擇的。

Early Authentication能夠實現需要兩種重要的機制，即CAP（authenticator discovery）的發現和相關信息的綁定（context binding）。

ERP/AAK：RFC5836draft-ietf-hokey-erp-aak-02.txt

ERP/AAK：EAP Re-authentication Protocol Extensions for Authenticated Anticipatory Keying，即使用ERP的方式來實現Early Authentication中的第三種模式。

實現的條件是在Peer進行此過程之前一定已經完成了完整的EAP過程，這一點在ERP中已經講述。

ERP/AAK重用了ERP定義的包形式，但是制定一個新的flag來卻分EAP預認證和EAP重認證。

Peer發送置位了的重認證啟動消息來啟動預認證。

SAP加密預認證消息，轉化為AAA消息模式發送給消息中指定的server。

Server授權消息中攜帶的CAP信息，在CAP通過授權之後，server為各個CAP生成pRK和pMSK。

Server傳送pMSK給各個CAP；在此之後，Server將確定每個CA是否接受pMSK，是否Peer能夠與其連接。

最後，Server發送finish消息經過SAP給Peer，在消息中包含了所有可以接入的CAP。

ERP/AAK Key Hierarchy與ERP是一致的，如下

ERP/AAK的消息格式如下，主要是一個標誌位來識別。這裡給出的是EAP-Initiate/Re-auth-Start，其他的包括EAP-Initiate/Re-auth、EAP-Finish/Re-auth都是類似的。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！