Network Working Group D. McDonald Request for Comments: 2367 C. Metz Category: Informational B. Phan July 1998 PF_KEY Key Management API, Version 2 PF_KEY 鍵管理 API, Version 2 Status of this Memo このメモの位置づけ This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. このメモは、Internet community のための情報を提供する。これは、 どんな 種類の Internet 標準を規定するものではない。このメモの配布は、無制限で ある。 ------------------------------------------------------------------------- Copyright Notice 著作権表示 Copyright (C) The Internet Society (1998). All Rights Reserved. ------------------------------------------------------------------------- Abstract 要約 A generic key management API that can be used not only for IP Security [Atk95a] [Atk95b] [Atk95c] but also for other network security services is presented in this document. Version 1 of this API was implemented inside 4.4-Lite BSD as part of the U. S. Naval Research Laboratory's freely distributable and usable IPv6 and IPsec implementation[AMPMC96]. It is documented here for the benefit of others who might also adopt and use the API, thus providing increased portability of key management applications (e.g. a manual keying application, an ISAKMP daemon, a GKMP daemon [HM97a][HM97b], a Photuris daemon, or a SKIP certificate discovery protocol daemon). 一般的な鍵管理 API、それは IP Security [Atk95a] [Atk95b] [Atk95c] のた めだけでなく、他のネットワークサービスにもまた使用されることができる API が、この文書で示される。この API の version 1 は、U. S. Naval Research Laboratory の自由に配布できて使用できる IPv6 と IPsec 実装 [AMPMC96] の一部分として 4.4-Lite BSD 内部に実装された。この API も採 用し使用するかもしれない他のプロトコルの利益について、ここで文章で説明 される。したがって鍵管理アプリケーション (たとえば手動鍵設定アプリケー ション、ISAKMP デーモン、GKMP デーモン [HM97a][HM97b]、Photuris デーモ ン、もしくは SKIP 証明書探索プロトコルデーモン) の増加されるポータビリ ティを提供している。 ------------------------------------------------------------------------- Table of Contents 目次 1 Introduction ............................................. 3 1.1 Terminology .............................................. 3 1.2 Conceptual Model ......................................... 4 1.3 PF_KEY Socket Definition ................................. 8 1.4 Overview of PF_KEY Messaging Behavior .................... 8 1.5 Common PF_KEY Operations ................................. 9 1.6 Differences Between PF_KEY and PF_ROUTE .................. 10 1.7 Name Space ............................................... 11 1.8 On Manual Keying ..........................................11 2 PF_KEY Message Format .................................... 11 2.1 Base Message Header Format ............................... 12 2.2 Alignment of Headers and Extension Headers ............... 14 2.3 Additional Message Fields ................................ 14 2.3.1 Association Extension .................................... 15 2.3.2 Lifetime Extension ....................................... 16 2.3.3 Address Extension ........................................ 18 2.3.4 Key Extension ............................................ 19 2.3.5 Identity Extension ....................................... 21 2.3.6 Sensitivity Extension .................................... 21 2.3.7 Proposal Extension ....................................... 22 2.3.8 Supported Algorithms Extension ........................... 25 2.3.9 SPI Range Extension ...................................... 26 2.4 Illustration of Message Layout ........................... 27 3 Symbolic Names ........................................... 30 3.1 Message Types ............................................ 31 3.1.1 SADB_GETSPI .............................................. 32 3.1.2 SADB_UPDATE .............................................. 33 3.1.3 SADB_ADD ................................................. 34 3.1.4 SADB_DELETE .............................................. 35 3.1.5 SADB_GET ................................................. 36 3.1.6 SADB_ACQUIRE ............................................. 36 3.1.7 SADB_REGISTER ............................................ 38 3.1.8 SADB_EXPIRE .............................................. 39 3.1.9 SADB_FLUSH ............................................... 40 3.1.10 SADB_DUMP ................................................ 40 3.2 Security Association Flags ............................... 41 3.3 Security Association States .............................. 41 3.4 Security Association Types ............................... 41 3.5 Algorithm Types .......................................... 42 3.6 Extension Header Values .................................. 43 3.7 Identity Extension Values ................................ 44 3.8 Sensitivity Extension Values ............................. 45 3.9 Proposal Extension Values ................................ 45 4 Future Directions ........................................ 45 5 Examples ................................................. 45 5.1 Simple IP Security Example ............................... 46 5.2 Proxy IP Security Example ................................ 47 5.3 OSPF Security Example .................................... 50 5.4 Miscellaneous ............................................ 50 6 Security Considerations .................................. 51 Acknowledgments ............,............................. 52 References ............................................... 52 Disclaimer ............................................... 54 Authors' Addresses ....................................... 54 A Promiscuous Send/Receive Extension ....................... 55 B Passive Change Message Extension ......................... 57 C Key Management Private Data Extension .................... 58 D Sample Header File ....................................... 59 E Change Log ............................................... 64 F Full Copyright Statement ................................. 68 1 序論 ..................................................... 3 1.1 用語 ..................................................... 3 1.2 概念上のモデル ........................................... 4 1.3 PF_KEY ソケット定義 ...................................... 8 1.4 PF_KEY メッセージ動作の概観 .............................. 8 1.5 共通の PF_KEY 操作 ....................................... 9 1.6 PF_KEY と PF_ROUTE との違い .............................. 10 1.7 名前空間 ................................................. 11 1.8 手動鍵設定について ....................................... 11 2 PF_KEY メッセージ形式 .................................... 11 2.1 基本メッセージヘッダ形式 ................................. 12 2.2 ヘッダと拡張ヘッダのアライメント ......................... 14 2.3 追加のメッセージフィールド ............................... 14 2.3.1 アソシエーション拡張 ..................................... 15 2.3.2 生存時間拡張 ............................................. 16 2.3.3 アドレス拡張 ............................................. 18 2.3.4 鍵拡張 ................................................... 19 2.3.5 身元拡張 ................................................. 21 2.3.6 感度拡張 ................................................. 21 2.3.7 提案拡張 ................................................. 22 2.3.8 サポートされるアルゴリズム拡張 ........................... 25 2.3.9 SPI 範囲拡張 ............................................. 26 2.4 メッセージレイアウトの実例 ............................... 27 3 記号による名前 ........................................... 30 3.1 メッセージタイプ ......................................... 31 3.1.1 SADB_GETSPI メッセージ ................................... 32 3.1.2 SADB_UPDATE メッセージ ................................... 33 3.1.3 SADB_ADD メッセージ ...................................... 34 3.1.4 SADB_DELETE メッセージ ................................... 35 3.1.5 SADB_GET メッセージ ...................................... 36 3.1.6 SADB_ACQUIRE メッセージ .................................. 36 3.1.7 SADB_REGISTER メッセージ ................................. 38 3.1.8 SADB_EXPIRE メッセージ ................................... 39 3.1.9 SADB_FLUSH メッセージ .................................... 40 3.1.10 SADB_DUMP メッセージ ..................................... 40 3.2 セキュリティアソシエーションフラグ ....................... 41 3.3 セキュリティアソシエーション状態 ......................... 41 3.4 セキュリティアソシエーションタイプ ....................... 41 3.5 アルゴリズムタイプ ....................................... 42 3.6 拡張ヘッダ値 ............................................. 43 3.7 身元拡張値 ............................................... 44 3.8 感度拡張値 ............................................... 45 3.9 提案拡張値 ............................................... 45 4 将来の方向 ............................................... 45 5 例 ....................................................... 45 5.1 シンプルな IP セキュリティ例 ............................. 46 5.2 プロクシ IP セキュリティ例 ............................... 47 5.3 OSPF セキュリティ例 ...................................... 50 5.4 その他 ................................................... 50 6 セキュリティに関する考察 ................................. 51 謝辞 ..................................................... 52 参考文献 ................................................. 52 否認声明書 ............................................... 54 著者のアドレス ........................................... 54 A 無差別送受信拡張 ......................................... 55 B 受動的な変更メッセージ拡張 ............................... 57 C 鍵管理非公開データ拡張 ................................... 58 D サンプルヘッダファイル ................................... 59 E 変更ログ ................................................. 64 F 著作権表示全文 ........................................... 68 ------------------------------------------------------------------------- 1 Introduction 1 序論 PF_KEY is a new socket protocol family used by trusted privileged key management applications to communicate with an operating system's key management internals (referred to here as the "Key Engine" or the Security Association Database (SADB)). The Key Engine and its structures incorporate the required security attributes for a session and are instances of the "Security Association" (SA) concept described in [Atk95a]. The names PF_KEY and Key Engine thus refer to more than cryptographic keys and are retained for consistency with the traditional phrase, "Key Management". PF_KEY は、("Key Engine (鍵エンジン)" もしくは Security Association Database (SADB) としてここで参照される) オペレーティングシステムの鍵管 理内部と通信するため、信頼され特権ある鍵管理アプリケーションにより使用 される、新しいソケットプロトコルファミリである。Key Engine とその構造 は、セッションのために必要とされるセキュリティ属性を取り入れ、[Atk95a] で記述される "Security Association" (SA) 概念のインスタンスである。 PF_KEY と Key Engine の名称は、暗号学鍵以上のことを指していて、伝統的 なフレーズ "Key Management (鍵管理)" で一貫性のために保持される。 PF_KEY is derived in part from the BSD routing socket, PF_ROUTE. [Skl91] This document describes Version 2 of PF_KEY. Version 1 was implemented in the first five alpha test versions of the NRL IPv6+IPsec Software Distribution for 4.4-Lite BSD UNIX and the Cisco ISAKMP/Oakley key management daemon. Version 2 extends and refines this interface. Theoretically, the messages defined in this document could be used in a non-socket context (e.g. between two directly communicating user-level processes), but this document will not discuss in detail such possibilities. PF_KEY は、BSD 経路制御 socket, PF_ROUTE [Skl91] から一部分、派生され ている。この文書は、PF_KEY の Version 2 を記述する。Version 1 は、 4.4-Lite BSD UNIX のために NRL IPv6+IPsec Software Distribution と Cisco ISAKMP/Oakley 鍵管理デーモンの 5 つの alpha テストバージョンで実 装された。Version 2 は、このインターフェイスを拡張し、洗練する。理論的 に、この文書で定義されたメッセージは、socket でない環境 (たとえば、直 接通信している 2 つのユーザレベルのプロセス) で使用されることができる が、この文書はそのような可能性を詳細に論じない。 Security policy is deliberately omitted from this interface. PF_KEY is not a mechanism for tuning systemwide security policy, nor is it intended to enforce any sort of key management policy. The developers of PF_KEY believe that it is important to separate security mechanisms (such as PF_KEY) from security policies. This permits a single mechanism to more easily support multiple policies. セキュリティポリシーは、このインターフェイスから慎重に省略された。 PF_KEY は、調整したシステムワイドなセキュリティポリシーのためのメカニ ズムではなく、いかなる種類の鍵管理ポリシーを守らせるつもりでもない。 PF_KEY の開発者は、これがセキュリティポリシーから (PF_KEY のような) セ キュリティメカニズムを分離することは重要だと考えている。これは、たった 1 つのメカニズムが多くの複数のポリシーを、より容易にサポートすることを 許す。 1.1 Terminology 1.1 用語 Even though this document is not intended to be an actual Internet standard, the words that are used to define the significance of particular features of this interface are usually capitalized. Some of these words, including MUST, MAY, and SHOULD, are detailed in [Bra97]. たとえ、この文書が実際の Internet 標準であることが意図されなくても、こ のインターフェイスの特定の特徴の重要性を定義するために使用される単語は 通例大文字で書かれる。MUST, MAY と SHOULD を含む、これらの単語の一部は [Bra97] で詳しく述べられる。 - CONFORMANCE and COMPLIANCE - 準拠と仕様への対応 Conformance to this specification has the same meaning as compliance to this specification. In either case, the mandatory-to-implement, or MUST, items MUST be fully implemented as specified here. If any mandatory item is not implemented as specified here, that implementation is not conforming and not compliant with this specification. この仕様への準拠は、この仕様に対応するものとして同じ意味を持つ。どちら かのケースで、mandatory-to-implement (実装への強制) は、ここで指定され たとして、すべて実装されるか、実装されなければならない (MUST)。アイテ ムも (同様に) 実装されなければならない (MUST)。もし何らかの強制的なア イテムがここで指定されたように実装されないなら、その実装は、この仕様に 準拠していなく対応していない。 This specification also uses many terms that are commonly used in the context of network security. Other documents provide more definitions and background information on these [VK83, HA94, Atk95a]. Two terms deserve special mention: この仕様書は、ネットワークセキュリティの環境で一般的に使用される多くの 用語も使用する。その他の文書は、[VK83, HA94, Atk95a] で、より多くの定 義と背景情報を提供する。2 つの用語は、特別な言及に値する。 - (Encryption/Authentication) Algorithm - (暗号化/認証) アルゴリズム For PF_KEY purposes, an algorithm, whether encryption or authentication, is the set of operations performed on a packet to complete authentication or encryption as indicated by the SA type. A PF_KEY algorithm MAY consist of more than one cryptographic algorithm. Another possibility is that the same basic cryptographic algorithm may be applied with different modes of operation or some other implementation difference. These differences, henceforth called _algorithm differentiators_, distinguish between different PF_KEY algorithms, and options to the same algorithm. Algorithm differentiators will often cause fundamentally different security properties. PF_KEY の目的のために、暗号化や認証であろうと、1 つのアルゴリズムは、 SA タイプにより指し示されるとして、認証や暗号化を仕上げるためにパケッ トでおこなわれる演算のセットである。PF_KEY アルゴリズムは、1 つの暗号 学アルゴリズム以上からなるかもしれない (MAY)。他の可能性は、同じ基本的 なアルゴリズムが演算の異なったモードか、一部の実装相違で適用されるかも しれないことである。これらの相違は、今後 _algorithm differentiators_ (アルゴリズム区別) と呼び、異なった PF_KEY アルゴリズムとその同じアル ゴリズムへのオプションとを見分ける。algorithm differentiators は、根本 的に異なったセキュリティプロパティを、しばしば引き起こすだろう。 For example, both DES and 3DES use the same cryptographic algorithm, but they are used differently and have different security properties. The triple-application of DES is considered an algorithm differentiator. There are therefore separate PF_KEY algorithms for DES and 3DES. Keyed-MD5 and HMAC-MD5 use the same hash function, but construct their message authentication codes differently. The use of HMAC is an algorithm differentiator. DES-ECB and DES-CBC are the same cryptographic algorithm, but use a different mode. Mode (e.g., chaining vs. code-book) is an algorithm differentiator. Blowfish with a 128-bit key, however, is similar to Blowfish with a 384-bit key, because the algorithm's workings are otherwise the same and therefore the key length is not an algorithm differentiator. たとえば DES と 3DES 両方は、同じ暗号学アルゴリズムを使用するが、それ らは異なって使用され、異なったセキュリティプロパティを持つ。DES の triple 適用は、algorithm differentiator と考えられる。それゆえ DES と 3DES のために、別々の PF_KEY アルゴリズムがある。Keyed-MD5 と HMAC-MD5 は、同じハッシュ関数を使用するが、それらのメッセージ認証コードは異なっ て構成する。HMAC の使用は、algorithm differentiator である。DES-ECB と DES-CBC は、同じ暗号学アルゴリズムであるが、異なったモードを使用する。 モード (たとえば、chaining vs. code-book) は、algorithm differentiator である。しかしながら、128-bit 鍵の Blowfish は、384-bit 鍵の Blowfish と同じようである。なぜならアルゴリズムのはたらきは鍵長以外の点では同じ であり、それゆえ鍵長は algorithm differentiator ではないからである。 In terms of IP Security, a general rule of thumb is that whatever might be labeled the "encryption" part of an ESP transform is probably a PF_KEY encryption algorithm. Whatever might be labelled the "authentication" part of an AH or ESP transform is probably a PF_KEY authentication algorithm. IP Security の用語で、一般的な経験的方法は、ESP 変換の "encryption (暗 号化)" 部分にラベルされるかもしれないものはみな、たぶん PF_KEY 暗号化 アルゴリズムであるといえる。AH や ESP 変換の "authentication (認証)" 部分にラベルされるかもしれないものはみな、たぶん PF_KEY 認証アルゴリズ ムである。 1.2 Conceptual Model 1.2 概念上のモデル This section describes the conceptual model of an operating system that implements the PF_KEY key management application programming interface. This section is intended to provide background material useful to understand the rest of this document. Presentation of this conceptual model does not constrain a PF_KEY implementation to strictly adhere to the conceptual components discussed in this subsection. このセクションは、PF_KEY 鍵管理アプリケーションプログラミングインター フェイスを実装するオペレーティングシステムの概念上のモデルを記述する。 このセクションは、この文書の残りを理解するために有用な背景材料を提供す るつもりである。この概念上のモデルの紹介は、PF_KEY 実装に、このサブセ クションで議論される概念上の構成要素を厳密に固執させない。 Key management is most commonly implemented in whole or in part at the application layer. For example, the ISAKMP/Oakley, GKMP, and Photuris proposals for IPsec key management are all application-layer protocols. Manual keying is also done at the application layer. Even parts of the SKIP IP-layer keying proposal can be implemented at the application layer. Figure 1 shows the relationship between a Key Management daemon and PF_KEY. Key management daemons use PF_KEY to communicate with the Key Engine and use PF_INET (or PF_INET6 in the case of IPv6) to communicate, via the network, with a remote key management entity. 鍵管理は、アプリケーション層で全体または一部分に、最も一般的に実装され る。たとえば、IPsec 鍵管理のための ISAKMP/Oakley, GKMP と Photuris 提 案は、すべてアプリケーション層プロトコルである。手動鍵設定もまた、アプ リケーション層でおこなわれる。SKIP IP 層鍵設定提案の一部分でさえ、アプ リケーション層で実装されることができる。図 1 は、Key Management デーモ ンと PF_KEY 間の関係を示す。鍵管理デーモンは、Key Engine と通信するた めに PF_KEY を使用し、ネットワーク経由でリモート鍵管理エンティティと通 信するために PF_INET (または IPv6 のケースで PF_INET6) を使用する。 The "Key Engine" or "Security Association Database (SADB)" is a logical entity in the kernel that stores, updates, and deletes Security Association data for various security protocols. There are logical interfaces within the kernel (e.g. getassocbyspi(), getassocbysocket()) that security protocols inside the kernel (e.g. IP Security, aka IPsec) use to request and obtain Security Associations. "Key Engine (鍵エンジン)" や "Security Association Database (セキュリ ティアソシエーションデータベース) (SADB)" は、さまざまなセキュリティプ ロトコルのために、Security Association データを格納したり、更新したり 削除するカーネル内での論理的なエンティティである。kernel 内部のセキュ リティプロトコル (たとえば IP Security, 別名 IPsec) が Security Association を要求したり得るために使用する kernel 内の論理的なインター フェイス (たとえば getassocbyspi(), getassocbysocket()) がある。 In the case of IPsec, if by policy a particular outbound packet needs processing, then the IPsec implementation requests an appropriate Security Association from the Key Engine via the kernel-internal interface. If the Key Engine has an appropriate SA, it allocates the SA to this session (marking it as used) and returns the SA to the IPsec implementation for use. If the Key Engine has no such SA but a key management application has previously indicated (via a PF_KEY SADB_REGISTER message) that it can obtain such SAs, then the Key Engine requests that such an SA be created (via a PF_KEY SADB_ACQUIRE message). When the key management daemon creates a new SA, it places it into the Key Engine for future use. IPsec のケースで、もしポリシーにより特定の外向けのパケットが処理を必要 とするなら、それから IPsec 実装は kernel 内部のインターフェイス経由で Key Engine から適した Security Association を要求する。もし Key Engine が適した SA を持つなら、Key Engine は、このセッションにその SA を割り 当て (使用されたとしてマークし)、使用のために IPsec 実装にその SA を返 す。もし Key Engine がそのような SA を持っていないが、鍵管理アプリケー ションが (PF_KEY SADB_REGISTER メッセージ経由で) そのような SAs を得る ことができることを以前に指し示しているなら、それから Key Engine は (PF_KEY SADB_ACQUIRE メッセージ経由で) そのような SA が作り出されるこ とを要求する。鍵管理デーモンが新しい SA を作り出す時、将来の使用のため に、その SA を Key Engine に置く。 +---------------+ |Key Mgmt Daemon| +---------------+ | | | | | | Applications ======[PF_KEY]====[PF_INET]========================== | | OS Kernel +------------+ +-----------------+ | Key Engine | | TCP/IP, | | or SADB |---| including IPsec | +------------+ | | +-----------------+ | +-----------+ | Network | | Interface | +-----------+ Figure 1: Relationship of Key Mgmt to PF_KEY +----------------+ | 鍵管理デーモン | +----------------+ | | | | | | アプリケーション =======[PF_KEY]====[PF_INET]============================== | | OS カーネル +-------------+ +-----------------+ | 鍵エンジン | | TCP/IP, | | または SADB |---| IPsec を含む | +-------------+ | | +-----------------+ | +------------------+ | ネットワーク | | インターフェイス | +------------------+ 図 1: PF_KEY への鍵管理の関係 For performance reasons, some security protocols (e.g. IP Security) are usually implemented inside the operating system kernel. Other security protocols (e.g. OSPFv2 Cryptographic Authentication) are implemented in trusted privileged applications outside the kernel. Figure 2 shows a trusted, privileged routing daemon using PF_INET to communicate routing information with a remote routing daemon and using PF_KEY to request, obtain, and delete Security Associations used with a routing protocol. パフォーマンス理由のために、一部のセキュリティプロトコル (たとえば IP Security) は、オペレーティングシステム kernel 内部に、たいてい実装され る。他のセキュリティプロトコル (たとえば OSPFv2 暗号学認証) は、kernel 外側の信頼された特権あるアプリケーションに実装される。図 2 は、遠隔経 路制御デーモンと経路制御情報を通信するために PF_INET を使用し、そして 経路制御プロトコルで使用される Security Associations を要求、獲得、削 除するために PF_KEY を使用する、信頼された特権ある経路制御デーモンを示 す。 +---------------+ |Routing Daemon| +---------------+ | | | | | | Applications ======[PF_KEY]====[PF_INET]========================== | | OS Kernel +------------+ +---------+ | Key Engine | | TCP/IP | | or SADB |---| | +------------+ +---------+ | +-----------+ | Network | | Interface | +-----------+ Figure 2: Relationship of Trusted Application to PF_KEY +------------------+ | 経路制御デーモン | +------------------+ | | | | | | アプリケーション ======[PF_KEY]====[PF_INET]============================== | | OS カーネル +-------------+ +---------+ | 鍵エンジン | | TCP/IP | | または SADB |---| | +-------------+ +---------+ | +------------------+ | ネットワーク | | インターフェイス | +------------------+ 図 2: PF_KEY への信頼されたアプリケーションの関係 When a trusted privileged application is using the Key Engine but implements the security protocol within itself, then operation varies slightly. In this case, the application needing an SA sends a PF_KEY SADB_ACQUIRE message down to the Key Engine, which then either returns an error or sends a similar SADB_ACQUIRE message up to one or more key management applications capable of creating such SAs. As before, the key management daemon stores the SA into the Key Engine. Then, the trusted privileged application uses an SADB_GET message to obtain the SA from the Key Engine. 信頼され特権あるアプリケーションが Ken Engine を使用しているが、それ自 身内部にセキュリティプロトコルを実装する時、オペレーションは少しばかり 変わる。このケースで、SA を必要とするアプリケーションは、Key Engine に 下へと PF_KEY SADB_ACQUIRE メッセージを送信し、それからエラーを返すか そのような SAs を作り出すことができる 1 つか多くの鍵管理アプリケーショ ンへと上に同様な SADB_ACQUIRE メッセージを送信する。それより前に、鍵管 理デーモンは SA を Key Engine に格納する。それから信頼され特権あるアプ リケーションは、Key Engine から SA を得るために SADB_GET メッセージを 使用する。 In some implementations, policy may be implemented in user-space, even though the actual cryptographic processing takes place in the kernel. Such policy communication between the kernel mechanisms and the user-space policy MAY be implemented by PF_KEY extensions, or other such mechanism. This document does not specify such extensions. A PF_KEY implementation specified by the memo does NOT have to support configuring systemwide policy using PF_KEY. 一部の実装で、たとえ実際の暗号学処理が kernel 内部に置くとしても、ポリ シーはユーザ空間に実装されるかもしれない。kernel メカニズムとユーザ空 間ポリシー間のそのようなポリシー通信は、PF_KEY 拡張か、他のそのような メカニズムにより実装されるかもしれない (MAY)。この文書は、そのような拡 張を特定しない。このメモにより特定される PF_KEY 実装は、PF_KEY を使用 して構成しているシステムワイドなポリシーをサポートしなければならないこ とはない (NOT)。 Untrusted clients, for example a user's web browser or telnet client, do not need to use PF_KEY. Mechanisms not specified here are used by such untrusted client applications to request security services (e.g. IPsec) from an operating system. For security reasons, only trusted, privileged applications are permitted to open a PF_KEY socket. 信頼されないクライアント、たとえばユーザの web browser や telnet クラ イアントは、PF_KEY を使用する必要はない。ここで特定されないメカニズム は、オペレーティングシステムからセキュリティサービス (たとえば IPsec) を要求するために、そのような信頼されないクライアントにより使用される。 セキュリティ理由のために、信頼され特権あるアプリケーションのみが、 PF_KEY socket を開くことを許される。 1.3 PF_KEY Socket Definition 1.3 PF_KEY ソケット定義 The PF_KEY protocol family (PF_KEY) symbol is defined in in the same manner that other protocol families are defined. PF_KEY does not use any socket addresses. Applications using PF_KEY MUST NOT depend on the availability of a symbol named AF_KEY, but kernel implementations are encouraged to define that symbol for completeness. PF_KEY プロトコルファミリ (PF_KEY) シンボルは、他のプロトコルファミリ が定義される同じ方式で、 で定義される。PF_KEY は、どんな socket アドレスも使用しない。PF_KEY を使用するアプリケーションは、 AF_INET と名付けられたシンボルの有用性に決して依存してはならない (MUST NOT)。しかし kernel 実装は、完全のためにそのシンボルを定義するこ とが奨励される。 The key management socket is created as follows: 鍵管理ソケットは、次のようにして作り出される: #include #include #include int s; s = socket(PF_KEY, SOCK_RAW, PF_KEY_V2); The PF_KEY domain currently supports only the SOCK_RAW socket type. The protocol field MUST be set to PF_KEY_V2, or else EPROTONOSUPPORT will be returned. Only a trusted, privileged process can create a PF_KEY socket. On conventional UNIX systems, a privileged process is a process with an effective userid of zero. On non-MLS proprietary operating systems, the notion of a "privileged process" is implementation-defined. On Compartmented Mode Workstations (CMWs) or other systems that claim to provide Multi-Level Security (MLS), a process MUST have the "key management privilege" in order to open a PF_KEY socket[DIA]. MLS systems that don't currently have such a specific privilege MUST add that special privilege and enforce it with PF_KEY in order to comply and conform with this specification. Some systems, most notably some popular personal computers, do not have the concept of an unprivileged user. These systems SHOULD take steps to restrict the programs allowed to access the PF_KEY API. PF_KEY ドメインは、SOCK_RAW socket タイプのみを現在サポートする。プロ トコルフィールドは、PF_KEY_V2 にセットされなければならなく (MUST)、さ もないと EPROTONOSUPPORT が返されるだろう。信頼され特権あるプロセスの みが、PF_KEY socket を作り出すことができる。伝統的な UNIX システムで、 特権あるプロセスは、有効な値ゼロの userid を持つプロセスである。MLS で ない所有者のオペレーティングシステムで、"privileged process" の概念は 実装定義である。Multi-Level Security (MLS) を提供することを要求する Compartmented Mode Workstations (CMWs) や他のシステムで、プロセスは PF_KEY socket[DIA] を開くため "key management privilege (鍵管理特権)" を持たなければならない (MUST)。そのような特定の特権を現在持たない MLS システムは、その特別の特権を追加しなければならなく (MUST)、この仕様に 準拠し対応するため、PF_KEY でその特権を守らせなければならない (MUST)。 一部のシステム、最も特に一部の人気のあるパーソナルコンピュータは、特権 のないユーザの概念を持たない。これらのシステムは、PF_KEY API をアクセ スすることを許可されるプログラムを制限するためのステップを取るべきであ る (SHOULD)。 1.4 Overview of PF_KEY Messaging Behavior 1.4 PF_KEY メッセージ動作の概観 A process interacts with the key engine by sending and receiving messages using the PF_KEY socket. Security association information can be inserted into and retrieved from the kernel's security association table using a set of predefined messages. In the normal case, all properly-formed messages sent to the kernel are returned to all open PF_KEY sockets, including the sender. Improperly formed messages will result in errors, and an implementation MUST check for a properly formed message before returning it to the appropriate listeners. Unlike the routing socket, most errors are sent in reply messages, not the errno field when write() or send() fails. PF_KEY message delivery is not guaranteed, especially in cases where kernel or socket buffers are exhausted and messages are dropped. プロセスは、PF_KEY socket を使用するメッセージを送受信することにより、 鍵エンジンと相互に影響する。セキュリティアソシエーション情報は、前に定 義されたメッセージセットを使用する kernel のセキュリティアソシエーショ ンテーブルに挿入され、検索されることができる。普通のケースで、kernel に送信されるすべての厳密に構成されたメッセージは、送信者を含む、すべて の開いた PF_KEY sockets に返される。不正確に構成されたメッセージは、エ ラーという結果になるだろうし、適したリスナーにそれを返す前に、厳密に構 成されたメッセージをチェックしなければならない (MUST)。経路制御 socket と違い、write() や send() が失敗した時、大部分のエラーは errno フィー ルドではなく、リプライメッセージで送信される。PF_KEY メッセージ配送は kernel や socket バッファが使い果たされメッセージが落されるようなケー スで、特に保証されない。 Some messages are generated by the operating system to indicate that actions need to be taken, and are not necessarily in response to any message sent down by the user. Such messages are not received by all PF_KEY sockets, but by sockets which have indicated that kernel- originated messages are to be received. These messages are special because of the expected frequency at which they will occur. Also, an implementation may further wish to restrict return messages from the kernel, in cases where not all PF_KEY sockets are in the same trust domain. 一部のメッセージは、その作用がとられることを必要とすることを指し示すた めオペレーティングシステムにより作り出され、ユーザにより下に送信される 何らかのメッセージに必ずしも応答しない。そのようなメッセージは、すべて の PF_KEY sockets により受信されないが、kernel が作り出したメッセージ を指し示した sockets により受信されることができる。これらのメッセージ が生じるだろうことによる予期された頻繁さのために、これらのメッセージは 特別である。また実装は、すべての PF_KEY sockets が同じ信頼するドメイン でないケースで、kernel から返されたメッセージを制限することを、さらに 進んで望むかもしれない。 Many of the normal BSD socket calls have undefined behavior on PF_KEY sockets. These include: bind(), connect(), socketpair(), accept(), getpeername(), getsockname(), ioctl(), and listen(). 普通の BSD socket calls の多くは、PF_KEY sockets での動作を定義してい ない。これらは (次のものを) 含む: bind(), connect(), socketpair(), accept(), getpeername(), getsockname(), ioctl() と listen()。 1.5 Common PF_KEY Operations 1.5 共通の PF_KEY 操作 There are two basic ways to add a new Security Association into the kernel. The simplest is to send a single SADB_ADD message, containing all of the SA information, from the application into the kernel's Key Engine. This approach works particularly well with manual key management, which is required for IPsec, and other security protocols. kernel に新しい Security Association を追加するための 2 つの基本的な方 法がある。最も簡単な方法は、アプリケーションから kernel の Key Engine に SA 情報のすべてを含む、たった 1 つの SADB_ADD メッセージを送信する ことである。この方法は、手動鍵管理で特によくはたらき、それは IPsec と 他のセキュリティプロトコルのために必要とされる。 The second approach to add a new Security Association into the kernel is for the application to first request a Security Parameters Index (SPI) value from the kernel using the SADB_GETSPI message and then send an SADB_UPDATE message with the complete Security Association data. This second approach works well with key management daemons when the SPI values need to be known before the entire Security Association data is known (e.g. so the SPI value can be indicated to the remote end of the key management session). kernel に新しい Security Association を追加するための 2 つめの方法は、 アプリケーションが SADB_GETSPI メッセージを使用して kernel から Security Parameters Index (SPI) 値を最初要求し、完全な Security Association データを持つ SADB_UPDATE メッセージを送信することである。 全体の Security Association データが知られる前に、SPI 値が知っておく必 要がある時 (たとえば SPI 値が鍵管理セッションの remote end に指し示さ れることができるため)、この 2 番目の方法は、鍵管理デーモンとよくはたら く。 An individual Security Association can be deleted using the SADB_DELETE message. Categories of SAs or the entire kernel SA table can be deleted using the SADB_FLUSH message. 個々の Security Association は、SADB_DELTE メッセージを使用して削除さ れることができる。SAs の分類や全体の kernel SA テーブルは、SADB_FLUSH メッセージを使用して削除されることができる。 The SADB_GET message is used by a trusted application-layer process (e.g. routed(8) or gated(8)) to retrieve an SA (e.g. RIP SA or OSPF SA) from the kernel's Key Engine. SADB_GET メッセージは、kernel の Key Engine から SA (たとえば RIP SA や OSPF SA) を検索するために、信頼されたアプリケーション層プロセス (た とえば routed(8) や gated(8)) により使用される。 The kernel or an application-layer can use the SADB_ACQUIRE message to request that a Security Association be created by some application-layer key management process that has registered with the kernel via an SADB_REGISTER message. This ACQUIRE message will have a sequence number associated with it. This sequence number MUST be used by followup SADB_GETSPI, SADB_UPDATE, and SADB_ADD messages, in order to keep track of which request gets its keying material. The sequence number (described below) is similar to a transaction ID in a remote procedure call. kernel やアプリケーション層は、SADB_REGISTER メッセージ経由で kernel に登録した、あるアプリケーション層鍵管理プロセスにより作り出された Security Association を要求するために、SADB_ACQUIRE メッセージを使用す ることができる。この ACQUIRE メッセージは、それに関連された順序番号を 持つだろう。この順序番号は、その鍵材料を得る要求を見失わないために、追 いかける SADB_GETSPI, SADB_UPDATE と SADB_ADD メッセージにより使用され なければならない (MUST)。(下で記述される) 順序番号は、remote procedure call での transaction ID と同様である。 The SADB_EXPIRE message is sent from the kernel to key management applications when the "soft lifetime" or "hard lifetime" of a Security Association has expired. Key management applications should use receipt of a soft lifetime SADB_EXPIRE message as a hint to negotiate a replacement SA so the replacement SA will be ready and in the kernel before it is needed. Security Association の "soft lifetime (緩やかな生存時間)" や "hard lifetime (厳密な生存時間)" の期限が切れた時、SADB_EXPIRE メッセージは kernel から鍵管理アプリケーションに送信される。置き換えの SA が必要と されるより前に用意ができていて kernel 内にあるように、鍵管理アプリケー ションは、置き換えの SA を取り決めるために、ヒントとして soft lifetime SADB_EXPIRE メッセージ受信を使用すべきである。 A SADB_DUMP message is also defined, but this is primarily intended for PF_KEY implementor debugging and is not used in ordinary operation of PF_KEY. SADB_DUMP メッセージも定義される。しかしこれは、PF_KEY 実装者のデバッ グのために、おもに意図され、PF_KEY の通常の操作に使用されない。 1.6 Differences Between PF_KEY and PF_ROUTE 1.6 PF_KEY と PF_ROUTE との違い The following bullets are points of difference between the routing socket and PF_KEY. Programmers who are used to the routing socket semantics will find some differences in PF_KEY. 次の弾丸 (?) は、経路情報 socket と PF_KEY 間の相違点である。経路制御 socket セマンティクスに使用されるプログラマーは、PF_KEY での一部の違い を見つけるだろう。 * PF_KEY message errors are usually returned in PF_KEY messages instead of causing write() operations to fail and returning the error number in errno. This means that other listeners on a PF_KEY socket can be aware that requests from another process failed, which can be useful for auditing purposes. This also means that applications that fail to read PF_KEY messages cannot do error checking. * PF_KEY メッセージエラーは、write() 処理に失敗させ errno でエラー番号 を返すのではなく、PF_KEY メッセージ内で、たいてい返される。これは、 PF_KEY socket での他のリスナーが別のプロセスからの要求が失敗したこと に気づくことができることを意味し、そしてそれは監査目的のために有用で あることができる。これは、PF_KEY メッセージを読み込めないアプリケー ションがエラーチェックすることができないことも意味する。 An implementation MAY return the errors EINVAL, ENOMEM, and ENOBUFS by causing write() operations to fail and returning the error number in errno. This is an optimization for common error cases in which it does not make sense for any other process to receive the error. An application MUST NOT depend on such errors being set by the write() call, but it SHOULD check for such errors, and handle them in an appropriate manner. 実装は、write() 処理が失敗し errno でのエラー番号を返させることによ り、エラー EINVAL, ENOMEM と ENOBUFS を返すかもしれない (MAY)。これ は、何らかの他のプロセスがエラーを受信することを理解しない、共通のエ ラーケースのための最適化である。アプリケーションは、write() call に よりセットされたそのようなエラーに決して依存してはならない (MUST NOT) が、そのようなエラーをチェックすべきで (SHOULD)、そして適切な方 法でそのエラーを扱うべきである (SHOULD)。 * The entire message isn't always reflected in the reply. A SADB_ADD message is an example of this. * 全体のメッセージは、リプライにいつも反映されない。SADB_ADD メッセー ジは、これの 1 例である。 * The PID is not set by the kernel. The process that originates the message MUST set the sadb_msg_pid to its own PID. If the kernel ORIGINATES a message, it MUST set the sadb_msg_pid to 0. A reply to an original message SHOULD have the pid of the original message. (E.g. the kernel's response to an SADB_ADD SHOULD have its pid set to the pid value of the original SADB_ADD message.) * PID は、kernel によりセットされない。メッセージを作り出すプロセスは 自分自身の PID を sadb_msg_pid にセットしなければならない (MUST)。も し kernel がメッセージを生成する (ORIGINATES) なら、sadb_msg_pid を 0 にセットしなければならない (MUST)。もともとのメッセージへのリプラ イは、もともとのメッセージの pid を持つべきである (SHOULD)。(たとえ ば、SADB_ADD への kernel の応答は、もともとの SADB_ADD メッセージの pid 値にセットされたその pid を持つべきである (SHOULD)。) 1.7 Name Space 1.7 名前空間 All PF_KEYv2 preprocessor symbols and structure definitions are defined as a result of including the header file . There is exactly one exception to this rule: the symbol "PF_KEY" (two exceptions if "AF_KEY" is also counted), which is defined as a result of including the header file . All PF_KEYv2 preprocessor symbols start with the prefix "SADB_" and all structure names start with "sadb_". There are exactly two exceptions to this rule: the symbol "PF_KEY_V2" and the symbol "PFKEYV2_REVISION". すべての PF_KEYv2 プリプロセッサシンボルと構造体定義は、ヘッダファイル に含まれている結果として定義される。このルールへの正確 に言って 1 つの例外がある: シンボル "PF_KEY" (もし "AF_KEY" も数えられ るなら 2 つの例外) は、ヘッダファイル に含まれる結果と して定義される。すべての PF_KEYv2 プリプロセッサシンボルは、プレフィッ クス "SADB_" で始まり、すべての構造体名は、"sadb_" で始まる。このルー ルへの正確に言って 2 つの例外がある: シンボル "PF_KEY_V2" とシンボル "PFKEYV2_REVISION" である。 The symbol "PFKEYV2_REVISION" is a date-encoded value not unlike certain values defined by POSIX and X/Open. The current value for PFKEYV2_REVISION is 199806L, where 1998 is the year and 06 is the month. シンボル "PFKEYV2_REVISION" は、POSIX と X/Open により定義される確実な 値と違っていない日付けで符号化された値である。PFKEYV2_REVISION のため の最新の値は、199806L であり、1998 は年で 06 は月である。 Inclusion of the file MUST NOT define symbols or structures in the PF_KEYv2 name space that are not described in this document without the explicit prior permission of the authors. Any symbols or structures in the PF_KEYv2 name space that are not described in this document MUST start with "SADB_X_" or "sadb_x_". An implementation that fails to obey these rules IS NOT COMPLIANT WITH THIS SPECIFICATION and MUST NOT make any claim to be. These rules also apply to any files that might be included as a result of including the file . This rule provides implementors with some assurance that they will not encounter namespace-related surprises. ファイル の包含は、著者の明白な優先許可なしに、この文 書で記述されない PF_KEYv2 名前空間でのシンボルや構造体を決して定義して はならない (MUST)。この文書で記述されない PF_KEYv2 名前空間での何らか のシンボルや構造体は、"SADB_X_" か "sadb_x_" で始めなければならない (MUST)。これらのルールに従うことができない実装は、この仕様に対応してい なく (IS NOT COMPLIANT WITH THIS SPECIFICATION)、決して何らかの権利が あるようにしてはならない (MUST NOT)。これらのルールも、ファイル に含まれる結果として含まれるかもしれない何らかのファイ ルに適用する。このルールは、名前空間に関連される驚きに出くわさない、あ る保証を実装者に提供する。 1.8 On Manual Keying 1.8 手動鍵設定について Not unlike the 4.4-Lite BSD PF_ROUTE socket, this interface allows an application full-reign over the security associations in a kernel that implements PF_KEY. A PF_KEY implementation MUST have some sort of manual interface to PF_KEY, which SHOULD allow all of the functionality of the programmatic interface described here. 4.4-LITE BSD PF_ROUTE socket と違っていない、このインターフェイスは、 PF_KEY を実装する kernel でのセキュリティアソシエーションについてアプ リケーション完全支配を割り当てる。PF_KEY 実装は、PF_KEY への手動設定イ ンターフェイスの一部の種類を持たなければならなく (MUST)、そしてそれは ここで記述される programmatic インターフェイスの機能すべてを割り当てる べきである (SHOULD)。 ------------------------------------------------------------------------- 2. PF_KEY Message Format 2. PF_KEY メッセージ形式 PF_KEY messages consist of a base header followed by additional data fields, some of which may be optional. The format of the additional data is dependent on the type of message. PF_KEY メッセージは、追加のデータフィールドにより続く基本ヘッダからな り、追加部分の一部はオプションであるかもしれない。追加データの形式は、 メッセージタイプに依存する。 PF_KEY messages currently do not mandate any specific ordering for non-network multi-octet fields. Unless otherwise specified (e.g. SPI values), fields MUST be in host-specific byte order. PF_KEY メッセージは、ネットワークでないマルチオクテットフィールドにつ いて、何らかの特定の順序を命じない。もし別の方法で特定されなければ (た とえば SPI 値)、フィールドはホスト指定のバイトオーダでなければならない (MUST)。 2.1 Base Message Header Format 2.1 基本メッセージヘッダ形式 PF_KEY messages consist of the base message header followed by security association specific data whose types and lengths are specified by a generic type-length encoding. PF_KEY メッセージは、セキュリティアソシエーション特定データにより続か れる基本ヘッダからなる。そのデータのタイプと長さは、一般的な type- length 符号化により特定される。 This base header is shown below, using POSIX types. The fields are arranged primarily for alignment, and where possible, for reasons of clarity. この基本ヘッダは、POSIX タイプを使用して下に示される。フィールドは、ア ライメントと、どこへでも可能であることと、明解さの理由のために、おもに 取り決められる。 struct sadb_msg { uint8_t sadb_msg_version; uint8_t sadb_msg_type; uint8_t sadb_msg_errno; uint8_t sadb_msg_satype; uint16_t sadb_msg_len; uint16_t sadb_msg_reserved; uint32_t sadb_msg_seq; uint32_t sadb_msg_pid; }; /* sizeof(struct sadb_msg) == 16 */ sadb_msg_version The version field of this PF_KEY message. This MUST be set to PF_KEY_V2. If this is not set to PF_KEY_V2, the write() call MAY fail and return EINVAL. Otherwise, the behavior is undetermined, given that the application might not understand the formatting of the messages arriving from the kernel. この PF_KEY メッセージのバージョンフィールド。これは、 PF_KEY_V2 にセットされなければならない (MUST)。もし PF_KEY_V2 にセットされないなら、write() call は失敗す るかもしれなく (MAY)、そして EINVAL を返るかもしれない (MAY)。もしそうでなければ、アプリケーションは kernel から到着するメッセージの形式を理解できないかもしれない ことを考慮に入れると、動作は決定されない。 sadb_msg_type Identifies the type of message. The valid message types are described later in this document. メッセージタイプを識別する。有効なメッセージタイプが、 この文書の後で記述される。 sadb_msg_errno Should be set to zero by the sender. The responder stores the error code in this field if an error has occurred. This includes the case where the responder is in user space. (e.g. user-space negotiation fails, an errno can be returned.) 送信側によりゼロにセットすべきである。もしエラーが起こ るなら、応答側は、このフィールドにエラーコードを格納す る。これは、応答側がユーザ空間内にあるケースを含む (た とえば、ユーザ空間取り決めが失敗し、errno が返されるこ とができる)。 sadb_msg_satype Indicates the type of security association(s). Valid Security Association types are declared in the file . The current set of Security Association types is enumerated later in this document. (1 つか複数の) セキュリティアソシエーションのタイプを 指し示す。有効な Security Association タイプは、ファイ ル で宣言される。Security Association タイプの現在のセットは、この文書の後で列挙される。 sadb_msg_len Contains the total length, in 64-bit words, of all data in the PF_KEY message including the base header length and additional data after the base header, if any. This length includes any padding or extra space that might exist. Unless otherwise stated, all other length fields are also measured in 64-bit words. 基本ヘッダ長と、もしあれば基本ヘッダの後の追加データを 含む、PF_KEY メッセージ内のすべてのデータの、64-bit words での全長を含む。この長さは、存在するかもしれない 何らかのパディングや追加の空間を含む。もし別の方法で述 べられなければ、すべての他の長さフィールドも 64-bit words で長さがとられる。 On user to kernel messages, this field MUST be verified against the length of the inbound message. EMSGSIZE MUST be returned if the verification fails. On kernel to user messages, a size mismatch is most likely the result of the user not providing a large enough buffer for the message. In these cases, the user application SHOULD drop the message, but it MAY try and extract what information it can out of the message. kernel メッセージに対しユーザで、このフィールドは内向 けのメッセージ長に対して確かめられなければならない (MUST)。もし検証が失敗した時、EMSGSIZE は返されなけれ ばならない (MUST)。ユーザメッセージに対し kernel で、 サイズミスマッチは、たぶんメッセージのための十分大きな バッファを提供できないユーザの結果となる。これらのケー スで、ユーザアプリケーションはメッセージを落すべきであ る (SHOULD)。しかしメッセージの中から何か情報を試みる かもしれなく (MAY) 、抜き出すことがありうる。 sadb_msg_reserved Reserved value. It MUST be zeroed by the sender. All fields labeled reserved later in the document have the same semantics as this field. 予約された値。これは送信側によりゼロにされなければなら ない (MUST)。この文書の後で予約される、すべてのラベル されたフィールドは、このフィールドと同じセマンティクス を持つ。 sadb_msg_seq Contains the sequence number of this message. This field, along with sadb_msg_pid, MUST be used to uniquely identify requests to a process. The sender is responsible for filling in this field. This responsibility also includes matching the sadb_msg_seq of a request (e.g. SADB_ACQUIRE). このメッセージの順序番号を含む。このフィールドは、 sadb_msg_pid といっしょに、プロセスへの要求を一意に識 別するために使用されなければならない (MUST)。送信側は このフィールドに書き込むことに対して責任がある。この責 任もまた、要求 (たとえば SADB_ACQUIRE) の sadb_msg_seq にマッチすることを含む。 This field is similar to a transaction ID in a remote procedure call implementation. このフィールドは、remote procedure call 実装での transaction ID に類似である。 sadb_msg_pid Identifies the process which originated this message, or which process a message is bound for. For example, if process id 2112 sends an SADB_UPDATE message to the kernel, the process MUST set this field to 2112 and the kernel will set this field to 2112 in its reply to that SADB_UPDATE message. This field, along with sadb_msg_seq, can be used to uniquely identify requests to a process. このメッセージが作り出されたプロセスや、メッセージがど のプロセスへ行くのかを識別する。たとえば、もしプロセス id 2112 は kernel に SADB_UPDATE メッセージを送信する なら、プロセスは、このフィールドを 2112 にセットしなけ ればならなく (MUST)、kernel は、その SADB_UPDATE メッ セージへのリプライに、このフィールドを 2112 にセットす るだろう。このフィールドは、sadb_msg_seq といっしょに プロセスへの要求を一意に識別するために使用されることが できる。 It is currently assumed that a 32-bit quantity will hold an operating system's process ID space. 32-bit 数が、オペレーティングシステムのプロセス ID 空 間を持っていると現在思われる。 2.2 Alignment of Headers and Extension Headers 2.2 ヘッダと拡張ヘッダのアライメント The base message header is a multiple of 64 bits and fields after it in memory will be 64 bit aligned if the base itself is 64 bit aligned. Some of the subsequent extension headers have 64 bit fields in them, and as a consequence need to be 64 bit aligned in an environment where 64 bit quantities need to be 64 bit aligned. 基本メッセージヘッダは 64 bits の倍数であり、もしベース自身が 64 bit ごとに配置されるなら、メモリ内の基本メッセージヘッダの後のフィールドは 64 bit ごとに配置されるだろう。次の拡張ヘッダの一部は、それ自身に 64 bit を持つ。その結果、64 bit 数が 64 bit ごとに配置する必要がある環境 で、それら拡張ヘッダは 64 bit ごとに配置する必要がある。 The basic unit of alignment and length in PF_KEY Version 2 is 64 bits. Therefore: PF_KEY Version 2 でのアライメントと長さの基本単位は、64 bits である。 それゆえに: * All extension headers, inclusive of the sadb_ext overlay fields, MUST be a multiple of 64 bits long. * sadb_ext 上書きフィールドを含めて、すべての拡張ヘッダは 64 bits 長 の倍数でなければならない (MUST)。 * All variable length data MUST be padded appropriately such that its length in a message is a multiple of 64 bits. * すべての可変長データは、そのメッセージの長さが 64 bits の倍数であ るように、適切にパッドされなければならない (MUST)。 * All length fields are, unless otherwise specified, in units of 64 bits. * もし他の方法で特定されなければ、すべての長さフィールドは、64 bits の単位である。 * Implementations may safely access quantities of between 8 and 64 bits directly within a message without risk of alignment faults. * 実装は、アライメント誤りの危険なしにメッセージ内で直接、 8 から 64 bits 間の数に安全にアクセスするだろう。 All PF_KEYv2 structures are packed and already have all intended padding. Implementations MUST NOT insert any extra fields, including hidden padding, into any structure in this document. This forbids implementations from "extending" or "enhancing" existing headers without changing the extension header type. As a guard against such insertion of silent padding, each structure in this document is labeled with its size in bytes. The size of these structures in an implementation MUST match the size listed. すべての PF_KEYv2 構造体はパックされ、すべての意図されたパディングをす でに持つ。実装は、隠されたパディングを含む何らかの追加のフィールドを、 この文書でのどんな構造体にも決して挿入してはならない (MUST NOT)。これ は拡張ヘッダタイプを変更することなしに、"extending (拡張)" や "enhancing (高める)" 存在するヘッダからの実装を禁じる。そのような無言 のパディングの挿入に対するガードとして、この文書のそれぞれの構造体は、 バイトでのサイズでラベルされる。実装でのこれら構造体のサイズは、リスト されたサイズにマッチしなければならない (MUST)。 2.3 Additional Message Fields 2.3 追加のメッセージフィールド The additional data following the base header consists of various length-type-values fields. The first 32-bits are of a constant form: 基本ヘッダに続く追加のデータは、さまざまな length-type-values フィール ドからなる。最初の 32-bits は、定まった形式からなる。 struct sadb_ext { uint16_t sadb_ext_len; uint16_t sadb_ext_type; }; /* sizeof(struct sadb_ext) == 4 */ sadb_ext_len Length of the extension header in 64 bit words, inclusive. 64 bits words での、自分自身を含んでの拡張ヘッダ長。 sadb_ext_type The type of extension header that follows. Values for this field are detailed later. The value zero is reserved. 続く拡張ヘッダのタイプ。このフィールドのための値は、後 で詳述される。値ゼロは、予約される。 Types of extension headers include: Association, Lifetime(s), Address(s), Key(s), Identity(ies), Sensitivity, Proposal, and Supported. There MUST be only one instance of a extension type in a message. (e.g. Base, Key, Lifetime, Key is forbidden). An EINVAL will be returned if there are duplicate extensions within a message. Implementations MAY enforce ordering of extensions in the order presented in the EXTENSION HEADER VALUES section. 拡張ヘッダのタイプは、(次のものを) 含む: Association, Lifetime(s), Address(s), Key(s), Identity(ies), Sensitivity, Proposal と Supported。これらは、メッセージ内で拡張タイプのたった一つのインスタン スでなければならない (MUST)。(たとえば、Base, Key, Lifetime, Key は禁 止される。) もしメッセージ内に重複の拡張があるなら、EINVAL が返される だろう。実装は、EXTENSION HEADER VALUES セクションで示された順序で、拡 張の順序を守らせるかもしれない (MAY)。 If an unknown extension type is encountered, it MUST be ignored. Applications using extension headers not specified in this document MUST be prepared to work around other system components not processing those headers. Likewise, if an application encounters an unknown extension from the kernel, it must be prepared to work around it. Also, a kernel that generates extra extension header types MUST NOT _depend_ on applications also understanding extra extension header types. もし未知の拡張タイプに出くわされたら、それは無視されなければならない (MUST)。この文書で指定されない拡張ヘッダを使用するアプリケーションは、 それらのヘッダを処理しない他のシステム構成要素を避けて動作するように用 意しなければならない (MUST)。同様に、もしアプリケーションが kernel か ら未知の拡張に出くわされたら、それを避けて動作するように用意しなければ ならない。また、追加の拡張ヘッダタイプを生成する kernel は、追加の拡張 ヘッダタイプも理解するアプリケーションに、決して依存してはならない (MUST NOT)。 All extension definitions include these two fields (len and exttype) because they are instances of a generic extension (not unlike sockaddr_in and sockaddr_in6 are instances of a generic sockaddr). The sadb_ext header MUST NOT ever be present in a message without at least four bytes of extension header data following it, and, therefore, there is no problem with it being only four bytes long. すべての拡張定義は、これら 2 つのフィールド (len と exttype) を含む。 なぜなら、(sockaddr_in と sockaddr_in6 が一般的な sockaddr のインスタ ンスであることに違っていなく) これらは一般的な拡張のインスタンスだから である。sadb_ext ヘッダは、これにより続く拡張ヘッダデータの少なくとも 4 bytes なしにメッセージで、少しでも決して示されてはならなく (MUST NOT)、それゆえ、4 bytes 長のみであることの問題はない。 All extensions documented in this section MUST be implemented by a PF_KEY implementation. このセクションで文書化されたすべての拡張は、PF_KEY 実装により実装され なければならない (MUST)。 2.3.1 Association Extension 2.3.1 アソシエーション拡張 The Association extension specifies data specific to a single security association. The only times this extension is not present is when control messages (e.g. SADB_FLUSH or SADB_REGISTER) are being passed and on the SADB_ACQUIRE message. Association 拡張は、たった 1 つのセキュリティアソシエーションに対する 明確なデータを明細に述べる。この拡張が示されない唯一の時間は、制御メッ セージ (たとえば SADB_FLUSH や SADB_REGISTER) が通過していたり SADB_ACQUIRE メッセージ上にある時である。 struct sadb_sa { uint16_t sadb_sa_len; uint16_t sadb_sa_exttype; uint32_t sadb_sa_spi; uint8_t sadb_sa_replay; uint8_t sadb_sa_state; uint8_t sadb_sa_auth; uint8_t sadb_sa_encrypt; uint32_t sadb_sa_flags; }; /* sizeof(struct sadb_sa) == 16 */ sadb_sa_spi The Security Parameters Index value for the security association. Although this is a 32-bit field, some types of security associations might have an SPI or key identifier that is less than 32-bits long. In this case, the smaller value shall be stored in the least significant bits of this field and the unneeded bits shall be zero. This field MUST be in network byte order. セキュリティアソシエーションのための Security Parameters Index 値。これは 32-bit フィールドであるけ れども、セキュリティアソシエーションの一部のタイプは 32-bits 長よりも小さい SPI や鍵識別子を持つかもしれな い。このケースで、小さい値は、このフィールドの最下位 ビットから格納されるだろうし、必要でないビットはゼロで あろう。このフィールドはネットワークバイトオーダでなけ ればならない (MUST)。 sadb_sa_replay The size of the replay window, if not zero. If zero, then no replay window is in use. もしゼロでなければ、リプレイウィンドウのサイズ。もしゼ ロなら、リプレイウィンドウは使用されていない。 sadb_sa_state The state of the security association. The currently defined states are described later in this document. セキュリティアソシエーションの状態。現在定義された状態 は、この文書の後で記述される。 sadb_sa_auth The authentication algorithm to be used with this security association. The valid authentication algorithms are described later in this document. A value of zero means that no authentication is used for this security association. このセキュリティアソシエーションで使用される、認証アル ゴリズム。有効な認証アルゴリズムは、この文書の後で記述 される。値ゼロは、このセキュリティアソシエーションに認 証は使用されないことを意味する。 sadb_sa_encrypt The encryption algorithm to be used with this security association. The valid encryption algorithms are described later in this document. A value of zero means that no encryption is used for this security association. このセキュリティアソシエーションで使用される、暗号アル ゴリズム。有効な暗号アルゴリズムは、この文書の後で記述 される。値ゼロは、このセキュリティアソシエーションに暗 号化は使用されないことを意味する。 sadb_sa_flags A bitmap of options defined for the security association. The currently defined flags are described later in this document. セキュリティアソシエーションのために定義されるオプショ ンのビットマップ。現在定義されるフラグは、この文書の後 で記述される。 The kernel MUST check these values where appropriate. For example, IPsec AH with no authentication algorithm is probably an error. kernel は、適した場所のこれらの値をチェックしなければならない (MUST)。 たとえば、認証アルゴリズムのない IPsec AH は、たぶんエラーである。 When used with some messages, the values in some fields in this header should be ignored. 一部のメッセージと一緒に使用される時、このヘッダの一部のフィールド値は 無視されるべきである。 2.3.2 Lifetime Extension 2.3.2 生存時間拡張 The Lifetime extension specifies one or more lifetime variants for this security association. If no Lifetime extension is present the association has an infinite lifetime. An association SHOULD have a lifetime of some sort associated with it. Lifetime variants come in three varieties, HARD - indicating the hard-limit expiration, SOFT - indicating the soft-limit expiration, and CURRENT - indicating the current state of a given security association. The Lifetime extension looks like: Lifetime 拡張は、あるセキュリティアソシエーションについて一つか多くの 異なった生存時間を明細に述べる。もし Lifetime 拡張がないなら、そのアソ シエーションは無限の生存時間を持つ。アソシエーションは、それと関連され た、ある種類の生存時間を持つべきである (SHOULD)。異なる生存時間は、3 種類ある。HARD - 厳密な制限期限を指し示す。SOFT - 緩やかな制限期限を指 し示す。CURRENT - 与えられたセキュリティアソシエーションの現在の状態を 指し示す。Lifetime 拡張は、次のようになりそうである。 struct sadb_lifetime { uint16_t sadb_lifetime_len; uint16_t sadb_lifetime_exttype; uint32_t sadb_lifetime_allocations; uint64_t sadb_lifetime_bytes; uint64_t sadb_lifetime_addtime; uint64_t sadb_lifetime_usetime; }; /* sizeof(struct sadb_lifetime) == 32 */ sadb_lifetime_allocations For CURRENT, the number of different connections, endpoints, or flows that the association has been allocated towards. For HARD and SOFT, the number of these the association may be allocated towards before it expires. The concept of a connection, flow, or endpoint is system specific. CURRENT のための、アソシエーションが割り当てられる、異 なるコネクション、エンドポイントやフロー数。HARD と SOFT のため、アソシエーションの期限が切れる前に、割り 当てられるかもしれない、これらのアソシエーション数。コ ネクション、フローやエンドポイントの概念は、システム特 有である。 sadb_lifetime_bytes For CURRENT, how many bytes have been processed using this security association. For HARD and SOFT, the number of bytes that may be processed using this security association before it expires. CURRENT のため、このセキュリティアソシエーションを使用 して、どれだけ処理されるかのバイト数。HARD と SOFT の ため、アソシエーションの期限が切れる前に、このセキュリ ティアソシエーションを使用して処理されるかもしれないバ イト数。 sadb_lifetime_addtime For CURRENT, the time, in seconds, when the association was created. For HARD and SOFT, the number of seconds after the creation of the association until it expires. CURRENT のため、アソシエーションが作り出された時の、秒 での時間。HARD と SOFT のため、アソシエーション作成の 後、その期限が切れるまでの秒数。 For such time fields, it is assumed that 64-bits is sufficiently large to hold the POSIX time_t value. If this assumption is wrong, this field will have to be revisited. このような時間フィールドについて、64-bits は POSIX time_t 値を持つために十分に大きいと思われる。もしこの 想定が悪ければ、このフィールドは修正しなければならない だろう。 sadb_lifetime_usetime For CURRENT, the time, in seconds, when association was first used. For HARD and SOFT, the number of seconds after the first use of the association until it expires. CURRENT のため、アソシエーションが最初に使用された時の 秒での時間。HARD と SOFT のため、このアソシエーション の最初の使用の後、その期限が切れるまでの秒数。 The semantics of lifetimes are inclusive-OR, first-to-expire. This means that if values for bytes and time, or multiple times, are passed in, the first of these values to be reached will cause a lifetime expiration. 生存時間のセマンティクスは、inclusive-OR, first-to-expire である。これ は、もしバイトと時間、複数時間の値が渡されるなら、到達されるこれらの値 の最初が生存時間期限を引き起こす。 2.3.3 Address Extension 2.3.3 アドレス拡張 The Address extension specifies one or more addresses that are associated with a security association. Address extensions for both source and destination MUST be present when an Association extension is present. The format of an Address extension is: Address 拡張は、セキュリティアソシエーションで関連される一つ、または多 くのアドレスを詳細に述べる。Association 拡張がある時、始点と終点両方に ついて Address 拡張は示されなければならない (MUST)。Address 拡張の形式 は、(次のとおりである): struct sadb_address { uint16_t sadb_address_len; uint16_t sadb_address_exttype; uint8_t sadb_address_proto; uint8_t sadb_address_prefixlen; uint16_t sadb_address_reserved; }; /* sizeof(struct sadb_address) == 8 */ /* followed by some form of struct sockaddr */ /* struct sockaddr の、ある形式により続けられる */ The sockaddr structure SHOULD conform to the sockaddr structure of the system implementing PF_KEY. If the system has an sa_len field, so SHOULD the sockaddrs in the message. If the system has NO sa_len field, the sockaddrs SHOULD NOT have an sa_len field. All non-address information in the sockaddrs, such as sin_zero for AF_INET sockaddrs, and sin6_flowinfo for AF_INET6 sockaddrs, MUST be zeroed out. The zeroing of ports (e.g. sin_port and sin6_port) MUST be done for all messages except for originating SADB_ACQUIRE messages, which SHOULD fill them in with ports from the relevant TCP or UDP session which generates the ACQUIRE message. If the ports are non-zero, then the sadb_address_proto field, normally zero, MUST be filled in with the transport protocol's number. If the sadb_address_prefixlen is non- zero, then the address has a prefix (often used in KM access control decisions), with length specified in sadb_address_prefixlen. These additional fields may be useful to KM applications. sockaddr 構造体は、PF_KEY を実装しているシステムの sockaddr 構造体に一 致すべきである (SHOULD)。もしシステムが (そのシステムの sockaddr 構造 体に) sa_len フィールドを持つなら、メッセージ内で sockaddrs を使用すべ きである (SHOULD)。もしシステムが sa_len フィールドを持たない (NO) な ら、sockaddrs は (メッセージ内に) sa_len フィールドを持つべきでない (SHOULD)。AF_INET sockaddrs での sin_zero と AF_INET6 sockaddrs での sin6_flowinfo のような、sockaddrs でのアドレス情報でないものすべては、 完全にゼロでなければならない (MUST)。SADB_ACQUIRE メッセージを生成する ことを除いて、ports (たとえば、sin_port と sin6_port) はゼロでなければ ならなく (MUST)、そしてそれは ACQUIRE メッセージを生成する関連した TCP や UDP セッションからの ports でそれらを書き込むべきである (SHOULD)。 もし ports がゼロでないなら、それから通常ゼロである sadb_address_proto フィールドは、トランスポートプロトコル番号で書き込まれなければならない (MUST)。もし sadb_address_prefixlen がゼロでないなら、それから sadb_address_prefixlen で指定される長さを持った (KM アクセス制御決定で しばしば使用される) prefix をアドレスは持つ。これらの追加のフィールド は、KM アプリケーションに有用かもしれない。 The SRC and DST addresses for a security association MUST be in the same protocol family and MUST always be present or absent together in a message. The PROXY address MAY be in a different protocol family, and for most security protocols, represents an actual originator of a packet. (For example, the inner-packets's source address in a tunnel.) セキュリティアソシエーションのための SRC (始点) と DST (終点) アドレス は同じプロトコルファミリでなければならなく (MUST)、メッセージでともに いつもある (present) かない (absent) かでなければならない (MUST)。 PROXY (プロクシ) アドレスは、異なるプロトコルファミリであるかもしれな く (MAY)、たいていのセキュリティプロトコルについてパケットの実際の送信 者を表す。(たとえば、トンネルでの内側のパケットの始点アドレス。) The SRC address MUST be a unicast or unspecified (e.g., INADDR_ANY) address. The DST address can be any valid destination address (unicast, multicast, or even broadcast). The PROXY address SHOULD be a unicast address (there are experimental security protocols where PROXY semantics may be different than described above). SRC アドレスは、ユニキャストか、指定されていない (たとえば INADDR_ANY) アドレスでなければならない (MUST)。DST アドレスは、有効などんな終点ア ドレス (ユニキャスト、マルチキャストやブロードキャストでさえ) もありう る。PROXY アドレスは、ユニキャストであるべきである (SHOULD) (PROXY セ マンティクスが上で記述されたものよりも異なっているかもしれない実験的な セキュリティプロトコルがあるから)。 2.3.4 Key Extension The Key extension specifies one or more keys that are associated with a security association. A Key extension will not always be present with messages, because of security risks. The format of a Key extension is: Key 拡張は、セキュリティアソシエーションで関連される 1 つか多くの鍵を 明細に記述する。Key 拡張は、セキュリティリスクの理由で、メッセージでい つも示されないだろう。Key 拡張の形式は (次のとおりである): struct sadb_key { uint16_t sadb_key_len; uint16_t sadb_key_exttype; uint16_t sadb_key_bits; uint16_t sadb_key_reserved; }; /* sizeof(struct sadb_key) == 8 */ /* followed by the key data */ /* 鍵データにより続けられる */ sadb_key_bits The length of the valid key data, in bits. A value of zero in sadb_key_bits MUST cause an error. 有効な鍵データの、ビットでの長さ。sadb_key_bits の値ゼ ロはエラーを引き起こさなければならない (MUST)。 The key extension comes in two varieties. The AUTH version is used with authentication keys (e.g. IPsec AH, OSPF MD5) and the ENCRYPT version is used with encryption keys (e.g. IPsec ESP). PF_KEY deals only with fully formed cryptographic keys, not with "raw key material". For example, when ISAKMP/Oakley is in use, the key management daemon is always responsible for transforming the result of the Diffie-Hellman computation into distinct fully formed keys PRIOR to sending those keys into the kernel via PF_KEY. This rule is made because PF_KEY is designed to support multiple security protocols (not just IP Security) and also multiple key management schemes including manual keying, which does not have the concept of "raw key material". A clean, protocol-independent interface is important for portability to different operating systems as well as for portability to different security protocols. 鍵拡張は 2 種類ある。AUTH バージョンは認証鍵 (たとえば、IPsec AH, OSPF MD5) で使用され、ENCRYPT バージョンは暗号鍵 (たとえば IPsec ESP) で使 用される。PF_KEY は、"raw key material (手を加えていない鍵材料)" では なく、完全に形式化された暗号学鍵のみを扱う。たとえば ISAKMP/Oakley が 使用されている時、PF_KEY 経由で鍵を kernel に送信するより前 (PRIOR) に 鍵管理デーモンは Diffie-Hellman 計算結果を、全然異なる完全に形式化され た鍵に変換することに対して、いつも責任がある。PF_KEY は (IP Security だけでなく) 複数のセキュリティプロトコルと手動鍵設定を含む複数の鍵管理 方法もサポートするために設計されたという理由で、このルールは作られ、 "raw key material" の概念を持たない。明瞭でプロトコル非依存のインター フェイスは、異なるセキュリティプロトコルに対しポータビリティであるため と同様に、異なるオペレーティングシステムに対しポータビリティであるため に重要である。 If an algorithm defines its key to include parity bits (e.g. DES) then the key used with PF_KEY MUST also include those parity bits. For example, this means that a single DES key is always a 64-bit quantity. もしアルゴリズムがパリティビットを含む鍵 (たとえば DES) を定義するなら PF_KEY で使用される鍵はそれらパリティビットも含まなければならない (MUST)。たとえばこれは、たった 1 つの DES 鍵がいつも 64-bit 数であるこ とを意味する。 When a particular security protocol only requires one authentication and/or one encryption key, the fully formed key is transmitted using the appropriate key extension. When a particular security protocol requires more than one key for the same function (e.g. Triple-DES using 2 or 3 keys, and asymmetric algorithms), then those two fully formed keys MUST be concatenated together in the order used for outbound packet processing. In the case of multiple keys, the algorithm MUST be able to determine the lengths of the individual keys based on the information provided. The total key length (when combined with knowledge of the algorithm in use) usually provides sufficient information to make this determination. 特定のセキュリティプロトコルが 1 つの認証 and/or 1 つの暗号鍵を必要と するだけの時、完全に形式化された鍵は適切な鍵拡張を使用して転送される。 特定のセキュリティプロトコルが同じ機能に対する 2 つ以上の鍵 (たとえば 2 つや 3 つの鍵を使用する Triple-DES と非対称アルゴリズム) を必要とす る時、それら 2 つの完全に形式化された鍵は、提供される情報に基づく個々 の鍵長を決定できなければならない (MUST)。(使用されるアルゴリズムの知識 で結合される時) 全鍵長は、この決定をおこなうための十分な情報をたいてい 提供する。 Keys are always passed through the PF_KEY interface in the order that they are used for outbound packet processing. For inbound processing, the correct order that keys are used might be different from this canonical concatenation order used with the PF_KEY interface. It is the responsibility of the implementation to use the keys in the correct order for both inbound and outbound processing. 鍵は、外向けのパケット処理のために使用される順序で PF_KEY インターフェ イスをいつも通過される。内向けの処理について、鍵が使用される正確な順序 は、PF_KEY インターフェイスで使用される、今の正統な連結順序と異なるか もしれない。内向けと外向けの処理両方について、正確な順序で鍵を使用する ことは、実装の責任である。 For example, consider a pair of nodes communicating unicast using an ESP three-key Triple-DES Security Association. Both the outbound SA on the sender node, and the inbound SA on the receiver node will contain key-A, followed by key-B, followed by key-C in their respective ENCRYPT key extensions. The outbound SA will use key-A first, followed by key-B, then key-C when encrypting. The inbound SA will use key-C, followed by key-B, then key-A when decrypting. (NOTE: We are aware that 3DES is actually encrypt-decrypt-encrypt.) The canonical ordering of key-A, key-B, key-C is used for 3DES, and should be documented. The order of "encryption" is the canonical order for this example. [Sch96] たとえば、ESP 3 つの鍵 Triple-DES Security Association を使用して、ユ ニキャストで通信しているノードのペアを考える。送信側ノードでの外向け SA と受信側ノードでの内向け SA 両方は、それぞれの ENCRYPT 鍵拡張に、 key-A, key-B, key-C である順序の鍵を含むだろう。外向け SA は、暗号化の 時、最初 key-A を使用し、続けて key-B で、それから key-C を使用する。 内向け SA は、復号の時に、key-C、続けて key-B、それから key-A を使用す る。(注意: われわれは、3DES が実際には (暗号化では) 暗号化-復号-暗号化 であることに気づいている。) "encryption" の順序は、この例で正統な順序 である。[Sch96] The key data bits are arranged most-significant to least significant. For example, a 22-bit key would take up three octets, with the least significant two bits not containing key material. Five additional octets would then be used for padding to the next 64-bit boundary. 鍵データビットは、most-significant から least significant へと配置され る。たとえば 22-bit 鍵は、鍵材料を含まない least significant 2 bits を 持つ 3 オクテットをとるだろう。追加の 5 オクテットは、次の 64-bit 境界 へのパディングのために使用されるだろう。 While not directly related to PF_KEY, there is a user interface issue regarding odd-digit hexadecimal representation of keys. Consider the example of the 16-bit number: PF_KEY に直接関連されないのだが、鍵の奇数桁 16 進数表現に関するユーザ インターフェイス問題がある。16-bit 数字の例を考える: 0x123 That will require two octets of storage. In the absence of other information, however, unclear whether the value shown is stored as: それは格納の 2 オクテットを必要とする。しかしながら、他の情報がない時 は、不透明な示される値のどちらかで格納される: 01 23 OR 12 30 It is the opinion of the authors that the former (0x123 == 0x0123) is the better way to interpret this ambiguity. Extra information (for example, specifying 0x0123 or 0x1230, or specifying that this is only a twelve-bit number) would solve this problem. 前者 (0x123 == 0x0123) がこの曖昧さを解釈するためのよりよい方法である というのが、著者の意見である。追加の情報 (たとえば、0x0123 か 0x1230 を特定することや、これは 12 bit 数のみであることを特定すること) は、こ の問題を解決するだろう。 2.3.5 Identity Extension 2.3.5 身元拡張 The Identity extension contains endpoint identities. This information is used by key management to select the identity certificate that is used in negotiations. This information may also be provided by a kernel to network security aware applications to identify the remote entity, possibly for access control purposes. If this extension is not present, key management MUST assume that the addresses in the Address extension are the only identities for this Security Association. The Identity extension looks like: Identity 拡張は、endpoint 身元を含む。この情報は、ネゴシエーションで使 用される身元証明書を選択するため鍵管理により使用される。ひょっとしたら アクセス制御目的のために、リモートエンティティを識別するためネットワー クセキュリティに認識あるアプリケーションに対し、この情報も kernel によ り提供されるかもしれない。もしこの拡張が示されないなら、鍵管理は、この Security Association について Address 拡張でのアドレスが唯一の身元であ ると、当然思わなければならない (MUST)。Identity 拡張は、(次のように) なりそうである: struct sadb_ident { uint16_t sadb_ident_len; uint16_t sadb_ident_exttype; uint16_t sadb_ident_type; uint16_t sadb_ident_reserved; uint64_t sadb_ident_id; }; /* sizeof(struct sadb_ident) == 16 */ /* followed by the identity string, if present */ /* もし示されるなら、身元文字列により続けられる */ sadb_ident_type The type of identity information that follows. Currently defined identity types are described later in this document. 続く身元文字列のタイプ。現在、定義される身元タイプは、 この文書の後で記述される。 sadb_ident_id An identifier used to aid in the construction of an identity string if none is present. A POSIX user id value is one such identifier that will be used in this field. Use of this field is described later in this document. もし何も示されないなら、身元文字列の解釈を助けるために 使用される識別子。POSIX user id の値が、このフィールド で使用されるだろう、1 つのそのような識別子である。この フィールドの使用は、この文書の後で記述される。 A C string containing a textual representation of the identity information optionally follows the sadb_ident extension. The format of this string is determined by the value in sadb_ident_type, and is described later in this document. 身元情報のテキストでの表現を含む C (言語での) 文字列は、オプションで sadb_ident 拡張に続く。この文字列の形式は、sadb_ident_type での値によ り決定され、そのことは、この文書の後で記述される。 2.3.6 Sensitivity Extension 2.3.6 感度拡張 The Sensitivity extension contains security labeling information for a security association. If this extension is not present, no sensitivity-related data can be obtained from this security association. If this extension is present, then the need for explicit security labeling on the packet is obviated. Semsitivity 拡張は、セキュリティアソシエーションについて情報をラベルし ているセキュリティを含む。もしこの拡張が示されないなら、感度に関連され るデータは、このセキュリティアソシエーションから、得られることができな い。もしこの拡張が示されたら、パケットでラベルしている明示的なセキュリ ティのための必要性は、前もって取り除かれる。 struct sadb_sens { uint16_t sadb_sens_len; uint16_t sadb_sens_exttype; uint32_t sadb_sens_dpd; uint8_t sadb_sens_sens_level; uint8_t sadb_sens_sens_len; uint8_t sadb_sens_integ_level; uint8_t sadb_sens_integ_len; uint32_t sadb_sens_reserved; }; /* sizeof(struct sadb_sens) == 16 */ /* followed by: (下の変数により続けられる:) uint64_t sadb_sens_bitmap[sens_len]; uint64_t sadb_integ_bitmap[integ_len]; */ sadb_sens_dpd Describes the protection domain, which allows interpretation of the levels and compartment bitmaps. 保護ドメインを記述し、ラベルと仕切りビットマップの解釈 を割り当てる。 sadb_sens_sens_level The sensitivity level. 感度レベル。 sadb_sens_sens_len The length, in 64 bit words, of the sensitivity bitmap. 感度ビットマップの 64 bit words での長さ。 sadb_sens_integ_level The integrity level. 完全性レベル。 sadb_sens_integ_len The length, in 64 bit words, of the integrity bitmap. 完全性ビットマップの 64 bit words での長さ。 This sensitivity extension is designed to support the Bell-LaPadula [BL74] security model used in compartmented-mode or multi-level secure systems, the Clark-Wilson [CW87] commercial security model, and/or the Biba integrity model [Biba77]. These formal models can be used to implement a wide variety of security policies. The definition of a particular security policy is outside the scope of this document. Each of the bitmaps MUST be padded to a 64-bit boundary if they are not implicitly 64-bit aligned. この感度拡張は、仕切られたモードや複数レベルセキュアシステムで使用され る Bell-LaPadula [BL74] セキュリティモデル、Clark-Wilson [CW87] 商業セ キュリティモデル、and/or Biba 完全性モデルをサポートするために設計され た。これらの形式上のモデルは、セキュリティポリシーの幅広い種類を実装す るために使用されることができる。特定のセキュリティポリシーの定義は、こ の文書の範囲外である。ビットマップのそれぞれは、もしそれとなく 64-bit ごとに配置されないなら、64-bit 境界にパッドされなければならない (MUST)。 2.3.7 Proposal Extension 2.3.7 提案拡張 The Proposal extension contains a "proposed situation" of algorithm preferences. It looks like: Proposal 拡張は、アルゴリズム選択の "proposed situation (提案される状 態)" を含む。これは (次のように) なりそうである: struct sadb_prop { uint16_t sadb_prop_len; uint16_t sadb_prop_exttype; uint8_t sadb_prop_replay; uint8_t sadb_prop_reserved[3]; }; /* sizeof(struct sadb_prop) == 8 */ /* followed by: (下の変数により続けられる:) struct sadb_comb sadb_combs[(sadb_prop_len * sizeof(uint64_t) - sizeof(struct sadb_prop)) / sizeof(struct sadb_comb)]; */ Following the header is a list of proposed parameter combinations in preferential order. The values in these fields have the same definition as the fields those values will move into if the combination is chosen. 次のヘッダは、選択順序での提案されるパラメータ組み合わせリストである。 これらフィールドの値は、もし組み合わせが選ばれるなら、それらの値が移動 するだろうフィールドとして、同じ定義を持つ。 NOTE: Some algorithms in some security protocols will have variable IV lengths per algorithm. Variable length IVs are not supported by PF_KEY v2. If they were, however, proposed IV lengths would go in the Proposal Extension. 注意: あるセキュリティプロトコルのあるアルゴリズムは、アルゴリズム ごとに可変の IV 長を持つ。可変長 IVs は、PF_KEY v2 によりサ ポートされない。しかしながら、もしそれらがあるなら、提案され る IV 長は Proposal Extension の中へ入るだろう。 These combinations look like: これらの組み合わせは、(次のように) なりそうである: struct sadb_comb { uint8_t sadb_comb_auth; uint8_t sadb_comb_encrypt; uint16_t sadb_comb_flags; uint16_t sadb_comb_auth_minbits; uint16_t sadb_comb_auth_maxbits; uint16_t sadb_comb_encrypt_minbits; uint16_t sadb_comb_encrypt_maxbits; uint32_t sadb_comb_reserved; uint32_t sadb_comb_soft_allocations; uint32_t sadb_comb_hard_allocations; uint64_t sadb_comb_soft_bytes; uint64_t sadb_comb_hard_bytes; uint64_t sadb_comb_soft_addtime; uint64_t sadb_comb_hard_addtime; uint64_t sadb_comb_soft_usetime; uint64_t sadb_comb_hard_usetime; }; /* sizeof(struct sadb_comb) == 72 */ sadb_comb_auth If this combination is accepted, this will be the value of sadb_sa_auth. もしこの組み合わせが受け入れられるなら、これは sadb_sa_auth の値である。 sadb_comb_encrypt If this combination is accepted, this will be the value of sadb_sa_encrypt. もしこの組み合わせが受け入れられるなら、これは sadb_sa_encrypt の値である。 sadb_comb_auth_minbits; sadb_comb_auth_maxbits; The minimum and maximum acceptable authentication key lengths, respectably, in bits. If sadb_comb_auth is zero, both of these values MUST be zero. If sadb_comb_auth is nonzero, both of these values MUST be nonzero. If this combination is accepted, a value between these (inclusive) will be stored in the sadb_key_bits field of KEY_AUTH. The minimum MUST NOT be greater than the maximum. ビットでの、まともに受け入れられる、最小と最大の認証鍵 長。もし sadb_comb_auth がゼロであるなら、これらの値両 方はゼロでなければならない (MUST)。もし sadb_comb_auth がゼロでないなら、これらの値両方はゼロでない値にしなけ ればならない (MUST)。もしこの組み合わせが受け入れられ るなら、(それらを含む) これらの間の値は KEY_AUTH の sadb_key_bits フィールドに格納されるだろう。最小値は、 最大値よりも決して大きくあってはならない (MUST NOT)。 sadb_comb_encrypt_minbits; sadb_comb_encrypt_maxbits; The minimum and maximum acceptable encryption key lengths, respectably, in bits. If sadb_comb_encrypt is zero, both of these values MUST be zero. If sadb_comb_encrypt is nonzero, both of these values MUST be nonzero. If this combination is accepted, a value between these (inclusive) will be stored in the sadb_key_bits field of KEY_ENCRYPT. The minimum MUST NOT be greater than the maximum. ビットでの、まともに受け入れられる、最小と最大の暗号鍵 長。もし sadb_comb_encrypt がゼロであるなら、これらの 値両方はゼロでなければならない (MUST)。もし sadb_comb_encrypt がゼロでないなら、これらの値両方はゼ ロでない値にしなければならない (MUST)。もしこの組み合 わせが受け入れられるなら、(それらを含む) これらの間の 値は KEY_ENCRYPT の sadb_key_bits に格納されるだろう。 最小値は、最大値よりも決して大きくあってはならない (MUST NOT)。 sadb_comb_soft_allocations sadb_comb_hard_allocations If this combination is accepted, these are proposed values of sadb_lifetime_allocations in the SOFT and HARD lifetimes, respectively. もしこの組み合わせが受け入れられるなら、別々に SOFT と HARD 生存時間での提案される sadb_lifetime_allocations 値がある。 sadb_comb_soft_bytes sadb_comb_hard_bytes If this combination is accepted, these are proposed values of sadb_lifetime_bytes in the SOFT and HARD lifetimes, respectively. もしこの組み合わせが受け入れられるなら、別々に SOFT と HARD 生存時間での提案される sadb_lifetime_bytes 値があ る。 sadb_comb_soft_addtime sadb_comb_hard_addtime If this combination is accepted, these are proposed values of sadb_lifetime_addtime in the SOFT and HARD lifetimes, respectively. もしこの組み合わせが受け入れられるなら、別々に SOFT と HARD 生存時間での提案される sadb_lifetime_addtime 値が ある。 sadb_comb_soft_usetime sadb_comb_hard_usetime If this combination is accepted, these are proposed values of sadb_lifetime_usetime in the SOFT and HARD lifetimes, respectively. もしこの組み合わせが受け入れられるなら、別々に SOFT と HARD 生存時間での提案される sadb_lifetime_usetime 値が ある。 Each combination has an authentication and encryption algorithm, which may be 0, indicating none. A combination's flags are the same as the flags in the Association extension. The minimum and maximum key lengths (which are in bits) are derived from possible a priori policy decisions, along with basic properties of the algorithm. Lifetime attributes are also included in a combination, as some algorithms may know something about their lifetimes and can suggest lifetime limits. それぞれの組み合わせは、認証と暗号アルゴリズムを持ち、そしてそれは何も 指し示していない 0 であろう。組み合わせのフラグは、Association 拡張で のフラグと同じである。(ビットでの) 最小と最大鍵長は、アルゴリズムの基 本プロパティと一緒に、可能で直感的なポリシー決定から派生される。 Lifetime 属性も、一部のアルゴリズムがこれらの生存時間について何か知っ ているかもしれないのと生存時間制限を提案できるとして、組み合わせに含ま れる。 2.3.8 Supported Algorithms Extension 2.3.8 サポートされるアルゴリズム拡張 The Supported Algorithms extension contains a list of all algorithms supported by the system. This tells key management what algorithms it can negotiate. Available authentication algorithms are listed in the SUPPORTED_AUTH extension and available encryption algorithms are listed in the SUPPORTED_ENCRYPT extension. The format of these extensions is: Supported Algorithms 拡張は、システムによりサポートされるすべてのアル ゴリズムのリストを含む。これは、鍵管理に取り決めることができるアルゴリ ズムすべてを教える。利用できる認証アルゴリズムは、SUPPORTED_AUTH 拡張 でリストされ、利用できる暗号アルゴリズムは、SUPPORTED_ENCRYPT 拡張でリ ストされる。これらの拡張の形式は、(次のとおりである): struct sadb_supported { uint16_t sadb_supported_len; uint16_t sadb_supported_exttype; uint32_t sadb_supported_reserved; }; /* sizeof(struct sadb_supported) == 8 */ /* followed by: (次の変数により続けられる:) struct sadb_alg sadb_algs[(sadb_supported_len * sizeof(uint64_t) - sizeof(struct sadb_supported)) / sizeof(struct sadb_alg)]; */ This header is followed by one or more algorithm descriptions. An algorithm description looks like: このヘッダは、1 つか多くのアルゴリズム記述により続けられる。アルゴリ ズム記述は、(次のように) なりそうである: struct sadb_alg { uint8_t sadb_alg_id; uint8_t sadb_alg_ivlen; uint16_t sadb_alg_minbits; uint16_t sadb_alg_maxbits; uint16_t sadb_alg_reserved; }; /* sizeof(struct sadb_alg) == 8 */ sadb_alg_id The algorithm identification value for this algorithm. This is the value that is stored in sadb_sa_auth or sadb_sa_encrypt if this algorithm is selected. 今のアルゴリズムについてのアルゴリズム識別子値。もし今 のアルゴリズムが選択されるなら、これは sadb_sa_auth や sadb_sa_encrypt で格納された値である。 sadb_alg_ivlen The length of the initialization vector to be used for the algorithm. If an IV is not needed, this value MUST be set to zero. アルゴリズムのために使用される初期ベクトルの長さ。もし IV が必要でないなら、この値はゼロにセットされなければな らない (MUST)。 sadb_alg_minbits The minimum acceptable key length, in bits. A value of zero is invalid. 受け入れられるビットでの最小の鍵長。値ゼロは、無効であ る。 sadb_alg_maxbits The maximum acceptable key length, in bits. A value of zero is invalid. The minimum MUST NOT be greater than the maximum. 受け入れられるビットでの最大の鍵長。値ゼロは、無効であ る。最小値は、最大値より決して大きくあってはならない。 2.3.9 SPI Range Extension 2.3.9 SPI 範囲拡張 One PF_KEY message, SADB_GETSPI, might need a range of acceptable SPI values. This extension performs such a function. 1 つの PF_KEY メッセージ、SADB_GETSPI は、受け入れられる SPI 値の範囲 を必要とするかもしれない。この拡張は、そのような機能をおこなう。 struct sadb_spirange { uint16_t sadb_spirange_len; uint16_t sadb_spirange_exttype; uint32_t sadb_spirange_min; uint32_t sadb_spirange_max; uint32_t sadb_spirange_reserved; }; /* sizeof(struct sadb_spirange) == 16 */ sadb_spirange_min The minimum acceptable SPI value. 受け入れられる最小の SPI 値。 sadb_spirange_max The maximum acceptable SPI value. The maximum MUST be greater than or equal to the minimum. 受け入れられる最大の SPI 値。最大は、最小よりも大きい か等しくなければならない (MUST)。 2.4 Illustration of Message Layout メッセージレイアウトの実例 The following shows how the octets are laid out in a PF_KEY message. Optional fields are indicated as such. 次に述べるものは、PF_KEY メッセージでオクテットがどのように配置される かを示す。オプションのフィールドは、そういうものとして指し示される。 The base header is as follows: 基本ヘッダは、次のとおりである: 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 +---------------+---------------+---------------+---------------+ | ...version | sadb_msg_type | sadb_msg_errno| ...msg_satype | +---------------+---------------+---------------+---------------+ | sadb_msg_len | sadb_msg_reserved | +---------------+---------------+---------------+---------------+ | sadb_msg_seq | +---------------+---------------+---------------+---------------+ | sadb_msg_pid | +---------------+---------------+---------------+---------------+ The base header may be followed by one or more of the following extension fields, depending on the values of various base header fields. The following fields are ordered such that if they appear, they SHOULD appear in the order presented below. 基本ヘッダは、さまざまな基本ヘッダフィールド値に依存して、1 つか多くの 続く拡張フィールドにより続けられるかもしれない。続くフィールドは、もし それらが現れるなら、下で表される順序で現れるべきであるように、命じられ る。 An extension field MUST not be repeated. If there is a situation where an extension MUST be repeated, it should be brought to the attention of the authors. 拡張フィールドは、繰り返されてはならない (MUST)。もし拡張が繰り返され なければならない (MUST) 状況があるなら、著者の注意へともたらすべきであ る。 The Association extension 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 +---------------+---------------+---------------+---------------+ | sadb_sa_len | sadb_sa_exttype | +---------------+---------------+---------------+---------------+ | sadb_sa_spi | +---------------+---------------+---------------+---------------+ | ...replay | sadb_sa_state | sadb_sa_auth |sadb_sa_encrypt| +---------------+---------------+---------------+---------------+ | sadb_sa_flags | +---------------+---------------+---------------+---------------+ Association 拡張 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 +---------------+---------------+---------------+---------------+ | sadb_sa_len | sadb_sa_exttype | +---------------+---------------+---------------+---------------+ | sadb_sa_spi | +---------------+---------------+---------------+---------------+ | ...replay | sadb_sa_state | sadb_sa_auth |sadb_sa_encrypt| +---------------+---------------+---------------+---------------+ | sadb_sa_flags | +---------------+---------------+---------------+---------------+ The Lifetime extension +---------------+---------------+---------------+---------------+ | sadb_lifetime_len | sadb_lifetime_exttype | +---------------+---------------+---------------+---------------+ | sadb_lifetime_allocations | +---------------+---------------+---------------+---------------+ | sadb_lifetime_bytes | | (64 bits) | +---------------+---------------+---------------+---------------+ | sadb_lifetime_addtime | | (64 bits) | +---------------+---------------+---------------+---------------+ | sadb_lifetime_usetime | | (64 bits) | +---------------+---------------+---------------+---------------+ Lifetime 拡張 +---------------+---------------+---------------+---------------+ | sadb_lifetime_len | sadb_lifetime_exttype | +---------------+---------------+---------------+---------------+ | sadb_lifetime_allocations | +---------------+---------------+---------------+---------------+ | sadb_lifetime_bytes | | (64 bits) | +---------------+---------------+---------------+---------------+ | sadb_lifetime_addtime | | (64 bits) | +---------------+---------------+---------------+---------------+ | sadb_lifetime_usetime | | (64 bits) | +---------------+---------------+---------------+---------------+ The Address extension +---------------+---------------+---------------+---------------+ | sadb_address_len | sadb_address_exttype | +---------------+---------------+---------------+---------------+ | _address_proto| ..._prefixlen | sadb_address_reserved | +---------------+---------------+---------------+---------------+ > Some form of 64-bit aligned struct sockaddr goes here. < +---------------+---------------+---------------+---------------+ Address 拡張 +---------------+---------------+---------------+---------------+ | sadb_address_len | sadb_address_exttype | +---------------+---------------+---------------+---------------+ | _address_proto| ..._prefixlen | sadb_address_reserved | +---------------+---------------+---------------+---------------+ > 64-bit おきに配置される struct sockaddr の、ある形式がここに < < 置かれる > +---------------+---------------+---------------+---------------+ The Key extension +---------------+---------------+---------------+---------------+ | sadb_key_len | sadb_key_exttype | +---------------+---------------+---------------+---------------+ | sadb_key_bits | sadb_key_reserved | +---------------+---------------+---------------+---------------+ > A key, padded to 64-bits, most significant bits to least. > +---------------+---------------+---------------+---------------+ Key 拡張 +---------------+---------------+---------------+---------------+ | sadb_key_len | sadb_key_exttype | +---------------+---------------+---------------+---------------+ | sadb_key_bits | sadb_key_reserved | +---------------+---------------+---------------+---------------+ > 最上位から最下位への、64-bits にパッドされた鍵。 > +---------------+---------------+---------------+---------------+ The Identity extension +---------------+---------------+---------------+---------------+ | sadb_ident_len | sadb_ident_exttype | +---------------+---------------+---------------+---------------+ | sadb_ident_type | sadb_ident_reserved | +---------------+---------------+---------------+---------------+ | sadb_ident_id | | (64 bits) | +---------------+---------------+---------------+---------------+ > A null-terminated C-string which MUST be padded out for > < 64-bit alignment. < +---------------+---------------+---------------+---------------+ Identity 拡張 +---------------+---------------+---------------+---------------+ | sadb_ident_len | sadb_ident_exttype | +---------------+---------------+---------------+---------------+ | sadb_ident_type | sadb_ident_reserved | +---------------+---------------+---------------+---------------+ | sadb_ident_id | | (64 bits) | +---------------+---------------+---------------+---------------+ > 64-bit 配置のためにパッドされなければならない (MUST) null で > < 終了する C 文字列。 < +---------------+---------------+---------------+---------------+ The Sensitivity extension +---------------+---------------+---------------+---------------+ | sadb_sens_len | sadb_sens_exttype | +---------------+---------------+---------------+---------------+ | sadb_sens_dpd | +---------------+---------------+---------------+---------------+ | ...sens_level | ...sens_len |..._integ_level| ..integ_len | +---------------+---------------+---------------+---------------+ | sadb_sens_reserved | +---------------+---------------+---------------+---------------+ > The sensitivity bitmap, followed immediately by the < < integrity bitmap, each is an array of uint64_t. > +---------------+---------------+---------------+---------------+ Sensitivity 拡張 +---------------+---------------+---------------+---------------+ | sadb_sens_len | sadb_sens_exttype | +---------------+---------------+---------------+---------------+ | sadb_sens_dpd | +---------------+---------------+---------------+---------------+ | ...sens_level | ...sens_len |..._integ_level| ..integ_len | +---------------+---------------+---------------+---------------+ | sadb_sens_reserved | +---------------+---------------+---------------+---------------+ > 完全性ビットマップにより直ちに続けられる、感度ビットマップ。 < < それぞれは、uint64_t の配列である。 > +---------------+---------------+---------------+---------------+ The Proposal extension +---------------+---------------+---------------+---------------+ | sadb_prop_len | sadb_prop_exttype | +---------------+---------------+---------------+---------------+ |...prop_replay | sadb_prop_reserved | +---------------+---------------+---------------+---------------+ > One or more combinations, specified as follows... < +---------------+---------------+---------------+---------------+ Proposal 拡張 +---------------+---------------+---------------+---------------+ | sadb_prop_len | sadb_prop_exttype | +---------------+---------------+---------------+---------------+ |...prop_replay | sadb_prop_reserved | +---------------+---------------+---------------+---------------+ > 次のとおりに指定される、1 つか多くの組み合わせ。 < +---------------+---------------+---------------+---------------+ Combination +---------------+---------------+---------------+---------------+ |sadb_comb_auth |sadb_comb_encr | sadb_comb_flags | +---------------+---------------+---------------+---------------+ | sadb_comb_auth_minbits | sadb_comb_auth_maxbits | +---------------+---------------+---------------+---------------+ | sadb_comb_encrypt_minbits | sadb_comb_encrypt_maxbits | +---------------+---------------+---------------+---------------+ | sadb_comb_reserved | +---------------+---------------+---------------+---------------+ | sadb_comb_soft_allocations | +---------------+---------------+---------------+---------------+ | sadb_comb_hard_allocations | +---------------+---------------+---------------+---------------+ | sadb_comb_soft_bytes | | (64 bits) | +---------------+---------------+---------------+---------------+ | sadb_comb_hard_bytes | | (64 bits) | +---------------+---------------+---------------+---------------+ | sadb_comb_soft_addtime | | (64 bits) | +---------------+---------------+---------------+---------------+ | sadb_comb_hard_addtime | | (64 bits) | +---------------+---------------+---------------+---------------+ | sadb_comb_soft_usetime | | (64 bits) | +---------------+---------------+---------------+---------------+ | sadb_comb_hard_usetime | | (64 bits) | +---------------+---------------+---------------+---------------+ 組み合わせ +---------------+---------------+---------------+---------------+ |sadb_comb_auth |sadb_comb_encr | sadb_comb_flags | +---------------+---------------+---------------+---------------+ | sadb_comb_auth_minbits | sadb_comb_auth_maxbits | +---------------+---------------+---------------+---------------+ | sadb_comb_encrypt_minbits | sadb_comb_encrypt_maxbits | +---------------+---------------+---------------+---------------+ | sadb_comb_reserved | +---------------+---------------+---------------+---------------+ | sadb_comb_soft_allocations | +---------------+---------------+---------------+---------------+ | sadb_comb_hard_allocations | +---------------+---------------+---------------+---------------+ | sadb_comb_soft_bytes | | (64 bits) | +---------------+---------------+---------------+---------------+ | sadb_comb_hard_bytes | | (64 bits) | +---------------+---------------+---------------+---------------+ | sadb_comb_soft_addtime | | (64 bits) | +---------------+---------------+---------------+---------------+ | sadb_comb_hard_addtime | | (64 bits) | +---------------+---------------+---------------+---------------+ | sadb_comb_soft_usetime | | (64 bits) | +---------------+---------------+---------------+---------------+ | sadb_comb_hard_usetime | | (64 bits) | +---------------+---------------+---------------+---------------+ The Supported Algorithms extension +---------------+---------------+---------------+---------------+ | sadb_supported_len | sadb_supported_exttype | +---------------+---------------+---------------+---------------+ | sadb_supported_reserved | +---------------+---------------+---------------+---------------+ Supported Algorithms 拡張 +---------------+---------------+---------------+---------------+ | sadb_supported_len | sadb_supported_exttype | +---------------+---------------+---------------+---------------+ | sadb_supported_reserved | +---------------+---------------+---------------+---------------+ Followed by one or more Algorithm Descriptors +---------------+---------------+---------------+---------------+ | sadb_alg_id | sadb_alg_ivlen| sadb_alg_minbits | +---------------+---------------+---------------+---------------+ | sadb_alg_maxbits | sadb_alg_reserved | +---------------+---------------+---------------+---------------+ 1 つか多くの Algorithm Descriptors により続けられる +---------------+---------------+---------------+---------------+ | sadb_alg_id | sadb_alg_ivlen| sadb_alg_minbits | +---------------+---------------+---------------+---------------+ | sadb_alg_maxbits | sadb_alg_reserved | +---------------+---------------+---------------+---------------+ The SPI Range extension +---------------+---------------+---------------+---------------+ | sadb_spirange_len | sadb_spirange_exttype | +---------------+---------------+---------------+---------------+ | sadb_spirange_min | +---------------+---------------+---------------+---------------+ | sadb_spirange_max | +---------------+---------------+---------------+---------------+ | sadb_spirange_reserved | +---------------+---------------+---------------+---------------+ SPI Range 拡張 +---------------+---------------+---------------+---------------+ | sadb_spirange_len | sadb_spirange_exttype | +---------------+---------------+---------------+---------------+ | sadb_spirange_min | +---------------+---------------+---------------+---------------+ | sadb_spirange_max | +---------------+---------------+---------------+---------------+ | sadb_spirange_reserved | +---------------+---------------+---------------+---------------+ ------------------------------------------------------------------------- 3 Symbolic Names 3 記号による名前 This section defines various symbols used with PF_KEY and the semantics associated with each symbol. Applications MUST use the symbolic names in order to be portable. The numeric definitions shown are for illustrative purposes, unless explicitly stated otherwise. The numeric definition MAY vary on other systems. The symbolic name MUST be kept the same for all conforming implementations. このセクションは、PF_KEY で使用されるさまざまなシンボルと、それぞれの シンボルに関連されるセマンティクスを定義する。アプリケーションは、移植 性があるために、この記号による名前を使用しなければならない (MUST)。も し明示的に別の方法で述べられなければ、示される数値の定義は、実例となる 目的のためである。この数値の定義は、他のシステムで異なるかもしれない (MAY)。記号による名前は、すべての準拠している実装のために、同じに保ち 続けなければならない (MUST)。 3.1 Message Types 3.1 メッセージタイプ The following message types are used with PF_KEY. These are defined in the file . 次のメッセージタイプは、PF_KEY で使用される。これらは、ファイル で定義される。 #define SADB_RESERVED 0 #define SADB_GETSPI 1 #define SADB_UPDATE 2 #define SADB_ADD 3 #define SADB_DELETE 4 #define SADB_GET 5 #define SADB_ACQUIRE 6 #define SADB_REGISTER 7 #define SADB_EXPIRE 8 #define SADB_FLUSH 9 #define SADB_DUMP 10 /* not used normally */ /* 普通には使用されない */ #define SADB_MAX 10 Each message has a behavior. A behavior is defined as where the initial message travels (e.g. user to kernel), and what subsequent actions are expected to take place. Contents of messages are illustrated as: それぞれのメッセージは動作を持つ。動作は、初期メッセージが進み (たとえ ばユーザから kernel に)、続く動作が生じてほしいと期待されることとして 定義される。メッセージの内容は、(次のように) 実例で説明される: The SA extension is sometimes used only for its SPI field. If all other fields MUST be ignored, this is represented by "SA(*)". SA 拡張は、その SPI フィールドのためだけに、ときどき使用される。もしす べての他のフィールドが無視されなければならない (MUST) なら、これは "SA(*)" により表される。 The lifetime extensions are represented with one to three letters after the word "lifetime," representing (H)ARD, (S)OFT, and (C)URRENT. 単語 "lifetime" の後に、(H)ARD, (S)OFT と (C)URRENT を表している 1 つ から 3 つの文字で、生存時間拡張は表される。 The address extensions are represented with one to three letters after the word "address," representing (S)RC, (D)ST, (P)ROXY. 単語 "address" の後に、(S)RC, (D)ST, (P)ROXY を表している 1 つから 3 つの文字で、アドレス拡張は表される。 NOTE: Some security association types do not use a source address for SA identification, where others do. This may cause EEXIST errors for some SA types where others do not report collisions. It is expected that application authors know enough about the underlying security association types to understand these differences. 注意: あるセキュリティアソシエーションタイプは、他がするようなとこ ろの、SA 識別子のための始点アドレスを使用しない。これは他が 衝突をレポートしない、ある SA タイプについて EEXIST エラー を引き起こすかもしれない。アプリケーション作者が、これらの 違いを理解するために、基礎をなすセキュリティアソシエーショ ンタイプについて十分に知っていることが期待される。 The key extensions are represented with one or two letters after the word "key," representing (A)UTH and (E)NCRYPT. 単語 "key" の後に、(A)UTH と (E)NCRYPT を表している 1 つか 2 つの文字 で、鍵拡張は表される。 The identity extensions are represented with one or two letters after the word "identity," representing (S)RC and (D)ST. 単語 "identity" の後に、(S)RC と (D)ST を表している 1 つか 2 つの文字 で、身元拡張は表される。 In the case of an error, only the base header is returned. エラーケースで、基本ヘッダのみが返される。 Note that any standard error could be returned for any message. どんなメッセージについても、どんな標準エラーも返されることができること に注意しなさい。 Typically, they will be either one of the errors specifically listed in the description for a message or one of the following: 典型的にこれらのエラーは、メッセージに対し明確に記述してリストしている エラーの 1 つか、次に述べるものの 1 つである。 EINVAL Various message improprieties, including SPI ranges that are malformed. 誤った SPI 範囲を含む、さまざまなメッセージ不適当。 ENOMEM Needed memory was not available. 必要とされるメモリが利用可能ではない。 ENOBUFS Needed memory was not available. 必要とされるメモリが利用可能ではない。 EMSGSIZ The message exceeds the maximum length allowed. メッセージが割り当てられた最大長を越える。 3.1.1 SADB_GETSPI 3.1.1 SADB_GETSPI メッセージ The SADB_GETSPI message allows a process to obtain a unique SPI value for given security association type, source address, and destination address. This message followed by an SADB_UPDATE is one way to create a security association (SADB_ADD is the other method). The process specifies the type in the base header, the source and destination address in address extension. If the SADB_GETSPI message is in response to a kernel-generated SADB_ACQUIRE, the sadb_msg_seq MUST be the same as the SADB_ACQUIRE message. The application may also specify the SPI. This is done by having the kernel select within a range of SPI values by using the SPI range extension. To specify a single SPI value to be verified, the application sets the high and low values to be equal. Permitting range specification is important because the kernel can allocate an SPI value based on what it knows about SPI values already in use. The kernel returns the same message with the allocated SPI value stored in the spi field of an association extension. The allocate SPI (and destination address) refer to a LARVAL security association. An SADB_UPDATE message can later be used to add an entry with the requested SPI value. SADB_GETSPI メッセージは、プロセスが、与えられたセキュリティアソシエー ション、始点アドレスと終点アドレスについて、一意な SPI 値を得るのを可 能にする。SADB_UPDATE により続かれるこのメッセージは、セキュリティアソ シエーションを作り出すための 1 つの方法である (SADB_ADD は、別の方法で ある)。プロセスは、基本ヘッダでのタイプ、アドレス拡張での始点と終点ア ドレスを特定する。もし SADB_GETSPI メッセージが kernel の生成した SADB_ACQUIRE メッセージへの応答であるなら、sadb_msg_seq は SADB_ACQUIRE メッセージと同じでなければならない (MUST)。アプリケーショ ンは SPI も指定するかもしれない。これは、SPI 範囲拡張を使用することに よる SPI 値の範囲内の kernel 選択をもつことによりおこなわれる。確認さ れるたった 1 つの SPI 値を指定するために、アプリケーションは最大値と最 小値を等しくしてセットする。許可する範囲指定は重要である。なぜなら、 kernel はすでに使用されている SPI 値を知っていることに基づき、kernel は SPI 値を割り当てることができるからである。kernel は、アソシエーショ ン拡張の spi フィールドに格納された割り当てられた SPI 値を持つ同じメッ セージを返す。割り当てた SPI (と終点アドレス) は、LARVAL セキュリティ アソシエーションをさして言う。SADB_UPDATE メッセージは、要求される SPI 値を持つエントリを追加するために、後で使用される。 It is recommended that associations that are created with SADB_GETSPI SHOULD be automatically deleted within a fixed amount of time if they are not updated by an SADB_UPDATE message. This allows SA storage not to get cluttered with larval associations. SADB_GETSPI で作り出されたアソシエーションは、もしそのアソシエーション が SADB_UPDATE メッセージにより更新されないなら、固定化された時間内に 自動的に削除されるべきである (SHOULD) ことが推奨される。これは SA 格納 が larval アソシエーションで散乱されていないことを可能にする。 The message behavior of the SADB_GETSPI message is: SADB_GETSPI メッセージにメッセージ動作は、(次のとおりである): Send an SADB_GETSPI message from a user process to the kernel. ユーザプロセスから kernel に、SADB_GETSPI メッセージを送信する。 The kernel returns the SADB_GETSPI message to all listening processes. kernel は、すべての聞いているプロセスに、SADB_GETSPI メッセージを 返す。 Errors: エラー: EEXIST Requested SPI or SPI range is not available or already used. 要求された SPI や SPI 範囲は、利用できないか、すでに使用 されている。 3.1.2 SADB_UPDATE Message 3.1.2 SADB_UPDATE メッセージ The SADB_UPDATE message allows a process to update the information in an existing Security Association. Since SADB_GETSPI does not allow setting of certain parameters, this message is needed to fully form the SADB_SASTATE_LARVAL security association created with SADB_GETSPI. The format of the update message is a base header, followed by an association header and possibly by several extension headers. The kernel searches for the security association with the same type, spi, source address and destination address specified in the message and updates the Security Association information using the content of the SADB_UPDATE message. SADB_UPDATE メッセージは、プロセスが、存在する Security Association 内 の情報更新を可能にする。SADB_GETSPI は確実なパラメータのセットを割り当 てないので、このメッセージは SADB_GETSPI で作成された SADB_SASTATE_LARVAL セキュリティアソシエーションを完全に構成するために 必要とされる。更新するメッセージの形式は、基本ヘッダと、それに続くアソ シエーションヘッダと、ひょっとしたらいくつかの拡張ヘッダである。kernel は、メッセージ内で指定された同じタイプ、spi、始点アドレスと終点アドレ スを持つセキュリティアソシエーションを捜し、SADB_UPDATE メッセージの内 容を使用して Security Association 情報を更新する。 The kernel MAY disallow SADB_UPDATE to succeed unless the message is issued from the same socket that created the security association. Such enforcement significantly reduces the chance of accidental changes to an in-use security association. Malicious trusted parties could still issue an SADB_FLUSH or SADB_DELETE message, but deletion of associations is more easily detected and less likely to occur accidentally than an erroneous SADB_UPDATE. The counter argument to supporting this behavior involves the case where a user-space key management application fails and is restarted. The new instance of the application will not have the same socket as the creator of the security association. もしメッセージがセキュリティアソシエーションを作成した同じ socket から 発行されなければ、kernel は SADB_UPDATE が成功するのを許可しないかもし れない (MAY)。このような強制は、使用しているセキュリティアソシエーショ ンに対し、思いがけない変更の機会を減らす。悪意のある信頼されたパーティ は、なお SADB_FLUSH や SADB_DELETE メッセージを発行できるがしかし、ア ソシエーションの削除は、より簡単に発見され、誤った SADB_UPDATE より偶 然に起こりそうでない (?)。この動作をサポートする逆の議論は、ユーザ空間 鍵管理アプリケーションが失敗し再起動するケースを必然的に含む。このアプ リケーションの新しいインスタンスは、セキュリティアソシエーションの作成 者として同じ socket を持たないだろう。 The kernel MUST sanity check all significant values submitted in an SADB_UPDATE message before changing the SA in its database and MUST return EINVAL if any of the values are invalid. Examples of checks that should be performed are DES key parity bits, key length checking, checks for keys known to be weak for the specified algorithm, and checks for flags or parameters known to be incompatible with the specified algorithm. kernel は、そのデータベース内の SA を変更する前に SADB_UPDATE メッセー ジで提出される、すべての重要な値を sanity check しなければならなく (MUST)、もし何らかの値が無効であるなら、EINVAL を返さなければならない (MUST)。おこなわれるべきチェック例は、DES 鍵パリティビット、鍵長チェッ ク、特定のアルゴリズムについて弱点であると知られた鍵についてのチェック と特定のアルゴリズムで矛盾であると知られたフラグやパラメータについての チェックである。 Only SADB_SASTATE_MATURE SAs may be submitted in an SADB_UPDATE message. If the original SA is an SADB_SASTATE_LARVAL SA, then any value in the SA may be changed except for the source address, destination address, and SPI. If the original SA is an SADB_SASTATE_DEAD SA, any attempt to perform an SADB_UPDATE on the SA MUST return EINVAL. It is not valid for established keying or algorithm information to change without the SPI changing, which would require creation of a new SA rather than a change to an existing SA. Once keying and algorithm information is negotiated, address and identity information is fixed for the SA. Therefore, if the original SA is an SADB_SASTATE_MATURE or DYING SA, only the sadb_sa_state field in the SA header and lifetimes (hard, soft, and current) may be changed and any attempt to change other values MUST result in an error return of EINVAL. SADB_SASTATE_MATURE SAs のみは、SADB_UPDATE メッセージで提出されるかも しれない。もしオリジナル SA が SADB_SASTATE_LARVAL SA であるなら、SA の何らかの値は、始点アドレス、終点アドレス、SPI があるという点を除いて は、変更されるかもしれない。もしオリジナル SA が SADB_SASTATE_DEAD SA なら、その SA 上で SADB_UPDATE をおこなうためのどんな試みも、EINVAL を 返さなければならない (MUST)。確立された鍵やアルゴリズム情報は、SPI 変 更なしに変更することは有効ではなく、そしてそれは存在している SA への変 更よりもむしろ新しい SA の作成を要求するだろう。いったん鍵とアルゴリズ ム情報が取り決められると、アドレスと身元情報は SA について固定される。 それゆえに、もしオリジナル SA が SADB_SASTATE_MATURE や DYING SA なら SA ヘッダ内の sadb_sa_state フィールドと生存時間 (hard, soft と current) のみが変更されるだろうし、他の値を変更するどんな試みも EINVAL エラーを返す結果でなければならない (MUST)。 The message behavior of the SADB_UPDATE message is: SADB_UPDATE メッセージのメッセージ動作は、(次のとおりである): Send an SADB_UPDATE message from a user process to the kernel. ユーザプロセスから kernel に、SADB_UPDATE メッセージを送信する。 The kernel returns the SADB_UPDATE message to all listening processes. kernel は、すべての聞いているプロセスに、SADB_UPDATE メッセージを 返す。 The keying material is not returned on the message from the kernel to listening sockets because listeners might not have the privileges to see such keying material. 鍵材料は、kernel から聞いている sockets にメッセージで返されない。なぜ ならリスナーは、そのような鍵材料を見るための特権を持っていないかもしれ ないからである。 Errors: エラー: ESRCH The security association to be updated was not found. 更新されるセキュリティアソシエーションは見つけられなかっ た。 EINVAL In addition to other possible causes, this error is returned if sanity checking on the SA values (such as the keys) fails. 他の可能性のある原因に加えて、もし (鍵のような) SA 値の sanity checking が失敗したなら、このエラーは返される。 EACCES Insufficient privilege to update entry. The socket issuing the SADB_UPDATE is not creator of the entry to be updated. エントリを更新するのに不十分な特権。SADB_UPDATE を発行す る socket は、更新されるエントリの作成者ではない。 3.1.3 SADB_ADD 3.1.3 SADB_ADD メッセージ The SADB_ADD message is nearly identical to the SADB_UPDATE message, except that it does not require a previous call to SADB_GETSPI. The SADB_ADD message is used in manual keying applications, and in other cases where the uniqueness of the SPI is known immediately. SADB_ADD メッセージは、SADB_GETSPI に対して前の呼び出しを必要としない という点を除いて、SADB_UDPATE メッセージとほとんど同じである。SADB_ADD メッセージは、手動鍵設定アプリケーションと、SPI の唯一さが直接知られて いるケースで使用される。 An SADB_ADD message is also used when negotiation is finished, and the second of a pair of associations is added. The SPI for this association was determined by the peer machine. The sadb_msg_seq MUST be set to the value set in a kernel-generated SADB_ACQUIRE so that both associations in a pair are bound to the same ACQUIRE request. SADB_ADD メッセージもまた、取り決めが終了した時、使用される。そしてア ソシエーションペアの 2 番目が追加される。このアソシエーションのための SPI は、peer マシンにより決定される。ペアの両方のアソシエーションは同 じ ACQUIRE 要求に割り当てられるので、sadb_msg_seq は kernel が生成した SADB_ACQUIRE でセットされた値にセットされなければならない (MUST)。 The kernel MUST sanity check all used fields in the SA submitted in an SADB_ADD message before adding the SA to its database and MUST return EINVAL if any of the values are invalid. kernel は、そのデータベースに SA を追加する前に、SADB_ADD メッセージ内 の提出される SA のすべての使用されるフィールドを sanity check しなけれ ばならなく (MUST)、もし何らかの値が無効であるなら、EINVAL を返さなけれ ばならない (MUST)。 Only SADB_SASTATE_MATURE SAs may be submitted in an SADB_ADD message. SADB_SASTATE_LARVAL SAs are created by SADB_GETSPI and it is not sensible to add a new SA in the DYING or SADB_SASTATE_DEAD state. Therefore, the sadb_sa_state field of all submitted SAs MUST be SADB_SASTATE_MATURE and the kernel MUST return an error if this is not true. 唯一 SADB_SASTATE_MATURE SAs のみは、SADB_ADD メッセージで提出されるか もしれない。SADB_SASTATE_LARVAL SAs は、SADB_GETSPI により作り出され、 DYING or SADB_SASTATE_DEAD 状態で新しい SA を追加することは賢明ではな い。それゆえに、すべての提出される SAs の sadb_sa_state フィールドは、 SADB_SASTATE_MATURE でなければならなく (MUST)、もしこれが真でないなら kernel はエラーを返さなければならない (MUST)。 The message behavior of the SADB_ADD message is: SADB_ADD メッセージのメッセージ動作は、(次のとおりである): Send an SADB_ADD message from a user process to the kernel. ユーザプロセスから kernel に、SADB_ADD メッセージを送信する。 The kernel returns the SADB_ADD message to all listening processes. kernel は、すべての聞いているプロセスに、SADB_ADD メッセージを返 す。 The keying material is not returned on the message from the kernel to listening sockets because listeners may not have the privileges to see such keying material. 鍵材料は、kernel から聞いている sockets にメッセージで返されない。なぜ ならリスナーは、そのような鍵材料を見るための特権を持っていないかもしれ ないからである。 Errors: エラー: EEXIST The security association that was to be added already exists. 追加される予定だったセキュリティアソシエーションは、すで に存在する。 EINVAL In addition to other possible causes, this error is returned if sanity checking on the SA values (such as the keys) fails. 他の可能性のある原因に加えて、もし (鍵のような) SA 値の sanity checking が失敗するなら、このエラーは返される。 3.1.4 SADB_DELETE 3.1.4 SADB_DELETE メッセージ The SADB_DELETE message causes the kernel to delete a Security Association from the key table. The delete message consists of the base header followed by the association, and the source and destination sockaddrs in the address extension. The kernel deletes the security association matching the type, spi, source address, and destination address in the message. SADB_DELETE メッセージは、kernel が鍵テーブルから Security Association を削除するのを可能にする。削除メッセージは、基本ヘッダと、それに続くア ソシエーション拡張とアドレス拡張の始点と終点 sockaddrs からなる。 kernel は、メッセージのタイプ、spi、始点アドレスと終点アドレスにマッチ するセキュリティアソシエーションを削除する。 The message behavior for SADB_DELETE is as follows: SADB_DELETE についてのメッセージ動作は、次のとおりである: Send an SADB_DELETE message from a user process to the kernel. ユーザプロセスから kernel に、SADB_DELETE メッセージを送信する。 The kernel returns the SADB_DELETE message to all listening processes. kernel は、すべての聞いているプロセスに SADB_DELETE メッセージを 返す。 3.1.5 SADB_GET 3.1.5 SADB_GET メッセージ The SADB_GET message allows a process to retrieve a copy of a Security Association from the kernel's key table. The get message consists of the base header follows by the relevant extension fields. The Security Association matching the type, spi, source address, and destination address is returned. SADB_GET メッセージは、プロセスが、kernel の鍵テーブルから Security Association コピーの検索を可能にする。get メッセージは、基本ヘッダと、 それに続く関連する拡張フィールドからなる。タイプ、spi、始点アドレスと 終点アドレスにマッチする Security Association が返される。 The message behavior of the SADB_GET message is: SADB_GET メッセージのメッセージ動作は、(次のとおりである): Send an SADB_GET message from a user process to the kernel. ユーザプロセスから kernel に、SADB_GET メッセージを送信する。 The kernel returns the SADB_GET message to the socket that sent the SADB_GET message. kernel は、SADB_GET メッセージを送信した socket に SADB_GET メッ セージを返す。 Errors: エラー: ESRCH The sought security association was not found. 捜したセキュリティアソシエーションは見付けられなかった。 3.1.6 SADB_ACQUIRE 3.1.6 SADB_ACQUIRE メッセージ The SADB_ACQUIRE message is typically sent only by the kernel to key socket listeners who have registered their key socket (see SADB_REGISTER message). SADB_ACQUIRE messages can be sent by application-level consumers of security associations (such as an OSPFv2 implementation that uses OSPF security). The SADB_ACQUIRE message is a base header along with an address extension, possibly an identity extension, and a proposal extension. The proposed situation contains a list of desirable algorithms that can be used if the algorithms in the base header are not available. The values for the fields in the base header and in the security association data which follows the base header indicate the properties of the Security Association that the listening process should attempt to acquire. If the message originates from the kernel (i.e. the sadb_msg_pid is 0), the sadb_msg_seq number MUST be used by a subsequent SADB_GETSPI and SADB_UPDATE, or subsequent SADB_ADD message to bind a security association to the request. This avoids the race condition of two TCP connections between two IP hosts that each require unique associations, and having one steal another's security association. The sadb_msg_errno and sadb_msg_state fields should be ignored by the listening process. SADB_ACQURE メッセージは、鍵 socket を登録した (SADB_REGISTER メッセー ジを参照しなさい) socket リスナーに対して kernel のみにより典型的に送 信される。SADB_ACQUIRE メッセージは、(OSPF セキュリティを使用する OSPFv2 実装のような) セキュリティアソシエーションのアプリケーションレ ベル consumers により送信されることができる。SADB_ACQUIRE メッセージは アドレス拡張とひょっとしたら身元拡張と提案拡張といっしょの、基本ヘッダ である。提案される状況は、もし基本ヘッダのアルゴリズムが利用できないな ら、使用されることができる望ましいアルゴリズムのリストを含む。基本ヘッ ダと基本ヘッダに続くセキュリティアソシエーションデータ内のフィールド値 は、聞いているプロセスが獲得しようと試みられるべき Security Association のプロパティを指し示す。もしメッセージが kernel から生じる (すなわち sadb_msg_pid が 0) なら、sadb_msg_seq 番号は、要求にセキュリ ティアソシエーションを結びつけるために、続く SADB_GETSPI と SADB_UPDATE、または続く SADB_ADD メッセージにより使用されなければなら ない (MUST)。これは、2 つの IP ホストそれぞれが一意のアソシエーション を要求し、他のセキュリティアソシエーションをこっそり取るホスト間の 2 つの TCP コネクション競合状態を避ける。sadb_msg_errno と sadb_msg_state フィールドは、聞いているプロセスにより無視されるべきで ある。 The SADB_ACQUIRE message is typically triggered by an outbound packet that needs security but for which there is no applicable Security Association existing in the key table. If the packet can be sufficiently protected by more than one algorithm or combination of options, the SADB_ACQUIRE message MUST order the preference of possibilities in the Proposal extension. SADB_ACQUIRE メッセージは、鍵テーブルにある Security Association が適 用できないということがなければ (?、適用できなければ ?)、セキュリティを 必要とする外向けのパケットにより典型的にきっかけとされる。もしパケット が 1 つのアルゴリズムやオプションの組み合わせ以上のものにより十分に保 護されることができるなら、SADB_ACQUIRE メッセージは、Proposal 拡張で可 能性選択の処理しなければならない (MUST)。 There are three messaging behaviors for SADB_ACQUIRE. The first is where the kernel needs a security association (e.g. for IPsec). SADB_ACQUIRE について、3 つのメッセージ動作がある。最初は、kernel がセ キュリティアソシエーションを必要とする場合である (たとえば IPsec)。 The kernel sends an SADB_ACQUIRE message to registered sockets. kernel は、登録された sockets に SADB_ACQUIRE メッセージを送信する。 NOTE: The address(SD) extensions MUST have the port fields filled in with the port numbers of the session requiring keys if appropriate. 注意: アドレス (SD) 拡張は、もし適するなら鍵を要求するセッショ ンの port 番号で書かれた port フィールドを持たなければな らない (MUST)。 The second is when, for some reason, key management fails, it can send an ACQUIRE message with the same sadb_msg_seq as the initial ACQUIRE with a non-zero errno. 2 番目は、ある理由で鍵管理が失敗した時、ゼロでない errno を持つ初期 ACQUIRE として同じ sadb_msg_seq の ACQUIRE メッセージを送信できること である。 Send an SADB_ACQUIRE to indicate key management failure. 鍵管理失敗を指し示すために、SADB_ACQUIRE を送信する。 The third is where an application-layer consumer of security associations (e.g. an OSPFv2 or RIPv2 daemon) needs a security association. 3 番目は、セキュリティアソシエーションのアプリケーション層 consumer (たとえば OSPFv2 や RIPv2 デーモン) がセキュリティアソシエーションを必 要とする場合である。 Send an SADB_ACQUIRE message from a user process to the kernel. ユーザプロセスから kernel に、SADB_ACQUIRE メッセージを送信する。 The kernel returns an SADB_ACQUIRE message to registered sockets. kernel は、登録された sockets に SADB_ACQUIRE メッセージを返す。 The user-level consumer waits for an SADB_UPDATE or SADB_ADD message for its particular type, and then can use that association by using SADB_GET messages. ユーザレベル consumer は、その特定のタイプについて SADB_UPDATE や SADB_ADD メッセージを待ち、SADB_GET メッセージを使用することによ り、そのアソシエーションを使用することができる。 Errors: エラー: EINVAL Invalid acquire request. 無効な獲得要求。 EPROTONOSUPPORT No KM application has registered with the Key Engine as being able to obtain the requested SA type, so the requested SA cannot be acquired. SA タイプを得ることができるとしての Key Engine で登録する KM アプリケーションがない。それで要求された SA は獲得され ることができない。 3.1.7 SADB_REGISTER 3.1.7 SADB_REGISTER メッセージ The SADB_REGISTER message allows an application to register its key socket as able to acquire new security associations for the kernel. SADB_REGISTER allows a socket to receive SADB_ACQUIRE messages for the type of security association specified in sadb_msg_satype. The application specifies the type of security association that it can acquire for the kernel in the type field of its register message. If an application can acquire multiple types of security association, it MUST register each type in a separate message. Only the base header is needed for the register message. Key management applications MAY register for a type not known to the kernel, because the consumer may be in user-space (e.g. OSPFv2 security). SADB_REGISTER メッセージは、アプリケーションが kernel に対して新しいセ キュリティアソシエーションを獲得することができるとして、その鍵 socket の登録を可能にする。SADB_REGISTER は、socket が sadb_msg_satype で特定 されるセキュリティアソシエーションのタイプについて、SADB_ACQUIRE メッ セージ受信を可能にする。アプリケーションは、その register メッセージの タイプフィールドで kernel に対して獲得することができるセキュリティアソ シエーションのタイプを特定する。もしアプリケーションがセキュリティアソ シエーションの複数のタイプを獲得することができるなら、アプリケーション は別々のメッセージでそれぞれのタイプを登録しなければならない (MUST)。 鍵管理アプリケーションは、kernel に対し知られていないタイプについて登 録するかもしれない (MAY)。なぜなら consumer はユーザ空間内であるかもし れないからである (たとえば OSPFv2 セキュリティ)。 The reply of the SADB_REGISTER message contains a supported algorithm extension. That field contains an array of supported algorithms, one per octet. This allows key management applications to know what algorithm are supported by the kernel. SADB_REGISTER メッセージへのリプライは、サポートされるアルゴリズム拡張 を含む。そのフィールドは、オクテットあたり 1 つの、サポートされるアル ゴリズムの配列を含む。これは、鍵管理アプリケーションが kernel によりサ ポートされるアルゴリズムすべてについて知るのを可能にする。 In an environment where algorithms can be dynamically loaded and unloaded, an asynchronous SADB_REGISTER reply MAY be generated. The list of supported algorithms MUST be a complete list, so the application can make note of omissions or additions. アルゴリズムが動的にロードされアンロードされることができる環境で、非同 期 SADB_REGISTER リプライは生成されるかもしれない (MAY)。サポートされ るアルゴリズムのリストは、完全なリストでなければならなく (MUST)、それ でアプリケーションは省略や追加の記録をすることができる。 The messaging behavior of the SADB_REGISTER message is: SADB_REGISTER メッセージのメッセージ動作は、(次のとおりである): Send an SADB_REGISTER message from a user process to the kernel. ユーザプロセスから kernel に SADB_REGISTER メッセージを送信する。 The kernel returns an SADB_REGISTER message to registered sockets, with algorithm types supported by the kernel being indicated in the supported algorithms field. kernel は、サポートされるアルゴリズムフィールドに指し示されている kernel によりサポートされるアルゴリズムタイプを持って、登録された sockets に SADB_REGISTER メッセージを返す。 NOTE: This message may arrive asynchronously due to an algorithm being loaded or unloaded into a dynamically linked kernel. 注意: このメッセージは、アルゴリズムが動的にリンクされる kernel 内にロードされたりアンロードされるために、非同期に到着する かもしれない 3.1.8 SADB_EXPIRE Message 3.1.8 SADB_EXPIRE メッセージ The operating system kernel is responsible for tracking SA expirations for security protocols that are implemented inside the kernel. If the soft limit or hard limit of a Security Association has expired for a security protocol implemented inside the kernel, then the kernel MUST issue an SADB_EXPIRE message to all key socket listeners. If the soft limit or hard limit of a Security Association for a user-level security protocol has expired, the user-level protocol SHOULD issue an SADB_EXPIRE message. オペレーティングシステム kernel は、kernel の内部に実装されたセキュリ ティプロトコルの SA 期限切れを追跡することに対する責任がある。もし Security Association の soft 制限や hard 制限が kernel 内部に実装され たセキュリティプロトコルについて期限が切れるなら、それから kernel は、 すべての鍵 socket リスナーに SADB_EXPIRE メッセージを発行しなければな らない (MUST)。もしユーザレベルセキュリティプロトコルについての Security Association の soft 制限や hard 制限の期限が切れるなら、ユー ザレベルプロトコルは、SADB_EXPIRE メッセージを発行すべきである (SHOULD)。 The base header will contain the security association information followed by the source sockaddr, destination sockaddr, (and, if present, internal sockaddr,) (and, if present, one or both compartment bitmaps). 基本ヘッダは、始点 sockaddr、終点 sockaddr (と、もしあるなら、内側の sockaddr)、(と、もしあるなら、仕切りビットマップの 1 つか両方) により 続かれるセキュリティアソシエーション情報を含むだろう。 The lifetime extension of an SADB_EXPIRE message is important to indicate which lifetime expired. If a HARD lifetime extension is included, it indicates that the HARD lifetime expired. This means the association MAY be deleted already from the SADB. If a SOFT lifetime extension is included, it indicates that the SOFT lifetime expired. The CURRENT lifetime extension will indicate the current status, and comparisons to the HARD or SOFT lifetime will indicate which limit was reached. HARD lifetimes MUST take precedence over SOFT lifetimes, meaning if the HARD and SOFT lifetimes are the same, the HARD lifetime will appear on the EXPIRE message. The pathological case of HARD lifetimes being shorter than SOFT lifetimes is handled such that the SOFT lifetime will never expire. SADB_EXPIRE メッセージの生存時間拡張は、どの生存時間の期限が切れたかを 指し示すために重要である。もし HARD 生存時間拡張が含まれるなら、その HARD 生存時間の期限が切れたことを指し示す。もし SOFT 生存時間拡張が含 まれるなら、その SOFT 生存時間の期限が切れたことを指し示す。CURRENT 生 存時間拡張は現在の状態を指し示すだろうし、HARD や SOFT 生存時間に対す る比較はどの制限が到達したかを指し示すだろう。HARD 生存時間は、もし HARD と SOFT 生存時間が同じなら、HARD 生存時間は EXPIRE メッセージで現 れるだろうことを意味して、SOFT 生存時間よりも優先権を得なければならな い (MUST)。SOFT 生存時間より短い HARD 生存時間の病的なケースは、SOFT 生存時間が決して期限切れしないとして扱われる。 The messaging behavior of the SADB_EXPIRE message is: SADB_EXPIRE メッセージのメッセージ動作は、(次のとおりである): The kernel sends an SADB_EXPIRE message to all listeners when the soft limit of a security association has been expired. セキュリティアソシエーションの soft 制限の期限が切れる時、 kernel は、すべてのリスナーに対し SADB_EXPIRE メッセージを送信 する。 Note that the SADB_EXPIRE message is ONLY sent by the kernel to the KMd. It is a one-way informational message that does not have a reply. SADB_EXPIRE メッセージは kernel により KMd に送信されるだけ (ONLY) で あることに注意しなさい。これは、リプライを持たない一方向情報メッセージ である。 3.1.9 SADB_FLUSH 3.1.9 SADB_FLUSH メッセージ The SADB_FLUSH message causes the kernel to delete all entries in its key table for a certain sadb_msg_satype. Only the base header is required for a flush message. If sadb_msg_satype is filled in with a specific value, only associations of that type are deleted. If it is filled in with SADB_SATYPE_UNSPEC, ALL associations are deleted. SADB_FLUSH メッセージは、kernel に確実な sadb_msg_satype について、そ の鍵テーブル内のすべてのエントリを削除させる。基本ヘッダのみが、flush メッセージのために要求される。もし sadb_msg_satype が特定の値で書き込 まれるなら、そのタイプのアソシエーションのみが削除される。もし SADB_SATYPE_UNSPEC で書き込まれるなら、すべて (ALL) のアソシエーション が削除される。 The messaging behavior for SADB_FLUSH is: SADB_FLUSH のためのメッセージ動作は、(次のとおりである): Send an SADB_FLUSH message from a user process to the kernel. ユーザプロセスから kernel に SADB_FLUSH メッセージを送信する。 The kernel will return an SADB_FLUSH message to all listening sockets. kernel は、すべての聞いている sockets に SADB_FLUSH メッセージ を返す。 The reply message happens only after the actual flushing of security associations has been attempted. リプライメッセージは、試みられるセキュリティアソシエーションの 実際の flushing の後でのみ、生じる。 3.1.10 SADB_DUMP 3.1.10 SADB_DUMP メッセージ The SADB_DUMP message causes the kernel to dump the operating system's entire Key Table to the requesting key socket. As in SADB_FLUSH, if a sadb_msg_satype value is in the message, only associations of that type will be dumped. If SADB_SATYPE_UNSPEC is specified, all associations will be dumped. Each Security Association is returned in its own SADB_DUMP message. A SADB_DUMP message with a sadb_seq field of zero indicates the end of the dump transaction. The dump message is used for debugging purposes only and is not intended for production use. SADB_DUMP メッセージは kernel に、要求している鍵 socket に対して、オペ レーティングシステムの全体の Key Table を dump させる。SASB_FLUSH メッ セージで、もし sadb_msg_satype 値がメッセージ内である時、そのタイプの アソシエーションのみが dump されるだろう。もし SADB_SATYPE_UNSPEC が指 定されるなら、すべてのアソシエーションが dump されるだろう。それぞれの Security Association は、その自分自身の SADB_DUMP メッセージ内で返され るだろう。ゼロの sadb_seq フィールドを持つ SADB_DUMP メッセージは、 dump トランザクションの終わりを指し示す。dump メッセージは、debugging 目的のみに使用され、作品使用のために意図されない。 Support for the dump message MAY be discontinued in future versions of PF_KEY. Key management applications MUST NOT depend on this message for basic operation. dump メッセージのためのサポートは、PF_KEY の将来のバージョンで中止され るかもしれない (MAY)。鍵管理アプリケーションは、基本操作について、この メッセージに決して依存してはならない (MUST NOT)。 The messaging behavior for SADB_DUMP is: SADB_DUMP のためのメッセージ動作は、(次のとおりである): Send an SADB_DUMP message from a user process to the kernel. ユーザプロセスから kernel に、SADB_DUMP メッセージを送信する。 Several SADB_DUMP messages will return from the kernel to the sending socket. いくつかの SADB_DUMP メッセージは、kernel から送信している socket に返すだろう。 3.2 Security Association Flags 3.2 セキュリティアソシエーションフラグ The Security Association's flags are a bitmask field. These flags also appear in a combination that is part of a PROPOSAL extension. The related symbolic definitions below should be used in order that applications will be portable: Security Association のフラグは、ビットマスクフィールドである。これら のフラグもまた、PROPOSAL 拡張の一部分である組み合わせで現れる。下での 関連される記号定義は、アプリケーションが互換性があるだろう順序で使用さ れるべきである。 #define SADB_SAFLAGS_PFS 1 /* perfect forward secrecy */ /* 完全なフォワード秘密 */ The SADB_SAFLAGS_PFS flag indicates to key management that this association should have perfect forward secrecy in its key. (In other words, any given session key cannot be determined by cryptanalysis of previous session keys or some master key.) SADB_SAFLAGS_PFS フラグは、鍵管理に、このアソシエーションはその鍵に完 全なフォワード秘密を持つべきであることを指摘する。(言い換えれば、どん な与えられたセッション鍵も、前のセッション鍵や、あるマスター鍵の暗号解 析により決定されることができない。) 3.3 Security Association States 3.3 セキュリティアソシエーション状態 The security association state field is an integer that describes the states of a security association. They are: セキュリティアソシエーション状態フィールドは、1 つのセキュリティアソシ エーションの状態を記述する整数値である。これらは、(次のとおりである): #define SADB_SASTATE_LARVAL 0 #define SADB_SASTATE_MATURE 1 #define SADB_SASTATE_DYING 2 #define SADB_SASTATE_DEAD 3 #define SADB_SASTATE_MAX 3 A SADB_SASTATE_LARVAL security association is one that was created by the SADB_GETSPI message. A SADB_SASTATE_MATURE association is one that was updated with the SADB_UPDATE message or added with the SADB_ADD message. A DYING association is one whose soft lifetime has expired. A SADB_SASTATE_DEAD association is one whose hard lifetime has expired, but hasn't been reaped by system garbage collection. If a consumer of security associations has to extend an association beyond its normal lifetime (e.g. OSPF Security) it MUST only set the soft lifetime for an association. SADB_SASTATE_LARVAL セキュリティアソシエーションとは、SADB_GETSPI メッ セージにより作り出されたものである。SADB_SASTATE_MATURE アソシエーショ ンは、SADB_UPDATE メッセージで更新されたものか、SADB_ADD メッセージで 追加されたものである。DYING アソシエーションは、soft 生存時間の期限が 切れたものである。SADB_SASTATE_DEAD アソシエーションは、hard 生存時間 の期限が切れたものであるが、それはシステムガーベジコレクションにより刈 り取られない。もしセキュリティアソシエーションの consumer がその普通の 生存時間を越えてアソシエーションを拡張しなければならない (たとえば OSPF Security) なら、アソシエーションについて soft 生存時間をセットす るのみでなければならない (MUST)。 3.4 Security Association Types 3.4 セキュリティアソシエーションタイプ This defines the type of Security Association in this message. The symbolic names are always the same, even on different implementations. Applications SHOULD use the symbolic name in order to have maximum portability across different implementations. These are defined in the file . これは、あるメッセージでの Security Association のタイプを定義する。記 号名称は、異なる実装でさえ、いつも同じである。アプリケーションは、異な る実装を越えて最大の互換性を持つための順序で記号名称を使用すべきである (SHOULD)。これらは、ファイル で定義される。 #define SADB_SATYPE_UNSPEC 0 #define SADB_SATYPE_AH 2 /* RFC-1826 */ #define SADB_SATYPE_ESP 3 /* RFC-1827 */ #define SADB_SATYPE_RSVP 5 /* RSVP Authentication */ #define SADB_SATYPE_OSPFV2 6 /* OSPFv2 Authentication */ #define SADB_SATYPE_RIPV2 7 /* RIPv2 Authentication */ #define SADB_SATYPE_MIP 8 /* Mobile IP Auth. */ #define SADB_SATYPE_MAX 8 SADB_SATYPE_UNSPEC is defined for completeness and means no specific type of security association. This type is never used with PF_KEY SAs. SADB_SATYPE_UNSPEC は (タイプの) 完全のために定義され、セキュリティア ソシエーションの特定のタイプがないことを意味する。このタイプは、PF_KEY SAs で決して使用されない。 SADB_SATYPE_AH is for the IP Authentication Header [Atk95b]. SADB_SATYPE_AH は、IP Authentication Header [Atk95b] についてである。 SADB_SATYPE_ESP is for the IP Encapsulating Security Payload [Atk95c]. SADB_SATYPE_ESP は、IP Encapsulating Security Payload [Atk95c] につい てである。 SADB_SATYPE_RSVP is for the RSVP Integrity Object. SADB_SATYPE_RSVP は、RSVP Integrity Object についてである。 SADB_SATYPE_OSPFV2 is for OSPFv2 Cryptographic authentication [Moy98]. SADB_SATYPE_OSPFV2 は、OSPFv2 Cryptographic 認証 [Moy98] についてであ る。 SADB_SATYPE_RIPV2 is for RIPv2 Cryptographic authentication [BA97]. SADB_SATYPE_RIPV2 は、RIPv2 Cryptographic 認証 [BA97] についてである。 SADB_SATYPE_MIP is for Mobile IP's authentication extensions [Per97]. SADB_SATYPE_MIP は、Mobile IP の認証拡張 [Per97] についてである。 SADB_SATYPE_MAX is always set to the highest valid numeric value. SADB_SATYPE_MAX は有効な最大数値に、いつもセットされる。 3.5 Algorithm Types 3.5 アルゴリズムタイプ The algorithm type is interpreted in the context of the Security Association type defined above. The numeric value might vary between implementations, but the symbolic name MUST NOT vary between implementations. Applications should use the symbolic name in order to have maximum portability to various implementations. アルゴリズムタイプは、上で定義された Security Association タイプの前後 関係で解釈される。数値は、実装間で異なるかもしれないが、記号名称は実装 間で決して異なってはならない (MUST NOT)。アプリケーションは、さまざま な実装に対して、最大の互換性をもつための順序で記号名称を使用すべきであ る。 Some of the algorithm types defined below might not be standardized or might be deprecated in the future. To obtain an assignment for a symbolic name, contact the authors. 下で定義されたアルゴリズムタイプの一部は、標準化されないかもしれなく、 または将来反対されるかもしれない。記号名称について割り当てを得るために 著者に連絡をつけなさい。 The symbols below are defined in . 下のシンボルは、 で定義される。 /* Authentication algorithms */ /* 認証アルゴリズム */ #define SADB_AALG_NONE 0 #define SADB_AALG_MD5HMAC 2 #define SADB_AALG_SHA1HMAC 3 #define SADB_AALG_MAX 3 /* Encryption algorithms */ /* 暗号アルゴリズム */ #define SADB_EALG_NONE 0 #define SADB_EALG_DESCBC 2 #define SADB_EALG_3DESCBC 3 #define SADB_EALG_NULL 11 #define SADB_EALG_MAX 11 The algorithm for SADB_AALG_MD5_HMAC is defined in [MG98a]. The algorithm for SADB_AALG_SHA1HMAC is defined in [MG98b]. The algorithm for SADB_EALG_DESCBC is defined in [MD98]. SADB_EALG_NULL is the NULL encryption algorithm, defined in [GK98]. The SADB_EALG_NONE value is not to be used in any security association except those which have no possible encryption algorithm in them (e.g. IPsec AH). SADB_AALG_MD5_HMAC (注 SADB_AALG_MD5HMAC) についてのアルゴリズムは、 [MG98a] で定義される。SADB_AALG_SHA1HMAC についてのアルゴリズムは、 [MG98b] で定義される。SADB_EALG_DESCBC についてのアルゴリズムは、 [MD98] で定義される。SADB_EALG_NULL は、[GK98] で定義された、NULL 暗号 アルゴリズムである。SADB_EALG_NONE 値は、アルゴリズムの中に可能な暗号 アルゴリズムがない (たとえば IPsec AH) ことを除いては、どんなセキュリ ティアソシエーションにも使用することができない。 3.6 Extension Header Values 3.6 拡張ヘッダ値 To briefly recap the extension header values: 拡張ヘッダ値を簡潔に要約する: #define SADB_EXT_RESERVED 0 #define SADB_EXT_SA 1 #define SADB_EXT_LIFETIME_CURRENT 2 #define SADB_EXT_LIFETIME_HARD 3 #define SADB_EXT_LIFETIME_SOFT 4 #define SADB_EXT_ADDRESS_SRC 5 #define SADB_EXT_ADDRESS_DST 6 #define SADB_EXT_ADDRESS_PROXY 7 #define SADB_EXT_KEY_AUTH 8 #define SADB_EXT_KEY_ENCRYPT 9 #define SADB_EXT_IDENTITY_SRC 10 #define SADB_EXT_IDENTITY_DST 11 #define SADB_EXT_SENSITIVITY 12 #define SADB_EXT_PROPOSAL 13 #define SADB_EXT_SUPPORTED_AUTH 14 #define SADB_EXT_SUPPORTED_ENCRYPT 15 #define SADB_EXT_SPIRANGE 16 #define SADB_EXT_MAX 16 3.7 Identity Extension Values 3.7 身元拡張値 Each identity can have a certain type. それぞれの身元は、確実なタイプを持つことができる。 #define SADB_IDENTTYPE_RESERVED 0 #define SADB_IDENTTYPE_PREFIX 1 #define SADB_IDENTTYPE_FQDN 2 #define SADB_IDENTTYPE_USERFQDN 3 #define SADB_IDENTTYPE_MAX 3 The PREFIX identity string consists of a network address followed by a forward slash and a prefix length. The network address is in a printable numeric form appropriate for the protocol family. The prefix length is a decimal number greater than or equal to zero and less than the number of bits in the network address. It indicates the number of bits in the network address that are significant; all bits in the network address that are not significant MUST be set to zero. Note that implementations MUST parse the contents of the printable address into a binary form for comparison purposes because multiple printable strings are valid representations of the same address in many protocol families (for example, some allow leading zeros and some have letters that are case insensitive). Examples of PREFIX identities are "199.33.248.64/27" and "3ffe::1/128". If the source or destination identity is a PREFIX identity, the source or destination address for the SA (respectively) MUST be within that prefix. The sadb_ident_id field is zeroed for these identity types. PREFIX 身元文字列は、フォワードスラッシュ (/) と prefix 長で続けられる ネットワークアドレスからなる。ネットワークアドレスは、プロトコルファミ リ用に適した、表示可能な数値形式である。prefix 長は、ゼロより大きいか 等しい 10 進数であり、ネットワークアドレスでのビット数より小さい。これ は、重要であるネットワークアドレスのビット数を指し示す; 重要でないネッ トワークアドレスのすべてのビットは、ゼロにセットしなければならない (MUST)。実装は、比較目的のためバイナリ形式に表示可能なアドレスの内容を 構文解析しなければならない (MUST) ことに注意しなさい。なぜなら複数の表 示可能な文字列が、多くのプロトコルファミリで同じアドレスの有効な表現で あるからである (たとえば、あるものは先頭のゼロを許し、あるものは無神経 なケースである文字を持つもの)。PREFIX 身元の例は、"199.33.248.64/27" と "3ffe::1/128" である。もし始点や終点身元が PREFIX 身元であるなら、 (それぞれ) SA のための始点や終点アドレスは prefix 範囲内でなければなら ない (MUST)。sadb_ident_id フィールドは、これらの身元タイプのためにゼ ロとされる。 The FQDN identity string contains a fully qualified domain name. An example FQDN identity is "ministry-of-truth.inner.net". The sadb_ident_id field is zeroed for these identity types. FQDN 身元文字列は、fully qualified domain name を含む。FQND 身元の例は "ministry-of-truth.inner.net" である。sadb_ident_id フィールドは、これ らの身元タイプのためにゼロとされる。 The UserFQDN identity consists of a text string in the format commonly used for Internet-standard electronic mail. The syntax is the text username, followed by the "@" character, followed in turn by the appropriate fully qualified domain name. This identity specifies both a username and an associated FQDN. There is no requirement that this string specify a mailbox valid for SMTP or other electronic mail use. This identity is useful with protocols supporting user-oriented keying. It is a convenient identity form because the DNS Security extensions can be used to distribute signed public key values by associating KEY and SIG records with an appropriate MB DNS record. An example UserFQDN identity is "julia@ministry-of-love.inner.net". The sadb_ident_id field is used to contain a POSIX user id in the absence of an identity string itself so that a user-level application can use the getpwuid{,_r}() routine to obtain a textual user login id. If a string is present, it SHOULD match the numeric value in the sadb_ident_id field. If it does not match, the string SHOULD override the numeric value. UserFQDN 身元は、Internet-standard electronic mail のために一般に使用 される形式でのテキスト文字列からなる。構文は、テキストユーザ名、"@" 文 字、適した fully qualified domain name で順番に続かれるものである。こ の身元は、ユーザ名と関連される FQDN 両方を特定する。この文字列が SMTP について有効な mailbox や、他の electronic mail 使用を特定することの要 求はない。この身元は、ユーザ指向鍵設定をサポートしているプロトコルで有 用である。これは都合のよい身元形式である。なぜなら DNS Security 拡張は 適する MB DNS record での関連している KEY と SIG record による署名され た公開鍵値を配布するために使用されることができるからである。UserFQDN 身元例は、"julia@ministry-of-love.inner.net" である。ユーザレベルアプ リケーションがテキストの user login id を得るため getpwuid{,_r}() ルー チンを使用できるように、それ自身の身元文字列がないときは、 sadb_ident_id フィールドは、POSIX user id を含むために使用される。もし 文字列があるなら、これは sadb_ident_id フィールドでの数値にマッチする べきである (SHOULD)。もしこれがマッチしないなら、文字列は数値を無視す べきである (SHOULD)。 3.8 Sensitivity Extension Values 3.8 感度拡張値 The only field currently defined in the sensitivity extension is the sadb_sens_dpd, which represents the data protection domain. The other data in the sensitivity extension is based off the sadb_sens_dpd value. 感度拡張で現在定義される唯一のフィールドは、sadb_sens_dpd であり、それ はデータ保護ドメインを表す。感度拡張での他のデータは、sadb_sens_dpd 値 と離れて基づかれる。 The DP/DOI is defined to be the same as the "Labeled Domain Identifier Value" of the IP Security DOI specification [Pip98]. As noted in that specification, values in the range 0x80000000 to 0xffffffff (inclusive) are reserved for private use and values in the range 0x00000001 through 0x7fffffff are assigned by IANA. The all-zeros DP/DOI value is permanently reserved to mean that "no DP/DOI is in use". DP/DOI は、IP Security DOI 仕様書 [Pip98] の "Labeled Domain Identifier Value" と同じであるように定義される。その仕様書で書き留めら れたとして、範囲 0x80000000 から 0xffffffff (それ自身を含む) での値は プライベート使用のために予約され、範囲 0x00000001 から 0x7fffffff での 値は IANA により割り当てられる。すべてゼロの DP/DOI 値は、"使用されて いる DP/DOI はない" を意味するために、永久的に予約される。 3.9 Proposal Extension Values 3.9 提案拡張値 These are already mentioned in the Algorithm Types and Security Association Flags sections. これらは、Algorithm Types と Security Association Flags セクションで、 すでに述べられた。 ------------------------------------------------------------------------- 4 Future Directions 4 将来の方向 While the current specification for the Sensitivity and Integrity Labels is believed to be general enough, if a case should arise that can't work with the current specification then this might cause a change in a future version of PF_KEY. Sensitivity と Integrity Labels のための現在の仕様書は十分に全体的であ ると考えられるが、もし現在の仕様書で動作できないケースが発生するなら、 これは、PF_KEY の将来のバージョンで変更を引き起こすかもしれない。 Similarly, PF_KEY might need extensions to work with other kinds of Security Associations in future. It is strongly desirable for such extensions to be made in a backwards-compatible manner should they be needed. 同様に、PF_KEY は今後 Security Association の他の種類と働くための拡張 を必要とするかもしれない。そのような拡張が、必要とされるべき後方互換方 式で作られることは、強く望まれる。 When more experience is gained with certificate management, it is possible that the IDENTITY extension will have to be revisited to allow a finer grained selection of certificate identities. 多くの経験が証明書管理で増加される時、IDENTITY 拡張が証明身元の、より 洗練された粒度ある選択を許すために修正されなければならないことは可能で ある。 ------------------------------------------------------------------------- 5. Examples 5. 例 The following examples illustrate how PF_KEY is used. The first example is an IP Security example, where the consumer of the security associations is inside an operating system kernel. The second example is an OSPF Security example, which illustrates a user-level consumer of security associations. The third example covers things not mentioned by the first two examples. A real system may closely conform to one of these examples, or take parts of them. These examples are purely illustrative, and are not intended to mandate a particular implementation method. 次の例は、PF_KEY がどのように使用されるかを実例で説明する。最初の例は セキュリティアソシエーションの consumer がオペレーティングシステム kernel 内部である IP Security 例である。2 番目の例は、OSPF Security 例 であり、セキュリティアソシエーションのユーザレベル consumer を実例で説 明する。3 番目の例は、最初の 2 つの例で述べられなかったことを扱う。実 際のシステムは、これらの例の 1 つに精密に準拠しているか、一部分に従う だろう。これらの例は、純粋に実例となるものであり、特定の実装方法を命じ ることを意図されない。 5.1 Simple IP Security Example 5.1 シンプルな IP セキュリティ例 +---------------+ +-------------+ |Key Mgmt Daemon| | Application | +---------------+ +-------------+ | | / | | / | | | Applications ======[PF_KEY]====[PF_INET]========================== | | | OS Kernel +------------+ +-----------------+ | Key Engine | | TCP/IP, | | or SADB |---| including IPsec | +------------+ | | +-----------------+ +----------------+ +------------------+ | 鍵管理デーモン | | アプリケーション | +----------------+ +------------------+ | | / | | / | | | アプリケーション ======[PF_KEY]====[PF_INET]============================== | | | OS カーネル +-------------+ +-----------------+ | 鍵エンジン | | TCP/IP, | | または SADB |---| IPsec を含む | +-------------+ | | +-----------------+ When the Key Management daemon (KMd) begins. It must tell PF_KEY that it is willing to accept message for the two IPsec services, AH and ESP. It does this by sending down two SADB_REGISTER messages. Key Management デーモン (KMd) が始まる時、それは PF_KEY に、2 つの IPsec サービス、AH と ESP のためのメッセージを快く受け入れることを告げ なければならない。下へと 2 つの SADB_REGISTER メッセージを送信すること により、これをおこなう。 KMd->Kernel: SADB_REGISTER for ESP Kernel->Registered: SADB_REGISTER for ESP, Supported Algorithms KMd->Kernel: SADB_REGISTER for AH Kernel->Registered: SADB_REGISTER for AH, Supported Algorithms Each REGISTER message will cause a reply to go to all PF_KEY sockets registered for ESP and AH respectively (including the requester). それぞれの REGISTER メッセージは、リプライに、(要求者を含む) ESP と AH それぞれについて登録されたすべての PF_KEY sockets に送信される。 Assume that no security associations currently exist for IPsec to use. Consider when a network application begins transmitting data (e.g. a TCP SYN). Because of policy, or the application's request, the kernel IPsec module needs an AH security association for this data. Since there is not one present, the following message is generated: 使用するための IPsec に対し、セキュリティアソシエーションが現在存在し ないと仮定する。ネットワークアプリケーションがデータを転送し始める (た とえば TCP SYN) 時を考える。ポリシーやアプリケーションの要求のために、 kernel IPsec モジュールは、このデータのため AH セキュリティアソシエー ションを必要とする。その SA がないので、次のメッセージが生成される: Kernel->Registered: SADB_ACQUIRE for AH, addrs, ID, sens, proposals The KMd reads the ACQUIRE message, especially the sadb_msg_seq number. Before it begins the negotiation, it sends down an SADB_GETSPI message with the sadb_msg_seq number equal to the one received in the ACQUIRE. The kernel returns the results of the GETSPI to all listening sockets. KMd は ACQUIRE メッセージ、特に sadb_msg_seq 番号を読む。KMd がネゴシ エーションを始める前に、ACQUIRE で受信されたものに等しい sadb_msg_seq 番号で SADB_GETSPI メッセージを下へと送信する。kernel は、すべての聞い ている sockets に GETSPI の結果を返す。 KMd->Kernel: SADB_GETSPI for AH, addr, SPI range Kernel->All: SADB_GETSPI for AH, assoc, addrs The KMd may perform a second GETSPI operation if it needs both directions of IPsec SPI values. Now that the KMd has an SPI for at least one of the security associations, it begins negotiation. After deriving keying material, and negotiating other parameters, it sends down one (or more) SADB_UPDATE messages with the same value in sadb_msg_seq. もし KMd が IPsec SPI 値の方向両方を必要とするなら、KMd は 2 番目の GETSPI 操作をおこなうかもしれない。KMd はセキュリティアソシエーション の少なくとも 1 つの SPI を持ったので、KMd はネゴシエーションを始める。 鍵材料を引き出し他のパラメータを取り決めた後、sadb_msg_seq での同じ値 を持つ 1 つ (か多くの) SADB_UPDATE メッセージを下へと送信する。 If a KMd has any error at all during its negotiation, it can send down: もし KMd がすべてのネゴシエーションの間に何らかのエラーを持つなら、下 へと送信することができる: KMd->Kernel: SADB_ACQUIRE for AH, assoc (with an error) Kernel->All: SADB_ACQUIRE for AH, assoc (same error) but if it succeeds, it can instead: しかしもし成功するなら、その代わりに (下へと送信することができる): KMd->Kernel: SADB_UPDATE for AH, assoc, addrs, keys, Kernel->All: SADB_UPDATE for AH, assoc, addrs, The results of the UPDATE (minus the actual keys) are sent to all listening sockets. If only one SPI value was determined locally, the other SPI (since IPsec SAs are unidirectional) must be added with an SADB_ADD message. (実際の鍵のない) UPDATE の結果は、すべての聞いている sockets に送信さ れる。もしただ 1 つの SPI 値のみがローカルに決定されたなら、(IPsec SAs は一方向だけに作用するので) 他の SPI は SADB_ADD メッセージで追加され なければならない。 KMd->Kernel: SADB_ADD for AH, assoc, addrs, keys, Kernel->All: SADB_ADD for AH, assoc, addrs, If one of the extensions passed down was a Lifetime extension, it is possible at some point an SADB_EXPIRE message will arrive when one of the lifetimes has expired. もし下へと渡される拡張の 1 つが Lifetime 拡張であるなら、生存時間の 1 つの期限が切れた時、いくつかの位置で SADB_EXPIRE メッセージが到着する ことは可能である。 Kernel->All: SADB_EXPIRE for AH, assoc, addrs, Hard or Soft, Current, The KMd can use this as a clue to begin negotiation, or, if it has some say in policy, send an SADB_UPDATE down with a lifetime extension. KMd はネゴシエーションを始めるための手がかりとしてこれを使用することが でき、もしポリシーでいくつかの発言を持つなら、生存時間拡張を持つ SADB_UPDATE を下へと送信する。 5.2 Proxy IP Security Example 5.2 プロクシ IP セキュリティ例 Many people are interested in using IP Security in a "proxy" or "firewall" configuration in which an intermediate system provides security services for "inside" hosts. In these environments, the intermediate systems can use PF_KEY to communicate with key management applications almost exactly as they would if they were the actual endpoints. The messaging behavior of PF_KEY in these cases is exactly the same as the previous example, but the address information is slightly different. 多くの人々は、中間システムが "inside" ホストのためにセキュリティサービ スを提供する"proxy" または "firewall" 構成での IP Security を使用する ことに興味を持っている。これらの環境で、それらによくあることだが、もし それらが実際の endpoint であるなら、中間システムは、ほとんど正確に鍵管 理アプリケーションで通信するために PF_KEY を使用することができる。これ らのケースでの PF_KEY のメッセージ動作は、前の例と正確に同じである。し かしアドレス情報は、わずかに異なる。 Consider this case: このケースを考える: A ========= B --------- C Key: 鍵: A "outside" host that implements IPsec B "firewall" that implements IPsec C "inside" host that does not implement IPsec A IPsec を実装する "外側" のホスト B IPsec を実装する "firewall" C IPsec を実装しない "inside" のホスト === IP_{A<->B} ESP [ IP_{A<->C} ULP ] --- IP_{A<->C} ULP A is a single system that wishes to communicate with the "inside" system C. B is a "firewall" between C and the outside world that will do ESP and tunneling on C's behalf. A discovers that it needs to send traffic to C via B through methods not described here (Use of the DNS' KX record might be one method for discovering this). A は、"inside" システム C と通信を望むたった 1 つのシステムである。B は C と、ESP と C のための tunneling をする外側の世界との間の "firewall" である。A は、ここで記述されない方法を通して B 経由で C に 対しトラフィックを送信する必要があることを発見する (DNS の KX record の使用は、これを発見するための 1 つの方法であるかもしれない)。 For packets that flow from left to right, A and B need an IPsec Security Association with: (上のケースで) 左から右に流れるパケットについて、A と B は、(次のもの を持つ) IPsec Security Association を必要とする: SA type of ESP tunnel-mode Source Identity that dominates A (e.g. A's address) Destination Identity that dominates B (e.g. B's address) Source Address of A Destination Address of B ESP トンネルモードの SA タイプ A を支配する Source Identity (たとえば A のアドレス) B を支配する Destination Identity (たとえば B のアドレス) A の Source Address B の Destination Address For packets to flow from right to left, A and B need an IPsec Security Association with: 右から左に流れるパケットについて、A と B は、(次のものを持つ) IPsec Security Association を必要とする: SA type of ESP tunnel-mode Source Identity that dominates C Destination Identity that dominates A Source Address of B Destination Address of A Proxy Address of C ESP トンネルモードの SA タイプ C を支配する Source Identity A を支配する Destination Identity B の Source Address A の Destination Address C の Proxy Address For this second SA (for packets flowing from C towards A), node A MUST verify that the inner source address is dominated by the Source Identity for the SA used with those packets. If node A does not do this, an adversary could forge packets with an arbitrary Source Identity and defeat the packet origin protections provided by IPsec. (A に対して C から流れているパケットに対する) この 2 番目の SA につい て、ノード A は、それらのパケットで使用される SA について Source Identity により支配される内側の始点アドレスを確かめなければならない (MUST)。もしノード A がこれをしないなら、敵は、好き勝手の Source Identity を持つパケットを偽造することができ、IPsec により提供されるパ ケット送信元保護を負かすことができる。 Now consider a slightly more complex case: 今、少しばかりもっと複雑なケースを考える: A_1 --| |-- D_1 |--- B ====== C ---| A_2 --| |-- D_2 Key: 鍵: A_n "inside" host on net 1 that does not do IPsec. B "firewall" for net 1 that supports IPsec. C "firewall" for net 2 that supports IPsec. D_n "inside" host on net 2 that does not do IPsec. A_n IPsec をしない net 1 上の "inside" ホスト。 B IPsec をサポートする net 1 のための "firewall"。 C IPsec をサポートする net 2 のための "firewall"。 D_n IPsec をしない net 2 上の "inside" ホスト。 === IP_{B<->C} ESP [ IP_{A<->C} ULP ] --- IP_{A<->C} ULP For A_1 to send a packet to D_1, B and C need an SA with: D_1 にパケットを送信する A_1 について、B と C は、(次のものを 持つ) SA を必要とする: SA Type of ESP Source Identity that dominates A_1 Destination Identity that dominates C Source Address of B Destination Address of C Proxy Address of A_1 ESP の SA Type A_1 を支配する Source Identity C を支配する Destination Identity B の Source Address C の Destination Address A_1 の Proxy Address For D_1 to send a packet to A_1, C and B need an SA with: A_1 にパケットを送信する D_1 について、C と B は、(次のものを 持つ) SA を必要とする: SA Type of ESP Tunnel-mode Source Identity that dominates D_1 Destination Identity that dominates B Source Address of C Destination Address of B Proxy Address of D_1 ESP Tunnel-mode の SA Type D_1 を支配する Source Identity B を支配する Destination Identity C の Source Address B の Destination Address D_1 の Proxy Address Note that A_2 and D_2 could be substituted for A_1 and D_1 (respectively) here; the association of an SA with a particular pair of ends or group of those pairs is a policy decision on B and/or C and not necessarily a function of key management. The same check of the Source Identity against the inner source IP address MUST also be performed in this case for the same reason. A_2 と D_2 は、ここで (それぞれ) A_1 と D_1 の代わりに用いられることが できることに注意しなさい; ends の特定のペアやそれらのペアの group を持 つ SA のアソシエーションは、B and/or C でのポリシー決定であり、必ずし も鍵管理の機能ではない。内側始点 IP アドレスに対する Source Identity の同じチェックは、同じ理由のために、このケースでもおこなわなければなら ない (MUST)。 For a more detailed discussion of the use of IP Security in complex cases, please see [Atk97]. 複雑なケースでの IP Security 使用のより多くの詳細な議論について、 [Atk97] を参照してもらいたい。 NOTE: The notion of identity domination might be unfamiliar. Let H represent some node. Let Hn represent H's fully qualified domain name. Let Ha represent the IP address of H. Let Hs represent the IP subnet containing Ha. Let Hd represent a fully qualified domain name that is a parent of the fully qualified domain name of H. Let M be a UserFQDN identity that whose right-hand part is Hn or Ha. 注意: 身元支配の概念は、聞きなれないかもしれない。H にノードを意味さ せる。Hn に H の fully qualified domain name を意味させる。Ha に H の IP アドレスを意味させる。Hs に Ha を含んでいる IP subnet を意味さ せる。Hd に H の fully qualified domain name の親である fully qualified domain name を意味させる。 M に、UserFQDN 身元のもっとも信 頼されている部分が Hn や Ha である UserFQDN 身元とさせる。 Any of M, Hn, Ha, Hs, and Hd is considered to dominate H in the example above. Hs dominates any node having an IP address within the IP address range represented by Hs. Hd dominates any node having a fully qualified domain name within underneath Hd. M, Hn, Ha, Hs と Hd のどれも、上の例での H を支配するために考えられ る。Hs は、Hs により表される IP アドレス範囲内の IP アドレスを持つど んなノードも支配する。Hd は、Hd の下の範囲内の fully qualified domain name を持つどんなノードも支配する。 5.3 OSPF Security Example 5.3 OSPF セキュリティ例 +---------------+ +-------------+ |Key Mgmt Daemon| | OSPF daemon | +---------------+ +-------------+ | | / / | | /------|----+ / | | / | +---+ | Applications ======[PF_KEY]====[PF_INET]===========[PF_ROUTE]================ | | | | OS Kernel +------------+ +-----------------+ +---------+ | Key Engine | | TCP/IP, | | Routing | | or SADB |---| including IPsec |--| Table | +------------+ | | +---------+ +-----------------+ +----------------+ +---------------+ | 鍵管理デーモン | | OSPF デーモン | +----------------+ +---------------+ | | / / | | /------|----+ / | | / | +---+ | アプリケーション =======[PF_KEY]====[PF_INET]===========[PF_ROUTE]==================== | | | | OS カーネル +-------------+ +-----------------+ +---------+ | 鍵エンジン | | TCP/IP, | | 経路表 | | または SADB |---| IPsec を含む |--| | +-------------+ | | +---------+ +-----------------+ As in the previous examples, the KMd registers itself with the Key Engine via PF_KEY. Even though the consumer of the security associations is in user-space, the PF_KEY and Key Engine implementation knows enough to store SAs and to relay messages. 前の例で述べられたように、KMd は PF_KEY 経由で Key Engine にそれ自身を 登録する。たとえセキュリティアソシエーションの consumer がユーザ空間内 だとしても、PF_KEY と Key Engine 実装は、SAs を格納しメッセージを中継 するのに十分であることを知っている。 When the OSPF daemon needs to communicate securely with its peers, it would perform an SADB_GET message and retrieve the appropriate association: OSPF デーモンがその peer と安全に通信する必要がある時、これは SADB_GET メッセージをおこない、適するアソシエーションを検索するだろう。 OSPFd->Kernel: SADB_GET of OSPF, assoc, addrs Kernel->OSPFd: SADB_GET of OSPF, assoc, addrs, keys, If this GET fails, the OSPFd may need to acquire a new security association. This interaction is as follows: もしこの GET が失敗するなら、OSPFd は新しいセキュリティアソシエーショ ンを獲得する必要があるかもしれない。この相互作用は、次のとおりである: OSPFd->Kernel: SADB_ACQUIRE of OSPF, addrs, proposal Kernel->Registered: SADB_ACQUIRE of OSPF, The KMd sees this and performs actions similar to the previous example. One difference, however, is that when the UPDATE message comes back, the OSPFd will then perform a GET of the updated SA to retrieve all of its parameters. KMd はこれを見て、前の例と同じような動作をおこなう。しかしながら、1 つ の違いは、UPDATE メッセージが返って来た時、OSPFd はそのパラメータのす べてを検索するために、更新された SA の GET をおこなうだろう。 5.4 Miscellaneous 5.4 その他 Some messages work well only in system maintenance programs, for debugging, or for auditing. In a system panic situation, such as a detected compromise, an SADB_FLUSH message should be issued for a particular SA type, or for ALL SA types. 一部のメッセージは、debugging や監査のために、システムメンテナンスプロ グラムのみで、よくはたらく。見破られた妥協 (?) のようなシステムパニッ ク状況で、SADB_FLUSH メッセージは、特定の SA タイプ、またはすべての (ALL) SA タイプについて発行されるべきである。 Program->Kernel: SADB_FLUSH for ALL Kernel->All: SADB_FLUSH for ALL Some SAs may need to be explicitly deleted, either by a KMd, or by a system maintenance program. ある SA は、KMd かシステムメンテナンスプログラムにより、明示的に削除さ れる必要があるかもしれない。 Program->Kernel: SADB_DELETE for AH, association, addrs Kernel->All: SADB_DELETE for AH, association, addrs Common usage of the SADB_DUMP message is discouraged. For debugging purposes, however, it can be quite useful. The output of a DUMP message should be read quickly, in order to avoid socket buffer overflows. SADB_DUMP の共通の使用法は阻止される。しかしながら、debugging 目的のた めに、実際有用であることができる。DUMP メッセージの出力は、socket バッファオーバフローを避けるために、すばやく読まれるべきである。 Program->Kernel: SADB_DUMP for ESP Kernel->Program: SADB_DUMP for ESP, association, Kernel->Program: SADB_DUMP for ESP, association, Kernel->Program: SADB_DUMP for ESP, association, ------------------------------------------------------------------------- 6 Security Considerations 6 セキュリティに関する考察 This memo discusses a method for creating, reading, modifying, and deleting Security Associations from an operating system. Only trusted, privileged users and processes should be able to perform any of these operations. It is unclear whether this mechanism provides any security when used with operating systems not having the concept of a trusted, privileged user. このメモは、オペレーティングシステムから Security Association の作成、 読み出し、変更と削除をするための方法を議論する。信頼され特権あるユーザ とプロセスのみが、これら操作のどれも、おこなうことができるべきである。 信頼され特権あるユーザの概念を持たないオペレーティングシステムで使用さ れる時、このメカニズムがどんなセキュリティを提供できるかどうか明らかで はない。 If an unprivileged user is able to perform any of these operations, then the operating system cannot actually provide the related security services. If an adversary knows the keys and algorithms in use, then cryptography cannot provide any form of protection. もし特権のないユーザがこれらのどんな操作もおこなうことができるなら、オ ペレーティングシステムは、関係があるセキュリティアソシエーションを実際 に提供することができない。もし敵が使用されている鍵とアルゴリズムを知る なら、暗号学は、保護のどんな形式も提供することができない。 This mechanism is not a panacea, but it does provide an important operating system component that can be useful in creating a secure internetwork. このメカニズムは万能ではないが、安全な internetwork を作り出すのに有用 であることができるオペレーティングシステム構成要素を提供する。 Users need to understand that the quality of the security provided by an implementation of this specification depends completely upon the overall security of the operating system, the correctness of the PF_KEY implementation, and upon the security and correctness of the applications that connect to PF_KEY. It is appropriate to use high assurance development techniques when implementing PF_KEY and the related security association components of the operating system. この仕様の実装により提供されるセキュリティの質が、オペレーティングシス テムの全体的なセキュリティ、PF_KEY の実装の正確さ、PF_KEY に接続するア プリケーションのセキュリティと正確さに完全に依存することを、ユーザは理 解する必要がある。PF_KEY とオペレーティングシステムの関連するセキュリ ティアソシエーション構成要素を実装する時、高い確信ある開発テクニックを 使用するのに適切である。 ------------------------------------------------------------------------- Acknowledgments 謝辞 The authors of this document are listed primarily in alphabetical order. Randall Atkinson and Ron Lee provided useful feedback on earlier versions of this document. この文書の著者は、アルファベット順で最初にリストされる。Randall Atkinson と Ron Lee は、この文書の早期のバージョンで有用なフィードバッ クを提供した。 At one time or other, all of the authors worked at the Center for High Assurance Computer Systems at the U.S. Naval Research Laboratory. This work was sponsored by the Information Security Program Office (PMW-161), U.S. Space and Naval Warfare Systems Command (SPAWAR) and the Computing Systems Technology Office, Defense Advanced Research Projects Agency (DARPA/CSTO). We really appreciate their sponsorship of our efforts and their continued support of PF_KEY development. Without that support, PF_KEY would not exist. 同時に、または別に、著者たちすべては U.S. Naval Research Laboratory で の the Center for High Assurance Computer Systems で働いた。この仕事は the Information Security Program Office (PMW-161)、U.S. Space and Naval Warfare Systems Command (SPAWAR) と the Computing Systems Technology Office, Defense Advanced Research Projects Agency (DARPA/CSTO) により後援された。われわれは、われわれの努力に関しての彼 らのスポンサーシップと PF_KEY 開発の彼らの継続したサポートに、ほんとう に感謝する。そのサポートなしに、PF_KEY は存在しなかっただろう。 The "CONFORMANCE and COMPLIANCE" wording was taken from [MSST98]. "CONFORMANCE (準拠) と COMPLIANCE (対応)" という言葉は、[MSST98] から 得られた。 Finally, the authors would like to thank those who sent in comments and questions on the various iterations of this document. This specification and implementations of it are discussed on the PF_KEY mailing list. If you would like to be added to this list, send a note to . 最後に著者たちは、この文書のさまざまな繰り返しでコメントと質問に関して 送った彼らに感謝したい。この仕様書とその実装は、PF_KEY mailing list で 議論される。もしあなたがこのリストに追加されたいなら、 に手紙を送りなさい。 ------------------------------------------------------------------------- References 参考文献 [AMPMC96] Randall J. Atkinson, Daniel L. McDonald, Bao G. Phan, Craig W. Metz, and Kenneth C. Chin, "Implementation of IPv6 in 4.4-Lite BSD", Proceedings of the 1996 USENIX Conference, San Diego, CA, January 1996, USENIX Association. [Atk95a] Atkinson, R., "IP Security Architecture", RFC 1825, August 1995. [Atk95b] Atkinson, R., "IP Authentication Header", RFC 1826, August 1995. [Atk95c] Atkinson, R., "IP Encapsulating Security Payload", RFC 1827, August 1995. [Atk97] Atkinson, R., "Key Exchange Delegation Record for the Domain Name System", RFC 2230, October 1997. [BA97] Baker, F., and R. Atkinson, "RIP-2 MD5 Authentication", RFC 2082, January 1997. [Biba77] K. J. Biba, "Integrity Considerations for Secure Computer Systems", MTR-3153, The MITRE Corporation, June 1975; ESD-TR-76-372, April 1977. [BL74] D. Elliot Bell and Leonard J. LaPadula, "Secure Computer Systems: Unified Exposition and Multics Interpretation", MTR 2997, The MITRE Corporation, April 1974. (AD/A 020 445) [Bra97] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [CW87] D. D. Clark and D. R. Wilson, "A Comparison of Commercial and Military Computer Security Policies", Proceedings of the 1987 Symposium on Security and Privacy, pp. 184-195, IEEE Computer Society, Washington, D.C., 1987. [DIA] US Defense Intelligence Agency (DIA), "Compartmented Mode Workstation Specification", Technical Report DDS-2600-6243-87. [GK98] Glenn, R., and S. Kent, "The NULL Encryption Algorithm and Its Use with IPsec", Work in Progress. [HM97a] Harney, H., and C. Muckenhirn, "Group Key Management Protocol (GKMP) Specification", RFC 2093, July 1997. [HM97b] Harney, H., and C. Muckenhirn, "Group Key Management Protocol (GKMP) Architecture", RFC 2094, July 1997. [MD98] Madsen, C., and N. Doraswamy, "The ESP DES-CBC Cipher Algorithm With Explicit IV", Work in Progress. [MG98a] Madsen, C., and R. Glenn, "The Use of HMAC-MD5-96 within ESP and AH", Work in Progress. [MG98b] Madsen, C., and R. Glenn, "The Use of HMAC-SHA-1-96 within ESP and AH", Work in Progress. [MSST98] Maughan, D., Schertler, M., Schneider, M., and J. Turner, "Internet Security Association and Key Management Protocol (ISAKMP)", Work in Progress. [Moy98] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. [Per97] Perkins, C., "IP Mobility Support", RFC 2002, October 1996. [Pip98] Piper, D., "The Internet IP Security Domain of Interpretation for ISAKMP", Work in Progress. [Sch96] Bruce Schneier, Applied Cryptography, p. 360, John Wiley & Sons, Inc., 1996. [Skl91] Keith Sklower, "A Tree-based Packet Routing Table for Berkeley UNIX", Proceedings of the Winter 1991 USENIX Conference, Dallas, TX, USENIX Association. 1991. pp. 93-103. ------------------------------------------------------------------------- Disclaimer 否認声明書 The views and specification here are those of the editors and are not necessarily those of their employers. The employers have not passed judgment on the merits, if any, of this work. The editors and their employers specifically disclaim responsibility for any problems arising from correct or incorrect implementation or use of this specification. ここでの意見と仕様は編集者のものであり、必ずしも彼らの雇い主のものでは ない。雇い主は、もしあるなら、この成果の価値に判断を下していない。編集 者とその雇い主は、正確または不正確な実装や、この仕様の利用から生じる何 らかの問題への責任を、明確に否認する。 ------------------------------------------------------------------------- Authors' Addresses 著者のアドレス Daniel L. McDonald Sun Microsystems, Inc. 901 San Antonio Road, MS UMPK17-202 Palo Alto, CA 94303 Phone: +1 650 786 6815 EMail: danmcd@eng.sun.com Craig Metz (for Code 5544) U.S. Naval Research Laboratory 4555 Overlook Ave. SW Washington, DC 20375 Phone: (DSN) 754-8590 EMail: cmetz@inner.net Bao G. Phan U. S. Naval Research Laboratory EMail: phan@itd.nrl.navy.mil ------------------------------------------------------------------------- Appendix A: Promiscuous Send/Receive Message Type 付録 A: 無差別送受信拡張 A kernel supporting PF_KEY MAY implement the following extension for development and debugging purposes. If it does, it MUST implement the extension as specified here. An implementation MAY require an application to have additional privileges to perform promiscuous send and/or receive operations. PF_KEY をサポートしている kernel は、開発とデバッグ目的のために次の拡 張を実装するかもしれない (MAY)。もしこれをするなら、ここで指定されたも のとして実装されなければならない (MUST)。実装はアプリケーションに、無 差別な送信 and/or 受信操作をおこなうために、追加の特権を持つことを要求 するかもしれない (MAY)。 The SADB_X_PROMISC message allows an application to send and receive messages in a "promiscuous mode." There are two forms of this message: control and data. The control form consists of only a message header. This message is used to toggle the promiscuous- receive function. A value of one in the sadb_msg_satype field enables promiscuous message reception for this socket, while a value of zero in that field disables it. SADB_X_PROMISC メッセージは、アプリケーションに "promiscuous mode" で のメッセージを送受信を許す。このメッセージの 2 つの形式: 制御とデータ がある。制御形式は、メッセージヘッダのみからなる。このメッセージは、無 差別受信機能を切り替えるために使用される。sadb_msg_satype フィールドで の 1 つの値は、この socket での無差別メッセージ受信を可能にする。だが そのフィールドでの値ゼロは、それを不可能にする。 The second form of this message is the data form. This is used to send or receive messages in their raw form. Messages in the data form consist of a message header followed by an entire new message. There will be two message headers in a row: one for the SADB_X_PROMISC message, and one for the payload message. このメッセージの 2 番目の形式は、データ形式である。これは、手を加えて いない形式でのメッセージを送信か受信するために使用される。このデータ形 式でのメッセージは、全体の新しいメッセージにより続けられる、メッセージ ヘッダからなる。1 列に 2 つのメッセージヘッダがあるだろう: SADB_X_PROMISC のためのもの、とペイロードタイプのためのものである。 Data messages sent from the application are sent to either the PF_KEY socket of a single process identified by a nonzero sadb_msg_seq or to all PF_KEY sockets if sadb_msg_seq is zero. These messages are sent without any processing of their contents by the PF_KEY interface (including sanity checking). This promiscuous-send capability allows an application to send messages as if it were the kernel. This also allows it to send erroneous messages. アプリケーションから送信されるデータメッセージは、ゼロでない sadb_msg_seq により識別されるたった 1 つのプロセスの PF_KEY socket に 送信されるか、もし sadb_msg_seq がゼロなら、すべての PF_KEY sockets に 送信される。(sanity checking を含む) PF_KEY インターフェイスによりそれ らの内容の何らかの処理なしに、これらのメッセージは送信される。この無差 別送信能力は、あたかも kernel であるかのように、アプリケーションにメッ セージを送信させることを許す。これもまた、そのアプリケーションにエラー を含むメッセージを送信させることを許す。 If the promiscuous-receive function has been enabled, a copy of any message sent via PF_KEY by another application or by the kernel is sent to the promiscuous application. This is done before any processing of the message's contents by the PF_KEY interface (again, including sanity checking). This promiscuous-receive capability allows an application to receive all messages sent by other parties using PF_KEY. もし無差別受信機能が可能にされるなら、他のアプリケーションや kernel に より PF_KEY 経由で送信されるどんなメッセージのコピーも、無差別なアプリ ケーションに送信される。これは、PF_KEY インターフェイスによる (再び sanity checking を含む) メッセージ内容の何らかの処理の前に、おこなわれ る。この無差別受信能力はアプリケーションに、PF_KEY を使用している他の パーティにより送信されるすべてのメッセージを受信することを許す。 The messaging behavior of the SADB_X_PROMISC message is: SADB_X_PROMISC メッセージのメッセージ動作は、(次のとおりである): Send a control-form SADB_X_PROMISC message from a user process to the kernel. ユーザプロセスから kernel に、制御形式の SADB_X_PROMISC メッセー ジを送信する。 The kernel returns the SADB_X_PROMISC message to all listening processes. kernel は、すべての聞いているプロセスに SADB_X_PROMISC メッセー ジを返す。 Send a data-form SADB_X_PROMISC message from a user process to the kernel. ユーザプロセスから kernel に、データ形式 SADB_X_PROMISC メッセー ジを送信する。 The kernel sends the encapsulated message to the target process(s). kernel は、目的のプロセス (または複数のプロセス) にカプセル化さ れたメッセージを送信する。 If promiscuous-receive is enabled, the kernel will encapsulate and send copies of all messages sent via the PF_KEY interface. もし無差別受信が可能にされるなら、kernel は PF_KEY インターフェ イス経由で送信される、すべてのメッセージのコピーをカプセル化し送 信するだろう。 Errors: エラー: EPERM Additional privileges are required to perform the requested operations. EPERM 追加の特権が、要求される操作をおこなうために必要とされる。 ESRCH (Data form, sending) The target process in sadb_msg_seq does not exist or does not have an open PF_KEY Version 2 socket. ESRCH (送信している、データ形式) sadb_msg_seq での目的のプロセス が存在しないか、開いた PF_KEY Version 2 socket を持ってい ない。 Appendix B: Passive Change Message Type 付録 B: 受動的な変更メッセージ拡張 The SADB_X_PCHANGE message is a passive-side (aka. the "listener" or "receiver") counterpart to the SADB_ACQUIRE message. It is useful for when key management applications wish to more effectively handle incoming key management requests for passive-side sessions that deviate from systemwide default security services. If a passive session requests that only certain levels of security service be allowed, the SADB_X_PCHANGE message expresses this change to any registered PF_KEY sockets. Unlike SADB_ACQUIRE, this message is purely informational, and demands no other PF_KEY interaction. SADB_X_PCHANGE は、SADB_ACQUIRE メッセージに対する受動側 (別名 "listener" や "receiver") 対応部分である。これは鍵管理アプリケーション が、システムワイドなデフォルトセキュリティサービスから離れた受動側セッ ションのため、入って来る鍵管理要求をより効果的に扱うことを望む時に有用 である。もしセキュリティサービスの確実なレベルのみが割り当てられること を受動セッションが要求するなら、SADB_X_PCHANGE メッセージは、何らかの 登録された PF_KEY sockets に、この変更を表す。SADB_ACQUIRE と違い、こ のメッセージは純粋に情報であり、他の PF_KEY 相互作用を要求しない。 The SADB_X_PCHANGE message is typically triggered by either a change in an endpoint's requested security services, or when an endpoint that made a special request disappears. In the former case, an SADB_X_PCHANGE looks like an SADB_ACQUIRE, complete with an sadb_proposal extension indicating the preferred algorithms, lifetimes, and other attributes. When a passive session either disappears, or reverts to a default behavior, an SADB_X_PCHANGE will be issued with _no_ sadb_proposal extension, indicating that the exception to systemwide default behavior has disappeared. SADB_X_PCHANGE メッセージは、endpoint の要求されるセキュリティサービス の変更か、特別な要求が作成された endpoint が見えなくなった時に、典型的 にきっかけとされる。前者のケースで SADB_X_PCHANGE は、提案されたアルゴ リズム、生存時間と他の属性を指し示した sadb_proposal 拡張を持つ全部の SADB_ACQUIRE のようにみえる。受動セッションが見えなくなるか、デフォル トの動作に戻る時、SADB_X_PCHANGE は、システムワイドなデフォルト動作へ の例外が見えなくなることを指し示して、sadb_proposal 拡張を持たずに発行 されるだろう。 There are two messaging behaviors for SADB_X_PCHANGE. The first is the kernel-originated case: SADB_X_PCHANGE のために、2 つのメッセージ動作がある。最初は kernel で 作成されたケースである: The kernel sends an SADB_X_PCHANGE message to registered sockets. kernel は、登録された sockets に SADB_X_PCHANGE メッセージを送信 する。 NOTE: The address(SD) extensions MUST have the port fields filled in with the port numbers of the session requiring keys if appropriate. 注意: アドレス (SD) 拡張は、もし適するなら、鍵を要求しているセッ ションの port 番号で書き込まれた ports フィールドを持たな ければならない (MUST)。 The second is for a user-level consumer of SAs. 2 番目は、SAs のユーザレベル consumer のためである。 Send an SADB_X_PCHANGE message from a user process to the kernel. ユーザプロセスから kernel へと、SADB_X_PCHANGE メッセージを送信す る。 The kernel returns an SADB_X_PCHANGE message to registered sockets. kernel は登録された sockets に SADB_X_PCHANGE メッセージを返す。 Appendix C: Key Management Private Data Extension 付録 C: 鍵管理非公開データ拡張 The Key Management Private Data extension is attached to either an SADB_ADD or an SADB_UPDATE message. It attaches a single piece of arbitrary data to a security association. It may be useful for key managment applications that could use an SADB_DUMP or SADB_GET message to obtain additional state if it needs to restart or recover after a crash. The format of this extension is: Key Management Private Data 拡張は、SADB_ADD や SADB_UPDATE メッセージ どちらかに取り付けられる。これはセキュリティアソシエーションに対し、任 意のデータのたった 1 つの一部分を取り付ける。もし crash の後、鍵管理ア プリケーションが再起動や回復を必要とするなら、追加の状態を得るために SADB_DUMP や SADB_GET メッセージを使用することができる鍵管理アプリケー ションについて有用であるかもしれない。この拡張の形式は、(次のとおりで ある): #define SADB_X_EXT_KMPRIVATE 17 struct sadb_x_kmprivate { uint16_t sadb_x_kmprivate_len; uint16_t sadb_x_kmprivate_exttype; uint32_t sadb_x_kmprivate_reserved; }; /* sizeof(struct sadb_x_kmprivate) == 8 */ /* followed by arbitrary data */ /* 任意のデータにより続けられる */ The data following the sadb_x_kmprivate extension can be anything. It will be stored with the actual security association in the kernel. Like all data, it must be padded to an eight byte boundary. sadb_x_kmpribate 拡張に続くデータは、どのようなものでもできる。kernel に実際のセキュリティアソシエーションで置かれるだろう。すべてのデータ のように、これは 8 byte 境界にパディングされなければならない。 Appendix D: Sample Header File 付録 D: サンプルヘッダファイル /* This file defines structures and symbols for the PF_KEY Version 2 key management interface. It was written at the U.S. Naval Research Laboratory. This file is in the public domain. The authors ask that you leave this credit intact on any copies of this file. */ /* このファイルは、PF_KEY Version 2 鍵管理インターフェイスのための構造体 とシンボルを定義する。これは、U.S. Naval Research Laboratory で書かれ た。このファイルは、public domain である。著者は、あなたがこのファイル の何らかのコピーで、この功績をそのままにしておくことを求める。 */ #ifndef __PFKEY_V2_H #define __PFKEY_V2_H 1 #define PF_KEY_V2 2 #define PFKEYV2_REVISION 199806L #define SADB_RESERVED 0 #define SADB_GETSPI 1 #define SADB_UPDATE 2 #define SADB_ADD 3 #define SADB_DELETE 4 #define SADB_GET 5 #define SADB_ACQUIRE 6 #define SADB_REGISTER 7 #define SADB_EXPIRE 8 #define SADB_FLUSH 9 #define SADB_DUMP 10 #define SADB_X_PROMISC 11 #define SADB_X_PCHANGE 12 #define SADB_MAX 12 struct sadb_msg { uint8_t sadb_msg_version; uint8_t sadb_msg_type; uint8_t sadb_msg_errno; uint8_t sadb_msg_satype; uint16_t sadb_msg_len; uint16_t sadb_msg_reserved; uint32_t sadb_msg_seq; uint32_t sadb_msg_pid; }; struct sadb_ext { uint16_t sadb_ext_len; uint16_t sadb_ext_type; }; struct sadb_sa { uint16_t sadb_sa_len; uint16_t sadb_sa_exttype; uint32_t sadb_sa_spi; uint8_t sadb_sa_replay; uint8_t sadb_sa_state; uint8_t sadb_sa_auth; uint8_t sadb_sa_encrypt; uint32_t sadb_sa_flags; }; struct sadb_lifetime { uint16_t sadb_lifetime_len; uint16_t sadb_lifetime_exttype; uint32_t sadb_lifetime_allocations; uint64_t sadb_lifetime_bytes; uint64_t sadb_lifetime_addtime; uint64_t sadb_lifetime_usetime; }; struct sadb_address { uint16_t sadb_address_len; uint16_t sadb_address_exttype; uint8_t sadb_address_proto; uint8_t sadb_address_prefixlen; uint16_t sadb_address_reserved; }; struct sadb_key { uint16_t sadb_key_len; uint16_t sadb_key_exttype; uint16_t sadb_key_bits; uint16_t sadb_key_reserved; }; struct sadb_ident { uint16_t sadb_ident_len; uint16_t sadb_ident_exttype; uint16_t sadb_ident_type; uint16_t sadb_ident_reserved; uint64_t sadb_ident_id; }; struct sadb_sens { uint16_t sadb_sens_len; uint16_t sadb_sens_exttype; uint32_t sadb_sens_dpd; uint8_t sadb_sens_sens_level; uint8_t sadb_sens_sens_len; uint8_t sadb_sens_integ_level; uint8_t sadb_sens_integ_len; uint32_t sadb_sens_reserved; }; struct sadb_prop { uint16_t sadb_prop_len; uint16_t sadb_prop_exttype; uint8_t sadb_prop_replay; uint8_t sadb_prop_reserved[3]; }; struct sadb_comb { uint8_t sadb_comb_auth; uint8_t sadb_comb_encrypt; uint16_t sadb_comb_flags; uint16_t sadb_comb_auth_minbits; uint16_t sadb_comb_auth_maxbits; uint16_t sadb_comb_encrypt_minbits; uint16_t sadb_comb_encrypt_maxbits; uint32_t sadb_comb_reserved; uint32_t sadb_comb_soft_allocations; uint32_t sadb_comb_hard_allocations; uint64_t sadb_comb_soft_bytes; uint64_t sadb_comb_hard_bytes; uint64_t sadb_comb_soft_addtime; uint64_t sadb_comb_hard_addtime; uint64_t sadb_comb_soft_usetime; uint64_t sadb_comb_hard_usetime; }; struct sadb_supported { uint16_t sadb_supported_len; uint16_t sadb_supported_exttype; uint32_t sadb_supported_reserved; }; struct sadb_alg { uint8_t sadb_alg_id; uint8_t sadb_alg_ivlen; uint16_t sadb_alg_minbits; uint16_t sadb_alg_maxbits; uint16_t sadb_alg_reserved; }; struct sadb_spirange { uint16_t sadb_spirange_len; uint16_t sadb_spirange_exttype; uint32_t sadb_spirange_min; uint32_t sadb_spirange_max; uint32_t sadb_spirange_reserved; }; struct sadb_x_kmprivate { uint16_t sadb_x_kmprivate_len; uint16_t sadb_x_kmprivate_exttype; uint32_t sadb_x_kmprivate_reserved; }; #define SADB_EXT_RESERVED 0 #define SADB_EXT_SA 1 #define SADB_EXT_LIFETIME_CURRENT 2 #define SADB_EXT_LIFETIME_HARD 3 #define SADB_EXT_LIFETIME_SOFT 4 #define SADB_EXT_ADDRESS_SRC 5 #define SADB_EXT_ADDRESS_DST 6 #define SADB_EXT_ADDRESS_PROXY 7 #define SADB_EXT_KEY_AUTH 8 #define SADB_EXT_KEY_ENCRYPT 9 #define SADB_EXT_IDENTITY_SRC 10 #define SADB_EXT_IDENTITY_DST 11 #define SADB_EXT_SENSITIVITY 12 #define SADB_EXT_PROPOSAL 13 #define SADB_EXT_SUPPORTED_AUTH 14 #define SADB_EXT_SUPPORTED_ENCRYPT 15 #define SADB_EXT_SPIRANGE 16 #define SADB_X_EXT_KMPRIVATE 17 #define SADB_EXT_MAX 17 #define SADB_SATYPE_UNSPEC 0 #define SADB_SATYPE_AH 2 #define SADB_SATYPE_ESP 3 #define SADB_SATYPE_RSVP 5 #define SADB_SATYPE_OSPFV2 6 #define SADB_SATYPE_RIPV2 7 #define SADB_SATYPE_MIP 8 #define SADB_SATYPE_MAX 8 #define SADB_SASTATE_LARVAL 0 #define SADB_SASTATE_MATURE 1 #define SADB_SASTATE_DYING 2 #define SADB_SASTATE_DEAD 3 #define SADB_SASTATE_MAX 3 #define SADB_SAFLAGS_PFS 1 #define SADB_AALG_NONE 0 #define SADB_AALG_MD5HMAC 2 #define SADB_AALG_SHA1HMAC 3 #define SADB_AALG_MAX 3 #define SADB_EALG_NONE 0 #define SADB_EALG_DESCBC 2 #define SADB_EALG_3DESCBC 3 #define SADB_EALG_NULL 11 #define SADB_EALG_MAX 11 #define SADB_IDENTTYPE_RESERVED 0 #define SADB_IDENTTYPE_PREFIX 1 #define SADB_IDENTTYPE_FQDN 2 #define SADB_IDENTTYPE_USERFQDN 3 #define SADB_IDENTTYPE_MAX 3 #define SADB_KEY_FLAGS_MAX 0 #endif /* __PFKEY_V2_H */ Appendix E: Change Log 付録 E: 変更ログ The following changes were made between 05 and 06: 次の変更は、05 と 06 の間でおこなわれた: * Last change before becoming an informational RFC. Removed all Internet-Draft references. Also standardized citation strings. Now cite RFC 2119 for MUST, etc. * 広域的な情報である RFC になる前の最後の変更。すべての Internet-Draft 参考文献を取り除いた。標準化された引用文字列もまた取り除いた。今、 MUST 等のために RFC 2119 を引用する。 * New appendix on optional KM private data extension. * オプションである KM 非公開データ拡張での新しい付録。 * Fixed example to indicate the ACQUIRE messages with errno mean KM failure. * ACQUIRE は KM 失敗を意味した errno を持っていて、そのことを指し示す 例を訂正。 * Added SADB_EALG_NULL. * SADB_EALG_NULL を追加。 * Clarified proxy examples to match definition of PROXY address being the inner packet's source address. (Basically a sign-flip. The example still shows how to protect against policy vulnerabilities in tunnel endpoints.) * 内側パケットの始点アドレスである PROXY アドレスの定義にマッチするた めのプロクシ例を明瞭化。 * Loosened definition of a destination address to include broadcast. * ブロードキャストを含む終点アドレスの、ゆるい定義。 * Recommended that LARVAL security associations have implicit short lifetimes. * LARVAL セキュリティアソシエーションは暗に意味された短い生存時間を持 つことが推奨される。 The following changes were made between 04 and 05: 次の変更は 04 と 05 の間でおこなわれた: * New appendix on Passive Change message. * Passive Change メッセージでの新しい付録。 * New sadb_address_prefixlen field. * 新しい sadb_address_prefixlen フィールド。 * Small clarifications on sadb_ident_id usage. * sadb_ident_id 使用法での、小さな明瞭化。 * New PFKEYV2_REVISION value. * 新しい PFKEYV2_REVISION 値。 * Small clarification on what a PROXY address is. * PROXY アドレスが何であるかの、小さな明瞭化。 * Corrected sadb_spirange_{min,max} language. * sadb_spirange_{min,max} 専門用語を訂正。 * In ADD messages that are in response to an ACQUIRE, the sadb_msg_seq MUST be the same as that of the originating ACQUIRE. * ACQUIRE に対するレスポンスである ADD メッセージで、sadb_msg_seq は、 生成する ACQUIRE のそれと同じでなければならない (MUST)。 * Corrected ACQUIRE message behavior, ACQUIRE message SHOULD send up PROXY addresses when it needs them. * ACQUIRE メッセージ動作を訂正。ACQUIRE メッセージがは PROXY アドレス を必要とする時、そのメッセージは PROXY アドレスを上に送信すべきであ る。 * Clarification on SADB_EXPIRE and user-level security protocols. * SADB_EXPIRE と、ユーザレベルセキュリティプロトコルでの明瞭化。 The following changes were made between 03 and 04: 次の変更は 03 と 04 の間でおこなわれた: * Stronger language about manual keying. * 手動鍵設定について、より強力な専門用語。 * PFKEYV2_REVISION, ala POSIX. * PFKEYV2_REVISION、別名 POSIX。 * Put in language about sockaddr ports in ACQUIRE messages. * ACQUIRE メッセージでの sockaddr ports について専門用語を入れた。 * Mention of asymmetric algorithms. * 非対称アルゴリズムの記載。 * New sadb_ident_id field for easier construction of USER_FQDN identity strings. * USER_FQDN 身元文字列の、より簡単な構造のための新しい sadb_ident_id フィールド。 * Caveat about source addresses not always used for collision detection. (e.g. IPsec) * 衝突発見のために、いつも使用されない始点アドレスについての警告。(た とえば IPsec) The following changes were made between 02 and 03: 次の変更は 02 と 03 の間でおこなわれた: * Formatting changes. * 形式の変更。 * Many editorial cleanups, rewordings, clarifications. * 多くの編集の一掃、言い替え、明瞭化。 * Restrictions that prevent many strange and invalid cases. * 多くの未知で無効なケースを防ぐ制限。 * Added definitions section. * 定義セクションの追加。 * Removed connection identity type (this will reappear when it is more clear what it should look like). * コネクション身元タイプを除去 (これは、それがもっと明らかになる時、何 らかのものになるべきように再び見えるだろう)。 * Removed 5.2.1 (Why involve the kernel?). * 5.2.1 を除去 (なぜ kernel を必然的に含む ?)。 * Removed INBOUND, OUTBOUND, and FORWARD flags; they can be computed from src, dst, and proxy and you had to anyway for sanity checking. * INBOUND, OUTBOUND と FORWARD フラグの除去; これらは src, dst と proxy から計算されることができ、とにかく sanity checking のためにし なければならない。 * Removed REPLAY flag; sadb_sa_replay==0 means the same thing. * REPLAY フラグを削除; sadb_sa_replay==0 は同じことを意味する。 * Renamed bit lengths to "bits" to avoid potential confusion. * 可能性のある混乱を避けるために、bit 長を "bits" にリネーム。 * Explicitly listed lengths for structures. * 明示的に、構造体の長さをリスト。 * Reworked identities to always use a string format. * 文字列形式をいつも使用するように、身元を作り直した。 * Removed requirements for support of shutdown() and SO_USELOOPBACK. * shutdown() と SO_USELOOPBACK のサポートのための要求を削除。 * 64 bit alignment and 64 bit lengths instead of 32 bit. * 32 bit の代わりに 64 bit アライメントと 64 bit 長。 * time_t replaced with uint64 in lifetimes. * 生存時間で、uint64 を持つ大きさに置き換えられた time_t。 * Inserted Appendix A (SADB_X_PROMISC) and Appendix B (SAMPLE HEADER FILE). * 付録 A (SADB_X_PROMISC) と付録 B (SAMPLE HEADER FILE) を挿入。 * Explicit error if PF_KEY_V2 not set at socket() call. * もし PF_KEY_V2 が socket call() でセットされないなら明示的なエラー。 * More text on SO_USELOOPBACK. * SO_USELOOPBACK での、より多い文章。 * Made fields names and symbol names more consistent. * より一致したフィールド名とシンボル名の作成。 * Explicit error if PF_KEY_V2 is not in sadb_msg_version field. * もし PF_KEY_V2 が sadb_msg_version フィールドにないなら、明示的なエ ラー。 * Bytes lifetime field now a 64-bit quantity. * 今、64-bit 数の生存時間フィールド。 * Explicit len/exttype wording. * 明示的な len/exttype 用語。 * Flattening out of extensions (LIFETIME_HARD, LIFETIME_SOFT, etc.) * 拡張 (LIFETIME_HARD, LIFETIME_SOFT 等) から平らになる。 * UI example (0x123 == 0x1230 or 0x0123). * UI 例 (0x123 == 0x1230 か 0x0123)。 * Cleaned up and fixed some message behavior examples. * 一掃と、一部のメッセージ動作例の修正。 The following changes were made between 01 and 02: 次の変更は、01 と 02 の間でおこなわれた: * Mentioned that people COULD use these same messages between user progs. (Also mentioned why you still might want to use the actual socket.) * 人々が、ユーザとプログラムの間でこれらの同じメッセージを使用すること ができることを記載。(あなたが実際の socket を、なぜまだ使用したいか もしれないことも記載。) * Various wordsmithing changes. * さまざまな流ちょうで豊かなものに変更。 * Took out netkey/ directory, and make net/pfkeyv2.h * netkey/ ディレクトリの除去と、net/pfkeyv2.h の作成。 * Inserted PF_KEY_V2 proto argument per C. Metz. * C に対し PF_KEY_V2 プロトコル引数の挿入。Metz。 * Mentioned other socket calls and how their PF_KEY behavior is undefined. * 他の socket call と PF_KEY の動作がどのように定義されないかの記載。 * SADB_EXPIRE now communicates both hard and soft lifetime expires. * SADB_EXPIRE は、厳密と緩やかな生存時間期限両方を今通信する。 * New "association" extension, even smaller base header. * より小さい基本ヘッダでさえ、新しい "association" 拡張。 * Lifetime extension improvements. * Lifetime 拡張の改良。 * Length now first in extensions. * 今、拡張での最初の長さ。 * Errors can be sent from kernel to user, also. * エラーは、kernel からユーザにも送信されることができる。 * Examples section inserted. * Examples セクションの挿入。 * Some bitfield cleanups, including STATE and SA_OPTIONS cleanup. * STATE と SA_OPTIONS の一掃を含む、一部のビットフィールドの一掃。 * Key splitting now only across auth algorithm and encryption algorithm. Thanks for B. Sommerfeld for clues here. * 今、認証アルゴリズムと暗号アルゴリズムを横切るのみの鍵分割。B につい て感謝。ここでの手がかりについて Sommerfeld。 The following changes were made between 00 and 01: 次の変更は、00 と 01 の間でおこなわれた: * Added this change log. * この変更ログを追加。 * Simplified TLV header syntax. * 単純化された TLV ヘッダ構文。 * Splitting of algorithms. This may be controversial, but it allows PF_KEY to be used for more than just IPsec. It also allows some kinds of policies to be placed in the KMd easier. * アルゴリズムの分割。これは議論の余地があるかもしれない。しかしこれは PF_KEY に、IPsec だけよりも多くのもののために使用させることを許す。 これもポリシーの一部の種類に、KMd 内へと容易に置かせることを許す。 * Added solid definitions and formats for certificate identities, multiple keys, etc. * 証明書身元、複数鍵等についての、信頼できる定義と形式の追加。 * Specified how keys are to be layed out (most-to-least bits). * 鍵がどのように配置されるかを指定 (最上位から最下位ビット)。 * Changed sequence number semantics to be like an RPC transaction ID number. * RFC transaction ID 値のようである順序番号セマンティクスに変更。 F. Full Copyright Statement F. 著作権表示全文 Copyright (C) The Internet Society (1998). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. --- 日本語訳: 鈴木 知見