$Id: report-ipsec.txt,v 1.1.1.1 1999/10/26 17:19:17 sakane Exp $ %Hd: IPSECについて はじめに これは RFC1825-1829をもとに 1997/02頃に調査したものなので、 現状にそぐわないかもしれない。詳細は最新のドキュメントを参照するべきである。 IPSECの概要 IPSECの背景 o マルチレベルセキュアネットワーク(MLS)の必要性 - 単一のネットワーク上において異なる機密レベルを用いての通信が可能 e.g., Unclassified, Secret - 合州国政府が情報をやりとりするために必要としていた - IPSECメカニズムは、MLSをサポートすることが目的であった o Internetにおけるセキュリティの早急な必要性 - 通信技術の急速な進歩 - ユーザの増加 o セキュリティに関する２つのWGが合併した - IPv6を検討しているIPng WG内のセキュリティを議論する部門と、 IPv4でのセキュリティを検討していたIPSEC WGが、 検討内容が類似していたこととメンバーがかなり重複していたために IPSEC WGに統合され、現在に至っている。 o 既存のセキュリティプロトコル - 米国政府のSP3セキュリティプロトコル仕様 - ISO/IECのNLSP仕様 - swIPeセキュリティプロトコル IPSECの思想 o 強力なセキュリティの提供 複数のセキュリティシステムを組合せて使用することにより、 より強固なセキュリティを提供する。 o 多様なセキュリティポリシーに対応する セキュリティ機能を分離する。 新しい強力なセキュリティ機能が開発された場合に、 他の機能に影響を与えずに容易に交換できる。 o セキュリティシステム構成の柔軟性を提供 暗号アルゴリズム、認証方式、鍵交換アルゴリズム、証明書発行アルゴリズム 等をユーザのポリシーに従い選択して使用できる。 o 暗号技術の利用 セキュリティと暗号技術の関係は深いのは周知。 これを利用し認証、保全性、アクセスコントロール、機密性を提供する。 o IPSECメカニズムを用いないユーザへ影響を与えない。 IPSECの概要 o セキュリティプロトコルとSA管理プロトコルの分離 - IPパケット認証プロトコルと暗号カプセル化プロトコル IP Authentication Header (AH) IP Encapsulating Security Payload (ESP) - 鍵管理/SA管理プロトコル Internet Key Management Protocol (IKMP) - AHとESPは組合せて使用することが出来る。 o セキュリティプロトコルと暗号メカニズムの分離 o OSI参照モデルのネットワーク層でセキュリティを提供する o アプリケーションには透過的にセキュリティを提供する 例えばファイルの秘密を保持しておきたい場合は、他のセキュリティ処理が必要 o セキュリティ機能の無いIPプロトコルとの共存性 o IPv4/IPv6におけて共通技術となる IPv4ではオプション、IPv6では必須機能として標準化の方向 o インターネットにおける全てのセキュリティ問題を解決するわけではない IPSECアーキテクチャ o IP Authentication Header (AH) - IPデータグラムに認証情報を追加することによりセキュリティを提供する - コネクションレスな保全性とデータ送信元の認証を提供する - オプションで、対リプレイ攻撃も提供できる - 機密性とトラフィック分析に対する保護は、AHでは提供されない - 機密性を認めない国であっても適用できる - 送信途中に変更されないIPヘッダのフィールドとペイロードを保護する - 否認防止は、 (by draft-arch) 通常AHでは提供されない (by draft-esp) ある認証アルゴリズムを使用するならば、提供出来る o IP Encapsulating Security Payload (ESP) - データを暗号化し、ESPのペイロードにそのデータを置くことにより セキュリティを提供する - 機密性とデータの送信元の認証、コネクションレスな保全性、対リプレイ攻撃、 制限されたトラフィックフローの機密性を組合せて提供する - セキュリティゲートウェイに実装することにより、信頼された 内部ネットワークにおける暗号化を省略することが出来る。 - カプセル化を行なうプロコトルであるので、ネストしても良い。 例えば、１つのESPで保護されたSAは、１ホストと１セキュリティゲートウェ イ間のものであり、ネストした２番目のESPで保護されたSAは、同じホスト からセキュリティゲートウェイを越えた後側にあるホストへ到達するもの であってもよい。 - Transport-modeとTunnel-modeの２つのモードがある。 - 機密性は全てのサービスに依存せずに選ぶことが出来る。 - データの送信元の認証とコネクションレスな保全性は、 機密性に依存せずに結合されたサービスである。 - 機密性に依存せずにこれら２つのサービスが選択されたときには、 対リプレイ攻撃を選択することが出来る。 - 制限されたトラフィックフローの機密性の使用は機密性に依存し、 さらにTunnel-modeの使用を要求する。 o Internet Key Management Protocol (IKMP) - SAの情報を交換するために使用される。 - IPSECを広域にかつ安全に使用するために必要。 - 鍵管理のためのセキュリティ機能と鍵管理メカニズムの分離 様々な鍵管理メカニズムに対して柔軟に対応する。 e.g., KDC,DH,CA - SAを管理するために論理的なテーブルを作成する。 IPSECの安全性 o IPSECにより提供されるセキュリティの品質が以下のことに 完全に依存していることを理解する必要がある - 実装されている暗号アルゴリズムの強度 - 暗号アルゴリズムの実装の正確さ - 使用されている鍵の強度 - 鍵管理プロトコルとその実装の安全性 - 関係している全システムのAHとIPの実装の正確さ o IPSECの安全性は、セキュリティを実装しているOSの安全性に一部関係している - OSが対称鍵や非対称鍵暗号における秘密鍵を秘密にしておくことが出来ない ならば、それらの鍵を使うトラフィックは安全とは言えない - 同一システム上の異なるユーザ同士は、互いに信用できない可能性がある。 この時、ユーザまたはセッション単位で個々に鍵を持つべきである。 o トラフィック分析に対する保護 - IPSECのメカニズムでは提供されない - １つの対策として、Bulk Link Encryption がある V.L. Voydock & S.T. Kent, "Security Mechanisms in High-level Networks", ACM Computing Surveys, Vol. 15, No. 2, June 1983. - その他のテクニックは、偽装したトラフィックを使用する方法もある トラフィック分析により得られるデータにノイズを増加させる o アプリケーション特有のセキュリティメカニズムは、IPSECでは提供しない - 電子メール等のいくつかのアプリケーションは、恐らく固有の セキュリティメカニズムを持つ必要がある。 PEM,PGP,S/MIME,SSL Security Association (SA) o SAの概念 - セキュリティの目的で作成された単一方向の論理的なコネクション - 安全な通信を行なうためのルールを特定するパラメータ群である - SA内を飛び交う全てのトラフィックに対して、送信者と受信者は 同じセキュリティプロセスを用いる - AHとESPの実装は、このSAの概念をサポート(MUST)しなければならない o Security Parameters Index (SPI) - IPSECを使用する通信の適切なSAを決定するために使用される - IPSECプロトコルにより運ばれる - SPIは、SAの作成者にのみ意味を持つビット列である。 作成者以外には意味をなさないビット列とみなされる。 SAの作成者は、SPIのビット列を解釈して処理しやすいように選んでも良い。 - IANAにより予約されていない範囲内の可変なSPI値を持たなければならない。 - SPIとDestinationアドレスの組合せで、１つのSAをユニークに識別する - SA管理プロトコルは、SPIのみでセキュリティプロトコルを関係付ける いくつかのSA管理メカニズムが使用でき、更にSA管理プロトコルや セキュリティプロトコルの変更や訂正が柔軟に行なえる。 o SAの単一方向性 - １つのSAは、AH,ESPのどちらか１つを採用した単一方向のコネクションである AH,ESPの両方を含むSAはありえない - ２ホスト間または２セキュリティゲートウェイ間での安全な双方向通信を 保証するためには、それぞれの方向の２つのSAが必要とされる。 o SAの受信者指向性 - 受信側システムがSAを決定し、SPIの値を選択する 鍵管理プロトコル等による自動設定したSAと、 手動設定したSAが矛盾する可能性がなくなる。 o SAのパラメータ - SAは、以下に示すのパラメータをサポートしなければならない(MUST)。 - その他のパラメータは、実装者の選択にまかせる(MAY)。 [全実装でREQUIRED] - AHまたはESPで使用される認証アルゴリズムとモード。 - 上記の認証アルゴリズムで使用される１つ以上の鍵。 - 時刻または期間で指定される認証鍵の有効期間(lifetime) - SA自身の有効期間(lifetime) - SAのDestination IPアドレス １つ以上の受信側システムが同じSAを共有する場合、ワイルドカードの 使用が可能。 e.g., セキュリティゲートウェイに隠されている場合 アドレスは、ユニキャストアドレスやIPv4ブロードキャストアドレス、 マルチキャストグループアドレスでも良い。 - SAのSource IPアドレス 複数可。 １つ以上の送信側システムが、１つのDestinationアドレスにおいて 同じSAを共有するならば、ワイルドカードが使用可能。 - 対リプレイ攻撃のための情報 使用に関わらずシーケンス番号等のウィンドウサイズの情報を含む。 [ESP実装においてREQUIRED] - 暗号化アルゴリズムとモード。 - 上記の暗号化アルゴリズムで使用される１つ以上の鍵 - 暗号化アルゴリズムのための暗号化/復号化同期フィールドまたは 初期化ベクタフィールドのサイズとその有無。 - 時刻または期間で指定される暗号化鍵の有効期間 (Authentication key crypto period) [セキュリティゲートウェイにおいてREQUIRED] [その他の全実装でRECOMMENDED] - SAのProxy IPアドレス 送信側と受信側の終端間においてIPSECが使用されない場合に、 Source IPアドレスのためにセキュリティサービスを提供する セキュリティゲートウェイのIPアドレスを含む。 [マルチレベルセキュリティを提供する全システムにおいてREQUIRED] [その他の全実装でRECOMMENDED] - 保護するデータの機密レベル。 Kent, S., "US DoD Security Options for the Internet Protocol", RFC 1108, BBN Communications, November 1991. [全実装でRECOMMENDED] - Next Protocol (from IP header) 外向きのトラフィックのためにSAを選択するための付加的な情報 - Source または(and/or) Destination のTCP/UDPポート 外向きのトラフィックのためにSAを選択するための付加的な情報 - SAのSourceの身元 - SAのDestinationの身元 o SAの選択 - IPSECを利用した通信を行なうために適切なSAを選択する必要がある - 有効なSAまたは鍵が確立されていなければ、このセッションのためのSAまたは 鍵を確立するために、鍵/SA管理プロトコルを使用する。 - 外向きのトラフィックのためのSAを選択するには、以下を使用する。 ホスト senderのユーザID、 Destinationアドレス Next Protocolフィールド Source, Destinationポートフィールド sourceとdestinationの身元 機密ラベル(マルチレベルセキュリティならば) セキュリティゲートウェイ セキュリティゲートウェイは、ユーザID情報へのアクセスを持たない。 Sourceアドレス Next Protocolフィールド Source, Destinationポートフィールド Destinationアドレス (マルチレベルセキュリティにおける機密ラベルが 要求されるならば) - 内向きのトラフィックのSAを選択するには、以下を使用する。 SPI Destinationアドレス o SAの有効期限 - SAの期限が切れた場合、SPIをすぐに再利用するべきではない(SHOULD NOT)。 - SPIの値を、他のSAに使用される前に失効させるべきである(SHOULD)。 マルチキャスト(?) o IPSECはマルチキャストにおいても使用できるよう考慮されている o (?)鍵配送プロトコルは別に議論されている 最近発表されたマルチキャストの鍵配送プロトコルはスケーラビリティがない。 しかし、マニュアル鍵配送は、セキュアなユニキャスト鍵配送プロトコルを 複数回使用することで鍵を配送することが出来る。 o 対称暗号アルゴリズムの使用 - １つのマルチキャストグループへメッセージを送信する複数の送信者は、 そのグループへの全てのトラフィックに対して１つのSA (SPI)を 使用するべきである(SHOULD)。 - 受信側は、どのシステムから送信したのかを認証することができない。 そのマルチキャストグループのSAを知っているシステムから送られてきた メッセージであることだけを知る。 o 非対称暗号アルゴリズムの使用 - 各々の送信者のために分離された１つのSAを、マルチキャストグループに 対して使用するべきである。 - 受信側は、そのメッセージの送信元であるシステムを認証することができる。 o ユーザ指向のマルチキャストグループへ送信される、 情報とコントロールメッセージに対し別々の鍵を使用してもよい。 QoS o リアルタイムサービスにおいても、セキュリティを提供しようとしている マルチレベルセキュリティ - マルチレベルセキュリティを実装しているシステムでは、ユーザＡは少なくとも 機密レベル毎に一つの鍵を形式的に持つ。 - AHは、マルチレベルネットワークでの Mandatory Access Controls (MAC) の決定と、あらゆるネットワークでの Discretionary Access Control(DAC) の決定の両方に、強力な保証を提供するために使用できる。 - 明示的なIPの機密ラベル(e.g., IPSO[Ken91])が使用され、機密性が特定の 動作環境で不必要であると考えらるならば、AHは、機密レベルをIPパケットと ユーザデータに暗号的に結びつけ、全パケットに認証を提供するために 使用される。これは、IPヘッダとユーザデータにラベルを結びつけ、 認証することをしないようなIPv4ネットワークにおいては重要な改善である。 - 通常IPv6では、明示的な機密ラベルを使用するかわりに、各パケットによ って伝達されないSAの一部である暗黙の機密ラベルが使用される。 - 全ての明示的な機密ラベルは、ESPやAH、またはその両方により使用され認証 (MUST)されなければならない。 - ESPは完全なMLSを提供するために、適切な鍵ポリシーと併用することができる。 この場合、各鍵は単一の 機密レベルと区画においてのみ使用しなければなら ない。例えば、鍵"A"は sensitive Unclassified パケットのためだけに使用 されていて、鍵"B"は Secret/Nocompartment トラフィックのためだけに使用 されている。そして、鍵"C"は Secret/No-Foreign トラフィックのためだけに 使用されるとする。この時、保護されたトラフィックの機密レベルは、これら のトラフィックで使用されるSAの機密レベルを支配(MUST NOT)してはならない。 - ESPにおいて、必須のアクセスコントロールは、receivingプロセスの セキュリティレベルや、SAに関連するセキュリティレベルに基づき適用(MUST) されるべきである。それらの必須のアクセスコントロールが失敗するならば、 パケットは廃棄(SHOULD)され、その失敗は実装固有のプロシージャを使って 記録(SHOULD)すべきである。 - SAの機密レベルは、これらのSAに属する鍵の機密レベルを支配(MUST NOT) してはならない。 - 鍵の機密レベルは、SAの機密レベルと同様にすべき(SHOULD)である。 - AHは、これと同じ理由により異なる複数の鍵(パケットの 機密レベルに一部 依存するが)を持つことが出来る。 - IPv4におけるIPSO [ken91] のような明示的な 機密ラベルや、暗黙的な 機密ラベルのどちらかに関連して強力な DAC を提供するために、インター ネット標準の暗号化アルゴリズムは、適切な鍵管理とともに使用される。 - 完全な暗号化は、コンピューティング環境を保護するべきだと判断される時で さえ、マルチレベルコンピュータやcompartmented mode workstations間の全 ての通信のために使用すべき(SHOULD)である。 IPSECアーキテクチャに対する要求事項 o 必須(MUST) - AHと２つのESPのモードをサポートしなければならない - SAの作成と受信が可能でなければならない - セキュリティゲートウェイでのIPパケットフィルタリングの執行 セキュリティゲートウェイを使用している環境において、 これらゲートウェイは、IPSECを使用していると称するシステムからの 許可されていないパケットに対し、アドレスベースの IPパケットフィルタリングを行なわなければならない。 o 奨励(SHOULD) - AHとESPのSAの組合わせを作ることが可能であるべきである - 疑わしい(*)ルーティングヘッダは、受信側により無視されるべきである システムは source routing 攻撃等のような種類の攻撃に弱いものになる であろう。 * 保全性が暗号的に保護されない原因 AHに対する要求事項 o 必須(MUST) - 上位層のプロトコルと協調することを保証しなければならない。 - IPv4でAH使用されていて、さらに中継点での認証が要求されている時には、 PMTUD を使用し、"Don't Fragment"ビットを設定しなければならない。 これは、中継点ではフラグメント化されたパケットの切片を認証することが 出来ないからである。 - IKMPが作るSA情報の論理テーブルを参照できなければならない。 - 暗号的に強力でないチェックサムは、AHでは使ってはならない。 CRCのような旧来のチェックサム等 - IPv6を実装している全てのノードと、AHを実装しているIPv4システムは、 Standards Track である必須のAHトランスフォームを実装しなければ ならない。 現時点では、HMAC-MD5、HMAC-SHAが存在する。 Mike Oehler & Rob Glenn, "HMAC-MD5 IP Authentication with Replay Prevention", Internet Draft, 20 Nov 1996. draft-ietf-ipsec-ah-hmac-md5-04.txt Shu-jen Chang & Rob Glenn, "HMAC-SHA IP Authentication with Replay Prevention", Internet Draft, 20 Nov 1996. draft-ietf-ipsec-ah-hmac-sha-04.txt o 奨励(SHOULD) - AHは送信元から最終のDestinationに使用されるべきである。 セキュリティゲートウェイにおいて、背後に隠れたホストのためにAHを 使用する運用モードは勧められない。 - 暗号的に強力なアルゴリズムだけが、AHで使われるべきである。 一方向性関数など - "Internet Official Protocol Standards" [STD-1]を参照するべきである。 実装者は、現状の必須の情報などのガイダンスのために最新の版を参照 o 許可(MAY) - 必須のトランスフォームに加え、他のAHトランスフォームを実装してもよい。 - 必須のアルゴリズムに加えて、他の認証アルゴリズムをサポートしても良い。 ESPの要求事項 o 必須(MUST) - 上位層のプロトコルと協調することを保証しなければならない。 - ２つのモードにおいて、ネストしたESPのSAをサポートしなければならない。 - IKMPが作るSA情報の論理テーブルを参照できなければならない。 - ESPの有効なトランスフォームは、機密性、保全性、認証を提供 しなければならない。 - IPv6を実装している全てのノードと、ESPを実装しているIPv4システムは、 Standards Track である必須のESPトランスフォームを実装しなければ ならない。 現時点では、DES-CBC, HMAC MD5, Replay Protection を組合せた ESPトランスフォームがある。 J. Hughes (Editor), "Combined DES-CBC, HMAC, and Replay Prevention Security Transform", Internet Draft, Sep 1996. draft-ietf-ipsec-esp-des-md5-03.txt o 奨励(SHOULD) - ESPの有効なトランスフォームは、対リプレイ攻撃を提供するべきである。 - "Internet Official Protocol Standards" [STD-1]を参照するべきである。 実装者は、現状の必須の情報などのガイダンスのために最新の版を参照 o 許可(MAY) - 必須のトランスフォームに加え、他のESPトランスフォームを実装してもよい。 - 必須のアルゴリズムとモードに加えて、他の機密性を提供するアルゴリズムと モードを実装してもよい。 鍵管理/SA管理 o 必須(MUST) - マニュアルの鍵/SA配送方式をサポートしなければならない。 - 全IPv6 IPセキュリティの実装は、ISAKMP/Oakleyを実装しなければならない。 - ２つの終端が与えられた時、これらの間での通信のために、 １つ以上のSAを持たせることが可能でなければならない。 - 適切なSPIを決定することが出来なければならない。 - 全てのSAに対して安全なネゴシエーションを保証しなければならない。 - 全てのSAの属性の識別を可能にしなければならない。 - SAを管理する論理的なテーブルをメンテナンスできなければならない。 - 鍵/SA情報を、許可されていないアクセスから保護しなければならない。 全ての実装は鍵にある。 - ホスト指向性のSAをサポートしなければならない。 - (by draft-arch) マルチユーザホストでは、ユーザまたはセッション指向性のSAのどちらかを サポートしなければならない。 パスワード等による、任意のアクセス制御をしているホスト (by draft-esp) ユーザ指向性の鍵をサポートすべき(SHOULD)である。 ユーザ指向性の鍵が使用されないのならば、選択的平文攻撃に対して弱い いかなる種類のアルゴリズムを使うべきではない(SHOULD NOT)。 - 将来的に実装必須である"Perfect Forward Secrecy"(?)の性質を 提供しなければならない。 - 他のシステムから送信されたIPパケットを暗号化または認証する セキュリティゲートウェイなどのデバイスは、そのトラフィックに対して、 ユーザ指向性鍵を提供しない。そのようなシステムは、セッション独自性鍵 をサポート(MUST)しなければならない。 また、そのようなシステムは、そのトラフィックに対してユーザ指向性鍵の サポートの提供を実装しても良い(MAY)。 o 奨励(SHOULD) - 全IPv4 IPセキュリティの実装は、ISAKMP/Oakleyを実装するべきである。 - IETF's DNSセキュリティワークと互換であるべきである。 - Secure DNSからブートストラップ情報を得ることが出来るべきである。 e.g. 鍵、アドレス 将来的に実装必須。 o 許可(MAY) - 他の鍵管理プロトコルが、実装されても良い。 - SAを設定する他の方法もまたサポートしても良い。 ドキュメント Security Architecture for the Internet Protocol draft-ietf-ipsec-arch-sec-01.txt, 10 November 1996 rfc1825.txt, August 1995, Standards Track The Internet IP Security Domain of Interpretation for ISAKMP draft-ietf-ipsec-ipsec-doi-01.txt, November 15, 1996 ICMP Security Failures Messages draft-simpson-icmp-ipsec-fail-02.txt, April 1996 Others A Simple IP Security API Extension to BSD Sockets draft-mcdonald-simple-ipsec-api-00.txt, 1 November 1996 HMAC: Keyed-Hashing for Message Authentication draft-ietf-ipsec-hmac-md5-01.txt, August 1996 Internet Security Transform Enhancements draft-simpson-ipsec-enhancement-00.txt, April 1996 IP in IP Tunneling rfc1853.txt, October 1995, Informational AH AHの位置 o 中継点で検査されるAH以外のヘッダの後、 中継点で検査されないAH以外のヘッダの前に置かれる。 o AHの直前に置かれるIPv6(v4)ヘッダのNext Header(Protocol field)フィールド には、IANAで割り当てられているプロトコル番号51 が設定される。 o IPv6 - (by draft-arch) FragmentationヘッダやEnd-to-Endヘッダの後、 トランスポートレイヤヘッダの前に置かれる。他のIPヘッダの情報は、 送信元から destination にデータグラムを経路付けるために使用される。 +-------------+--------------------+-------------+--------+----------------+ | IPv6 Header | Fragment/End-to-End| Auth Header | Others | Upper Protocol | +-------------+--------------------+-------------+--------+----------------+ (by draft-ah) Hop-by-HopヘッダとFragmentationヘッダの後、 Destinationオプションの前に置かれる。 +-------------+--------------------+-------------+--------+----------------+ | IPv6 Header | Hop-by-Hop/Routing | Auth Header | Others | Upper Protocol | +-------------+--------------------+-------------+--------+----------------+ - Fragmentationヘッダがパケットに存在したならば、AHはFragmentationヘッダ の前に存在してはならない(MUST NOT)。 - Hop-by-HopヘッダやFragmentationヘッダがパケットに存在しなければ、 AHは、そのようなヘッダには直接続かなくても良い。 o IPv4 - IPv4ヘッダの直後に置かれなければならない(MUST)。 - インラインのIP層鍵管理技術がパケットに使用されるならば、 インラインIP層鍵管理ヘッダのに続く。 - それ以外の場所は無効である。 +-------------+--------------+-------------------------------+ | IPv4 Header | Auth Header | Upper Protocol (e.g TCP, UDP) | +-------------+--------------+-------------------------------+ AHのフォーマット +---------------+---------------+---------------+---------------+ | Next Header | Length | RESERVED | +---------------+---------------+---------------+---------------+ | Security Parameters Index | +---------------+---------------+---------------+---------------+ | | + Authentication Data (variable number of 32-bit words) | | | +---------------+---------------+---------------+---------------+ 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 Next Header 8ビット長。 認証ヘッダの後に続く次のペイロードを識別する。 このフィールドに含まれる値は、"Assigned Numbers"[STD-2] を記述している IANAから出されている最新の RFCに定義されているIPプロトコル番号である。 Payload Length 8ビット長。 32ビット単位で表したAuthentication Dataフィールドの長さ。 最小値は0である。 これは、"null"認証アルゴリズムが用いられた場合にのみありえる。 RESERVED 16ビット長。 今後の使用のために予約されている。 送信時には全て0にセット(MUST)されなければならない。 認証データ計算の対象だが、受信者には無視される。 Security Parameters Index (SPI) 32ビット値。 このデータグラムのSAを識別する。 SPIの値が 0 は、"SAが存在しない"ことを示すために予約されている。 1から255は、今後の使用のために IANAに予約されている。 Authentication Data 32ビット単位長。 このフィールドは可変長であるが、常に32ビットの整数倍である。 全ての実装は境界調整をサポート(MUST)しなければならない。 パフォーマンスの改善のためなどによる。 境界調整の値は、SPI毎のDestinationにより規定されている。 境界調整の値は、Sourceにより勝手に選択され、認証データ計算に含められる。 例えば64ビット。 実装は、DestinationアドレスとSPIを組合せて、 このフィールドのサイズと利用方法を規定しているSAを決定する。 このフィールドの内容の詳細は、各認証トランスフォームの仕様を参照。 実際の認証データを格納するのに、このフィールドが必要以上に長いならば、 未使用ビットは不確定な実装依存の値で満たされる。 AHの送信処理 - 送信するパケットに適用するための適切なSAを選択する。 - 伝送中に変更されるフィールドは、0に置き換えられ認証計算が行なわれる。 - 認証データをAuthentication Data内に置く。 - フラグメントは、外向きのパケットのAHの処理後に起こる。 AHの受信処理 - 送信したパケットに適用する適切なSAを選択する。 - 認証データフィールドと受信したデータパケットが一致していることを検証する。 - リアセンブルは、内向きのパケットのAHの処理前に起こる。 - 検証した結果、受信したデータが無効であるならば、receiverは受信した IPデータグラムを無効とし廃棄しなければならない(MUST)。 システムログまたは監査ログに認証失敗と記録しなければならない(MUST)。 記録されるログデータは、以下の情報を含まねばならない(MUST)。 - SPI - 受信した日付/時間 - 平文のSending/Destinationアドレス - (あるならば)平文のFlow ID これに関する他の情報を含んでもよい(MAY)。 認証計算時に 0 として扱われるフィールド o Authentication Data o IPv4 Type of Service (TOS) Time To Live (TTL) Header Checksum Fragment Offset Flags (identification) オプションヘッダ(IPSOのBSOとESOとCIPSOを除く) (by draft-arch) IPSOのBSOとESO(RFC-1038, RFC-1108)と、ドキュメント化されていない非標準な CIPSO(IPv4オプション番号 134)を除く、オプションヘッダもまた、 0として認証計算が行なわれる。 (by draft-ah) オプションヘッダは認証データ計算のために通常0で置き換えられる。 IPSOは、認証データ計算に含まれる。文書化されていない非標準な CIPSO(IANAより134が割り当てられている。)も同様である。 o IPv6 IP Version Type of Service Flow Label Hop Limit (?)(by draft-ah) 基本ヘッダにおいては、"Hop Limit" フィールドだけが、認証データ 計算時に0として計算される。 IPv6ヘッダの他のフィールドは、認証データ計算の対称にならなければならな い(MUST)。 オプションヘッダは、自身が伝送中に変更されるかどうか(認証データ計算に 含まれるかどうか)を示すビットをOption Typeフィールドの3ビット目に持っ ている。 このビットが 0ならば、該当するオプションは認証データ計算に含められる。 このビットが 1ならば、該当するオプションはそのオプションと同じ長さの 0ビットで置き換えられ計算される。 IPv6 Routingヘッダ "Type 0" は、source からdestinationへの転送中に パケット内のaddressフィールドを組み替える。しかしながら、receiver側に 現れるパケットの内容は、senderと全中継ホップで知られているので、 これは問題ではない。故に、IPv6 Routingヘッダ "Type 0"は、通常手順で 認証データ計算に含められる。 より多くの情報のためには、IPv6の仕様を見よ。 ICMP 一つ特別な問題は、ICMPエラーとなるようなパケットは、ICMPメッセージに適さな いほどに非常に大きな場合があることである。そのような場合、ICMPメッセージの receiverは戻されたICMPメッセージの一部を単独で認証することは不可能である。 これは、そのようなICMPメッセージを受信するホストは、セキュリティ問題を引き 起こす原因となるような未認証のICMPメッセージを信頼するかしないか、つまり、 対応すべきであった正しいICMPメッセージに、適切に反応しないことを意味する。 この問題は、最小MTUと等しいもしくはそれより大きいパケットで、十分解決するこ とができるということは明らかではない。暗号化されたパケットが、ICMPエラーメ ッセージを送信する原因となり、そのパケットが捨てられるならば、同様の複雑さ が発生する。 ドキュメント IP Authentication Header draft-ietf-ipsec-auth-header-00.txt, 4 June 1996 rfc1826.txt, August 1995, Standards Track ESP ESPの位置 - トランポート層プロトコルの最後のヘッダの前、IPヘッダの後方に置かれる。 - 中継点で検査されないAH以外のヘッダの前に置かれる。 - ESPの直前に置かれるIPv6(v4)ヘッダのNext Header(Protocol field)フィールド には、IANAで割り当てられているプロトコル番号50 が設定される。 |<-- Unencrypted -->|<---- Encrypted ------>| +-------------+--------------------+------------+---------------------+ | IP Header | Other IP Headers | ESP Header | encrypted data | +-------------+--------------------+------------+---------------------+ ESPのフォーマット 非暗号化ヘッダとそれに続く暗号化されたデータから構成される。 暗号化されたデータは、ESPヘッダの一部とモードに依存するデータで構成される +---------------+---------------+---------------+---------------+ | Security Parameters Index (SPI) | +===============+===============+===============+===============+ | Opaque Transform Data | +---------------+---------------+---------------+---------------+ 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 Security Parameters Index (SPI) 32ビット値。 このデータグラムのSAを識別する。 SPIの値が 0 は、"SAが存在しない"ことを示すために予約されている。 1から255は、今後の使用のために IANAに予約されている。 Opaque Transform Data 可変長。 暗号化アルゴリズムに柔軟に対応するために設計されている。 ESPの送信処理 - 送信するパケットに適用する適切なSAを選択する。 - 暗号化を行ない、トランスフォームに従いカプセル化を行なう。 - フラグメントは、外向きのパケットのESPの処理後に起こる。 ESPの受信処理 - 平文のIPヘッダやIPオプショナルペイロードを処理する。 - 送信したパケットに適用する適切なSAを選択する。 - 復号化を行ない、ESPからデータを取り出し、 通常のIPプロトコルスペックにより処理される。 - リアセンブルは、内向きのパケットのESPの処理前に起こる。 - セッションの有効なSAが存在しないならば、receiverは暗号化された ESPを廃棄(MUST)しなければならない。 その失敗をシステムログまたは監査ログに記録(MUST)しなければならない。 記録されるログデータは、以下の情報を含まねばならない(SHOULD)。 - SPI - 日付/時間 - 平文のSending/Destinationアドレス - (あるならば)平文のFlow ID 他の識別するためのデータを持たせても(MAY)よい。 - receiverは、この失敗をsenderに知らせると言う対応をとらなくても良い。 denial of service攻撃に利用される可能性がある。 Tunnel-mode o 概要 - 全てのIPデータグラムをESPヘッダの暗号化部にカプセル化する。 - 新たな暗号化されていないIPヘッダが暗号化されたESPの前に置かれる。 - 暗号化されていないIPヘッダの情報は、保護したデータをsourceから destinationへ運ぶためだけに使用される。 - 暗号化されていないIPルーティングヘッダは、 IPヘッダとESPの間に含まれるかもしれない。 o 利点 - サイト間でのVPNを作成するために使用することが出来る。 - フラグメントの可能性等による操作性を容易にする - 必須な実装にすることにより、通信のインターオペラビリティの保証をする。 Transport-mode o 概要 - トランスポート層プロトコルをESP内へカプセル化する。 ICMP含む - 暗号化の対象にならなかったIPヘッダの後に置かれる。 - 両方のホストに直接ESPが実装され、セキュリティゲートウェイの間には何も 存在しない時、このモードを使用してもよい。 o 利点 - 冗長なセキュリティをいくらか減少させることが出来る。 - 必須な実装にすることにより、通信のインターオペラビリティの保証をする。 - 処理コストと両帯域の消費を減らす。 ドキュメント IP Encapsulating Security Payload draft-ietf-ipsec-payload-00.txt, 6 June 1996 rfc1827.txt, August 1995, Standards Track AHとESPの組合せ o 組合せの要求事項 - １つのノードにおいて、１つのIPデータグラムにはESP,AHの両方を適用しない。 - 機密性が要求されないならば、AHが使用されるべきである。 - 機密性が要求されるならば、ESPが使用されるべきである。 - 機密性と認証の両方が必要とされる時は、AHとESPを使用するのではなく、ESPトラ ンスフォームを組み合わせて使用する。 - ESPとAH両方を含むIPパケットは厳密には禁止されない。 VPNがセキュリティゲートウェイにより形成されている時、そのゲートウェイでは パケットを転送する前にESP(またはAH)をそのパケットに適用する。(?) o サポートされなければならない組合せ (MUST) IPSEC準拠ホスト [IP][AH] [IP][ESP(tunnel)] [IP][ESP(transport)] [IP][AH][ESP(tunnel)] [IP][AH][ESP(transport)] [IP][ESP(tunnel)][AH] [IP][ESP(tunnel)][ESP(transport)] [IP][AH][ESP(tunnel)][ESP(transport)] IPSEC準拠セキュリティゲートウェイ [IP][AH] [IP][ESP(tunnel)] [IP][AH][ESP(tunnel)] Transport-mode ESPのSAのサポートは必要としない。 セキュリティゲートウェイに隠れたホストを終端として、 そのゲートウェイを越えて適用される。 ゆえに、このゲートウェイでは、透過的に渡されるそれらSAを処理しない。 o 正しくない組合せ [IP][AH][AH][upper-layer protocol] １つのパケットは、単独のAHを持つべきである。 [IP][ESP][AH][upper-layer protocol] 2に関して、ESPトランスフォーム(e.g. [Hugh96])を使用する o ESPにおいて、AHと使用するべき場合 - 強力な保全性のためのメカニズムが欠けている、DES-CBCトランスフォーム。 cut-and-paste 攻撃に弱いので、AHと共に使用するべきである。 Steven M. Bellovin, Presentation at IP Security Working Group Meeting, Proceedings of the 32nd Internet Engineering Task Force, March 1995, Internet Engineering Task Force, Danvers, MA. - 認証を提供しないトランスフォームを使用する場合 認証すべきデータによりAHの位置がかわる。 o 組合せの例 - 受信した全てのIPデータグラムが認証され、 ESPヘッダの後に送られるデータのみ機密性が保たれる。 送信処理 保護するデータにESPを適用する。 新しい平文のIPヘッダがESPヘッダの前に置かれる。 全IPデータグラムを対象にAHを計算する。 受信処理 AH処理を使用して全IPデータグラムを認証する。 認証に成功するば、ESP処理で復号化を行なう。 復号化に成功すれば、結果であるデータは上位層に渡される。 Transport-mode ESPを使用する場合、AHは ESPヘッダの前に置かれ、 全てのIPデータグラムを対象に計算される。 - ESPにより保護されたデータにのみ認証される。 Tunnel-mode ESPにより保護されるデータ内にAHは置かれる。 o セキュリティ分類レベル (security classification level) - AHが Tunnel-mode ESPヘッダ内にカプセル化された場合 両ヘッダが関連する固有のセキュリティ分類レベルを持ち、さらに、２つの セキュリティ分類レベルが一致しなければ、エラーがとなる。 そのエラーは、ログに記録(SHOULD)すべきである。 - AHが ESPヘッダの外側に置かれた場合 ２つのセキュリティ分類レベルが異なることは、エラーではない。 データが ESPを用いて暗号化された後に、平文のIPヘッダは 異なるセキュリティ分類レベルを持つ可能性があるので有効かもしれない。 トランスフォーム - 新しく追加される暗号化アルゴリズムをサポートするために、 セキュリティプロトコルと分離されている。 - 今後新しいトランスフォームが定義されるかもしれない。 ドキュメント AH HMAC-MD5 IP Authentication with Replay Prevention draft-ietf-ipsec-ah-hmac-md5-04.txt, November 20 1996 HMAC-SHA IP Authentication with Replay Prevention draft-ietf-ipsec-ah-hmac-sha-04.txt, November 20 1996 IP Authentication using Keyed SHA1 with Data Padding draft-simpson-ah-sha-kdp-00.txt, April 1996 ESP Combined 3DES-CBC, HMAC and Replay Prevention Security Transform draft-ietf-ipsec-esp-3des-md5-00.txt, November 1996 Combined 3DES-CBC, LZS Compression, HMAC, and Replay Prevention draft-sabin-esp-des3-lzs-md5-00.txt, October 1996 Combined DES-CBC, HMAC and Replay Prevention Security Transform draft-ietf-ipsec-esp-des-md5-03.txt, September 1996 The ESP Stream Transform draft-caronni-esp-stream-01.txt, September 1996 Compression Payload for Use with IP Security draft-thayer-seccomp-00.txt, July 1996 The DES-CBC plus DES-MAC Security Transform draft-frommer-sec-transform-00.txt, June 1996 The ESP Triple DES Transform draft-simpson-esp-des3-x-00.txt, April 1996 The ESP DES-CBC Transform rfc1829.txt, August 1995 鍵管理/SA管理 鍵管理方式 o マニュアル鍵配送 - 最も単純な方法である。 - スケーラブルでない静的な環境等の小範囲で非常に現実的である。 メールやフロッピディスクの交換 電子的な配送手段以外の方法 o Diffie-Helman方式 (DH) o KDC Key Distribution Center (KDC) o DNSsec - DNSを利用する方法である。 - 非対称鍵暗号アルゴリズムを使用している。 - 他の鍵管理パーティと共に、鍵管理メッセージを、認証することを可能にする。 - 将来的に実装必須となる o マルチキャスト鍵管理方式 - アクティブな研究エリアである。 - 比較的少数メンバーのマルチキャストグループに対しては、 マニュアル鍵配送方式やmodified Diffie-Hellman方式のような既存のユニキ ャスト鍵配送の複合した使用は可能と思われる。 暗号化に用いる鍵の単位 o ホスト指向性 - 鍵をホスト単位で保持する。 与えられたIPアドレスに対して、１つの鍵を割り当てる。 - ２ホスト間のトラフィック全てに同じ鍵を使用する。 ホストＡの全ユーザが、ホストＢの全てのユーザに宛てたトラフィックに 同じ鍵を使用する。 - マルチユーザのホストにおいてユーザ同士、互いに信用している場合。 o ユーザ指向性 - 鍵をユーザ単位で保持する。 与えられたIPアドレスとユーザIDに対して、１つの鍵を割り当てる。 - ホストＡのあるユーザが、ホストＢに宛てたトラフィックに対して、 他のホストとは共有しない１つ以上のユニークな鍵を持つ。 - マルチユーザのホストにおいて、他ユーザが信用できない場合 o セッション指向性 - 鍵をセッション単位で保持する。 与えられたIPアドレス、上位層プロトコル、ポート番号に対して １つの鍵を割り当てるものである。 - 同一ユーザであっても、アプリケーション毎(ソケット毎)に異なるSAを持つ。 あるユーザのFTPセッションは、同ユーザのtelnetセッションと異なる鍵を 使用する。 - (?)適切な動的鍵管理方法と適切なアルゴリズムを用いている時、保全性と機密性 はホスト指向性鍵で提供できる。しかし、エンドシステムのアプリケーション を用いている本人の認証は、アプリケーションを実行しているプロセス自身の SAを要求し使用できることが必要であり、認証を提供する鍵配送機能を使う ことができる。 ドキュメント ISAKMP/Oakley The resolution of ISAKMP with Oakley draft-ietf-ipsec-isakmp-oakley-02.txt, November 1996 ISAKMP Internet Security Association and Key Management Protocol (ISAKMP) draft-ietf-ipsec-isakmp-06.txt, November 22 1996 Inline Keying within the ISAKMP Framework. draft-ietf-ipsec-inline-isakmp-00.txt, November 1996 Oakley The OAKLEY Key Determination Protocol draft-ietf-ipsec-oakley-01.txt, May 1996 SKIP Simple Key-Management For Internet Protocols (SKIP) draft-ietf-ipsec-skip-07.txt, August 14 1996 SKIP Algorithm Discovery Protocol draft-ietf-ipsec-skip-adp-01.txt, August 5 1996 SKIP Extensions for IP Multicast draft-ietf-ipsec-skip-mc-01.txt, August 5 1996 SKIP extension for Perfect Forward Secrecy (PFS) draft-ietf-ipsec-skip-pfs-01.txt, August 5 1995 Encoding of an Unsigned Diffie-Hellman Public Value draft-ietf-ipsec-skip-udh-01.txt, August 1 1996 X.509 Encoding of Diffie-Hellman Public Values draft-ietf-ipsec-skip-x509-01.txt, August 5 1996 Photuris The Photuris Session Key Management Protocol draft-simpson-photuris-11.txt, June 1996 Photuris Schemes and Privacy Protection draft-simpson-photuris-schemes-00.txt, April 1996 GKMP Group Key Management Protocol (GKMP) Specification draft-harney-gkmp-spec-01.txt, June 18 96 Group Key Management Protocol (GKMP) Architecture draft-harney-gkmp-arch-01.txt, June 18 96 Others Key Derivation for Authentication, Integrity, and Privacy draft-horowitz-key-derivation-00.txt, November 1996 Certificate Discovery Protocol draft-ietf-ipsec-cdp-01.txt, June 6 1996 インターフェース PK_KEY 図(?) ドキュメント A Socket Based Key Management API draft-mcdonald-pf-key-v2-00.txt PF_KEY.ps 機密ラベルに関して セキュリティアーキテクチャ - ゲートウェイと外側のdestinationの間に、AHの使用のためのSAを作成する時、信 用したホストからの認識された機密ラベルを含むデータグラムを受信する セキュリティゲートウェイは、そのラベルの値を考慮にいれなければならない (MUST)。そのような環境において、ESPを含むIPパケットを受信するゲートウェイ は、終端のホストである信用したホストへ送信する復号化したパケットのために、 暗黙的ラベル、または明示的ラベル情報を含んでいる、適切な認証を付け加えるべ きである。 - IPセキュリティは、終端間のラベルの保全性をある程度保証するために、明示的な 機密ラベルを含むパケットを、常に使用するべきである。 AH - IPデータグラムに対し機密ラベルを割り当てるために使用することが 出来る。(e.g. IPSO [Kent91]) - AHは、終端間のラベルの保全性を保証するために、明示的な機密ラベルを 含むパケットを、いつも使用するべきである。 - IP Security Architectureドキュメントでより詳しく述べられているように、IPv6 では通常、IPv4で現在使用されている明示的label よりも、暗黙的 Security Label が使われる[Ken91] [Atk95a]。いくつかの状況において、ユーザはAHにより提供さ れる暗黙的labelに加えて、明示的label(e.g. RFC1108に定義されているようなIPSO ラベルは、IPv4で使用されている。)の使用を選択(MAY)できる。 明示的labelオプションは、IPv6と併用することが定義されている。(e.g. IPv6 end-to-endオプションヘッダや IPv6 hop-by-hopオプションヘッダの使用)実装には、 暗黙的labelに加えて明示的labelをサポート(MAY)してもよいが、これは特に必 要ない。明示的labelを使用するならば、これを認証計算に含めなければ(MUST)なら ない。 ESP - ゲートウェイと外側のdestinationの間に、ESPの使用のためのSAを作成/選択する 時、信用したホストからの認識された機密ラベルを含むデータグラムを受 信するセキュリティゲートウェイは、そのラベルの値を考慮にいれるべきである。 そのような環境では、ESPを含むIPパケットを受信するゲートウェイは、終端のホ ストである信用したホストへ送信する復号化したパケットに、適切なラベル付けを するべきである。IPセキュリティは、終端間のラベルの保全性をある程度保証する ために、明示的な機密ラベルを含むパケットを、常に使用するべきである。 - SPI は機密ラベルを示しているので、暗号化されたIPデータグラムは、明 確な Securityラベルを通常は持つ必要がない。これは、Security ラベルを要求し ている Compartmented Modeワークステーションとその他のシステムと共に、明白な 機密ラベルが、通常用いられているIPv4での現行の慣習を改良したものであ る[Ken91] [DIA]。いくつかの状況において、ユーザは ESPにより提供される暗黙の ラベルを使用することに加えて、明白なラベル(e.g. RFC1108で定義されたIPSOラ ベル)の使用を選択(MAY)しても良い。明白なラベルオプションは、IPv6での IPv6 End-to-End Optionヘッダ, IPv6 Hop-by-Hop Optionヘッダ等の使用のために定義さ れるている。実装は、暗黙のラベルに加えて明白なラベルをサポート(MAY)しても良 いが、これは特に必要ない。multi-level セキュリティを提供していることを宣言 するシステムにおけるESPの実装は、暗黙のラベルをサポート(MUST)しなければなら ない。 (?)IPSECの使用の可能性 o ファイアウォールでの使用 - ファイアウォールでのセキュリティを向上させることが出来る。 - トランスポートプロトコルとポート番号を確定するためにヘッダと オプションを解析する必要がある。 - AHの場合は、ファイアウォールと適切なSAに関係なく使用できる。 - ESPの場合、適切なSAと関係しなければ、暗号化されたデータを復号化する ことが出来ないので、パケットフィルタリングやアクセスコントロールに 使われるデータ(Source/Destinationアドレス、プロトコル、ポート番号等)を 検証することが出来ない。 - 組織やキャンパス内、インターネットを利用したリモートシステムの両端では 認証が行われているであろう。 - AHを使用することにより、アクセスコントロールの決定に使われるデータがより 確実である保証を与える。 - プロバイダを使って複数のサイトへ相互接続している組織は、 暗号化ファイアウォールの使用を選ぶ必要があるであろう。 暗号化ファイアウォールが、各サイトとプロバイダ間に設置されると、 それぞれのサイト間で暗号化IPトンネルを提供できる。 これにより、盗聴と変形からトラフィックを保護することが出来る。 - 政府などのような、商用プロバイダ上でVPNを構築するために完全な暗号化が 可能なファイアウォールを利用したいと考える組織もあるであろう。 - そのようなファイアウォールと一般的なIP暗号化デバイスとの違いは、 IPパケットの暗号化と複合化されたトラフィックのフィルタリングが 可能であることである。移動体コンピュータとセキュリティゲートウェイや 暗号化ファイアウォールとの間で、暗号化を使用するべきである。 IPSECの動向 アーキテクチャ o 修正されたアーキテクチャ,ESP,AHがDraft Standardsとして、IESGへ提出された。 ゆくゆくは RFC1825 から draft-ietf-ipsec-arch-sec-01.txt ？ ゆくゆくは RFC1826 から draft-ietf-ipsec-auth-header-00.txt ？ ゆくゆくは RFC1827 から draft-ietf-ipsec-payload-00.txt ？ トランスフォーム o AH IP Authentication using Keyed MD5 rfc1828.txt, Historic, 27 Nov 1996 HMAC-MD5 IP Authentication with Replay Prevention draft-ietf-ipsec-ah-hmac-md5-04.txt, Proposed Standards, 27 Nov 1996 HMAC-SHA IP Authentication with Replay Prevention draft-ietf-ipsec-ah-hmac-sha-04.txt, Proposed Standards, 27 Nov 1996 o ESP The ESP DES-CBC Transform rfc1829.txt, Historic, 06 Dec 1996 Combined DES-CBC, HMAC and Replay Prevention Security Transform draft-ietf-ipsec-esp-des-md5-03.txt, Proposed Standard, 06 Dec 1996 鍵管理 o ISAKMP/Oakley IPv4ではオプション IPv6では必須 http://www.cisco.com/public/library/isakmp.html http://web.mit.edu/network/isakmp o SKIP IPv4ではオプション IPv6ではオプション http://skip.incog.com/ o IKMP Jan 97 Proposed StandardなISAKMP/OakleyベースのIKMPのドラフトが提出される予定。 Jul 97 Draft StandardなIKMPがIESGへ提出される予定。 その他 o S/WAN http://www.rsa.com/rsa/SWAN/ IPSEC標準をベースとした、ファイアウォールやTCP/IPのベンダーらによる VPN相互接続実験。鍵管理ではSKIPがやや有利。 IPSECにおける用語 o コネクションレスな保全性 (Connectionless Integrity) - データが改ザンされずに、送信者から受信者まで送られることを保証すること。 - 改変されたことがわかる場合も含む。 o コネクション指向な保全性 (connection-oriented integrity) - コネクションレスな保全性に加えて、送信されたデータの順序が保証される。 o データ元の認証 (Authentication) - 受信者が受けとったデータの送信元が、実際に送信した者であるということを 保証すること。 - 通常は保全性サービス、特にコネクションレスの保全性と併用される。 o 対リプレイ攻撃 (anti-replay) - 重複してたり、古くなったデータユニットを探し出し、拒絶すること。 o 機密性 (Confidentiality) - データの内容について、正規の受信者は知ることができるが、 認められていない者には知ることの出来ないデータ通信を保証すること。 o トラフィックフローの機密性 - 外側に見ることの出来る通信の特質に対して、機密性を保証する Source/Destination識別子,メッセージ長,通信の頻度など。 o 暗号化 (Encryption) - 機密性を提供するために一般に使われるメカニズム o 否認防止 (Non-repudiation) - 通信の参加者が、あとで通信に参加していたことを否定出来ないこと - この特質は、データの送信者と受信者のどちらか、または両方に適用される o セキュリティゲートウェイ (Security Gateway) - 信用されていない外部ネットワークと、信用された内部のホストやサブネット ワーク間の通信インターフェイスとして振舞うシステム。 - 内部のサブネットやホストは、共通またはローカルのセキュリティ管理ポリシー により信用されたセキュリティゲートウェイによりサービスを受ける。 - セキュリティゲートウェイに実装されているのはAHとESPである o トラフィック分析 (Traffic Analysis) - 盗聴者にとって有益な情報を抽出するためにネットワークの トラフィックフローの分析。 - 転送頻度や会話中のパーティーの識別、パケットサイズ、 使用されているフロー識別子等があげられる。 Bruce Schneier, Applied Cryptography, Section 8.6, John Wiley & Sons, New York, NY, 1994. o 信用されたネットワーク (Trusted Subnetwork) - 以下の条件を踏まえたネットワーク 悪意を持った者がいない 意図していなくとも攻撃に関与する者がいない 全ての層において攻撃が存在しない Changed draft-ietf-ipsec-esp-des-cbc-04.txt: replaced by rfc1829.txt draft-zorn-yaap-00.txt: deleted draft-rogaway-ipsec-comments-00.txt: deleted draft-ietf-ipsec-cbc-encrypt-00.txt: replaced by draft-rogaway-cbc-encrypt-00.txt draft-rogaway-cbc-encrypt-00.txt: deleted draft-ietf-ipsec-aziz-skip-01.txt: replaced by draft-aziz-skip-01.txt draft-aziz-skip-01.txt: deleted draft-ietf-ipsec-dss-cert-00.txt: deleted draft-ietf-ipsec-icmp-fail-01.txt: replaced by draft-simpson-icmp-ipsec-fail-02.txt draft-krawczyk-keyed-md5-01.txt: replaced by draft-ietf-ipsec-hmac-md5-00.txt draft-ietf-ipsec-photuris-09.txt: replaced by draft-simpson-photuris-11.txt, June 1996 draft-ietf-ipsec-photuris-attrib-01.txt: replaced by draft-ietf-ipsec-photuris-ext-01.txt draft-ietf-ipsec-photuris-ext-01.txt: deleted draft-ietf-ipsec-arch-02.txt: replaced by rfc1825.txt, August 1995 draft-ietf-ipsec-auth-02.txt: replaced by rfc1826.txt, August 1995 draft-ietf-ipsec-esp-01.txt: replaced by rfc1827.txt, August 1995