本文摘錄自美國(guó)NIST近期發(fā)布的特別出版物《IPsec VPNs指南》第一次修訂版。該《指南》為各組織提供正確部署基于IPsec的安全服務(wù)的實(shí)用教程，以便它們能夠降低跨網(wǎng)絡(luò)傳輸敏感信息的風(fēng)險(xiǎn)。
《指南》簡(jiǎn)要討論了IPsec領(lǐng)域的部分未來發(fā)展方向。目前，IETF正著力研究各類IKE（Internet Key Exchange，互聯(lián)網(wǎng)密鑰交換）與IPsec擴(kuò)展議題。本文旨在介紹當(dāng)前正在開發(fā)的新標(biāo)準(zhǔn)，以及與之相關(guān)的其它資源信息。
1.支持組播（Multicast）與組認(rèn)證（Group Authentication）
組播流量是指將數(shù)據(jù)包發(fā)送至被指定為組播地址的IP地址。接下來，一臺(tái)或多臺(tái)關(guān)注此通信的主機(jī)將接收此單一數(shù)據(jù)包的副本。與將數(shù)據(jù)包分發(fā)至子網(wǎng)上所有主機(jī)中的常規(guī)廣播流量不同，組播流量只會(huì)被發(fā)送至關(guān)注或有權(quán)接收相應(yīng)數(shù)據(jù)包的主機(jī)。目前，組播機(jī)制主要應(yīng)用于音頻與視頻流傳輸領(lǐng)域。
從發(fā)送方的角度來看，組播機(jī)制擁有兩大核心優(yōu)勢(shì)。首先，發(fā)送方只需要?jiǎng)?chuàng)建并發(fā)送單一數(shù)據(jù)包，而無需為各個(gè)接收方創(chuàng)建并發(fā)送不同的數(shù)據(jù)包。其次，發(fā)送方無需跟蹤實(shí)際接收方。從網(wǎng)絡(luò)角度來看，組播還具有另一大優(yōu)勢(shì)，即減少對(duì)網(wǎng)絡(luò)帶寬資源的占用。
RFC 4301描述了組播流量的IPsec處理方式。RFC 5374則擴(kuò)展了IKEv1協(xié)議，旨在匹配組與組播流量的應(yīng)用需求。其中定義一種新的SA（組安全關(guān)聯(lián)，簡(jiǎn)稱GSA）以及用于對(duì)組播流量應(yīng)用IPsec保護(hù)的其他數(shù)據(jù)庫。這些GSA的secret密鑰將被分發(fā)至各個(gè)組成員。一旦成員離開該組，各剩余成員所持有的secret密鑰都必須被立即替換為離組成員所不知曉的新組密鑰。但對(duì)于不斷有成員加入及離開的大型組，這樣的機(jī)制可能非常復(fù)雜。
截至撰稿時(shí)，IKEv2還不支持組播流量，但目前正在草擬文件以添加相關(guān)支持。其中提到將定義一項(xiàng)新的G-IKEv2擴(kuò)展，能夠全面匹配組播組（MEC）安全架構(gòu)以及組播安全（MSEC）組密鑰管理架構(gòu)。G-IKEv2將替代負(fù)責(zé)在IKEv1中定義類似組密鑰管理協(xié)議的原有組釋域（GDOI）機(jī)制。
2.標(biāo)記IPsec
標(biāo)記IPsec是一種用于傳達(dá)與IPsec流關(guān)聯(lián)的安全標(biāo)簽或上下文的機(jī)制。兩側(cè)端點(diǎn)都可以對(duì)通過IPsec連接進(jìn)行傳輸?shù)木唧w流量類型做出進(jìn)一步限制。部分供應(yīng)商還對(duì)IKEv1進(jìn)行了專有擴(kuò)展，借此支持標(biāo)記IPsec。
IETF目前正擬議將該擴(kuò)展添加至IKEv2草案當(dāng)中。該擴(kuò)展作為額外的流量選擇器形式存在，負(fù)責(zé)指定流量必須匹配的安全上下文。目前這項(xiàng)決策仍在討論當(dāng)中。
3. 封裝安全載荷（ESP）中的隱式IV
對(duì)于物聯(lián)網(wǎng)設(shè)備及其他依靠電池供電的網(wǎng)絡(luò)設(shè)備，人們希望盡可能減少網(wǎng)絡(luò)數(shù)據(jù)傳輸量以節(jié)約電池電量。
在使用AEAD（利用關(guān)聯(lián)數(shù)據(jù)進(jìn)行身份驗(yàn)證加密，例如AES-GCM）部署IPsec時(shí)，每個(gè)數(shù)據(jù)包中都包含一個(gè)IV，也稱為隨機(jī)數(shù)。
該值必須唯一，但可以預(yù)測(cè)。目前推薦的實(shí)現(xiàn)方式是使用一款簡(jiǎn)單的計(jì)數(shù)器。但ESP協(xié)議本身已經(jīng)包含一款計(jì)數(shù)器，用于抵御重放攻擊的影響。
IETF正在組織提案，希望定義AES-CGM與AES-CCM的變體，用于省略掉發(fā)送AEAD IV并使用ESP重播計(jì)數(shù)器的步驟。這些變體僅適用于ESP算法（不適用于IKE算法定義），目前相關(guān)決策仍在討論當(dāng)中。
4.中間交換
經(jīng)典Diffie-Hellman（DH）密鑰交換可能受到量子計(jì)算攻擊的影響。為此，需要使用量子安全密鑰交換以替代DH密鑰交換機(jī)制。
目前針對(duì)此類算法的建議，要求用戶使用大型公共密鑰，而大型公共密鑰需要在IKE_SA_INIT階段在IKE之內(nèi)進(jìn)行交換。
在交換過程中，由于尚未建立起可識(shí)別片段合法性的保密通道，因此無法使用IKEv2片段。通過在IDE_SA_INIT與IDE_AUTH交換之間添加新的中間交換環(huán)節(jié)，即可實(shí)現(xiàn)片段支持。目前這項(xiàng)決策仍在討論當(dāng)中。
5.在遠(yuǎn)程訪問VPN中支持IPv4與IPv6
電信網(wǎng)絡(luò)（LTE/5G）可以在網(wǎng)絡(luò)連接當(dāng)中就是否嘗試使用IPv4、IPv6或者二者混合的嘗試發(fā)出通知。但是，IKEv2并不提供類似的通知結(jié)構(gòu)，也不具備豐富的錯(cuò)誤通知功能，因此導(dǎo)致客戶端無法確定是否應(yīng)僅嘗試使用IPv4、僅使用IPv6或者同時(shí)同時(shí)進(jìn)行IPv4/IPv6尋址以實(shí)現(xiàn)IPsec。
目前已經(jīng)有新的草案就此展開討論，希望更好地將3GPP標(biāo)準(zhǔn)與IKEv2集成起來。目前這項(xiàng)決策仍在討論當(dāng)中。
6.后量子密鑰交換
一旦出現(xiàn)了能夠替代經(jīng)典（EC）DH密鑰交換機(jī)制的量子安全密鑰交換算法，自然需要擴(kuò)展IKEv2協(xié)議以支持這種新算法。
目前一種建議是保留現(xiàn)有的（EC）DH交換機(jī)制，并在協(xié)議中添加一種或者多種量子安全密鑰交換機(jī)制，保證所得到的混合密鑰交換機(jī)制在安全度方面至少與最安全的組件處于同一水平。如此一來，即使當(dāng)前指定的候選量子安全算法隨時(shí)間推移而不再安全，連接的安全性也至少能夠保持在與經(jīng)典（EC）DH密鑰交換相同的水平。
這項(xiàng)設(shè)計(jì)還能夠保證NIST批準(zhǔn)的IPsec實(shí)現(xiàn)（其中添加了量子安全算法以提升保護(hù)能力）仍可符合當(dāng)前所有NIST要求。目前這項(xiàng)決策仍在討論當(dāng)中。
在線咨詢
在線咨詢
0371-63319761