2008年下期（7月〜12月）における、注目すべきネットワークセキュリティ分野のトピックとしては、IETF（Internet Engineering Task Force）のIPsec（IP Security Protocol）関連ワーキンググループ（WG）における標準化動向がある。IETFには、IPsec関連の3つのWGがあるが、この期間に新たなWGが承認され、既存の2つのWGにおいて、WGのメインとなる文書がRFCとして発行された。今回はこれらの標準化動向について報告する。

 　IPsecは、IP（Internet Protocol）にセキュリティ機能を追加するためのプロトコルスイートである。IPsecは、ESP（Encapsulating Security Protocol）、AH（Authentication Header）、IKE（Internet Key Exchange）の3つのプロトコルからなっており、ESPがデータの暗号化とメッセージ認証、AHがメッセージ認証、IKEが暗号化やメッセージ認証に必要な共通鍵の交換を行う。IPsecの最初のバージョン（IPsecバージョン1）は、1995年にRFC 1825〜RFC 1829として発表され、鍵管理プロトコルであるIKE（IKEv1）やいくつかの機能追加がなされたバージョン（IPsecバージョン2）が1998年にRFC 2401〜RFC 2412, RFC 2451として発表された。そして、2005年に、リモートアクセス機能などが強化されたIKEv2を含むバージョン（IPsecバージョン3）がRFC 4301〜RFC 4303, RFC 4305〜RFC 4307として発表された。
 　IPsec（バージョン3）の動作の手順は図1のとおりである。最初に、通信を行うノードの間でIKEv2による交換が行われる。ここでは、IKE_SA_INIT交換によって、IKEv2の通信を保護するためのIKE SA（Security Association）を確立し、次のIKE_AUTH交換によって、データを保護するためのIPsec SA（CHILD_SA）の確立と、相手認証を行う。その後は、確立されたIPsec SAを使用して、データをIPsecのESPまたはAHを使用して保護する。IPsecが提供する保護サービスは、使用するプロトコルによって異なり、表1のようになる。

図1 IPsecの手順

表1 IPsecが提供するサービス

 　現在、IETFには、IPsec関連のWGとして、IPSECME（IP Security Maintenance and Extensions）、MSEC（Multicast Security）、BTNS（Better-Than-Nothing Security）の3つが存在する。

•  　IPSECME WG
  IKEv2を含むIPsecに関する仕様の明確化や改良、機能追加を議論するためのものであり、2005年に終了したIPSEC WGを引き継ぐ形で活動している。
•  　MSEC WG
  ユニキャストにしか対応していない現在のIPsec/IKEv2に対して、マルチキャストへの対応を議論している。
•  　BTNS WG
  既存のIPsecでは相手認証のための設定が煩雑であることから、相手認証をせずに、通信を保護するための仕組みを検討している。

 　2008年下期には各WGにおいて次の動きがあった。

 　ユニキャストが1対1の通信を行うものに対して、マルチキャストは1対多の通信を行うものである。マルチキャストは、インターネット上では実現が難しいが、NTT東西のフレッツ網やNGN（フレッツ光ネクスト）網、NTTコミュニケーションズやソフトバンクテレコムなどのIP-VPN網において利用することができる。マルチキャスト通信は、会議の模様や経営層からのメッセージの中継や、売上データなどの一斉ファイル配信など、ビジネスにおいても有効に利用することができ、その際に暗号化などのIPsecの機能が有効となる。
 　従来のIPsecでは、マルチキャスト通信の保護に対して、主に次のような問題があった。

 　このため、MSEC WGでは、1対1の通信を想定しているIPsecのSAを拡張したGSA（Group Security Association）を新たに定義し、GSAを確立するための鍵管理プロトコルを開発した。GSAは図2のように、レジストレーションSA、リキーSA、データSAの3つから構成される。また、送信元を個々に認証する必要がある場合を想定し、共通鍵ベースのメッセージ認証コード（MAC）ではなく、公開鍵ベースのデジタル署名を使用して送信元を認証する仕組みを開発している（RFC 4082, RFC 4359）。
 　マルチキャスト用IPsecでは、ユニキャスト用IPsecと比較してSAだけでなく、SPD（Security Policy Database）、PAD（Peer Authorization Database）といったデータベースも拡張され、それぞれGSPD（Group Security Policy Database）、GPAD（Group Peer Authorization Database）として再定義している。また、鍵管理プロトコルについては、IKEv1/IKEv2の代わりに、GDOI（Group Domain of Interpretation）、GSAKMP（Group Secure Association Key Management Protocol）などがある。しかし、ESPとAHのプロトコル自体には変更はないようにしている。表2にユニキャスト用IPsecとマルチキャスト用IPsecの違いをまとめる。

図2 Group Security Association（GSA）

表2 ユニキャスト用IPsecとマルチキャスト用IPsecの違い

 　IPsecでは、相手認証にデジタル署名認証方式が推奨されており、エンドツーエンドの通信にIPsecを適用するためには、各端末用に公開鍵証明書を発行しなければならず、管理が非常に負担になるという問題がある。このため、この相手認証の処理を行わないことで、容易にIPsecを使えるようにするための検討が開始された。認証の処理を行わないため、通信相手が意図している相手かどうかを確認することはできないが、暗号化やメッセージ認証などの機能は利用することができるという意味で、”Better-Than-Nothing-Security”（無いよりはまし）という名称が付けられている。
 　また、相手認証の機能はIPsecのレベルで行わず、上位層プロトコルに任せるということも考えられる。例えば、ネットワークファイルシステムのプロトコルであるNFSv4では、認証はアプリケーションレベルで行い、暗号化やメッセージ認証はBTNSを利用することを検討している。
 　BTNSでは、IPsecで定義されているデータベースであるPADとSPDのエントリに、それぞれ” PUBLICKEY”、”BTNS_OK”という新たな識別子を導入することで、認証なしのIPsec通信を行うためのポリシーを追加している。そして、相手認証を行うIKEv2において、認証の処理をバイパスさせればよいのであるが、バイパスさせようとするとIKEv2のプロトコル仕様を変更する必要がある。このため、実際には、認証の処理をバイパスせずに、自己署名証明書やRSA公開鍵など、認証局（CA）による証明書発行の処理の必要のない認証情報を送信する。この時、通常のデジタル署名認証方式では、証明書が有効であることを確認するために、ルート証明書などによる公開鍵証明書の正当性の確認を行うが、この処理は行わない。つまり、送信されてきた公開鍵を使用してデジタル署名の検証は行うが、公開鍵の正当性は確認しないため、相手認証をしていないのと結果的には同じということになる。これにより、IPsecやIKEv2のプロトコルを修正せずに、認証局による公開鍵証明書の発行などの管理の必要なしに、IPsecが利用できるようになる。

 　2008年下期に、マルチキャストトラフィックを保護する仕組みと、相手認証処理を省略することで簡易にトラフィックを保護する仕組みがRFC化された。これにより、NGN（Next Generation Network）などにおけるマルチキャストトラフィックの保護にIPsecを利用することや、証明書発行などの面倒な処理を必要とせずに、エンドツーエンドでIPsecを利用することが可能となる。
 　今後は、これらの仕組みを実装した製品が出現するのを待つことになるが、マルチキャスト通信を保護する必要性や、エンドツーエンド通信をIPsecレベルで保護する必要性がユーザに認知されるかどうかもポイントになると考えられる。

以上