RFC2412 日本語訳
2412 The OAKLEY Key Determination Protocol. H. Orman. November 1998. (Format: TXT=118649 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group H. Orman
Request for Comments: 2412 Department of Computer Science
Category: Informational University of Arizona
November 1998
Ormanがコメントのために要求するワーキンググループH.をネットワークでつないでください: 2412年のコンピュータサイエンス学部カテゴリ: 情報のアリゾナ大学1998年11月
The OAKLEY Key Determination Protocol
オークリーの主要な決断プロトコル
Status of this Memo
この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.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright(C)インターネット協会(1998)。 All rights reserved。
Abstract
要約
This document describes a protocol, named OAKLEY, by which two authenticated parties can agree on secure and secret keying material. The basic mechanism is the Diffie-Hellman key exchange algorithm.
このドキュメントは2回の認証されたパーティーが安全で秘密の合わせることの材料に同意できるオークリーというプロトコルについて説明します。 基本的機構はディフィー-ヘルマンの主要な交換アルゴリズムです。
The OAKLEY protocol supports Perfect Forward Secrecy, compatibility with the ISAKMP protocol for managing security associations, user- defined abstract group structures for use with the Diffie-Hellman algorithm, key updates, and incorporation of keys distributed via out-of-band mechanisms.
オークリープロトコルはバンドで出ているメカニズムで分配されたキーのディフィー-ヘルマンアルゴリズム、主要なアップデート、および編入でPerfect Forward Secrecy、セキュリティ協会を経営するためのISAKMPプロトコルとの互換性に使用のためのユーザの定義された抽象的な集団構造を支えます。
1. INTRODUCTION
1. 序論
Key establishment is the heart of data protection that relies on cryptography, and it is an essential component of the packet protection mechanisms described in [RFC2401], for example. A scalable and secure key distribution mechanism for the Internet is a necessity. The goal of this protocol is to provide that mechanism, coupled with a great deal of cryptographic strength.
主要な設立は暗号を当てにするデータ保護の心です、そして、それは例えば、[RFC2401]で説明されたパケット保護メカニズムの必須成分です。 インターネットへのスケーラブルで安全な主要な分配メカニズムは必要性です。 このプロトコルの目標は多くの暗号の強さに結びつけられたそのメカニズムを提供することです。
The Diffie-Hellman key exchange algorithm provides such a mechanism. It allows two parties to agree on a shared value without requiring encryption. The shared value is immediately available for use in encrypting subsequent conversation, e.g. data transmission and/or authentication. The STS protocol [STS] provides a demonstration of how to embed the algorithm in a secure protocol, one that ensures that in addition to securely sharing a secret, the two parties can be sure of each other's identities, even when an active attacker exists.
ディフィー-ヘルマンの主要な交換アルゴリズムはそのようなメカニズムを提供します。 それで、暗号化を必要としないで、2回のパーティーが共有された値に同意できます。 共有された値はすぐに、その後の会話、例えばデータ伝送を暗号化することにおける使用、そして/または、認証に利用可能です。 2回のパーティーがSTSプロトコル[STS]はどう安全なプロトコルにアルゴリズムを埋め込むかに関するデモンストレーションを提供します、しっかりと秘密を共有することに加えてそれを確実にするものを互いのアイデンティティを確信している場合があります、活発な攻撃者が存在すると。
Orman Informational [Page 1] RFC 2412 The OAKLEY Key Determination Protocol November 1998
決断プロトコル1998年11月に主要なOrmanの情報[1ページ]のRFC2412のオークリー
Because OAKLEY is a generic key exchange protocol, and because the keys that it generates might be used for encrypting data with a long privacy lifetime, 20 years or more, it is important that the algorithms underlying the protocol be able to ensure the security of the keys for that period of time, based on the best prediction capabilities available for seeing into the mathematical future. The protocol therefore has two options for adding to the difficulties faced by an attacker who has a large amount of recorded key exchange traffic at his disposal (a passive attacker). These options are useful for deriving keys which will be used for encryption.
オークリーが総称キー交換プロトコルであり、それが生成するキーが長いプライバシー生涯でデータを暗号化するのに使用されるかもしれないので、20年間以上、プロトコルの基礎となるアルゴリズムがその期間にキーのセキュリティを確実にすることができるのは、重要です、数学の未来を調べるのに利用可能な最も良い予測能力に基づいて。 したがって、プロトコルで、彼の自由(受け身の攻撃者)に多量の記録された主要な交換トラフィックを持っている攻撃者は困難に加えるための2つのオプションに直面しています。 これらのオプションは暗号化に使用されるキーを引き出すことの役に立ちます。
The OAKLEY protocol is related to STS, sharing the similarity of authenticating the Diffie-Hellman exponentials and using them for determining a shared key, and also of achieving Perfect Forward Secrecy for the shared key, but it differs from the STS protocol in several ways.
オークリープロトコルは、ディフィー-ヘルマンexponentialsを認証する類似性を共有して、共有されたキーを決定するのに彼らを使用して、STSに関連して、いくつかの方法でまた、しかし、共有されたキー、それのためにPerfect Forward Secrecyを達成するのをSTSプロトコルと異なっています。
The first is the addition of a weak address validation mechanism
("cookies", described by Phil Karn in the Photuris key exchange
protocol work in progress) to help avoid denial of service
attacks.
1番目はサービス不能攻撃を避けるのを助ける弱いアドレス合法化メカニズム(Photurisの主要な交換プロトコル処理中の作業でフィルKarnによって説明された「クッキー」)の追加です。
The second extension is to allow the two parties to select
mutually agreeable supporting algorithms for the protocol: the
encryption method, the key derivation method, and the
authentication method.
2番目の拡大は2回のパーティーがプロトコルのために互いに快いサポートアルゴリズムを選択するのを許容することです: 暗号化メソッド、主要な誘導法、および認証方法。
Thirdly, the authentication does not depend on encryption using
the Diffie-Hellman exponentials; instead, the authentication
validates the binding of the exponentials to the identities of the
parties.
三番目に、認証はディフィー-ヘルマンexponentialsを使用することで暗号化によりません。 代わりに、認証はexponentialsの結合をパーティーのアイデンティティに有効にします。
The protocol does not require the two parties compute the shared
exponentials prior to authentication.
プロトコルは2回のパーティーを必要としません。認証の前に共有されたexponentialsを計算してください。
This protocol adds additional security to the derivation of keys
meant for use with encryption (as opposed to authentication) by
including a dependence on an additional algorithm. The derivation
of keys for encryption is made to depend not only on the Diffie-
Hellman algorithm, but also on the cryptographic method used to
securely authenticate the communicating parties to each other.
このプロトコルは、暗号化(認証と対照的に)で追加アルゴリズムへの依存を含んでいることによって、使用のために意味されたキーの派生に追加担保を加えます。 ディフィーヘルマンアルゴリズムによるだけではなく、しっかりと交信を認証するのに使用される暗号のメソッドにもよるのを暗号化をするので、キーの派生は互いにパーティーへ行きます。
Finally, this protocol explicitly defines how the two parties can
select the mathematical structures (group representation and
operation) for performing the Diffie-Hellman algorithm; they can
use standard groups or define their own. User-defined groups
provide an additional degree of long-term security.
最終的に、このプロトコルは明らかに2回のパーティーがディフィー-ヘルマンアルゴリズムを実行するために、どう、数学的構造(集団代表制と操作)を選択できるかを定義します。 彼らは、標準のグループを使用するか、またはそれら自身のを定義できます。 ユーザによって定義されたグループは追加度合いの長期のセキュリティを提供します。
Orman Informational [Page 2] RFC 2412 The OAKLEY Key Determination Protocol November 1998
決断プロトコル1998年11月に主要なOrmanの情報[2ページ]のRFC2412のオークリー
OAKLEY has several options for distributing keys. In addition to the classic Diffie-Hellman exchange, this protocol can be used to derive a new key from an existing key and to distribute an externally derived key by encrypting it.
オークリーには、キーを分配するためのいくつかのオプションがあります。 古典的なディフィー-ヘルマンの交換に加えて、既存のキーから新しいキーを得て、それを暗号化することによって外部的に派生しているキーを分配するのにこのプロトコルを使用できます。
The protocol allows two parties to use all or some of the anti- clogging and perfect forward secrecy features. It also permits the use of authentication based on symmetric encryption or non-encryption algorithms. This flexibility is included in order to allow the parties to use the features that are best suited to their security and performance requirements.
プロトコルで、2回のパーティーが反目詰まりの、そして、完全な前進の秘密保持機能のすべてかいくつかを使用できます。 また、それは左右対称の暗号化か非暗号化アルゴリズムに基づく認証の使用を可能にします。この柔軟性は、パーティーがそれらのセキュリティと性能要件に最も良い合わせる特徴を使用するのを許容するために含まれています。
This document draws extensively in spirit and approach from the Photuris work in progress by Karn and Simpson (and from discussions with the authors), specifics of the ISAKMP document by Schertler et al. the ISAKMP protocol document, and it was also influenced by papers by Paul van Oorschot and Hugo Krawcyzk.
このドキュメントはKarnとシンプソン(そして作者との議論から)による進行中のPhoturis仕事から精神とアプローチで手広く作成されて、ISAKMPの詳細はSchertler他でISAKMPプロトコルドキュメントを記録します、そして、また、それがポールバンOorschotとユーゴーKrawcyzkによる書類によって影響を及ぼされました。
2. The Protocol Outline
2. プロトコルアウトライン
2.1 General Remarks
2.1 一般所見
The OAKLEY protocol is used to establish a shared key with an assigned identifier and associated authenticated identities for the two parties. The name of the key can be used later to derive security associations for the RFC 2402 and RFC 2406 protocols (AH and ESP) or to achieve other network security goals.
オークリープロトコルは、2回のパーティーのために割り当てられた識別子と関連認証されたアイデンティティで共有されたキーを証明するのに使用されます。 後でRFC2402とRFC2406プロトコル(AHと超能力)のためにセキュリティ協会を引き出すか、または他のネットワークセキュリティ目標を達成するのにキーの名前を使用できます。
Each key is associated with algorithms that are used for authentication, privacy, and one-way functions. These are ancillary algorithms for OAKLEY; their appearance in subsequent security association definitions derived with other protocols is neither required nor prohibited.
それぞれのキーは認証、プライバシー、および一方向関数に使用されるアルゴリズムに関連しています。 これらはオークリーへの付属のアルゴリズムです。 他のプロトコルで引き出されたその後のセキュリティ協会定義におけるそれらの外観は、必要でなく、また禁止されていません。
The specification of the details of how to apply an algorithm to data is called a transform. This document does not supply the transform definitions; they will be in separate RFC's.
どうアルゴリズムをデータに適用するかに関する詳細の仕様は変換と呼ばれます。 このドキュメントは変換定義を供給しません。 they will be in separate RFC's.
The anti-clogging tokens, or "cookies", provide a weak form of source address identification for both parties; the cookie exchange can be completed before they perform the computationally expensive part of the protocol (large integer exponentiations).
トークン、または「クッキー」が双方のためのソースアドレス識別の弱形を提供する反目詰まり。 彼らがプロトコル(大きい整数羃法)の計算上高価な部分を実行する前にクッキー交換は終了できます。
It is important to note that OAKLEY uses the cookies for two purposes: anti-clogging and key naming. The two parties to the protocol each contribute one cookie at the initiation of key establishment; the pair of cookies becomes the key identifier (KEYID), a reusable name for the keying material. Because of this
オークリーが2つの目的にクッキーを使用することに注意するのは重要です: 反目詰まりの、そして、主要な命名。 プロトコルへの2回のパーティーが主要な設立の手引きでそれぞれ1個のクッキーを寄付します。 クッキーの組は主要な識別子(KEYID)、合わせることの材料のための再利用できる名前になります。 これ
Orman Informational [Page 3] RFC 2412 The OAKLEY Key Determination Protocol November 1998
決断プロトコル1998年11月に主要なOrmanの情報[3ページ]のRFC2412のオークリー
dual role, we will use the notation for the concatenation of the
cookies ("COOKIE-I, COOKIE-R") interchangeably with the symbol
"KEYID".
ニ重の役割、私たちはクッキー(「クッキーI、クッキーR」)の連結に"KEYID"というシンボルで記法を互換性を持って使用するつもりです。
OAKLEY is designed to be a compatible component of the ISAKMP protocol [ISAKMP], which runs over the UDP protocol using a well- known port (see the RFC on port assignments, STD02-RFC-1700). The only technical requirement for the protocol environment is that the underlying protocol stack must be able to supply the Internet address of the remote party for each message. Thus, OAKLEY could, in theory, be used directly over the IP protocol or over UDP, if suitable protocol or port number assignments were available.
オークリーは、ISAKMPプロトコル[ISAKMP]のコンパチブル成分になるように設計されています(ポート課題にRFCを見てください、STD02-RFC-1700)。(プロトコルは、よく知られているポートを使用することでUDPプロトコルをひきます)。 プロトコル環境のための唯一の技術的要求事項は基本的なプロトコル・スタックがリモートパーティーのインターネット・アドレスを各メッセージに供給できなければならないということです。 したがって、IPプロトコルの直接上、または、UDPの上で理論上オークリーを使用できました、適当なプロトコルかポートナンバー課題が利用可能であったなら。
The machine running OAKLEY must provide a good random number generator, as described in [RANDOM], as the source of random numbers required in this protocol description. Any mention of a "nonce" implies that the nonce value is generated by such a generator. The same is true for "pseudorandom" values.
マシン実行オークリーは良い乱数発生器を提供しなければなりません、[RANDOM]で説明されるように、乱数の源がこのプロトコル記述で必要であるように。 「一回だけ」のどんな言及も、一回だけの値がそのようなジェネレータによって生成されるのを含意します。 「擬似ランダム」値に、同じくらいは本当です。
2.2 Notation
2.2 記法
The section describes the notation used in this document for message sequences and content.
セクションは本書ではメッセージ系列と内容に使用される記法を説明します。
2.2.1 Message descriptions
2.2.1 メッセージ記述
The protocol exchanges below are written in an abbreviated notation that is intended to convey the essential elements of the exchange in a clear manner. A brief guide to the notation follows. The detailed formats and assigned values are given in the appendices.
以下でのプロトコル交換は明確な方法で交換の必須元素を伝えることを意図する省略表記法で書かれています。 記法への簡潔なガイドは続きます。 付録で詳細な形式と割り当てられた値を与えます。
In order to represent message exchanges succinctly, this document uses an abbreviated notation that describes each message in terms of its source and destination and relevant fields.
簡潔に交換処理を表すために、このドキュメントはそのソースと目的地に関して各メッセージについて説明する省略表記法と関連分野を使用します。
Arrows ("->") indicate whether the message is sent from the initiator
to the responder, or vice versa ("<-").
アロウズ("->")は、メッセージが創始者から応答者に送られるかどうかを示すか、逆もまた同様です("<")。
The fields in the message are named and comma separated. The protocol uses the convention that the first several fields constitute a fixed header format for all messages.
メッセージの分野は命名されました、そして、コンマは分離しました。 プロトコルはコンベンションを使用します。いくつかの最初の分野がすべてのメッセージのための固定ヘッダー形式を構成します。
For example, consider a HYPOTHETICAL exchange of messages involving a fixed format message, the four fixed fields being two "cookies", the third field being a message type name, the fourth field being a multi-precision integer representing a power of a number:
例えば、固定フォーマットメッセージにかかわるメッセージのHYPOTHETICAL交換を考えてください、4つの固定分野が2「クッキー」であり、3番目の分野がメッセージ型名であり、4番目の分野が累乗を表すマルチ精度整数であり:
Orman Informational [Page 4] RFC 2412 The OAKLEY Key Determination Protocol November 1998
決断プロトコル1998年11月に主要なOrmanの情報[4ページ]のRFC2412のオークリー
Initiator Responder
-> Cookie-I, 0, OK_KEYX, g^x ->
<- Cookie-R, Cookie-I, OK_KEYX, g^y <-
創始者Responder->Cookie-I(0)は_g^x-><KEYX、クッキーR、Cookie-I、OK_KEYX、g^y<を承認します。
The notation describes a two message sequence. The initiator begins by sending a message with 4 fields to the responder; the first field has the unspecified value "Cookie-I", second field has the numeric value 0, the third field indicates the message type is OK_KEYX, the fourth value is an abstract group element g to the x'th power.
記法は2メッセージ系列について説明します。 創始者は4つの分野でメッセージを送ることによって、応答者に始めます。 最初の分野には、不特定の値「クッキーI」があって、2番目の分野では、数値0があって、3番目の分野が、メッセージタイプがOK_KEYXであることを示して、4番目の値はx'thパワーへの抽象的なグループ要素gです。
The second line indicates that the responder replies with value "Cookie-R" in the first field, a copy of the "Cookie-I" value in the second field, message type OK_KEYX, and the number g raised to the y'th power.
セカンドラインは、応答者が最初の分野、2番目の分野、メッセージタイプOK_KEYX、および数gにおける「クッキーI」価値のコピーの「クッキーR」がy'thパワーに上げた値で返答するのを示します。
The value OK_KEYX is in capitals to indicate that it is a unique constant (constants are defined in the appendices).
それがユニークな定数であることを示すために、値のOK_KEYXは首都にあります(定数は付録で定義されます)。
Variable precision integers with length zero are null values for the protocol.
長さゼロに従った可変精度整数はプロトコルのためのヌル値です。
Sometimes the protocol will indicate that an entire payload (usually the Key Exchange Payload) has null values. The payload is still present in the message, for the purpose of simplifying parsing.
時々、プロトコルは、全体のペイロード(通常Key Exchange有効搭載量)にはヌル値があるのを示すでしょう。 ペイロードは構文解析を簡素化する目的へのメッセージにまだ存在しています。
2.2.2 Guide to symbols
2.2.2 シンボルへのガイド
Cookie-I and Cookie-R (or CKY-I and CKY-R) are 64-bit pseudo-random numbers. The generation method must ensure with high probability that the numbers used for each IP remote address are unique over some time period, such as one hour.
クッキーIとCookie-R(または、CKY-IとCKY-R)は64ビットの擬似乱数です。 世代メソッドは数が各IPに使用した高い確率でリモートアドレスが確実にいつかの期間にわたってユニークになるようにしなければなりません、1時間などのように。
KEYID is the concatenation of the initiator and responder cookies and the domain of interpretation; it is the name of keying material.
KEYIDは解釈の創始者の連結と、応答者クッキーとドメインです。 それは合わせることの材料の名前です。
sKEYID is used to denote the keying material named by the KEYID. It is never transmitted, but it is used in various calculations performed by the two parties.
sKEYIDは、材料がKEYIDで命名した合わせることを指示するのに使用されます。 決して伝えられませんが、それは2回のパーティーによって実行された様々な計算に使用されます。
OK_KEYX and OK_NEWGRP are distinct message types.
OK_KEYXとOK_NEWGRPは異なったメッセージタイプです。
IDP is a bit indicating whether or not material after the encryption boundary (see appendix B), is encrypted. NIDP means not encrypted.
IDPは、暗号化境界(付録Bを見る)の後の材料が暗号化されているかどうかを少し示しています。 NIDPは、暗号化されていないことを意味します。
g^x and g^y are encodings of group elements, where g is a special group element indicated in the group description (see Appendix A) and g^x indicates that element raised to the x'th power. The type of the encoding is either a variable precision integer or a pair of such
g^xとg^yはグループ要素のencodingsです、そして、g^xはx'thパワーに上げられたその要素を示します。(そこでは、gがグループ記述で示された特別なグループ要素(Appendix Aを見る)です)。 コード化のタイプは可変精度整数か1組のどちらかのそのようなものです。
Orman Informational [Page 5] RFC 2412 The OAKLEY Key Determination Protocol November 1998
決断プロトコル1998年11月に主要なOrmanの情報[5ページ]のRFC2412のオークリー
integers, as indicated in the group operation in the group description. Note that we will write g^xy as a short-hand for g^(xy). See Appendix F for references that describe implementing large integer computations and the relationship between various group definitions and basic arithmetic operations.
グループ記述におけるグループ操作にみられるように整数。 私たちがg^(xy)のための速記としてg^xyに書くつもりであることに注意してください。 大きい整数計算を実装すると説明する参照と様々なグループ定義と基本的な四則演算との関係に関してAppendix Fを見てください。
EHAO is a list of encryption/hash/authentication choices. Each item is a pair of values: a class name and an algorithm name.
EHAOは暗号化/ハッシュ/認証選択のリストです。 各個条は1組の値です: クラス名とアルゴリズム名。
EHAS is a set of three items selected from the EHAO list, one from each of the classes for encryption, hash, authentication.
EHASはEHAOリストから選択された項目(暗号化のためのそれぞれのクラスからの1)が論じ尽くす3人のセットです、認証。
GRP is a name (32-bit value) for the group and its relevant parameters: the size of the integers, the arithmetic operation, and the generator element. There are a few pre-defined GRP's (for 768 bit modular exponentiation groups, 1024 bit modexp, 2048 bit modexp, 155-bit and 210-bit elliptic curves, see Appendix E), but participants can share other group descriptions in a later protocol stage (see the section NEW GROUP). It is important to separate notion of the GRP from the group descriptor (Appendix A); the former is a name for the latter.
GRPはグループとその関連パラメタのための名前(32ビットの値)です: 整数、四則演算、およびジェネレータ要素のサイズ。 事前に定義されたGRPのいくつかのものがありますが(768ビットのモジュールの羃法グループ、1024年のビットのmodexpに関して、2048年のビットのmodexp、155ビットの、そして、210ビットの楕円曲線はAppendix Eを見ます)、関係者は後のプロトコルステージに他のグループ記述を分担できます(セクションNEW GROUPを見てください)。 グループ記述子(付録A)とGRPの概念を切り離すのは重要です。 前者は後者のための名前です。
The symbol vertical bar "|" is used to denote concatenation of bit strings. Fields are concatenated using their encoded form as they appear in their payload.
「シンボル縦棒」|「ビット列の連結を指示するために、使用されます。」 分野は、自己のペイロードに現れるようにそれらのコード化されたフォームを使用することで連結されます。
Ni and Nr are nonces selected by the initiator and responder, respectively.
NiとNrは創始者と応答者によってそれぞれ選択された一回だけです。
ID(I) and ID(R) are the identities to be used in authenticating the initiator and responder respectively.
ID(I)とID(R)はそれぞれ創始者と応答者を認証する際に使用されるべきアイデンティティです。
E{x}Ki indicates the encryption of x using the public key of the
initiator. Encryption is done using the algorithm associated with
the authentication method; usually this will be RSA.
E x、気は、創始者の公開鍵を使用することでxの暗号化を示します。 暗号化は認証方法に関連しているアルゴリズムを使用し終わっています。 通常、これはRSAになるでしょう。
S{x}Ki indicates the signature over x using the private key (signing
key) of the initiator. Signing is done using the algorithm
associated with the authentication method; usually this will be RSA
or DSS.
S x、気は、創始者の秘密鍵(署名キー)を使用することでxの上の署名を示します。 署名は認証方法に関連しているアルゴリズムを使用し終わっています。 通常、これは、RSAかDSSになるでしょう。
prf(a, b) denotes the result of applying pseudo-random function "a" to data "b". One may think of "a" as a key or as a value that characterizes the function prf; in the latter case it is the index into a family of functions. Each function in the family provides a "hash" or one-way mixing of the input.
prf(a、b)はデータ「b」に擬似ランダム機能“a"を適用するという結果を指示します。 キーとして、または、機能prfを特徴付ける値として“a"を考えるかもしれません。 後者の場合では、それは関数族へのインデックスです。 ファミリーにおける各機能は入力の「ハッシュ」か一方向混合を提供します。
prf(0, b) denotes the application of a one-way function to data "b".
prf(0、b)はデータ「b」に一方向関数のアプリケーションを指示します。
Orman Informational [Page 6] RFC 2412 The OAKLEY Key Determination Protocol November 1998
決断プロトコル1998年11月に主要なOrmanの情報[6ページ]のRFC2412のオークリー
The similarity with the previous notation is deliberate and indicates that a single algorithm, e.g. MD5, might will used for both purposes. In the first case a "keyed" MD5 transform would be used with key "a"; in the second case the transform would have the fixed key value zero, resulting in a one-way function.
前の記法がある類似性は、慎重であり、そのaただ一つのアルゴリズム、例えばMD5(意志が両方の目的に使用した力)を示します。 前者の場合「合わせられた」MD5変換は主要な“a"と共に使用されるでしょう。 2番目の場合では、変換で、一方向関数をもたらして、固定キーはゼロを評価するでしょう。
The term "transform" is used to refer to functions defined in auxiliary RFC's. The transform RFC's will be drawn from those defined for IPSEC AH and ESP (see RFC 2401 for the overall architecture encompassing these protocols).
「変形」という用語は、補助のRFCのもので定義された機能について言及するのに使用されます。 IPSEC AHと超能力のために定義されたものから変換RFCのものを得るでしょう(これらのプロトコルを包含する総合的なアーキテクチャに関してRFC2401を見てください)。
2.3 The Key Exchange Message Overview
2.3 主要な交換メッセージ概要
The goal of key exchange processing is the secure establishment of common keying information state in the two parties. This state information is a key name, secret keying material, the identification of the two parties, and three algorithms for use during authentication: encryption (for privacy of the identities of the two parties), hashing (a pseudorandom function for protecting the integrity of the messages and for authenticating message fields), and authentication (the algorithm on which the mutual authentication of the two parties is based). The encodings and meanings for these choices are presented in Appendix B.
主要な交換処理の目標は2つの党で情報状態を合わせる一般的の安全な設立です。 この州の情報は、主要な名前と、材料を合わせる秘密と、2回のパーティーの識別と、認証の間の使用のための3つのアルゴリズムです: 暗号化(2回のパーティーのアイデンティティのプライバシーのための)、(メッセージの保全を保護して、メッセージ分野を認証するための擬似ランダム機能)を論じ尽くして、および認証(2回のパーティーの互いの認証が基づいているアルゴリズム)。 これらの選択のためのencodingsと意味はAppendix Bに提示されます。
The main mode exchange has five optional features: stateless cookie exchange, perfect forward secrecy for the keying material, secrecy for the identities, perfect forward secrecy for identity secrecy, use of signatures (for non-repudiation). The two parties can use any combination of these features.
主なモード交換には、5つのオプション機能があります: 状態がないクッキー交換(合わせることの材料のための秘密保持、アイデンティティのための秘密保持、アイデンティティ秘密保持のための完全な前進の秘密保持が使用する署名(非拒否のための)の完全なフォワード)。 2回のパーティーがこれらの特徴のどんな組み合わせも使用できます。
The general outline of processing is that the Initiator of the exchange begins by specifying as much information as he wishes in his first message. The Responder replies, supplying as much information as he wishes. The two sides exchange messages, supplying more information each time, until their requirements are satisfied.
処理に関する概要は交換のInitiatorが彼が最初のメッセージで願っているように同じくらい多くの情報を指定することによって始まるということです。 彼が願っているように同じくらい多くの情報を提供して、Responderは返答します。 それらの要件が満たされるまでその都度詳しい情報を提供して、2つの側がメッセージを交換します。
The choice of how much information to include in each message depends on which options are desirable. For example, if stateless cookies are not a requirement, and identity secrecy and perfect forward secrecy for the keying material are not requirements, and if non- repudiatable signatures are acceptable, then the exchange can be completed in three messages.
この選択は各メッセージにどのくらいの情報を含んでいるかをどのオプションが望ましいか次第です。 例えば、状態がないクッキーが要件と、またはアイデンティティ秘密保持でないか、そして、合わせることの材料のための完全な前進の秘密保持は要件ではありません、そして、非否認可能な署名が許容できるなら、交換は3つのメッセージで終了できます。
Additional features may increase the number of roundtrips needed for the keying material determination.
付加的な機能は合わせることの物質的な決断に必要である往復旅行の数を増強するかもしれません。
ISAKMP provides fields for specifying the security association parameters for use with the AH and ESP protocols. These security
ISAKMPはAHと超能力プロトコルで使用のためのセキュリティ協会パラメタを指定するのに野原を供給します。 これらのセキュリティ
Orman Informational [Page 7] RFC 2412 The OAKLEY Key Determination Protocol November 1998
決断プロトコル1998年11月に主要なOrmanの情報[7ページ]のRFC2412のオークリー
association payload types are specified in the ISAKMP memo; the payload types can be protected with OAKLEY keying material and algorithms, but this document does not discuss their use.
協会ペイロードタイプはISAKMPメモで指定されます。 オークリーが材料とアルゴリズムを合わせていて、ペイロードタイプを保護できますが、このドキュメントは彼らの使用について議論しません。
2.3.1 The Essential Key Exchange Message Fields
2.3.1 不可欠の主要な交換メッセージ分野
There are 12 fields in an OAKLEY key exchange message. Not all the fields are relevant in every message; if a field is not relevant it can have a null value or not be present (no payload).
オークリーの主要な交換メッセージには12の分野があります。 すべての分野がどんなあらゆるメッセージで関連しているというわけではありません。 分野が関連していないなら、ヌル値を持っているか、または存在しているはずがありません(ペイロードがありません)。
CKY-I originator cookie.
CKY-R responder cookie.
MSGTYPE for key exchange, will be ISA_KE&AUTH_REQ or
ISA_KE&AUTH_REP; for new group definitions,
will be ISA_NEW_GROUP_REQ or ISA_NEW_GROUP_REP
GRP the name of the Diffie-Hellman group used for
the exchange
g^x (or g^y) variable length integer representing a power of
group generator
EHAO or EHAS encryption, hash, authentication functions,
offered and selectedj, respectively
IDP an indicator as to whether or not encryption with
g^xy follows (perfect forward secrecy for ID's)
ID(I) the identity for the Initiator
ID(R) the identity for the Responder
Ni nonce supplied by the Initiator
Nr nonce supplied by the Responder
CKY-I創始者クッキー。 CKY-R応答者クッキー。 主要な交換のためのMSGTYPEはISA_KE&AUTH_になREQかISA_KEとAUTH_REPるでしょう。 新しいグループ定義のための、ISA_NEW_GROUP_REQであるかISA_NEW_GROUP_REP GRPはグループジェネレータEHAOかEHAS暗号化のパワーを表す交換g^x(または、g^y)可変長整数に使用されるディフィー-ヘルマングループの名前をREQです、ハッシュ、認証機能; 提供、selectedjと、それぞれIDPは(I) Responder Ni一回だけのためのアイデンティティがInitiator Nr一回だけから供給したInitiator ID(R)へのアイデンティティがResponderを供給したというg^xyとの暗号化がIDに続くかどうかに関する(IDのものへの完全な前進の秘密保持)インディケータをそうします。
The construction of the cookies is implementation dependent. Phil Karn has recommended making them the result of a one-way function applied to a secret value (changed periodically), the local and remote IP address, and the local and remote UDP port. In this way, the cookies remain stateless and expire periodically. Note that with OAKLEY, this would cause the KEYID's derived from the secret value to also expire, necessitating the removal of any state information associated with it.
クッキーの構造は実装に依存しています。 フィルKarnは、それらを秘密の値(定期的に変える)、地方の、そして、リモートなIPアドレス、および地方の、そして、遠く離れたUDPポートに適用された一方向関数の結果にすることを勧めました。 このように、クッキーは、状態がないままで残っていて、定期的に期限が切れます。 オークリーで、これがまた、吐き出す秘密の値から派生していた状態でKEYIDのものを引き起こすことに注意してください、それに関連しているどんな州の情報の取り外しも必要として。
In order to support pre-distributed keys, we recommend that implementations reserve some portion of their cookie space to permanent keys. The encoding of these depends only on the local implementation.
あらかじめ分配されたキーを支えるために、私たちは、実装がそれらのクッキースペースの何らかの部分を永久的なキーに予約することを勧めます。 これらのコード化は地方の実装だけによります。
The encryption functions used with OAKLEY must be cryptographic transforms which guarantee privacy and integrity for the message data. Merely using DES in CBC mode is not permissible. The MANDATORY and OPTIONAL transforms will include any that satisfy this criteria and are defined for use with RFC 2406 (ESP).
オークリーと共に使用される暗号化機能はメッセージデータのためにプライバシーと保全を保証する暗号の変換であるに違いありません。 CBCモードでDESを単に使用するのは許されていません。 MANDATORYとOPTIONAL変換は、この評価基準を満たすいずれも含んで、RFC2406(超能力)との使用のために定義されます。
Orman Informational [Page 8] RFC 2412 The OAKLEY Key Determination Protocol November 1998
決断プロトコル1998年11月に主要なOrmanの情報[8ページ]のRFC2412のオークリー
The one-way (hash) functions used with OAKLEY must be cryptographic transforms which can be used as either keyed hash (pseudo-random) or non-keyed transforms. The MANDATORY and OPTIONAL transforms will include any that are defined for use with RFC 2406 (AH).
オークリーと共に使用される一方向(ハッシュ)機能はどちらかがハッシュ(擬似ランダム)か非合わせられた変換を合わせたので使用できる暗号の変換であるに違いありません。MANDATORYとOPTIONAL変換はRFC2406(AH)との使用のために定義されるいずれも含むでしょう。
Where nonces are indicated, they will be variable precision integers with an entropy value that matches the "strength" attribute of the GRP used with the exchange. If no GRP is indicated, the nonces must be at least 90 bits long. The pseudo-random generator for the nonce material should start with initial data that has at least 90 bits of entropy; see RFC 1750.
一回だけが示されるところでは、交換と共に使用されるGRPの「強さ」属性に合っているエントロピー値に応じて、それらは可変精度整数になるでしょう。 GRPが全く示されないなら、一回だけは長さ少なくとも90ビットでなければなりません。 一回だけの材料のための擬似ランダムジェネレータはエントロピーの少なくとも90ビットを持っている初期のデータから始まるはずです。 RFC1750を見てください。
2.3.1.1 Exponent Advice
2.3.1.1 解説者アドバイス
Ideally, the exponents will have at least 180 bits of entropy for every key exchange. This ensures complete independence of keying material between two exchanges (note that this applies if only one of the parties chooses a random exponent). In practice, implementors may wish to base several key exchanges on a single base value with 180 bits of entropy and use one-way hash functions to guarantee that exposure of one key will not compromise others. In this case, a good recommendation is to keep the base values for nonces and cookies separate from the base value for exponents, and to replace the base value with a full 180 bits of entropy as frequently as possible.
理想的に、解説者には、あらゆる主要な交換のためのエントロピーの少なくとも180ビットがあるでしょう。 これは合わせることの材料からの2回の交換(パーティーの唯一のひとりが無作為の解説者を選ぶならこれが適用されることに注意する)の間の完全な独立を確実にします。 実際には、作成者は、数回の主要な交換をエントロピーの180ビットがある単独ベース値に基礎づけて、1個のキーの展示が他のものに感染しないのを保証するのに一方向ハッシュ関数を使用したがっているかもしれません。 この場合、良い推薦は、解説者に、基礎点から別々の一回だけとクッキーのために基礎点を保って、できるだけ頻繁に基礎点をエントロピーの完全な180ビットに取り替えることです。
The values 0 and p-1 should not be used as exponent values; implementors should be sure to check for these values, and they should also refuse to accept the values 1 and p-1 from remote parties (where p is the prime used to define a modular exponentiation group).
解説者値として値の0とp-1を使用するべきではありません。 作成者は確実にこれらの値がないかどうかチェックするべきです、そして、また、それらはリモートパーティー(pがモジュールの羃法グループを定義するために費やされた第1であるところ)から値の1とp-1を受け入れるのを拒否するべきです。
2.3.2 Mapping to ISAKMP Message Structures
2.3.2 ISAKMPメッセージに構造を写像すること。
All the OAKLEY message fields correspond to ISAKMP message payloads or payload components. The relevant payload fields are the SA payload, the AUTH payload, the Certificate Payload, the Key Exchange Payload. The ISAKMP protocol framwork is a work in progress at this time, and the exact mapping of Oakley message fields to ISAKMP payloads is also in progress (to be known as the Resolution document).
すべてのオークリーメッセージ分野がISAKMPメッセージペイロードかペイロード成分に対応しています。 関連ペイロード分野はSAペイロード、AUTHペイロード、Certificate有効搭載量、Key Exchange有効搭載量です。 このときISAKMPプロトコルframworkは処理中の作業です、そして、また、ISAKMPペイロードへのオークリーメッセージ分野の正確なマッピングは進行しています(Resolutionドキュメントとして知られている)。
Some of the ISAKMP header and payload fields will have constant values when used with OAKLEY. The exact values to be used will be published in a Domain of Interpretation document accompanying the Resolution document.
ISAKMPヘッダーとペイロード分野のいくつかには、オークリーと共に使用されると、恒常価値があるでしょう。 使用されるべき正確な値はResolutionが記録するInterpretationドキュメント伴走のDomainで発行されるでしょう。
In the following we indicate where each OAKLEY field appears in the ISAKMP message structure. These are recommended only; the Resolution document will be the final authority on this mapping.
以下では、私たちは、それぞれのオークリー野原がISAKMPメッセージ構造でどこに見えるかを示します。 これらがお勧めである、単に。 Resolutionドキュメントはこのマッピングで最終的な権威になるでしょう。
Orman Informational [Page 9] RFC 2412 The OAKLEY Key Determination Protocol November 1998
決断プロトコル1998年11月に主要なOrmanの情報[9ページ]のRFC2412のオークリー
CKY-I ISAKMP header
CKY-R ISAKMP header
MSGTYPE Message Type in ISAKMP header
GRP SA payload, Proposal section
g^x (or g^y) Key Exchange Payload, encoded as a variable
precision integer
EHAO and EHAS SA payload, Proposal section
IDP A bit in the RESERVED field in the AUTH header
ID(I) AUTH payload, Identity field
ID(R) AUTH payload, Identity field
Ni AUTH payload, Nonce Field
Nr AUTH payload, Nonce Field
S{...}Kx AUTH payload, Data Field
prf{K,...} AUTH payload, Data Field
ISAKMPヘッダーGRP SAペイロードのCKY-I ISAKMPヘッダーCKY-R ISAKMPヘッダーMSGTYPE Message Type(Proposal部g^x(または、g^y)の主要なExchange有効搭載量)が可変精度整数としてEHAOをコード化して、EHAS SAペイロード、RESERVEDで噛み付かれたProposalセクションIDP AがAUTHヘッダーID(I)AUTHペイロード、Identity分野ID(R)AUTHペイロード、Identity分野Ni AUTHペイロード、Nonce Field Nr AUTHペイロード、Nonce Field Sで…Kx AUTHをさばく、ペイロード、Data Field prf、K… AUTHペイロード、Data Field
2.4 The Key Exchange Protocol
2.4 主要な交換プロトコル
The exact number and content of messages exchanged during an OAKLEY key exchange depends on which options the Initiator and Responder want to use. A key exchange can be completed with three or more messages, depending on those options.
オークリーの主要な交換の間に交換されたメッセージのはっきりした数と内容はInitiatorとResponderがどのオプションを使用したがっているかに依存します。 それらのオプションによって、主要な交換は3つ以上のメッセージで終了できます。
The three components of the key determination protocol are the
主要な決断プロトコルの3つの成分がそうです。
1. cookie exchange (optionally stateless)
2. Diffie-Hellman half-key exchange (optional, but essential for
perfect forward secrecy)
3. authentication (options: privacy for ID's, privacy for ID's
with PFS, non-repudiatable)
1. クッキー交換(任意に状態がない)2。 ディフィー-ヘルマンの半分主要な交換(任意の、しかし、完全な前進の秘密保持に、不可欠の)3認証(オプション: IDのものへのプライバシー、PFSがあるIDのものへのプライバシー、非否認可能)
The initiator can supply as little information as a bare exchange request, carrying no additional information. On the other hand the initiator can begin by supplying all of the information necessary for the responder to authenticate the request and complete the key determination quickly, if the responder chooses to accept this method. If not, the responder can reply with a minimal amount of information (at the minimum, a cookie).
追加情報を全く運ばないで、創始者はむき出しの交換要求でほとんど情報を提供できません。 他方では、創始者は、応答者が、要求を認証して、必要情報のすべてを供給することによって、すぐに主要な決断を終了し始めることができます、応答者が、このメソッドを受け入れるのを選ぶなら。 そうでなければ、最小量の情報量(最小限におけるクッキー)で応答者は返答できます。
The method of authentication can be digital signatures, public key encryption, or an out-of-band symmetric key. The three different methods lead to slight variations in the messages, and the variations are illustrated by examples in this section.
The method of authentication can be digital signatures, public key encryption, or an out-of-band symmetric key. The three different methods lead to slight variations in the messages, and the variations are illustrated by examples in this section.
The Initiator is responsible for retransmitting messages if the protocol does not terminate in a timely fashion. The Responder must therefore avoid discarding reply information until it is acknowledged by Initiator in the course of continuing the protocol.
The Initiator is responsible for retransmitting messages if the protocol does not terminate in a timely fashion. The Responder must therefore avoid discarding reply information until it is acknowledged by Initiator in the course of continuing the protocol.
Orman Informational [Page 10] RFC 2412 The OAKLEY Key Determination Protocol November 1998
Orman Informational [Page 10] RFC 2412 The OAKLEY Key Determination Protocol November 1998
The remainder of this section contains examples demonstrating how to use OAKLEY options.
The remainder of this section contains examples demonstrating how to use OAKLEY options.
2.4.1 An Aggressive Example
2.4.1 An Aggressive Example
The following example indicates how two parties can complete a key exchange in three messages. The identities are not secret, the derived keying material is protected by PFS.
The following example indicates how two parties can complete a key exchange in three messages. The identities are not secret, the derived keying material is protected by PFS.
By using digital signatures, the two parties will have a proof of communication that can be recorded and presented later to a third party.
By using digital signatures, the two parties will have a proof of communication that can be recorded and presented later to a third party.
The keying material implied by the group exponentials is not needed for completing the exchange. If it is desirable to defer the computation, the implementation can save the "x" and "g^y" values and mark the keying material as "uncomputed". It can be computed from this information later.
The keying material implied by the group exponentials is not needed for completing the exchange. If it is desirable to defer the computation, the implementation can save the "x" and "g^y" values and mark the keying material as "uncomputed". It can be computed from this information later.
Initiator Responder
--------- ---------
-> CKY-I, 0, OK_KEYX, GRP, g^x, EHAO, NIDP, ->
ID(I), ID(R), Ni, 0,
S{ID(I) | ID(R) | Ni | 0 | GRP | g^x | 0 | EHAO}Ki
<- CKY-R, CKY-I, OK_KEYX, GRP, g^y, EHAS, NIDP,
ID(R), ID(I), Nr, Ni,
S{ID(R) | ID(I) | Nr | Ni | GRP | g^y | g^x | EHAS}Kr <-
-> CKY-I, CKY-R, OK_KEYX, GRP, g^x, EHAS, NIDP, ->
ID(I), ID(R), Ni, Nr,
S{ID(I) | ID(R) | Ni | Nr | GRP | g^x | g^y | EHAS}Ki
Initiator Responder --------- --------- -> CKY-I, 0, OK_KEYX, GRP, g^x, EHAO, NIDP, -> ID(I), ID(R), Ni, 0, S{ID(I) | ID(R) | Ni | 0 | GRP | g^x | 0 | EHAO}Ki <- CKY-R, CKY-I, OK_KEYX, GRP, g^y, EHAS, NIDP, ID(R), ID(I), Nr, Ni, S{ID(R) | ID(I) | Nr | Ni | GRP | g^y | g^x | EHAS}Kr <- -> CKY-I, CKY-R, OK_KEYX, GRP, g^x, EHAS, NIDP, -> ID(I), ID(R), Ni, Nr, S{ID(I) | ID(R) | Ni | Nr | GRP | g^x | g^y | EHAS}Ki
NB "NIDP" means that the PFS option for hiding identities is not used.
i.e., the identities are not encrypted using a key based on g^xy
NB "NIDP" means that the PFS option for hiding identities is not used. i.e., the identities are not encrypted using a key based on g^xy
NB Fields are shown separated by commas in this document; they are concatenated in the actual protocol messages using their encoded forms as specified in the ISAKMP/Oakley Resolution document.
NB Fields are shown separated by commas in this document; they are concatenated in the actual protocol messages using their encoded forms as specified in the ISAKMP/Oakley Resolution document.
The result of this exchange is a key with KEYID = CKY-I|CKY-R and value
The result of this exchange is a key with KEYID = CKY-I|CKY-R and value
sKEYID = prf(Ni | Nr, g^xy | CKY-I | CKY-R).
sKEYID = prf(Ni | Nr, g^xy | CKY-I | CKY-R).
The processing outline for this exchange is as follows:
The processing outline for this exchange is as follows:
Orman Informational [Page 11] RFC 2412 The OAKLEY Key Determination Protocol November 1998
Orman Informational [Page 11] RFC 2412 The OAKLEY Key Determination Protocol November 1998
Initiation
Initiation
The Initiator generates a unique cookie and associates it with the
expected IP address of the responder, and its chosen state
information: GRP (the group identifier), a pseudo-randomly
selected exponent x, g^x, EHAO list, nonce, identities. The first
authentication choice in the EHAO list is an algorithm that
supports digital signatures, and this is used to sign the ID's and
the nonce and group id. The Initiator further
The Initiator generates a unique cookie and associates it with the expected IP address of the responder, and its chosen state information: GRP (the group identifier), a pseudo-randomly selected exponent x, g^x, EHAO list, nonce, identities. The first authentication choice in the EHAO list is an algorithm that supports digital signatures, and this is used to sign the ID's and the nonce and group id. The Initiator further
notes that the key is in the initial state of "unauthenticated",
and
notes that the key is in the initial state of "unauthenticated", and
sets a timer for possible retransmission and/or termination of the
request.
sets a timer for possible retransmission and/or termination of the request.
When the Responder receives the message, he may choose to ignore all the information and treat it as merely a request for a cookie, creating no state. If CKY-I is not already in use by the source address in the IP header, the responder generates a unique cookie, CKY-R. The next steps depend on the Responder's preferences. The minimal required response is to reply with the first cookie field set to zero and CKY-R in the second field. For this example we will assume that the responder is more aggressive (for the alternatives, see section 6) and accepts the following:
When the Responder receives the message, he may choose to ignore all the information and treat it as merely a request for a cookie, creating no state. If CKY-I is not already in use by the source address in the IP header, the responder generates a unique cookie, CKY-R. The next steps depend on the Responder's preferences. The minimal required response is to reply with the first cookie field set to zero and CKY-R in the second field. For this example we will assume that the responder is more aggressive (for the alternatives, see section 6) and accepts the following:
group with identifier GRP,
first authentication choice (which must be the digital signature
method used to sign the Initiator message),
lack of perfect forward secrecy for protecting the identities,
identity ID(I) and identity ID(R)
group with identifier GRP, first authentication choice (which must be the digital signature method used to sign the Initiator message), lack of perfect forward secrecy for protecting the identities, identity ID(I) and identity ID(R)
In this example the Responder decides to accept all the information offered by the initiator. It validates the signature over the signed portion of the message, and associate the pair (CKY-I, CKY-R) with the following state information:
In this example the Responder decides to accept all the information offered by the initiator. It validates the signature over the signed portion of the message, and associate the pair (CKY-I, CKY-R) with the following state information:
the source and destination network addresses of the message
the source and destination network addresses of the message
key state of "unauthenticated"
key state of "unauthenticated"
the first algorithm from the authentication offer
the first algorithm from the authentication offer
group GRP, a "y" exponent value in group GRP, and g^x from the
message
group GRP, a "y" exponent value in group GRP, and g^x from the message
the nonce Ni and a pseudorandomly selected value Nr
the nonce Ni and a pseudorandomly selected value Nr
Orman Informational [Page 12] RFC 2412 The OAKLEY Key Determination Protocol November 1998
Orman Informational [Page 12] RFC 2412 The OAKLEY Key Determination Protocol November 1998
a timer for possible destruction of the state.
a timer for possible destruction of the state.
The Responder computes g^y, forms the reply message, and then signs the ID and nonce information with the private key of ID(R) and sends it to the Initiator. In all exchanges, each party should make sure that he neither offers nor accepts 1 or g^(p-1) as an exponential.
The Responder computes g^y, forms the reply message, and then signs the ID and nonce information with the private key of ID(R) and sends it to the Initiator. In all exchanges, each party should make sure that he neither offers nor accepts 1 or g^(p-1) as an exponential.
In this example, to expedite the protocol, the Responder implicitly accepts the first algorithm in the Authentication class of the EHAO list. This because he cannot validate the Initiator signature without accepting the algorithm for doing the signature. The Responder's EHAS list will also reflect his acceptance.
In this example, to expedite the protocol, the Responder implicitly accepts the first algorithm in the Authentication class of the EHAO list. This because he cannot validate the Initiator signature without accepting the algorithm for doing the signature. The Responder's EHAS list will also reflect his acceptance.
The Initiator receives the reply message and
validates that CKY-I is a valid association for the network
address of the incoming message,
The Initiator receives the reply message and validates that CKY-I is a valid association for the network address of the incoming message,
adds the CKY-R value to the state for the pair (CKY-I, network
address), and associates all state information with the pair
(CKY-I, CKY-R),
adds the CKY-R value to the state for the pair (CKY-I, network address), and associates all state information with the pair (CKY-I, CKY-R),
validates the signature of the responder over the state
information (should validation fail, the message is discarded)
validates the signature of the responder over the state information (should validation fail, the message is discarded)
adds g^y to its state information,
adds g^y to its state information,
saves the EHA selections in the state,
saves the EHA selections in the state,
optionally computes (g^y)^x (= g^xy) (this can be deferred until
after sending the reply message),
optionally computes (g^y)^x (= g^xy) (this can be deferred until after sending the reply message),
sends the reply message, signed with the public key of ID(I),
sends the reply message, signed with the public key of ID(I),
marks the KEYID (CKY-I|CKY-R) as authenticated,
marks the KEYID (CKY-I|CKY-R) as authenticated,
and composes the reply message and signature.
and composes the reply message and signature.
When the Responder receives the Initiator message, and if the signature is valid, it marks the key as being in the authenticated state. It should compute g^xy and associate it with the KEYID.
When the Responder receives the Initiator message, and if the signature is valid, it marks the key as being in the authenticated state. It should compute g^xy and associate it with the KEYID.
Note that although PFS for identity protection is not used, PFS for the derived keying material is still present because the Diffie- Hellman half-keys g^x and g^y are exchanged.
Note that although PFS for identity protection is not used, PFS for the derived keying material is still present because the Diffie- Hellman half-keys g^x and g^y are exchanged.
Even if the Responder only accepts some of the Initiator information, the Initiator will consider the protocol to be progressing. The Initiator should assume that fields that were not accepted by the
Even if the Responder only accepts some of the Initiator information, the Initiator will consider the protocol to be progressing. The Initiator should assume that fields that were not accepted by the
Orman Informational [Page 13] RFC 2412 The OAKLEY Key Determination Protocol November 1998
Orman Informational [Page 13] RFC 2412 The OAKLEY Key Determination Protocol November 1998
Responder were not recorded by the Responder.
Responder were not recorded by the Responder.
If the Responder does not accept the aggressive exchange and selects another algorithm for the A function, then the protocol will not continue using the signature algorithm or the signature value from the first message.
If the Responder does not accept the aggressive exchange and selects another algorithm for the A function, then the protocol will not continue using the signature algorithm or the signature value from the first message.
2.4.1.1 Fields Not Present
2.4.1.1 Fields Not Present
If the Responder does not accept all the fields offered by the Initiator, he should include null values for those fields in his response. Section 6 has guidelines on how to select fields in a "left-to-right" manner. If a field is not accepted, then it and all following fields must have null values.
If the Responder does not accept all the fields offered by the Initiator, he should include null values for those fields in his response. Section 6 has guidelines on how to select fields in a "left-to-right" manner. If a field is not accepted, then it and all following fields must have null values.
The Responder should not record any information that it does not accept. If the ID's and nonces have null values, there will not be a signature over these null values.
The Responder should not record any information that it does not accept. If the ID's and nonces have null values, there will not be a signature over these null values.
2.4.1.2 Signature via Pseudo-Random Functions
2.4.1.2 Signature via Pseudo-Random Functions
The aggressive example is written to suggest that public key technology is used for the signatures. However, a pseudorandom function can be used, if the parties have previously agreed to such a scheme and have a shared key.
The aggressive example is written to suggest that public key technology is used for the signatures. However, a pseudorandom function can be used, if the parties have previously agreed to such a scheme and have a shared key.
If the first proposal in the EHAO list is an "existing key" method, then the KEYID named in that proposal will supply the keying material for the "signature" which is computed using the "H" algorithm associated with the KEYID.
If the first proposal in the EHAO list is an "existing key" method, then the KEYID named in that proposal will supply the keying material for the "signature" which is computed using the "H" algorithm associated with the KEYID.
Suppose the first proposal in EHAO is
EXISTING-KEY, 32
and the "H" algorithm for KEYID 32 is MD5-HMAC, by prior negotiation.
The keying material is some string of bits, call it sK32. Then in
the first message in the aggressive exchange, where the signature
Suppose the first proposal in EHAO is EXISTING-KEY, 32 and the "H" algorithm for KEYID 32 is MD5-HMAC, by prior negotiation. The keying material is some string of bits, call it sK32. Then in the first message in the aggressive exchange, where the signature
S{ID(I), ID(R), Ni, 0, GRP, g^x, EHAO}Ki
S{ID(I), ID(R), Ni, 0, GRP, g^x, EHAO}Ki
is indicated, the signature computation would be performed by
MD5-HMAC_func(KEY=sK32, DATA = ID(I) | ID(R) | Ni | 0 | GRP | g^x
| g^y | EHAO) (The exact definition of the algorithm corresponding
to "MD5-HMAC- func" will appear in the RFC defining that transform).
is indicated, the signature computation would be performed by MD5-HMAC_func(KEY=sK32, DATA = ID(I) | ID(R) | Ni | 0 | GRP | g^x | g^y | EHAO) (The exact definition of the algorithm corresponding to "MD5-HMAC- func" will appear in the RFC defining that transform).
The result of this computation appears in the Authentication payload.
The result of this computation appears in the Authentication payload.
Orman Informational [Page 14] RFC 2412 The OAKLEY Key Determination Protocol November 1998
Orman Informational [Page 14] RFC 2412 The OAKLEY Key Determination Protocol November 1998
2.4.2 An Aggressive Example With Hidden Identities
2.4.2 An Aggressive Example With Hidden Identities
The following example indicates how two parties can complete a key exchange without using digital signatures. Public key cryptography hides the identities during authentication. The group exponentials are exchanged and authenticated, but the implied keying material (g^xy) is not needed during the exchange.
The following example indicates how two parties can complete a key exchange without using digital signatures. Public key cryptography hides the identities during authentication. The group exponentials are exchanged and authenticated, but the implied keying material (g^xy) is not needed during the exchange.
This exchange has an important difference from the previous signature scheme --- in the first message, an identity for the responder is indicated as cleartext: ID(R'). However, the identity hidden with the public key cryptography is different: ID(R). This happens because the Initiator must somehow tell the Responder which public/private key pair to use for the decryption, but at the same time, the identity is hidden by encryption with that public key.
This exchange has an important difference from the previous signature scheme --- in the first message, an identity for the responder is indicated as cleartext: ID(R'). However, the identity hidden with the public key cryptography is different: ID(R). This happens because the Initiator must somehow tell the Responder which public/private key pair to use for the decryption, but at the same time, the identity is hidden by encryption with that public key.
The Initiator might elect to forgo secrecy of the Responder identity, but this is undesirable. Instead, if there is a well-known identity for the Responder node, the public key for that identity can be used to encrypt the actual Responder identity.
The Initiator might elect to forgo secrecy of the Responder identity, but this is undesirable. Instead, if there is a well-known identity for the Responder node, the public key for that identity can be used to encrypt the actual Responder identity.
Initiator Responder
--------- ---------
-> CKY-I, 0, OK_KEYX, GRP, g^x, EHAO, NIDP, ->
ID(R'), E{ID(I), ID(R), E{Ni}Kr}Kr'
<- CKY-R, CKY-I, OK_KEYX, GRP, g^y, EHAS, NIDP,
E{ID(R), ID(I), Nr}Ki,
prf(Kir, ID(R) | ID(I) | GRP | g^y | g^x | EHAS) <-
-> CKY-I, CKY-R, OK_KEYX, GRP, 0, 0, NIDP,
prf(Kir, ID(I) | ID(R) | GRP | g^x | g^y | EHAS) ->
Initiator Responder --------- --------- -> CKY-I, 0, OK_KEYX, GRP, g^x, EHAO, NIDP, -> ID(R'), E{ID(I), ID(R), E{Ni}Kr}Kr' <- CKY-R, CKY-I, OK_KEYX, GRP, g^y, EHAS, NIDP, E{ID(R), ID(I), Nr}Ki, prf(Kir, ID(R) | ID(I) | GRP | g^y | g^x | EHAS) <- -> CKY-I, CKY-R, OK_KEYX, GRP, 0, 0, NIDP, prf(Kir, ID(I) | ID(R) | GRP | g^x | g^y | EHAS) ->
Kir = prf(0, Ni | Nr)
Kir = prf(0, Ni | Nr)
NB "NIDP" means that the PFS option for hiding identities is not used.
NB "NIDP" means that the PFS option for hiding identities is not used.
NB The ID(R') value is included in the Authentication payload as
described in Appendix B.
NB The ID(R') value is included in the Authentication payload as described in Appendix B.
The result of this exchange is a key with KEYID = CKY-I|CKY-R and value sKEYID = prf(Ni | Nr, g^xy | CKY-I | CKY-R).
The result of this exchange is a key with KEYID = CKY-I|CKY-R and value sKEYID = prf(Ni | Nr, g^xy | CKY-I | CKY-R).
The processing outline for this exchange is as follows:
The processing outline for this exchange is as follows:
Initiation
The Initiator generates a unique cookie and associates it with the
expected IP address of the responder, and its chosen state
information: GRP, g^x, EHAO list. The first authentication choice
in the EHAO list is an algorithm that supports public key
Initiation The Initiator generates a unique cookie and associates it with the expected IP address of the responder, and its chosen state information: GRP, g^x, EHAO list. The first authentication choice in the EHAO list is an algorithm that supports public key
Orman Informational [Page 15] RFC 2412 The OAKLEY Key Determination Protocol November 1998
Orman Informational [Page 15] RFC 2412 The OAKLEY Key Determination Protocol November 1998
encryption. The Initiator also names the two identities to be
used for the connection and enters these into the state. A well-
known identity for the responder machine is also chosen, and the
public key for this identity is used to encrypt the nonce Ni and
the two connection identities. The Initiator further
encryption. The Initiator also names the two identities to be used for the connection and enters these into the state. A well- known identity for the responder machine is also chosen, and the public key for this identity is used to encrypt the nonce Ni and the two connection identities. The Initiator further
notes that the key is in the initial state of "unauthenticated",
and
notes that the key is in the initial state of "unauthenticated", and
sets a timer for possible retransmission and/or termination of the
request.
sets a timer for possible retransmission and/or termination of the request.
When the Responder receives the message, he may choose to ignore all the information and treat it as merely a request for a cookie, creating no state.
When the Responder receives the message, he may choose to ignore all the information and treat it as merely a request for a cookie, creating no state.
If CKY-I is not already in use by the source address in the IP header, the Responder generates a unique cookie, CKY-R. As before, the next steps depend on the responder's preferences. The minimal required response is a message with the first cookie field set to zero and CKY-R in the second field. For this example we will assume that responder is more aggressive and accepts the following:
If CKY-I is not already in use by the source address in the IP header, the Responder generates a unique cookie, CKY-R. As before, the next steps depend on the responder's preferences. The minimal required response is a message with the first cookie field set to zero and CKY-R in the second field. For this example we will assume that responder is more aggressive and accepts the following:
group GRP, first authentication choice (which must be the public
key encryption algorithm used to encrypt the payload), lack of
perfect forward secrecy for protecting the identities, identity
ID(I), identity ID(R)
group GRP, first authentication choice (which must be the public key encryption algorithm used to encrypt the payload), lack of perfect forward secrecy for protecting the identities, identity ID(I), identity ID(R)
The Responder must decrypt the ID and nonce information, using the private key for the R' ID. After this, the private key for the R ID will be used to decrypt the nonce field.
The Responder must decrypt the ID and nonce information, using the private key for the R' ID. After this, the private key for the R ID will be used to decrypt the nonce field.
The Responder now associates the pair (CKY-I, CKY-R) with the following state information:
The Responder now associates the pair (CKY-I, CKY-R) with the following state information:
the source and destination network addresses of the message
the source and destination network addresses of the message
key state of "unauthenticated"
key state of "unauthenticated"
the first algorithm from each class in the EHAO (encryption-hash-
authentication algorithm offers) list
the first algorithm from each class in the EHAO (encryption-hash- authentication algorithm offers) list
group GRP and a y and g^y value in group GRP
group GRP and a y and g^y value in group GRP
the nonce Ni and a pseudorandomly selected value Nr
the nonce Ni and a pseudorandomly selected value Nr
a timer for possible destruction of the state.
a timer for possible destruction of the state.
Orman Informational [Page 16] RFC 2412 The OAKLEY Key Determination Protocol November 1998
Orman Informational [Page 16] RFC 2412 The OAKLEY Key Determination Protocol November 1998
The Responder then encrypts the state information with the public key of ID(I), forms the prf value, and sends it to the Initiator.
The Responder then encrypts the state information with the public key of ID(I), forms the prf value, and sends it to the Initiator.
The Initiator receives the reply message and
validates that CKY-I is a valid association for the network
address of the incoming message,
The Initiator receives the reply message and validates that CKY-I is a valid association for the network address of the incoming message,
adds the CKY-R value to the state for the pair (CKY-I, network
address), and associates all state information with the pair
(CKY-I, CKY-R),
adds the CKY-R value to the state for the pair (CKY-I, network address), and associates all state information with the pair (CKY-I, CKY-R),
decrypts the ID and nonce information
decrypts the ID and nonce information
checks the prf calculation (should this fail, the message is
discarded)
checks the prf calculation (should this fail, the message is discarded)
adds g^y to its state information,
adds g^y to its state information,
saves the EHA selections in the state,
saves the EHA selections in the state,
optionally computes (g^x)^y (= g^xy) (this may be deferred), and
optionally computes (g^x)^y (= g^xy) (this may be deferred), and
sends the reply message, encrypted with the public key of ID(R),
sends the reply message, encrypted with the public key of ID(R),
and marks the KEYID (CKY-I|CKY-R) as authenticated.
and marks the KEYID (CKY-I|CKY-R) as authenticated.
When the Responder receives this message, it marks the key as being in the authenticated state. If it has not already done so, it should compute g^xy and associate it with the KEYID.
When the Responder receives this message, it marks the key as being in the authenticated state. If it has not already done so, it should compute g^xy and associate it with the KEYID.
The secret keying material sKEYID = prf(Ni | Nr, g^xy | CKY-I | CKY-R)
The secret keying material sKEYID = prf(Ni | Nr, g^xy | CKY-I | CKY-R)
Note that although PFS for identity protection is not used, PFS for the derived keying material is still present because the Diffie- Hellman half-keys g^x and g^y are exchanged.
Note that although PFS for identity protection is not used, PFS for the derived keying material is still present because the Diffie- Hellman half-keys g^x and g^y are exchanged.
2.4.3 An Aggressive Example With Private Identities and Without Diffie-
Hellman
2.4.3 An Aggressive Example With Private Identities and Without Diffie- Hellman
Considerable computational expense can be avoided if perfect forward secrecy is not a requirement for the session key derivation. The two parties can exchange nonces and secret key parts to achieve the authentication and derive keying material. The long-term privacy of data protected with derived keying material is dependent on the private keys of each of the parties.
Considerable computational expense can be avoided if perfect forward secrecy is not a requirement for the session key derivation. The two parties can exchange nonces and secret key parts to achieve the authentication and derive keying material. The long-term privacy of data protected with derived keying material is dependent on the private keys of each of the parties.
Orman Informational [Page 17] RFC 2412 The OAKLEY Key Determination Protocol November 1998
Orman Informational [Page 17] RFC 2412 The OAKLEY Key Determination Protocol November 1998
In this exchange, the GRP has the value 0 and the field for the group exponential is used to hold a nonce value instead.
In this exchange, the GRP has the value 0 and the field for the group exponential is used to hold a nonce value instead.
As in the previous section, the first proposed algorithm must be a public key encryption system; by responding with a cookie and a non- zero exponential field, the Responder implicitly accepts the first proposal and the lack of perfect forward secrecy for the identities and derived keying material.
As in the previous section, the first proposed algorithm must be a public key encryption system; by responding with a cookie and a non- zero exponential field, the Responder implicitly accepts the first proposal and the lack of perfect forward secrecy for the identities and derived keying material.
Initiator Responder
--------- ---------
-> CKY-I, 0, OK_KEYX, 0, 0, EHAO, NIDP, ->
ID(R'), E{ID(I), ID(R), sKi}Kr', Ni
<- CKY-R, CKY-I, OK_KEYX, 0, 0, EHAS, NIDP,
E{ID(R), ID(I), sKr}Ki, Nr,
prf(Kir, ID(R) | ID(I) | Nr | Ni | EHAS) <-
-> CKY-I, CKY-R, OK_KEYX, EHAS, NIDP,
prf(Kir, ID(I) | ID(R) | Ni | Nr | EHAS) ->
Initiator Responder --------- --------- -> CKY-I, 0, OK_KEYX, 0, 0, EHAO, NIDP, -> ID(R'), E{ID(I), ID(R), sKi}Kr', Ni <- CKY-R, CKY-I, OK_KEYX, 0, 0, EHAS, NIDP, E{ID(R), ID(I), sKr}Ki, Nr, prf(Kir, ID(R) | ID(I) | Nr | Ni | EHAS) <- -> CKY-I, CKY-R, OK_KEYX, EHAS, NIDP, prf(Kir, ID(I) | ID(R) | Ni | Nr | EHAS) ->
Kir = prf(0, sKi | sKr)
Kir = prf(0, sKi | sKr)
NB The sKi and sKr values go into the nonce fields. The change in notation is meant to emphasize that their entropy is critical to setting the keying material.
NB The sKi and sKr values go into the nonce fields. The change in notation is meant to emphasize that their entropy is critical to setting the keying material.
NB "NIDP" means that the PFS option for hiding identities is not used.
NB "NIDP" means that the PFS option for hiding identities is not used.
The result of this exchange is a key with KEYID = CKY-I|CKY-R and value sKEYID = prf(Kir, CKY-I | CKY-R).
The result of this exchange is a key with KEYID = CKY-I|CKY-R and value sKEYID = prf(Kir, CKY-I | CKY-R).
2.4.3 A Conservative Example
2.4.3 A Conservative Example
In this example the two parties are minimally aggressive; they use the cookie exchange to delay creation of state, and they use perfect forward secrecy to protect the identities. For this example, they use public key encryption for authentication; digital signatures or pre-shared keys can also be used, as illustrated previously. The conservative example here does not change the use of nonces, prf's, etc., but it does change how much information is transmitted in each message.
In this example the two parties are minimally aggressive; they use the cookie exchange to delay creation of state, and they use perfect forward secrecy to protect the identities. For this example, they use public key encryption for authentication; digital signatures or pre-shared keys can also be used, as illustrated previously. The conservative example here does not change the use of nonces, prf's, etc., but it does change how much information is transmitted in each message.
The responder considers the ability of the initiator to repeat CKY-R as weak evidence that the message originates from a "live" correspondent on the network and the correspondent is associated with the initiator's network address. The initiator makes similar assumptions when CKY-I is repeated to the initiator.
The responder considers the ability of the initiator to repeat CKY-R as weak evidence that the message originates from a "live" correspondent on the network and the correspondent is associated with the initiator's network address. The initiator makes similar assumptions when CKY-I is repeated to the initiator.
Orman Informational [Page 18] RFC 2412 The OAKLEY Key Determination Protocol November 1998
Orman Informational [Page 18] RFC 2412 The OAKLEY Key Determination Protocol November 1998
All messages must have either valid cookies or at least one zero cookie. If both cookies are zero, this indicates a request for a cookie; if only the initiator cookie is zero, it is a response to a cookie request.
All messages must have either valid cookies or at least one zero cookie. If both cookies are zero, this indicates a request for a cookie; if only the initiator cookie is zero, it is a response to a cookie request.
Information in messages violating the cookie rules cannot be used for any OAKLEY operations.
Information in messages violating the cookie rules cannot be used for any OAKLEY operations.
Note that the Initiator and Responder must agree on one set of EHA algorithms; there is not one set for the Responder and one for the Initiator. The Initiator must include at least MD5 and DES in the initial offer.
Note that the Initiator and Responder must agree on one set of EHA algorithms; there is not one set for the Responder and one for the Initiator. The Initiator must include at least MD5 and DES in the initial offer.
Fields not indicated have null values.
Fields not indicated have null values.
Initiator Responder
--------- ---------
-> 0, 0, OK_KEYX ->
<- 0, CKY-R, OK_KEYX <-
-> CKY-I, CKY-R, OK_KEYX, GRP, g^x, EHAO ->
<- CKY-R, CKY-I, OK_KEYX, GRP, g^y, EHAS <-
-> CKY-I, CKY-R, OK_KEYX, GRP, g^x, IDP*,
ID(I), ID(R), E{Ni}Kr, ->
<- CKY-R, CKY-I, OK_KEYX, GRP, 0 , 0, IDP, <-
E{Nr, Ni}Ki, ID(R), ID(I),
prf(Kir, ID(R) | ID(I) | GRP | g^y | g^x | EHAS )
-> CKY-I, CKY-R, OK_KEYX, GRP, 0 , 0, IDP,
prf(Kir, ID(I) | ID(R) | GRP | g^x | g^y | EHAS ) ->
Initiator Responder --------- --------- -> 0, 0, OK_KEYX -> <- 0, CKY-R, OK_KEYX <- -> CKY-I, CKY-R, OK_KEYX, GRP, g^x, EHAO -> <- CKY-R, CKY-I, OK_KEYX, GRP, g^y, EHAS <- -> CKY-I, CKY-R, OK_KEYX, GRP, g^x, IDP*, ID(I), ID(R), E{Ni}Kr, -> <- CKY-R, CKY-I, OK_KEYX, GRP, 0 , 0, IDP, <- E{Nr, Ni}Ki, ID(R), ID(I), prf(Kir, ID(R) | ID(I) | GRP | g^y | g^x | EHAS ) -> CKY-I, CKY-R, OK_KEYX, GRP, 0 , 0, IDP, prf(Kir, ID(I) | ID(R) | GRP | g^x | g^y | EHAS ) ->
Kir = prf(0, Ni | Nr)
Kir = prf(0, Ni | Nr)
* when IDP is in effect, authentication payloads are encrypted with
the selected encryption algorithm using the keying material prf(0,
g^xy). (The transform defining the encryption algorithm will
define how to select key bits from the keying material.) This
encryption is in addition to and after any public key encryption.
See Appendix B.
* when IDP is in effect, authentication payloads are encrypted with the selected encryption algorithm using the keying material prf(0, g^xy). (The transform defining the encryption algorithm will define how to select key bits from the keying material.) This encryption is in addition to and after any public key encryption. See Appendix B.
Note that in the first messages, several fields are omitted from
the description. These fields are present as null values.
Note that in the first messages, several fields are omitted from the description. These fields are present as null values.
The first exchange allows the Responder to use stateless cookies; if the responder generates cookies in a manner that allows him to validate them without saving them, as in Photuris, then this is possible. Even if the Initiator includes a cookie in his initial request, the responder can still use stateless cookies by merely omitting the CKY-I from his reply and by declining to record the Initiator cookie until it appears in a later message.
The first exchange allows the Responder to use stateless cookies; if the responder generates cookies in a manner that allows him to validate them without saving them, as in Photuris, then this is possible. Even if the Initiator includes a cookie in his initial request, the responder can still use stateless cookies by merely omitting the CKY-I from his reply and by declining to record the Initiator cookie until it appears in a later message.
Orman Informational [Page 19] RFC 2412 The OAKLEY Key Determination Protocol November 1998
Orman Informational [Page 19] RFC 2412 The OAKLEY Key Determination Protocol November 1998
After the exchange is complete, both parties compute the shared key material sKEYID as prf(Ni | Nr, g^xy | CKY-I | CKY-R) where "prf" is the pseudo-random function in class "hash" selected in the EHA list.
After the exchange is complete, both parties compute the shared key material sKEYID as prf(Ni | Nr, g^xy | CKY-I | CKY-R) where "prf" is the pseudo-random function in class "hash" selected in the EHA list.
As with the cookies, each party considers the ability of the remote side to repeat the Ni or Nr value as a proof that Ka, the public key of party a, speaks for the remote party and establishes its identity.
As with the cookies, each party considers the ability of the remote side to repeat the Ni or Nr value as a proof that Ka, the public key of party a, speaks for the remote party and establishes its identity.
In analyzing this exchange, it is important to note that although the IDP option ensures that the identities are protected with an ephemeral key g^xy, the authentication itself does not depend on g^xy. It is essential that the authentication steps validate the g^x and g^y values, and it is thus imperative that the authentication not involve a circular dependency on them. A third party could intervene with a "man-in-middle" scheme to convince the initiator and responder to use different g^xy values; although such an attack might result in revealing the identities to the eavesdropper, the authentication would fail.
In analyzing this exchange, it is important to note that although the IDP option ensures that the identities are protected with an ephemeral key g^xy, the authentication itself does not depend on g^xy. It is essential that the authentication steps validate the g^x and g^y values, and it is thus imperative that the authentication not involve a circular dependency on them. A third party could intervene with a "man-in-middle" scheme to convince the initiator and responder to use different g^xy values; although such an attack might result in revealing the identities to the eavesdropper, the authentication would fail.
2.4.4 Extra Strength for Protection of Encryption Keys
2.4.4 Extra Strength for Protection of Encryption Keys
The nonces Ni and Nr are used to provide an extra dimension of secrecy in deriving session keys. This makes the secrecy of the key depend on two different problems: the discrete logarithm problem in the group G, and the problem of breaking the nonce encryption scheme. If RSA encryption is used, then this second problem is roughly equivalent to factoring the RSA public keys of both the initiator and responder.
The nonces Ni and Nr are used to provide an extra dimension of secrecy in deriving session keys. This makes the secrecy of the key depend on two different problems: the discrete logarithm problem in the group G, and the problem of breaking the nonce encryption scheme. If RSA encryption is used, then this second problem is roughly equivalent to factoring the RSA public keys of both the initiator and responder.
For authentication, the key type, the validation method, and the certification requirement must be indicated.
For authentication, the key type, the validation method, and the certification requirement must be indicated.
2.5 Identity and Authentication
2.5 Identity and Authentication
2.5.1 Identity
2.5.1 Identity
In OAKLEY exchanges the Initiator offers Initiator and Responder ID's -- the former is the claimed identity for the Initiator, and the latter is the requested ID for the Responder.
In OAKLEY exchanges the Initiator offers Initiator and Responder ID's -- the former is the claimed identity for the Initiator, and the latter is the requested ID for the Responder.
If neither ID is specified, the ID's are taken from the IP header source and destination addresses.
If neither ID is specified, the ID's are taken from the IP header source and destination addresses.
If the Initiator doesn't supply a responder ID, the Responder can reply by naming any identity that the local policy allows. The Initiator can refuse acceptance by terminating the exchange.
If the Initiator doesn't supply a responder ID, the Responder can reply by naming any identity that the local policy allows. The Initiator can refuse acceptance by terminating the exchange.
Orman Informational [Page 20] RFC 2412 The OAKLEY Key Determination Protocol November 1998
Orman Informational [Page 20] RFC 2412 The OAKLEY Key Determination Protocol November 1998
The Responder can also reply with a different ID than the Initiator suggested; the Initiator can accept this implicitly by continuing the exchange or refuse it by terminating (not replying).
The Responder can also reply with a different ID than the Initiator suggested; the Initiator can accept this implicitly by continuing the exchange or refuse it by terminating (not replying).
2.5.2 Authentication
2.5.2 Authentication
The authentication of principals to one another is at the heart of any key exchange scheme. The Internet community must decide on a scalable standard for solving this problem, and OAKLEY must make use of that standard. At the time of this writing, there is no such standard, though several are emerging. This document attempts to describe how a handful of standards could be incorporated into OAKLEY, without attempting to pick and choose among them.
The authentication of principals to one another is at the heart of any key exchange scheme. The Internet community must decide on a scalable standard for solving this problem, and OAKLEY must make use of that standard. At the time of this writing, there is no such standard, though several are emerging. This document attempts to describe how a handful of standards could be incorporated into OAKLEY, without attempting to pick and choose among them.
The following methods can appear in OAKLEY offers:
The following methods can appear in OAKLEY offers:
a. Pre-shared Keys
When two parties have arranged for a trusted method of
distributing secret keys for their mutual authentication, they can
be used for authentication. This has obvious scaling problems for
large systems, but it is an acceptable interim solution for some
situations. Support for pre-shared keys is REQUIRED.
a. Pre-shared Keys When two parties have arranged for a trusted method of distributing secret keys for their mutual authentication, they can be used for authentication. This has obvious scaling problems for large systems, but it is an acceptable interim solution for some situations. Support for pre-shared keys is REQUIRED.
The encryption, hash, and authentication algorithm for use with a
pre-shared key must be part of the state information distributed
with the key itself.
The encryption, hash, and authentication algorithm for use with a pre-shared key must be part of the state information distributed with the key itself.
The pre-shared keys have a KEYID and keying material sKEYID; the
KEYID is used in a pre-shared key authentication option offer.
There can be more than one pre-shared key offer in a list.
あらかじめ共有されたキーには、KEYIDと合わせることの物質的なsKEYIDがあります。 KEYIDはあらかじめ共有された主要な認証オプション申し出に使用されます。 リストには1つ以上のあらかじめ共有された主要な申し出があることができます。
Because the KEYID persists over different invocations of OAKLEY
(after a crash, etc.), it must occupy a reserved part of the KEYID
space for the two parties. A few bits can be set aside in each
party's "cookie space" to accommodate this.
KEYIDがオークリー(クラッシュなどの後の)の異なった実施の上で固執しているので、それは2回のパーティーのためにKEYIDスペースの予約された地域を占領しなければなりません。 これを収容するために各当事者の「クッキースペース」に数ビットをかたわらに置くことができます。
There is no certification authority for pre-shared keys. When a
pre-shared key is used to generate an authentication payload, the
certification authority is "None", the Authentication Type is
"Preshared", and the payload contains
あらかじめ共有されたキーのための証明権威が全くありません。 あらかじめ共有されたキーが認証ペイロードを生成するのに使用されるとき、証明権威がAuthentication Typeが"Preshared"と、「なにもに」ペイロードであるということである、含有
the KEYID, encoded as two 64-bit quantities, and the result of
applying the pseudorandom hash function to the message body
with the sKEYID forming the key for the function
sKEYIDが機能のためにキーを形成している状態で2つの64ビットの量、および擬似ランダムハッシュ関数をメッセージ本体に適用するという結果としてコード化されたKEYID
Orman Informational [Page 21] RFC 2412 The OAKLEY Key Determination Protocol November 1998
決断プロトコル1998年11月に主要なOrmanの情報[21ページ]のRFC2412のオークリー
b. DNS public keys
Security extensions to the DNS protocol [DNSSEC] provide a
convenient way to access public key information, especially for
public keys associated with hosts. RSA keys are a requirement for
secure DNS implementations; extensions to allow optional DSS keys
are a near-term possibility.
b。 DNSプロトコル[DNSSEC]へのDNS公開鍵Security拡張子は公開鍵情報にアクセスする便利な方法を提供します、特にホストに関連している公開鍵のために。 RSAキーは安全なDNS実装のための要件です。 任意のDSSキーを許容する拡大は短期間の可能性です。
DNS KEY records have associated SIG records that are signed by a
zone authority, and a hierarchy of signatures back to the root
server establishes a foundation for trust. The SIG records
indicate the algorithm used for forming the signature.
DNS KEY記録はゾーン権威によって署名されるSIG記録を関連づけました、そして、ルートサーバーへの署名の階層構造は信頼の基礎を確立します。 SIG記録は署名を形成するのに使用されるアルゴリズムを示します。
OAKLEY implementations must support the use of DNS KEY and SIG
records for authenticating with respect to IPv4 and IPv6 addresses
and fully qualified domain names. However, implementations are
not required to support any particular algorithm (RSA, DSS, etc.).
オークリー実装はDNS KEYとSIG記録のIPv4、IPv6アドレス、および完全修飾ドメイン名に関する認証の使用をサポートしなければなりません。 しかしながら、実装は、どんな特定のアルゴリズムも(RSA、DSSなど)であるとサポートするのに必要ではありません。
c. RSA public keys w/o certification authority signature PGP
[Zimmerman] uses public keys with an informal method for
establishing trust. The format of PGP public keys and naming
methods will be described in a separate RFC. The RSA algorithm
can be used with PGP keys for either signing or encryption; the
authentication option should indicate either RSA-SIG or RSA-ENC,
respectively. Support for this is OPTIONAL.
c。 設立のための非公式のメソッドがある公開鍵が信じる証明権威署名PGP[ジンマーマン]用途のないRSA公開鍵。 PGP公開鍵と命名メソッドの形式は別々のRFCで説明されるでしょう。 署名か暗号化のどちらかにPGPキーと共にRSAアルゴリズムを使用できます。 認証オプションはそれぞれRSA-SIGかRSA-ENCのどちらかを示すべきです。 このサポートはOPTIONALです。
d.1 RSA public keys w/ certificates There are various formats and
naming conventions for public keys that are signed by one or more
certification authorities. The Public Key Interchange Protocol
discusses X.509 encodings and validation. Support for this is
OPTIONAL.
証明書Thereがあるd.1 RSA公開鍵は、1つ以上の証明当局によって署名される公開鍵のための様々な形式と命名規則です。 Public Key InterchangeプロトコルはX.509 encodingsと合法化について議論します。 このサポートはOPTIONALです。
d.2 DSS keys w/ certificates Encoding for the Digital Signature
Standard with X.509 is described in draft-ietf-ipsec-dss-cert-
00.txt. Support for this is OPTIONAL; an ISAKMP Authentication
Type will be assigned.
X.509があるデジタル署名基準のための証明書Encodingがあるd.2DSSキーは草稿-ietf-ipsec-dss本命-00.txtで説明されます。 このサポートはOPTIONALです。 ISAKMP Authentication Typeは割り当てられるでしょう。
2.5.3 Validating Authentication Keys
2.5.3 認証キーを有効にすること。
The combination of the Authentication algorithm, the Authentication Authority, the Authentication Type, and a key (usually public) define how to validate the messages with respect to the claimed identity. The key information will be available either from a pre-shared key, or from some kind of certification authority.
Authenticationアルゴリズムの組み合わせ、Authentication Authority、Authentication Type、およびキー(通常公共の)は要求されたアイデンティティに関してメッセージを有効にする方法を定義します。 主要な情報はあらかじめ共有されたキーか、ある種の証明権威から利用可能になるでしょう。
Generally the certification authority produces a certificate binding the entity name to a public key. OAKLEY implementations must be prepared to fetch and validate certificates before using the public key for OAKLEY authentication purposes.
一般に証明権威は実体名を公開鍵に縛る証明書を製作します。 オークリー認証目的に公開鍵を使用する前に証明書をとって来て、有効にするようにオークリー実装を準備しなければなりません。
Orman Informational [Page 22] RFC 2412 The OAKLEY Key Determination Protocol November 1998
決断プロトコル1998年11月に主要なOrmanの情報[22ページ]のRFC2412のオークリー
The ISAKMP Authentication Payload defines the Authentication Authority field for specifying the authority that must be apparent in the trust hierarchy for authentication.
ISAKMP Authentication有効搭載量は、認証に、信頼階層構造で明らかであるに違いない権威を指定するためにAuthentication Authority分野を定義します。
Once an appropriate certificate is obtained (see 2.4.3), the validation method will depend on the Authentication Type; if it is PGP then the PGP signature validation routines can be called to satisfy the local web-of-trust predicates; if it is RSA with X.509 certificates, the certificate must be examined to see if the certification authority signature can be validated, and if the hierarchy is recognized by the local policy.
一度、適切な証明書を入手する、(見る、2.4、.3、)、合法化メソッドはAuthentication Typeによるでしょう。 それがPGPであるなら、ローカルの信頼のウェブ述部を満たすためにPGP署名合法化ルーチンを呼ぶことができます。 それがX.509証明書があるRSAであるなら、証明権威署名を有効にすることができるかどうかと、階層構造がローカルの方針で認識されるかどうか確認するために証明書を調べなければなりません。
2.5.4 Fetching Identity Objects
2.5.4 魅惑的なアイデンティティオブジェクト
In addition to interpreting the certificate or other data structure that contains an identity, users of OAKLEY must face the task of retrieving certificates that bind a public key to an identifier and also retrieving auxiliary certificates for certifying authorities or co-signers (as in the PGP web of trust).
アイデンティティを含む証明書か他のデータ構造を解釈することに加えて、オークリーのユーザは公開鍵を縛る証明書を識別子に検索して、また、当局か連帯保証人を公認するために補助の証明書を検索するタスクに直面しなければなりません(信頼のPGPウェブのように)。
The ISAKMP Credentials Payload can be used to attach useful certificates to OAKLEY messages. The Credentials Payload is defined in Appendix B.
役に立つ証明書をオークリーメッセージに添付するのにISAKMP Credentials有効搭載量を使用できます。 Credentials有効搭載量はAppendix Bで定義されます。
Support for accessing and revoking public key certificates via the Secure DNS protocol [SECDNS] is MANDATORY for OAKLEY implementations. Other retrieval methods can be used when the AUTH class indicates a preference.
Secure DNSプロトコル[SECDNS]で、公開鍵証明書にアクセスして、取り消すサポートはオークリー実装のためのMANDATORYです。 AUTHのクラスが優先を示すとき、他の検索メソッドを使用できます。
The Public Key Interchange Protocol discusses a full protocol that might be used with X.509 encoded certificates.
Public Key Interchangeプロトコルはコード化されるX.509と共に使用されるかもしれない完全なプロトコルについて議論します。証明書。
2.6 Interface to Cryptographic Transforms
2.6 暗号の変換へのインタフェース
The keying material computed by the key exchange should have at least 90 bits of entropy, which means that it must be at least 90 bits in length. This may be more or less than is required for keying the encryption and/or pseudorandom function transforms.
主要な交換によって計算された合わせることの材料はエントロピーの少なくとも90ビットを持っているはずです。(エントロピーは長さがそれは少なくとも90ビットでなければならないことを意味します)。 これは暗号化、そして/または、擬似ランダム機能変換を合わせるために必要とされるより多少そうです。
The transforms used with OAKLEY should have auxiliary algorithms which take a variable precision integer and turn it into keying material of the appropriate length. For example, a DES algorithm could take the low order 56 bits, a triple DES algorithm might use the following:
オークリーと共に使用される変換は可変精度整数を取って、それを適切な長さの材料を合わせるのに変える補助のアルゴリズムを持つべきです。 例えば、DESアルゴリズムは下位56ビットを取るかもしれなくて、三重のDESアルゴリズムは以下を使用するかもしれません:
K1 = low 56 bits of md5(0|sKEYID)
K2 = low 56 bits of md5(1|sKEYID)
K3 = low 56 bits of md5(2|sKEYID)
md5の低56md5(1| sKEYID)K3=ビットの低56md5(0| sKEYID)ケーツー=ビットの低56K1=ビット(2| sKEYID)
Orman Informational [Page 23] RFC 2412 The OAKLEY Key Determination Protocol November 1998
決断プロトコル1998年11月に主要なOrmanの情報[23ページ]のRFC2412のオークリー
The transforms will be called with the keying material encoded as a variable precision integer, the length of the data, and the block of memory with the data. Conversion of the keying material to a transform key is the responsibility of the transform.
変換は材料が可変精度整数、データの長さ、およびメモリのブロックとしてデータでコード化した合わせることで呼ばれるでしょう。 変換キーへの合わせることの材料の変換は変換の責任です。
2.7 Retransmission, Timeouts, and Error Messages
2.7 Retransmission、タイムアウト、およびエラーメッセージ
If a response from the Responder is not elicited in an appropriate amount of time, the message should be retransmitted by the Initiator. These retransmissions must be handled gracefully by both parties; the Responder must retain information for retransmitting until the Initiator moves to the next message in the protocol or completes the exchange.
Responderからの応答が適切な時間で引き出されないなら、メッセージはInitiatorによって再送されるはずです。 双方は優雅にこれらの「再-トランスミッション」を扱わなければなりません。 Initiatorがプロトコルの次のメッセージに移行するまで再送するための情報を保有しなければならない、さもなければ、Responderは交換を終了します。
Informational error messages present a problem because they cannot be authenticated using only the information present in an incomplete exchange; for this reason, the parties may wish to establish a default key for OAKLEY error messages. A possible method for establishing such a key is described in Appendix B, under the use of ISA_INIT message types.
情報のエラーメッセージは不完全な交換における現在の情報だけを使用することでそれらを認証できないので、問題を提示します。 この理由で、パーティーはオークリーエラーメッセージに、主要なデフォルトを確立したがっているかもしれません。 そのようなキーを設立するための可能なメソッドはAppendix BでISA_INITメッセージタイプの使用で説明されます。
In the following the message type is OAKLEY Error, the KEYID supplies the H algorithm and key for authenticating the message contents; this value is carried in the Sig/Prf payload.
以下のメッセージタイプがオークリーErrorである、KEYIDはメッセージ内容を認証するためのHアルゴリズムとキーを供給します。 この値はSig/Prfペイロードで運ばれます。
The Error payload contains the error code and the contents of the rejected message.
Errorペイロードはエラーコードと拒絶されたメッセージのコンテンツを含んでいます。
Orman Informational [Page 24] RFC 2412 The OAKLEY Key Determination Protocol November 1998
決断プロトコル1998年11月に主要なOrmanの情報[24ページ]のRFC2412のオークリー
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! !
~ Initiator-Cookie ~
/ ! !
KEYID +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ ! !
~ Responder-Cookie ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Domain of Interpretation !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Message Type ! Exch ! Vers ! Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! SPI (unused) !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! SPI (unused) !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Error Payload !
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Sig/prf Payload
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ! ~ Initiator-Cookie ~ / ! ! KEYID +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ ! ! ~ Responder-Cookie ~ ! ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Domain of Interpretation ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Message Type ! Exch ! Vers ! Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! SPI (unused) ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! SPI (unused) ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Error Payload ! ~ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Sig/prf Payload ~ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The error message will contain the cookies as presented in the offending message, the message type OAKLEY_ERROR, and the reason for the error, followed by the rejected message.
エラーメッセージは腹立たしいメッセージに示されるようにクッキーを含むでしょう、とメッセージタイプオークリー_ERROR、および誤りの理由は拒絶されたメッセージで続きました。
Error messages are informational only, and the correctness of the protocol does not depend on them.
エラーメッセージが情報である、唯一、プロトコルの正当性はそれらによりません。
Error reasons:
誤りは推論します:
TIMEOUT exchange has taken too long, state destroyed AEH_ERROR an unknown algorithm appears in an offer GROUP_NOT_SUPPORTED GRP named is not supported EXPONENTIAL_UNACCEPTABLE exponential too large/small or is +-1 SELECTION_NOT_OFFERED selection does not occur in offer NO_ACCEPTABLE_OFFERS no offer meets host requirements AUTHENTICATION_FAILURE signature or hash function fails RESOURCE_EXCEEDED too many exchanges or too much state info NO_EXCHANGE_IN_PROGRESS a reply received with no request in progress
また、TIMEOUT交換に時間がかかって、州の破壊されたAEH_ERRORが未知のアルゴリズムである、出現、申し出では、SUPPORTED GRPが命名したGROUP_NOT_は小さくサポートしているEXPONENTIAL_UNACCEPTABLE指数の大き過ぎる/でない+-1SELECTION_NOT_OFFERED選択がAUTHENTICATION_FAILURE署名かハッシュ関数があまりに多くの交換かあまりに多くRESOURCE_EXCEEDEDに失敗するというホスト要件が、要求が全く進行していなくインフォメーションいいえ_EXCHANGE_IN_PROGRESS a回答が受けたと述べる申し出いいえ_ACCEPTABLE_オッフェルスノー・オファー大会で起こらないということです。
Orman Informational [Page 25] RFC 2412 The OAKLEY Key Determination Protocol November 1998
決断プロトコル1998年11月に主要なOrmanの情報[25ページ]のRFC2412のオークリー
2.8 Additional Security for Privacy Keys: Private Groups
2.8 プライバシーキーのための追加担保: 民間のグループ
If the two parties have need to use a Diffie-Hellman key determination scheme that does not depend on the standard group definitions, they have the option of establishing a private group. The authentication need not be repeated, because this stage of the protocol will be protected by a pre-existing authentication key. As an extra security measure, the two parties will establish a private name for the shared keying material, so even if they use exactly the same group to communicate with other parties, the re-use will not be apparent to passive attackers.
2回のパーティーに標準のグループ定義によらないディフィー-ヘルマンの主要な決断体系を使用する必要があるなら、それらには、民間のグループを設立するオプションがあります。 プロトコルのこのステージが先在の認証キーによって保護されるので、認証は繰り返される必要はありません。 付加的なセキュリティが測定するとき、2回のパーティーが共有された合わせることの材料のために個人的な名前を確立するので、彼らが相手とコミュニケートするのにまさに同じグループを使用しても、再使用は受け身の攻撃者にとって明らかにならないでしょう。
Private groups have the advantage of making a widespread passive attack much harder by increasing the number of groups that would have to be exhaustively analyzed in order to recover a large number of session keys. This contrasts with the case when only one or two groups are ever used; in that case, one would expect that years and years of session keys would be compromised.
そうしなければならないグループの数を増強することによって広範囲の受け身の攻撃をはるかに困難にする利点は、民間のグループが、多くのセッションキーを回収するために徹底的に分析させています。 1か2つのグループだけが今までに使用されるとき、これはケースとひどく違います。 その場合、人は、何年もの何年ものセッションキーが感染されると予想するでしょう。
There are two technical challenges to face: how can a particular user create a unique and appropriate group, and how can a second party assure himself that the proposed group is reasonably secure?
直面している2つの技術的難関があります: 特定のユーザはどうしたらユニークで適切なグループを創設できるか、そして、2番目のパーティーは提案されたグループが合理的に安全であることをどうしたら自分に知らせることができますか?
The security of a modular exponentiation group depends on the largest prime factor of the group size. In order to maximize this, one can choose "strong" or Sophie Germaine primes, P = 2Q + 1, where P and Q are prime. However, if P = kQ + 1, where k is small, then the strength of the group is still considerable. These groups are known as Schnorr subgroups, and they can be found with much less computational effort than Sophie-Germaine primes.
モジュールの羃法グループのセキュリティはグループサイズの最も大きい主要因に依存します。 これを最大にするために、人は「強い」かソフィージャーメーン盛り、P=2Q+1を選ぶことができます。そこでは、PとQが主要です。 しかしながら、P=kQ+1であるなら、グループの勢力はまだ無視できません。そこでは、kが小さいです。 Schnorrサブグループとしてこれらのグループを知っています、そして、ソフィー-ジャーメーン盛りよりはるかに少ない計算量でそれらを見つけることができます。
Schnorr subgroups can also be validated efficiently by using probable prime tests.
また、素数候補テストを使用することによって、効率的にSchnorrサブグループを有効にすることができます。
It is also fairly easy to find P, k, and Q such that the largest prime factor can be easily proven to be Q.
また、それも、Qであると容易に最も大きい主要因を立証できるくらい掘り出し物P、k、およびQにかなり簡単です。
We estimate that it would take about 10 minutes to find a new group of about 2^1024 elements, and this could be done once a day by a scheduled process; validating a group proposed by a remote party would take perhaps a minute on a 25 MHz RISC machine or a 66 MHz CISC machine.
私たちは、およそ2つの^1024要素の新しいグループを見つけるにはおよそ10分かかると見積もっています、そして、これは1日に一度予定されているプロセスで終わることができました。 リモートパーティーによって提案されたグループを有効にするのは25MHzのRISCマシンか66MHzのCISCマシンの上で恐らく1分かかるでしょう。
We note that validation is done only between previously mutually authenticated parties, and that a new group definition always follows and is protected by a key established using a well-known group. There are five points to keep in mind:
私たちは新しいグループ定義を以前に互いに認証されたパーティーだけの間で合法化して、いつも続いて、よく知られるグループを使用することで設立されたキーで保護することに注意します。 覚えておく5ポイントがあります:
Orman Informational [Page 26] RFC 2412 The OAKLEY Key Determination Protocol November 1998
決断プロトコル1998年11月に主要なOrmanの情報[26ページ]のRFC2412のオークリー
a. The description and public identifier for the new group are
protected by the well-known group.
a。 新しいグループのための記述と公共の識別子はよく知られるグループによって保護されます。
b. The responder can reject the attempt to establish the new
group, either because he is too busy or because he cannot validate
the largest prime factor as being sufficiently large.
b。 応答者は新しいグループを設立する試みを拒絶できます、彼が忙し過ぎるか、または彼が十分大きいとして最も大きい主要因を有効にすることができないので。
c. The new modulus and generator can be cached for long periods of
time; they are not security critical and need not be associated
with ongoing activity.
c。 長期間の間、新しい係数とジェネレータをキャッシュできます。 それらは、セキュリティ重要でなく、進行中の活動に関連している必要はありません。
d. Generating a new g^x value periodically will be more expensive
if there are many groups cached; however, the importance of
frequently generating new g^x values is reduced, so the time
period can be lengthened correspondingly.
d。 キャッシュされた多くのグループがあると、定期的に新しいg^xが値であると生成するのは、より高価でしょう。 しかしながら、頻繁に新しいg^xが値であると生成する重要性が減少するので、期間を対応する伸すことができます。
e. All modular exponentiation groups have subgroups that are
weaker than the main group. For Sophie Germain primes, if the
generator is a square, then there are only two elements in the
subgroup: 1 and g^(-1) (same as g^(p-1)) which we have already
recommended avoiding. For Schnorr subgroups with k not equal to
2, the subgroup can be avoided by checking that the exponential is
not a kth root of 1 (e^k != 1 mod p).
e。 すべてのモジュールの羃法グループには、主なグループより弱いサブグループがあります。 ソフィージェルマン盛りのために、サブグループには2つの要素しかジェネレータが正方形であるならありません: 1と私たちが持っているg^(-1)(g^(p-1)と同じ)は、避けることを既に勧めました。 2と等しくないkがあるSchnorrサブグループに関しては、指数が1(e^k!=1モッズp)のkth根でないことをチェックすることによって、サブグループを避けることができます。
2.8.1 Defining a New Group
2.8.1 新しいグループを定義すること。
This section describes how to define a new group. The description of the group is hidden from eavesdroppers, and the identifier assigned to the group is unique to the two parties. Use of the new group for Diffie-Hellman key exchanges is described in the next section.
このセクションは新しいグループを定義する方法を説明します。 立ち聞きする者グループの記述を隠されます、そして、グループに配属された識別子は2回のパーティーにユニークです。 新しいグループのディフィー-ヘルマンの主要な交換の使用は次のセクションで説明されます。
The secrecy of the description and the identifier increases the difficulty of a passive attack, because if the group descriptor is not known to the attacker, there is no straightforward and efficient way to gain information about keys calculated using the group.
記述と識別子の秘密保持は受け身の攻撃の困難を増強します、グループ記述子が攻撃者にとって知られていないなら、グループを使用することで計算されたキーの周りで情報を得るどんな簡単で効率的な方法もないので。
Only the description of the new group need be encrypted in this exchange. The hash algorithm is implied by the OAKLEY session named by the group. The encryption is the encryption function of the OAKLEY session.
新しいグループの記述だけがこの交換で暗号化されなければなりません。 ハッシュアルゴリズムはグループによって指定されたオークリーのセッションで含意されます。 暗号化はオークリーのセッションの暗号化機能です。
The descriptor of the new group is encoded in the new group payload. The nonces are encoded in the Authentication Payload.
新しいグループに関する記述子は新しいグループペイロードでコード化されます。 一回だけはAuthentication有効搭載量でコード化されます。
Data beyond the encryption boundary is encrypted using the transform named by the KEYID.
暗号化境界を超えたデータは、KEYIDによって指定された変換を使用することで暗号化されています。
Orman Informational [Page 27] RFC 2412 The OAKLEY Key Determination Protocol November 1998
決断プロトコル1998年11月に主要なOrmanの情報[27ページ]のRFC2412のオークリー
The following messages use the ISAKMP Key Exchange Identifier OAKLEY New Group.
以下のメッセージはISAKMP Key Exchange IdentifierオークリーNew Groupを使用します。
To define a new modular exponentiation group:
新しいモジュールの羃法を定義するには、分類してください:
Initiator Responder
--------- ----------
-> KEYID, ->
INEWGRP,
Desc(New Group), Na
prf(sKEYID, Desc(New Group) | Na)
創始者応答者--------- ---------- ->KEYID、->INEWGRP、Desc(新しいGroup)、Na prf(Desc(新しいグループ)| sKEYID、Na)
<- KEYID,
INEWGRPRS,
Na, Nb
prf(sKEYID, Na | Nb | Desc(New Group)) <-
<KEYID、INEWGRPRS Na、Nb prf(sKEYID、Na|Nb|Desc(新しいグループ))<。
-> KEYID,
INEWGRPACK
prf(sKEYID, Nb | Na | Desc(New Group)) ->
->KEYID、INEWGRPACK prf(sKEYID、Nb|Na|Desc(新しいグループ))->。
These messages are encrypted at the encryption boundary using the key indicated. The hash value is placed in the "digital signature" field (see Appendix B).
これらのメッセージはキーが示した暗号化境界使用のときに暗号化されます。 ハッシュ値は「デジタル署名」分野に置かれます(Appendix Bを見てください)。
New GRP identifier = trunc16(Na) | trunc16(Nb)
新しいGRP識別子=trunc16(Na)| trunc16(Nb)
(trunc16 indicates truncation to 16 bits; the initiator and
responder must use nonces that have distinct upper bits from any
used for current GRPID's)
(trunc16はトランケーションを16ビットまで示します; 創始者と応答者は現在のGRPIDのものに、中古のいずれからの異なった上側のビットを持っている一回だけを使用しなければなりません)
Desc(G) is the encoding of the descriptor for the group descriptor
(see Appendix A for the format of a group descriptor)
Desc(G)はグループ記述子のための記述子のコード化です。(グループ記述子の形式に関してAppendix Aを見ます)
The two parties must store the mapping between the new group identifier GRP and the group descriptor Desc(New Group). They must also note the identities used for the KEYID and copy these to the state for the new group.
2回のパーティーが新しいグループ識別子GRPとグループ記述子Desc(新しいGroup)の間のマッピングを保存しなければなりません。 また、彼らは、アイデンティティがKEYIDとコピーに新しいグループのための状態にこれらを使用したことに注意しなければなりません。
Note that one could have the same group descriptor associated with several KEYID's. Pre-calculation of g^x values may be done based only on the group descriptor, not the private group name.
1つには数個KEYIDのものに関連している同じグループ記述子があるかもしれないことに注意してください。 個人的なグループ名ではなく、グループ記述子だけに基づいた状態でg^x値のプレ計算をするかもしれません。
2.8.2 Deriving a Key Using a Private Group
2.8.2 民間のグループを使用することでキーを引き出すこと。
Once a private group has been established, its group id can be used in the key exchange messages in the GRP position. No changes to the protocol are required.
民間のグループがいったん設立されると、GRP位置の主要な交換メッセージにグループイドを使用できます。 プロトコルへの変化は全く必要ではありません。
Orman Informational [Page 28] RFC 2412 The OAKLEY Key Determination Protocol November 1998
決断プロトコル1998年11月に主要なOrmanの情報[28ページ]のRFC2412のオークリー
2.9 Quick Mode: New Keys From Old,
2.9 迅速なモード: 古いのからの新しいキー
When an authenticated KEYID and associated keying material sKEYID already exist, it is easy to derive additional KEYID's and keys sharing similar attributes (GRP, EHA, etc.) using only hashing functions. The KEYID might be one that was derived in Main Mode, for example.
認証されたKEYIDと関連合わせることの材料sKEYIDが既に存在するとき、論じ尽くす機能だけを使用することで同様の属性(GRP、EHAなど)を共有する追加KEYIDのものとキーを引き出すのは簡単です。 KEYIDは例えば、Main Modeで引き出されたものであるかもしれません。
On the other hand, the authenticated key may be a manually distributed key, one that is shared by the initiator and responder via some means external to OAKLEY. If the distribution method has formed the KEYID using appropriately unique values for the two halves (CKY-I and CKY-R), then this method is applicable.
他方では、認証されたキーは手動で分配されたキーであるかもしれません、オークリーへの外部のいくつかの手段で創始者と応答者によって共有されるもの。 分配メソッドが2つの半分(CKY-IとCKY-R)に適切にユニークな値を使用することでKEYIDを形成したなら、このメソッドは適切です。
In the following, the Key Exchange Identifier is OAKLEY Quick Mode. The nonces are carried in the Authentication Payload, and the prf value is carried in the Authentication Payload; the Authentication Authority is "None" and the type is "Pre-Shared".
以下では、Key Exchange IdentifierはオークリークィックModeです。 一回だけはAuthentication有効搭載量で運ばれます、そして、prf値はAuthentication有効搭載量で運ばれます。 Authentication Authorityは「なにも」です、そして、タイプは「あらかじめ共有されています」。
The protocol is:
プロトコルは以下の通りです。
Initiator Responder
--------- ---------
-> KEYID, INEWKRQ, Ni, prf(sKEYID, Ni) ->
<- KEYID, INEWKRS, Nr, prf(sKEYID, 1 | Nr | Ni) <-
-> KEYID, INEWKRP, 0, prf(sKEYID, 0 | Ni | Nr) ->
創始者応答者--------- --------- -prf(sKEYID、Ni)-><prf(sKEYID、1|Nr|Ni)<>KEYID、INEWKRQ、Ni、KEYID、INEWKRS、Nr、->KEYID、INEWKRP、0、prf(sKEYID、0|Ni|Nr)->。
The New KEYID, NKEYID, is Ni | Nr
New KEYID(NKEYID)はNiです。| Nr
sNKEYID = prf(sKEYID, Ni | Nr )
sNKEYIDはprfと等しいです。(Ni| sKEYID、Nr)
The identities and EHA values associated with NKEYID are the same as those associated with KEYID.
NKEYIDに関連しているアイデンティティとEHA値はものがKEYIDと交際したのと同じです。
Each party must validate the hash values before using the new key for any purpose.
どんな目的にも新しいキーを使用する前に、各当事者はハッシュ値を有効にしなければなりません。
2.10 Defining and Using Pre-Distributed Keys
2.10 あらかじめ分配されたキーを定義して、使用すること。
If a key and an associated key identifier and state information have been distributed manually, then the key can be used for any OAKLEY purpose. The key must be associated with the usual state information: ID's and EHA algorithms.
キー、関連主要な識別子、および州の情報が手動で分配されたなら、どんなオークリー目的にもキーを使用できます。 キーは普通の州の情報に関連しているに違いありません: IDとEHAアルゴリズム。
Local policy dictates when a manual key can be included in the OAKLEY database. For example, only privileged users would be permitted to introduce keys associated with privileged ID's, an unprivileged user could only introduce keys associated with her own ID.
ローカルの方針は、いつオークリーデータベースに手動のキーを含むことができるかを決めます。 例えば、特権ユーザだけが特権があるIDのものに関連しているキーを紹介することが許可されて、「非-特権を与え」させられたユーザは彼女自身のIDに関連しているキーを紹介できただけです。
Orman Informational [Page 29] RFC 2412 The OAKLEY Key Determination Protocol November 1998
決断プロトコル1998年11月に主要なOrmanの情報[29ページ]のRFC2412のオークリー
2.11 Distribution of an External Key
2.11 外部のキーの分配
Once an OAKLEY session key and ancillary algorithms are established, the keying material and the "H" algorithm can be used to distribute an externally generated key and to assign a KEYID to it.
オークリーセッションキーと付属のアルゴリズムがいったん確立されると、外部的に生成しているキーを分配して、KEYIDをそれに割り当てるのに合わせることの材料と「H」アルゴリズムを使用できます。
In the following, KEYID represents an existing, authenticated OAKLEY session key, and sNEWKEYID represents the externally generated keying material.
以下では、KEYIDは既存の、そして、認証されたオークリーセッションキーを表します、そして、sNEWKEYIDは外部的に生成している合わせることの材料を表します。
In the following, the Key Exchange Identifier is OAKLEY External Mode. The Key Exchange Payload contains the new key, which is protected
以下では、Key Exchange IdentifierはオークリーExternal Modeです。 Key Exchange有効搭載量は新しいキーを含んでいます。(それは、保護されます)。
Initiator Responder --------- --------- -> KEYID, IEXTKEY, Ni, prf(sKEYID, Ni) -> <- KEYID, IEXTKEY, Nr, prf(sKEYID, 1 | Nr | Ni) <- -> KEYID, IEXTKEY, Kir xor sNEWKEYID*, prf(Kir, sNEWKEYID | Ni | Nr) ->
創始者応答者--------- --------- -prf(sKEYID、Ni)-><prf(sKEYID、1|Nr|Ni)<>KEYID、IEXTKEY、Ni、KEYID、IEXTKEY、Nr、->KEYID、IEXTKEY、Kir xor sNEWKEYID*、prf(Kir、sNEWKEYID|Ni|Nr)->。
Kir = prf(sKEYID, Ni | Nr)
Kirはprfと等しいです。(Ni| sKEYID、Nr)
* this field is carried in the Key Exchange Payload.
* この野原はKey Exchange有効搭載量で運ばれます。
Each party must validate the hash values using the "H" function in the KEYID state before changing any key state information.
各当事者は、どんな主要な州の情報も変える前にKEYID状態で「H」機能を使用することでハッシュ値を有効にしなければなりません。
The new key is recovered by the Responder by calculating the xor of the field in the Authentication Payload with the Kir value.
新しいキーは、Kir値に従ったAuthentication有効搭載量における分野のxorについて計算することによって、Responderによって回収されます。
The new key identifier, naming the keying material sNEWKEYID, is prf(sKEYID, 1 | Ni | Nr).
合わせる物質的なsNEWKEYIDを命名して、新しい主要な識別子はprf(sKEYID、1|Ni|Nr)です。
Note that this exchange does not require encryption. Hugo Krawcyzk suggested the method and noted its advantage.
この交換が暗号化を必要としないことに注意してください。 ユーゴーKrawcyzkはメソッドを勧めて、利点に注意しました。
2.11.1 Cryptographic Strength Considerations
2.11.1 暗号の強さ問題
The strength of the key used to distribute the external key must be at least equal to the strength of the external key. Generally, this means that the length of the sKEYID material must be greater than or equal to the length of the sNEWKEYID material.
外部のキーを分配するのに使用されるキーの強さは外部のキーの強さと少なくとも等しくなければなりません。 一般に、これは、sKEYIDの材料の長さがsNEWKEYIDの材料の長さ以上であるに違いないことを意味します。
The derivation of the external key, its strength or intended use are not addressed by this protocol; the parties using the key must have some other method for determining these properties.
その外部のキーの派生、強さまたは意図している使用がこのプロトコルによって扱われません。 キーを使用しているパーティーはこれらの特性を決定するためのある他のメソッドを持たなければなりません。
Orman Informational [Page 30] RFC 2412 The OAKLEY Key Determination Protocol November 1998
決断プロトコル1998年11月に主要なOrmanの情報[30ページ]のRFC2412のオークリー
As of early 1996, it appears that for 90 bits of cryptographic strength, one should use a modular exponentiation group modulus of 2000 bits. For 128 bits of strength, a 3000 bit modulus is required.
1996年前半現在、暗号の強さの90ビットに、2000ビットのモジュールの羃法グループ係数を使用するべきであるように見えます。 強さの128ビットにおいて、3000年のビットの係数が必要です。
3. Specifying and Deriving Security Associations
3. セキュリティ協会を指定して、引き出します。
When a security association is defined, only the KEYID need be given. The responder should be able to look up the state associated with the KEYID value and find the appropriate keying material, sKEYID.
セキュリティ協会を定義するとき、KEYIDだけを与えなければなりません。 応答者は、KEYID値に関連している状態を見上げて、適切な合わせるのが材料であることがわかることができるべきです、sKEYID。
Deriving keys for use with IPSEC protocols such as ESP or AH is a subject covered in the ISAKMP/Oakley Resolution document. That document also describes how to negotiate acceptable parameter sets and identifiers for ESP and AH, and how to exactly calculate the keying material for each instance of the protocols. Because the basic keying material defined here (g^xy) may be used to derive keys for several instances of ESP and AH, the exact mechanics of using one-way functions to turn g^xy into several unique keys is essential to correct usage.
超能力かAHなどのIPSECプロトコルによる使用のためのキーを引き出すのは、ISAKMP/オークリーResolutionドキュメントでカバーされた対象です。 また、そのドキュメントは、どのように超能力とAHのための許容できるパラメタセットと識別子を交渉するか、そして、プロトコルの各インスタンスのためにまさにどのように合わせることの材料について計算するかを説明します。 材料がここで定義した基本的な合わせること(g^xy)がいくつかのインスタンスのためにキーを引き出すのに使用されるかもしれないので、超能力とAH、使用一方向関数の正確な整備士では、g^xyを数個のユニークキーに変えるのは用法を修正するのに不可欠です。
4. ISAKMP Compatibility
4. ISAKMPの互換性
OAKLEY uses ISAKMP header and payload formats, as described in the text and in Appendix B. There are particular noteworthy extensions beyond the version 4 draft.
オークリーはテキストで説明されるようにISAKMPヘッダーとペイロード形式を使用します、そして、Appendixでは、B.Thereはバージョン4草稿を超えた特定の注目に値する拡大です。
4.1 Authentication with Existing Keys
4.1 既存のキーとの認証
In the case that two parties do not have suitable public key mechanisms in place for authenticating each other, they can use keys that were distributed manually. After establishment of these keys and their associated state in OAKLEY, they can be used for authentication modes that depend on signatures, e.g. Aggressive Mode.
2回のパーティーが互いを認証するために適所に適当な公開鍵メカニズムを持っていなくて、それらは手動で分配されたキーを使用できます。 オークリーのこれらのキーとそれらの準国家の設立の後に、署名(例えば、Aggressive Mode)に依存する認証モードにそれらを使用できます。
When an existing key is to appear in an offer list, it should be indicated with an Authentication Algorithm of ISAKMP_EXISTING. This value will be assigned in the ISAKMP RFC.
既存のキーが申し出リストに現れることになっているとき、それはISAKMP_EXISTINGのAuthentication Algorithmと共に示されるべきです。 この値はISAKMP RFCで割り当てられるでしょう。
When the authentication method is ISAKMP_EXISTING, the authentication authority will have the value ISAKMP_AUTH_EXISTING; the value for this field must not conflict with any authentication authority registered with IANA and is defined in the ISAKMP RFC.
認証方法がISAKMP_EXISTINGであるときに、認証権威には、値のISAKMP_AUTH_EXISTINGがあるでしょう。 この分野への値は、IANAに登録されるどんな認証権威とも闘争してはいけなくて、ISAKMP RFCで定義されます。
Orman Informational [Page 31] RFC 2412 The OAKLEY Key Determination Protocol November 1998
決断プロトコル1998年11月に主要なOrmanの情報[31ページ]のRFC2412のオークリー
The authentication payload will have two parts:
認証ペイロードには、2つの部品があるでしょう:
the KEYID for the pre-existing key
先在のキーのためのKEYID
the identifier for the party to be authenticated by the pre-
existing key.
パーティーがプレ既存のキーによって認証される識別子。
The pseudo-random function "H" in the state information for that KEYID will be the signature algorithm, and it will use the keying material for that key (sKEYID) when generating or checking the validity of message data.
そのKEYIDのための州の情報での擬似ランダム機能「H」は署名アルゴリズムになって、メッセージデータの正当性を生成するか、またはチェックするとき、それはそのキー(sKEYID)に合わせることの材料を使用するでしょう。
E.g. if the existing key has an KEYID denoted by KID and 128 bits of keying material denoted by sKID and "H" algorithm a transform named HMAC, then to generate a "signature" for a data block, the output of HMAC(sKID, data) will be the corresponding signature payload.
例えば、KIDとそして、データ・ブロックのための「署名」を発生させるようにHMACというsKIDによって指示された材料と「H」アルゴリズムを合わせる1変換あたり128ビットでKEYIDを指示すると、既存のキーでHMAC(滑り止め、データ)の出力は対応する署名ペイロードになるでしょう。
The KEYID state will have the identities of the local and remote parties for which the KEYID was assigned; it is up to the local policy implementation to decide when it is appropriate to use such a key for authenticating other parties. For example, a key distributed for use between two Internet hosts A and B may be suitable for authenticating all identities of the form "alice@A" and "bob@B".
KEYID州には、KEYIDが割り当てられた地方の、そして、リモートなパーティーのアイデンティティがあるでしょう。 相手を認証するのにそのようなキーを使用するのがいつ適切であるかを決めるのが地方の政策の実施まで達しています。 例えば、使用のために2人のインターネット・ホストAとBの間に分配されたキーはフォーム" alice@A "と" bob@B "のすべてのアイデンティティを認証するのに適当であるかもしれません。
4.2 Third Party Authentication
4.2 第三者認証
A local security policy might restrict key negotiation to trusted parties. For example, two OAKLEY daemons running with equal sensitivity labels on two machines might wish to be the sole arbiters of key exchanges between users with that same sensitivity label. In this case, some way of authenticating the provenance of key exchange requests is needed. I.e., the identities of the two daemons should be bound to a key, and that key will be used to form a "signature" for the key exchange messages.
ローカルの安全保障政策は主要な交渉を信じられたパーティーに制限するかもしれません。 例えば、2台のマシンの上に等しい感度ラベルがある状態で走る2つのオークリーデーモンがその同じ感度ラベルをもっているユーザの間の主要な交換について唯一の仲裁者になりたがっているかもしれません。 この場合、主要な交換要求の起源を認証する何らかの方法が必要です。 すなわち、2つのデーモンのアイデンティティはキーに縛られるべきです、そして、そのキーは、主要な交換メッセージのための「署名」を形成するのに使用されるでしょう。
The Signature Payload, in Appendix B, is for this purpose. This payload names a KEYID that is in existence before the start of the current exchange. The "H" transform for that KEYID is used to calculate an integrity/authentication value for all payloads preceding the signature.
Appendix Bに、Signature有効搭載量はこの目的のためにあります。 このペイロードは現在の交換の始まりの前に現存するKEYIDを命名します。 そのKEYIDのための「H」変換は、署名に先行するすべてのペイロードのために保全/認証値について計算するのに使用されます。
Local policy can dictate which KEYID's are appropriate for signing further exchanges.
ローカルの方針は、さらなる交換にサインするのに、どのKEYIDが適切であるかを決めることができます。
Orman Informational [Page 32] RFC 2412 The OAKLEY Key Determination Protocol November 1998
決断プロトコル1998年11月に主要なOrmanの情報[32ページ]のRFC2412のオークリー
4.3 New Group Mode
4.3 新しいグループモード
OAKLEY uses a new KEI for the exchange that defines a new group.
オークリーは新しいグループを定義する交換に新しいKEIを使用します。
5. Security Implementation Notes
5. セキュリティ実現紙幣
Timing attacks that are capable of recovering the exponent value used in Diffie-Hellman calculations have been described by Paul Kocher [Kocher]. In order to nullify the attack, implementors must take pains to obscure the sequence of operations involved in carrying out modular exponentiations.
ディフィー-ヘルマンの計算に使用される解説者値を回復できるタイミング攻撃がポール・コッハー[コッハー]によって説明されます。 攻撃を無効にして、作成者は、モジュールの羃法を行うのにかかわる操作の系列をあいまいにするために苦心をしなければなりません。
A "blinding factor" can accomplish this goal. A group element, r, is chosen at random. When an exponent x is chosen, the value r^(-x) is also calculated. Then, when calculating (g^y)^x, the implementation will calculate this sequence:
「目が眩むような要素」はこの目標を達成できます。 グループ要素(r)は無作為に選ばれています。 また、解説者xが選ばれているとき、値r^(-x)は計算されます。 次に、(g^y)^xについて計算するとき、実現はこの系列について計算するでしょう:
A = (rg^y)
B = A^x = (rg^y)^x = (r^x)(g^(xy))
C = B*r^(-x) = (r^x)(r^-(x))(g^(xy)) = g^(xy)
等しい..等しい(xy)
The blinding factor is only necessary if the exponent x is used more than 100 times (estimate by Richard Schroeppel).
解説者xが100回以上使用される場合にだけ(リチャードSchroeppelで、見積もってください)、目が眩むような要素が必要です。
6. OAKLEY Parsing and State Machine
6. 構文解析と州が機械加工するオークリー
There are many pathways through OAKLEY, but they follow a left-to- right parsing pattern of the message fields.
オークリーを通って多くの小道がありますが、それらはメッセージ分野のいなくなっている正しい構文解析パターンに従います。
The initiator decides on an initial message in the following order:
創始者は以下のオーダーにおける初期のメッセージを決めます:
1. Offer a cookie. This is not necessary but it helps with
aggressive exchanges.
1. クッキーを勧めてください。 これは必要ではありませんが、それは攻撃的な交換で助かります。
2. Pick a group. The choices are the well-known groups or any
private groups that may have been negotiated. The very first
exchange between two Oakley daemons with no common state must
involve a well-known group (0, meaning no group, is a well-known
group). Note that the group identifier, not the group descriptor,
is used in the message.
2. グループを選んでください。 選択は、交渉された周知のグループかあらゆる民間のグループです。 一般的な状態のない2つのオークリーデーモンの間のかなりの第一交換は周知のグループにかかわらなければなりません(グループを全く意味しないで、0は周知のグループです)。 グループ記述子ではなく、グループ識別子がメッセージで使用されることに注意してください。
If a non-null group will be used, it must be included with the
first message specifying EHAO. It need not be specified until
then.
非ヌルグループが使用されるなら、最初のメッセージがEHAOを指定している状態で、それを含まなければなりません。 それはそれまで、指定される必要はありません。
3. If PFS will be used, pick an exponent x and present g^x.
3. PFSが使用されるなら、解説者xと現在のg^xを選んでください。
4. Offer Encryption, Hash, and Authentication lists.
4. Encryption、Hash、およびAuthenticationにリストを提供してください。
Orman Informational [Page 33] RFC 2412 The OAKLEY Key Determination Protocol November 1998
決断プロトコル1998年11月に主要なOrmanの情報[33ページ]のRFC2412のオークリー
5. Use PFS for hiding the identities
5. アイデンティティを隠すのにPFSを使用してください。
If identity hiding is not used, then the initiator has this
option:
アイデンティティ隠れることが使用されていないなら、創始者には、このオプションがあります:
6. Name the identities and include authentication information
6. アイデンティティを命名してください、そして、認証情報を含めてください。
The information in the authentication section depends on the first authentication offer. In this aggressive exchange, the Initiator hopes that the Responder will accept all the offered information and the first authentication method. The authentication method determines the authentication payload as follows:
認証部の情報は最初の認証申し出によります。 この攻撃的な交換では、Initiatorは、Responderがすべての提供された情報と最初の認証方法を受け入れることを望んでいます。 認証方法は以下の認証ペイロードを測定します:
1. Signing method. The signature will be applied to all the
offered information.
1. 方法にサインします。 署名はすべての提供された情報に適用されるでしょう。
2. A public key encryption method. The algorithm will be used to
encrypt a nonce in the public key of the requested Responder
identity. There are two cases possible, depending on whether or
not identity hiding is used:
2. 公開鍵暗号化方法。 アルゴリズムは、要求されたResponderのアイデンティティの公開鍵における一回だけをコード化するのに使用されるでしょう。 アイデンティティ隠れることが使用されているかどうかによって、可能な2つのケースがあります:
a. No identity hiding. The ID's will appear as plaintext.
b. Identity hiding. A well-known ID, call it R', will appear
as plaintext in the authentication payload. It will be
followed by two ID's and a nonce; these will be encrypted using
the public key for R'.
a。 いいえアイデンティティ隠れること。 IDのものは平文bとして現れるでしょう。 アイデンティティ隠れること。 'A周知のID、それをR'と呼んでください、そして、認証ペイロードの平文として現れるために望んでください。 2のIDとa一回だけはそれのあとに続くでしょう。 'これらはRに公開鍵を使用することでコード化されるでしょう'。
3. A pre-existing key method. The pre-existing key will be used
to encrypt a nonce. If identity hiding is used, the ID's will be
encrypted in place in the payload, using the "E" algorithm
associated with the pre-existing key.
3. 先在の主要な方法。 先在のキーは、一回だけをコード化するのに使用されるでしょう。 アイデンティティ隠れることが使用されているなら、IDの意志がペイロードで適所でコード化されて、「E」アルゴリズムを使用するのは先在のキーと交際しました。
The Responder can accept all, part or none of the initial message.
Responderは初期のメッセージのすべて、部分またはいずれも受け入れることができません。
The Responder accepts as many of the fields as he wishes, using the same decision order as the initiator. At any step he can stop, implicitly rejecting further fields (which will have null values in his response message). The minimum response is a cookie and the GRP.
創始者と同じ決定命令を使用して、Responderは彼が願っているのと同じくらい多くを野原を受け入れます。 どんなステップにも、それとなく、さらなる分野(彼の応答メッセージにおけるヌル値を持つ)を拒絶する場合、彼は止まることができます。 最小の応答は、クッキーとGRPです。
1. Accept cookie. The Responder may elect to record no state
information until the Initiator successfully replies with a cookie
chosen by the responder. If so, the Responder replies with a
cookie, the GRP, and no other information.
1. クッキーを受け入れてください。 Responderは、クッキーが応答者によって選ばれている状態でInitiatorが首尾よく返答するまで州の情報を全く記録しないのを選ぶかもしれません。 そうだとすれば、ResponderはGRPにもかかわらず、クッキー、他のどんな情報でも返答しません。
2. Accept GRP. If the group is not acceptable, the Responder will
not reply. The Responder may send an error message indicating the
the group is not acceptable (modulus too small, unknown
identifier, etc.) Note that "no group" has two meanings during
2. GRPを受け入れてください。 グループが許容できないと、Responderは返答しないでしょう。 Responderはエラーメッセージにグループが許容できないのを(係数の小さ過ぎて、未知の識別子など)示させるかもしれません。 「グループがありません」には2つの意味がある注意
Orman Informational [Page 34] RFC 2412 The OAKLEY Key Determination Protocol November 1998
決断プロトコル1998年11月に主要なOrmanの情報[34ページ]のRFC2412のオークリー
the protocol: it may mean the group is not yet specified, or it
may mean that no group will be used (and thus PFS is not
possible).
プロトコル: それが、グループがまだ指定されていないことを意味するかもしれませんか、またはそれは、グループが全く使用されないことを意味するかもしれません(その結果、PFSは可能ではありません)。
3. Accept the g^x value. The Responder indicates his acceptance
of the g^x value by including his own g^y value in his reply. He
can postpone this by ignoring g^x and putting a zero length g^y
value in his reply. He can also reject the g^x value with an
error message.
3. g^x値を受け入れてください。 Responderは、彼の回答に彼自身のg^y値を含んでいることによって、彼のg^x価値の承認を示します。 彼は、彼の回答にg^xを無視して、ゼロ・レングスg^y価値を置くことによって、これを延期できます。 また、彼はエラーメッセージでg^x値を拒絶できます。
4. Accept one element from each of the EHA lists. The acceptance
is indicated by a non-zero proposal.
4. それぞれのEHAリストから1つの要素を受け入れてください。 承認は非ゼロ提案で示されます。
5. If PFS for identity hiding is requested, then no further data
will follow.
5. アイデンティティ隠れることへのPFSが要求されると、詳しいデータは全く続かないでしょう。
6. If the authentication payload is present, and if the first item
in the offered authentication class is acceptable, then the
Responder must validate/decrypt the information in the
authentication payload and signature payload, if present. The
Responder should choose a nonce and reply using the same
authentication/hash algorithm as the Initiator used.
6. 認証ペイロードが存在していて、提供された認証のクラスにおける最初の項目が許容できるなら、Responderは認証ペイロードと署名ペイロードの情報を有効にしなければならないか、または解読しなければなりません、存在しているなら。 Responderは、使用されるInitiatorと同じ認証/細切れ肉料理アルゴリズムを使用することで一回だけと回答を選ぶはずです。
The Initiator notes which information the Responder has accepted, validates/decrypts any signed, hashed, or encrypted fields, and if the data is acceptable, replies in accordance to the EHA methods selected by the Responder. The Initiator replies are distinguished from his initial message by the presence of the non-zero value for the Responder cookie.
InitiatorはResponderが何かであると受け入れて、有効にするか、または解読するどの情報が分野をサインしたか、論じ尽くしたか、またはコード化したか、そして、データが許容できるかどうかに注意します、Responderによって選択されたEHA方法との一致における回答。 Initiator回答はResponderクッキーのために非ゼロ価値の存在によって彼の初期のメッセージと区別されます。
The output of the signature or prf function will be encoded as a variable precision integer as described in Appendix C. The KEYID will indicate KEYID that names keying material and the Hash or Signature function.
Appendix C.KEYIDで説明される可変精度整数が材料を合わせて、HashかSignature機能を命名するKEYIDを示すとき、署名かprf機能の出力はコード化されるでしょう。
7. The Credential Payload
7. 信任している有効搭載量
Useful certificates with public key information can be attached to OAKLEY messages using Credential Payloads as defined in the ISAKMP document. It should be noted that the identity protection option applies to the credentials as well as the identities.
ISAKMPドキュメントで定義されるようにCredential有効搭載量を使用することで公開鍵情報がある役に立つ証明書をオークリーメッセージに添付できます。 アイデンティティ保護オプションがアイデンティティと同様に信任状に適用されることに注意されるべきです。
Security Considerations
セキュリティ問題
The focus of this document is security; hence security considerations permeate this memo.
このドキュメントの焦点はセキュリティです。 したがって、セキュリティ問題はこのメモを普及させます。
Orman Informational [Page 35] RFC 2412 The OAKLEY Key Determination Protocol November 1998
決断プロトコル1998年11月に主要なOrmanの情報[35ページ]のRFC2412のオークリー
Author's Address
作者のアドレス
Hilarie K. Orman Department of Computer Science University of Arizona
Hilarie K.Ormanコンピュータサイエンス学部アリゾナ大学
EMail: ho@darpa.mil
メール: ho@darpa.mil
Orman Informational [Page 36] RFC 2412 The OAKLEY Key Determination Protocol November 1998
決断プロトコル1998年11月に主要なOrmanの情報[36ページ]のRFC2412のオークリー
APPENDIX A Group Descriptors
付録はグループ記述子です。
Three distinct group representations can be used with OAKLEY. Each group is defined by its group operation and the kind of underlying field used to represent group elements. The three types are modular exponentiation groups (named MODP herein), elliptic curve groups over the field GF[2^N] (named EC2N herein), and elliptic curve groups over GF[P] (named ECP herein) For each representation, many distinct realizations are possible, depending on parameter selection.
オークリーと共に3つの異なった集団代表制を使用できます。 各グループはグループ操作で定義されます、そして、基本的な分野の種類は以前はよくグループ要素を表していました。 多くの異なった実現が3つのタイプがモジュールの羃法グループ(ここにMODPと命名される)と、分野GF[2^N]の上の楕円曲線グループ(ここにEC2Nと命名される)と、各表現のためのGF[P]の上の楕円曲線グループ(ここにECPと命名される)であることが可能です、パラメタ選択によって。
With a few exceptions, all the parameters are transmitted as if they were non-negative multi-precision integers, using the format defined in this appendix (note, this is distinct from the encoding in Appendix C). Every multi-precision integer has a prefixed length field, even where this information is redundant.
若干の例外はあるものの、すべてのパラメタがまるでそれらが非負のマルチ精度整数であるかのように伝えられます、この付録で定義された書式を使用して(注意、これはAppendix Cでのコード化と異なっています)。 あらゆるマルチ精度整数がこの情報が余分であるところにさえ前に置かれた長さの分野を持っています。
For the group type EC2N, the parameters are more properly thought of as very long bit fields, but they are represented as multi-precision integers, (with length fields, and right-justified). This is the natural encoding.
グループタイプEC2Nにおいて、パラメタが非常に長い噛み付いている分野として、より適切に考えられますが、それらがマルチ精度整数として表される、(長さの分野、まさしく正当であるのがある。) これは自然なコード化です。
MODP means the classical modular exponentiation group, where the operation is to calculate G^X (mod P). The group is defined by the numeric parameters P and G. P must be a prime. G is often 2, but may be a larger number. 2 <= G <= P-2.
MODPは古典的なモジュールの羃法グループを意味します。そこでは、操作はG^X(モッズP)について計算することです。 グループは数値パラメタPによって定義されます、そして、G.Pは主要であるに違いありません。 Gは、しばしば2ですが、より大きい数であるかもしれません。 2 G<=<はP-2と等しいです。
ECP is an elliptic curve group, modulo a prime number P. The
defining equation for this kind of group is
Y^2 = X^3 + AX + B The group operation is taking a multiple of an
elliptic-curve point. The group is defined by 5 numeric parameters:
The prime P, two curve parameters A and B, and a generator (X,Y).
A,B,X,Y are all interpreted mod P, and must be (non-negative)
integers less than P. They must satisfy the defining equation,
modulo P.
ECPは楕円曲線グループです、法a素数P.。定義方程式は、この種類のグループがY^2であるので、グループ操作が取っているX^3+AX+Bとa複数で楕円形のカーブポイントと等しいです。 グループは5つの数値パラメタによって定義されます: 第1P、2つのカーブパラメタAとB、およびジェネレータ(X、Y)。 A、B、X、Yは、解釈されたモッズPであり、P.Theyが定義方程式を満たさなければならないよりそれほど(非否定的)の整数であるに違いありません、法P。
EC2N is an elliptic curve group, over the finite field F[2^N]. The
defining equation for this kind of group is
Y^2 + XY = X^3 + AX^2 + B (This equation differs slightly from the
mod P case: it has an XY term, and an AX^2 term instead of an AX
term.)
EC2Nは有限分野Fの上の楕円曲線グループ[2^N]です。 この種類のグループのための定義方程式はY^2+XY=X^3+AX^2+Bです。(この方程式はモッズP事件と若干異なります: それはAX用語の代わりにXY用語、およびAX^2用語を過します。)
We must specify the field representation, and then the elliptic curve. The field is specified by giving an irreducible polynomial (mod 2) of degree N. This polynomial is represented as an integer of size between 2^N and 2^(N+1), as if the defining polynomial were evaluated at the value U=2.
私たちは、分野表現を指定して、次に、楕円曲線を指定しなければなりません。 分野はThis多項式が2^Nから2のサイズ^(N+1)の整数として表されるという度合いN.の既約多項式(モッズ風の2)を与えることによって、指定されます、まるで定義多項式が値のU=2で評価されるかのように。
Orman Informational [Page 37] RFC 2412 The OAKLEY Key Determination Protocol November 1998
決断プロトコル1998年11月に主要なOrmanの情報[37ページ]のRFC2412のオークリー
For example, the field defined by the polynomial U^155 + U^62 + 1 is represented by the integer 2^155 + 2^62 + 1. The group is defined by 4 more parameters, A,B,X,Y. These parameters are elements of the field GF[2^N], and can be thought of as polynomials of degree < N, with (mod 2) coefficients. They fit in N-bit fields, and are represented as integers < 2^N, as if the polynomial were evaluated at U=2. For example, the field element U^2 + 1 would be represented by the integer 2^2+1, which is 5. The two parameters A and B define the curve. A is frequently 0. B must not be 0. The parameters X and Y select a point on the curve. The parameters A,B,X,Y must satisfy the defining equation, modulo the defining polynomial, and mod 2.
例えば、多項式U^155+U^62+1によって定義された分野は整数2^155によって+ 2^62+1に表されます。 Y、グループはもう4つのパラメタ、A、B、Xによって定義されます。 これらのパラメタは、分野GF[2^N]の要素であり、度<Nの多項式として考えることができます、(モッズ風の2)係数で。 それらは、N-ビット分野をうまくはめ込んで、まるで多項式がU=2で評価されるかのように整数<2^Nとして表されます。 例えば、フィールド要素U^2+1が整数2^が表されるだろう、2、+1、5はどれです。 2つのパラメタAとBがカーブを定義します。 頻繁にAは0です。 Bは0であるはずがありません。 パラメタXとYはカーブのポイントを選択します。 パラメタA、B、X、Yが定義方程式を満たさなければならなくて、法が定義多項式であり、モッズは2歳です。
Group descriptor formats:
記述子形式を分類してください:
Type of group: A two-byte field,
assigned values for the types "MODP", "ECP", "EC2N"
will be defined (see ISAKMP-04).
Size of a field element, in bits. This is either Ceiling(log2 P)
or the degree of the irreducible polynomial: a 32-bit integer.
The prime P or the irreducible field polynomial: a multi-precision
integer.
The generator: 1 or 2 values, multi-precision integers.
EC only: The parameters of the curve: 2 values, multi-precision
integers.
グループのタイプ: 2バイトの分野、タイプ"MODP"、"ECP"のための割り当てられた値、"EC2N"は定義されるでしょう(ISAKMP-04を見てください)。 ビットのフィールド要素のサイズ。 これは、Ceiling(log2P)か既約多項式の度合いのどちらかです: 32ビットの整数。 第1Pか削減できない分野多項式: マルチ精度整数。 ジェネレータ: 1か2つの値、マルチ精度整数。 EC専用: カーブのパラメタ: 2つの値、マルチ精度整数。
The following parameters are Optional (each of these may appear
independently):
a value of 0 may be used as a place-holder to represent an unspecified
parameter; any number of the parameters may be sent, from 0 to 3.
以下のパラメタはOptional(それぞれのこれらは独自に現れるかもしれない)です: 0の値は不特定のパラメタを表すのにプレースホルダとして使用されるかもしれません。 0〜3までいろいろなパラメタを送るかもしれません。
The largest prime factor: the encoded value that is the LPF of the
group size, a multi-precision integer.
最も大きい主要因: グループサイズ、マルチ精度整数のLPFであるコード化された値。
EC only: The order of the group: multi-precision integer.
(The group size for MODP is always P-1.)
EC専用: グループの注文: マルチ精度整数。 (いつもMODPのためのグループサイズはP-1です。)
Strength of group: 32-bit integer.
The strength of the group is approximately the number of key-bits
protected.
It is determined by the log2 of the effort to attack the group.
It may change as we learn more about cryptography.
グループの勢力: 32ビットの整数。 グループの勢力は保護されたキービットのおよそ数です。 それはグループを攻撃するための努力のlog2によって決定されます。 私たちが暗号に関してもう少し学ぶようにそれは変化するかもしれません。
This is a generic example for a "classic" modular exponentiation group:
Group type: "MODP"
Size of a field element in bits: Log2 (P) rounded *up*. A 32bit
integer.
Defining prime P: a multi-precision integer.
Generator G: a multi-precision integer. 2 <= G <= P-2.
これは「古典的な」モジュールの羃法グループのための一般例です: タイプを分類してください: ビットのフィールド要素の"MODP"Size: Log2(P)は*32ビットの整数で*を一周させました。 第1Pを定義します: マルチ精度整数。 ジェネレータG: マルチ精度整数。 2 G<=<はP-2と等しいです。
Orman Informational [Page 38] RFC 2412 The OAKLEY Key Determination Protocol November 1998
決断プロトコル1998年11月に主要なOrmanの情報[38ページ]のRFC2412のオークリー
<optional>
Largest prime factor of P-1: the multi-precision integer Q
Strength of group: a 32-bit integer. We will specify a formula
for calculating this number (TBD).
P-1の<の任意の>Largest主要因: グループのマルチ精度整数Q Strength: 32ビットの整数。 私たちはこの数(TBD)について計算するのに公式を指定するつもりです。
This is a generic example for an elliptic curve group, mod P:
Group type: "ECP"
Size of a field element in bits: Log2 (P) rounded *up*,
a 32 bit integer.
Defining prime P: a multi-precision integer.
Generator (X,Y): 2 multi-precision integers, each < P.
Parameters of the curve A,B: 2 multi-precision integers, each < P.
<optional>
Largest prime factor of the group order: a multi-precision integer.
Order of the group: a multi-precision integer.
Strength of group: a 32-bit integer. Formula TBD.
モッズP、これは楕円曲線グループのための一般例です: タイプを分類してください: ビットのフィールド要素の"ECP"Size: Log2(P)は*、32ビットの整数で*を一周させました。 第1Pを定義します: マルチ精度整数。 ジェネレータ(X、Y): 2 マルチ精度整数、カーブAのそれぞれの<P.Parameters、B: 2 マルチ精度整数、共同注文のそれぞれの<のP.の<の任意の>Largest主要因: マルチ精度整数。 グループの注文: マルチ精度整数。 グループの勢力: 32ビットの整数。 公式TBD。
This is a specific example for an elliptic curve group:
Group type: "EC2N"
Degree of the irreducible polynomial: 155
Irreducible polynomial: U^155 + U^62 + 1, represented as the
multi-precision integer 2^155 + 2^62 + 1.
Generator (X,Y) : represented as 2 multi-precision integers, each
< 2^155.
For our present curve, these are (decimal) 123 and 456. Each is
represented as a multi-precision integer.
Parameters of the curve A,B: represented as 2 multi-precision
integers, each < 2^155.
For our present curve these are 0 and (decimal) 471951, represented
as two multi-precision integers.
これは楕円曲線グループのための特定の例です: タイプを分類してください: 既約多項式の"EC2N"Degree: 155 既約多項式: U^155+U^62+1マルチ精度整数2^155として+ 2^62+1に表されて、 ジェネレータ(X、Y): 2つのマルチ精度整数、それぞれの<2^155として、表されます。 私たちの現在のカーブのために、これらは、(10進)の123と456です。 それぞれがマルチ精度整数として表されます。 カーブAのパラメタ、B: 2つのマルチ精度整数、それぞれの<2^155として、表されます。 私たちの現在のカーブのために、これらは、0と2つのマルチ精度整数として表された(10進)の471951です。
<optional>
Largest prime factor of the group order:
共同注文の<の任意の>Largest主要因:
3805993847215893016155463826195386266397436443,
3805993847215893016155463826195386266397436443,
represented as a multi-precision integer.
The order of the group:
マルチ精度整数として、表されます。 グループの注文:
45671926166590716193865565914344635196769237316
45671926166590716193865565914344635196769237316
represented as a multi-precision integer.
マルチ精度整数として、表されます。
Strength of group: 76, represented as a 32-bit integer.
グループの勢力: 76 32ビットの整数として、表されます。
The variable precision integer encoding for group descriptor fields is the following. This is a slight variation on the format defined in Appendix C in that a fixed 16-bit value is used first, and the
グループ記述子のために分野をコード化する可変精度整数は以下です。 そしてこれが固定16ビットの値が最初に使用されるのでAppendix Cで定義された書式のわずかな変化である。
Orman Informational [Page 39] RFC 2412 The OAKLEY Key Determination Protocol November 1998
決断プロトコル1998年11月に主要なOrmanの情報[39ページ]のRFC2412のオークリー
length is limited to 16 bits. However, the interpretation is otherwise identical.
長さは16ビットに制限されます。 しかしながら、そうでなければ、解釈は同じです。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Fixed value (TBD) ! Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. Integer .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
評価
The format of a group descriptor is:
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!1!1! Group Description ! MODP !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!1!0! Field Size ! Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! MPI !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!1!0! Prime ! Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! MPI !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!1!0! Generator1 ! Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! MPI !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!1!0! Generator2 ! Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! MPI !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!1!0! Curve-p1 ! Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! MPI !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!1!0! Curve-p2 ! Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! MPI !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!1!0! Largest Prime Factor ! Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! MPI !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
グループ記述子の形式は以下の通りです。 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ !1!1! グループ記述!MODP!+++++++++++++++++++++++++++++++++! 1! 0! 分野..サイズ..長さ 主要..長さ 長さ 長さ カーブ..長さ カーブ..長さ 大きい..主要因..長さ
Orman Informational [Page 40] RFC 2412 The OAKLEY Key Determination Protocol November 1998
決断プロトコル1998年11月に主要なOrmanの情報[40ページ]のRFC2412のオークリー
!1!0! Order of Group ! Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! MPI ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ !0!0! Strength of Group ! Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! MPI ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!1!0! 命令する..グループ..長さ 強さ..グループ..長さ
Orman Informational [Page 41] RFC 2412 The OAKLEY Key Determination Protocol November 1998
決断プロトコル1998年11月に主要なOrmanの情報[41ページ]のRFC2412のオークリー
APPENDIX B Message formats
APPENDIX B Message形式
The encodings of Oakley messages into ISAKMP payloads is deferred to the ISAKMP/Oakley Resolution document.
ISAKMPペイロードへのオークリーメッセージのencodingsはISAKMP/オークリーResolutionドキュメントに延期されます。
Orman Informational [Page 42] RFC 2412 The OAKLEY Key Determination Protocol November 1998
決断プロトコル1998年11月に主要なOrmanの情報[42ページ]のRFC2412のオークリー
APPENDIX C Encoding a variable precision integer.
APPENDIXのCのEncodingのa可変精度整数。
Variable precision integers will be encoded as a 32-bit length field followed by one or more 32-bit quantities containing the representation of the integer, aligned with the most significant bit in the first 32-bit item.
最初の32ビットの項目における最も重要なビットに並べられた整数の表現を含む1つ以上の32ビットの量に従って32ビットの長さの野原が続いて、可変精度整数はコード化されるでしょう。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! first value word (most significant bits) !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! !
~ additional value words ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! first value word (most significant bits) ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ! ~ additional value words ~ ! ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
An example of such an encoding is given below, for a number with 51 bits of significance. The length field indicates that 2 32-bit quantities follow. The most significant non-zero bit of the number is in bit 13 of the first 32-bit quantity, the low order bits are in the second 32-bit quantity.
そのようなコード化に関する例は数のために意味の51ビットで以下に出されます。 長さの分野は、2つの32ビットの量が続くのを示します。 数の最も重要な非ゼロ・ビットが最初の32ビットの量のビット13にあって、下位のビットが2番目の32ビットの量にあります。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! 1 0!
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!0 0 0 0 0 0 0 0 0 0 0 0 0 1 x x x x x x x x x x x x x x x x x x!
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x!
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! 1 0! +++++++++++++++++++++++++++++++++! 0 0 0 0 0 0 0 0 0 0 0 0 0 1、x x x x x x x x x x x x x x x x x x! +++++++++++++++++++++++++++++++++! x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Orman Informational [Page 43] RFC 2412 The OAKLEY Key Determination Protocol November 1998
決断プロトコル1998年11月に主要なOrmanの情報[43ページ]のRFC2412のオークリー
APPENDIX D Cryptographic strengths
APPENDIX D Cryptographicの強さ
The Diffie-Hellman algorithm is used to compute keys that will be used with symmetric algorithms. It should be no easier to break the Diffie-Hellman computation than it is to do an exhaustive search over the symmetric key space. A recent recommendation by an group of cryptographers [Blaze] has recommended a symmetric key size of 75 bits for a practical level of security. For 20 year security, they recommend 90 bits.
ディフィー-ヘルマンアルゴリズムは、左右対称のアルゴリズムで使用されるキーを計算するのに使用されます。それは対称鍵スペースの上の徹底的な検索をすることになっているよりディフィー-ヘルマンの計算を壊すはずでありにくいです。 暗号使用者[炎]のグループによる最近の推薦は実務レベルのセキュリティのために75ビットの対称鍵サイズを推薦しました。 20年間のセキュリティのために、彼らは90ビットを推薦します。
Based on that report, a conservative strategy for OAKLEY users would be to ensure that their Diffie-Hellman computations were as secure as at least a 90-bit key space. In order to accomplish this for modular exponentiation groups, the size of the largest prime factor of the modulus should be at least 180 bits, and the size of the modulus should be at least 1400 bits. For elliptic curve groups, the LPF should be at least 180 bits.
そのレポートに基づいて、オークリーユーザにとって、保守的な戦略は彼らのディフィー-ヘルマンの計算が同じくらい少なくとも同じくらい安全な90ビットの主要なスペースであったのを保証するだろうことです。 モジュールの羃法グループのためにこれを達成するために、係数の最も大きい主要因のサイズは少なくとも180ビットであるべきです、そして、係数のサイズは少なくとも1400ビットであるべきです。 楕円曲線グループにおいて、LPFは少なくとも180ビットであるべきです。
If long-term secrecy of the encryption key is not an issue, then the following parameters may be used for the modular exponentiation group: 150 bits for the LPF, 980 bits for the modulus size.
暗号化キーの長期の秘密主義が問題でないなら、以下のパラメタはモジュールの羃法グループに使用されるかもしれません: LPFのための150ビット、係数サイズのための980ビット。
The modulus size alone does not determine the strength of the Diffie-Hellman calculation; the size of the exponent used in computing powers within the group is also important. The size of the exponent in bits should be at least twice the size of any symmetric key that will be derived from it. We recommend that ISAKMP implementors use at least 180 bits of exponent (twice the size of a 20-year symmetric key).
係数サイズだけがディフィー-ヘルマンの計算の強さを測定しません。 また、グループの中で強国を計算する際に使用される解説者のサイズも重要です。 ビットの解説者のサイズは少なくともそれから得られるどんな対称鍵のサイズの2倍であるべきです。 私たちは、ISAKMP作成者が解説者(20年の対称鍵のサイズの2倍)の少なくとも180ビットを使用することを勧めます。
The mathematical justification for these estimates can be found in texts that estimate the effort for solving the discrete log problem, a task that is strongly related to the efficiency of using the Number Field Sieve for factoring large integers. Readers are referred to [Stinson] and [Schneier].
これらの見積りのための数学の正当化はテキストのその見積りに離散的なログ問題を解決するための努力を設立することであるかもしれません、強く大きい整数を因数分解するのにNumber Field Sieveを使用する効率に関連するタスク。 読者は[スティンソン]と[シュナイアー]を参照されます。
Orman Informational [Page 44] RFC 2412 The OAKLEY Key Determination Protocol November 1998
決断プロトコル1998年11月に主要なOrmanの情報[44ページ]のRFC2412のオークリー
APPENDIX E The Well-Known Groups
周知が分類する付録E
The group identifiers:
グループ識別子:
0 No group (used as a placeholder and for non-DH exchanges)
1 A modular exponentiation group with a 768 bit modulus
2 A modular exponentiation group with a 1024 bit modulus
3 A modular exponentiation group with a 1536 bit modulus (TBD)
4 An elliptic curve group over GF[2^155]
5 An elliptic curve group over GF[2^185]
0 1024年のビットの係数3のAモジュールの羃法がある768ビットの係数2のAモジュールの羃法グループがあるどんなグループ(プレースホルダと非DHのために、交換を使用する)1のAモジュールの羃法グループもGFでGF[2^155]5An楕円曲線グループで1536年のビットの係数で(TBD)4An楕円曲線グループから構成されていません。[2^185]
values 2^31 and higher are used for private group identifiers
2^31をより高く評価する、個人的なグループ識別子のために、使用されます。
Richard Schroeppel performed all the mathematical and computational work for this appendix.
リチャードSchroeppelはこの付録のためのすべての数学の、そして、コンピュータの仕事をしました。
Classical Diffie-Hellman Modular Exponentiation Groups
古典的なディフィー-ヘルマンモジュールの羃法グループ
The primes for groups 1 and 2 were selected to have certain properties. The high order 64 bits are forced to 1. This helps the classical remainder algorithm, because the trial quotient digit can always be taken as the high order word of the dividend, possibly +1. The low order 64 bits are forced to 1. This helps the Montgomery- style remainder algorithms, because the multiplier digit can always be taken to be the low order word of the dividend. The middle bits are taken from the binary expansion of pi. This guarantees that they are effectively random, while avoiding any suspicion that the primes have secretly been selected to be weak.
グループ1と2のための盛りに、ある特性があるのが選択されました。 高位64ビットは1まで強制されます。 これは古典的な残りアルゴリズムを助けます、配当の高位単語としていつもトライアル商のケタをみなすことができるので、ことによると+1。 下位64ビットは1まで強制されます。 これはモンゴメリスタイル残りアルゴリズムを助けます、配当の下位の単語になるようにいつも乗数ケタを取ることができるので。 パイの2進の拡大から中くらいのビットを取ります。 これは、盛りが弱いのが秘かに選択されたというどんな容疑も避けている間、事実上、それらが無作為であることを保証します。
Because both primes are based on pi, there is a large section of overlap in the hexadecimal representations of the two primes. The primes are chosen to be Sophie Germain primes (i.e., (P-1)/2 is also prime), to have the maximum strength against the square-root attack on the discrete logarithm problem.
両方の盛りがパイに基づいているので、2盛りの16進表現にはオーバラップの大部分があります。 盛りはソフィージェルマン盛りになるように選ばれていて(また、すなわち、(P-1)/2も主要です)、最大の強さを平方根に抱くのは離散対数問題で攻撃されます。
The starting trial numbers were repeatedly incremented by 2^64 until suitable primes were located.
適当な盛りが見つけられるまで、始めのトライアル番号は2^64繰り返して増加されました。
Because these two primes are congruent to 7 (mod 8), 2 is a quadratic residue of each prime. All powers of 2 will also be quadratic residues. This prevents an opponent from learning the low order bit of the Diffie-Hellman exponent (AKA the subgroup confinement problem). Using 2 as a generator is efficient for some modular exponentiation algorithms. [Note that 2 is technically not a generator in the number theory sense, because it omits half of the possible residues mod P. From a cryptographic viewpoint, this is a virtue.]
これらの2盛りが7(モッズ風の8)に一致しているので、2はそれぞれの主要の平方剰余です。 また、すべての2人の強国が平方剰余になるでしょう。 これによって、相手がディフィー-ヘルマン解説者の下位のビットを学ぶことができない、(AKA、サブグループ監禁問題) いくつかのモジュールの羃法アルゴリズムに、ジェネレータとしての使用2は効率的です。[可能な残りモッズP.の半分を省略するので、2が整数論意味で技術的にジェネレータでないことに注意してください。Fromのa暗号の観点、これは美徳です。]
Orman Informational [Page 45] RFC 2412 The OAKLEY Key Determination Protocol November 1998
決断プロトコル1998年11月に主要なOrmanの情報[45ページ]のRFC2412のオークリー
E.1. Well-Known Group 1: A 768 bit prime
E.1。 周知のグループ1: 768ビットの第1
The prime is 2^768 - 2^704 - 1 + 2^64 * { [2^638 pi] + 149686 }. Its
decimal value is
155251809230070893513091813125848175563133404943451431320235
119490296623994910210725866945387659164244291000768028886422
915080371891804634263272761303128298374438082089019628850917
0691316593175367469551763119843371637221007210577919
第1は2^768--2^704--1+2^64*です。+ [2^638パイ]149686。 デシマル値が155251809230070893513091813125848175563133404943451431320235である、119490296623994910210725866945387659164244291000768028886422、915080371891804634263272761303128298374438082089019628850917、0691316593175367469551763119843371637221007210577919
This has been rigorously verified as a prime.
これは第1がきびしく確かめられました。
The representation of the group in OAKLEY is
オークリーでのグループの代理はそうです。
Type of group: "MODP"
Size of field element (bits): 768
Prime modulus: 21 (decimal)
Length (32 bit words): 24
Data (hex):
FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
E485B576 625E7EC6 F44C42E9 A63A3620 FFFFFFFF FFFFFFFF
Generator: 22 (decimal)
Length (32 bit words): 1
Data (hex): 2
グループのタイプ: フィールド要素(ビット)の"MODP"Size: 768 係数を用意してください: 21 (10進)の長さ(32ビットの単語): 24のデータ(十六進法): FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024 08Eの8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245E485B576 625E7EC6 F44C42E9 A63A3620 FFFFFFFF FFFFFFFFジェネレータ: 22 (10進)の長さ(32ビットの単語): 1つのデータ(十六進法): 2
Optional Parameters:
Group order largest prime factor: 24 (decimal)
Length (32 bit words): 24
Data (hex):
7FFFFFFF FFFFFFFF E487ED51 10B4611A 62633145 C06E0E68
94812704 4533E63A 0105DF53 1D89CD91 28A5043C C71A026E
F7CA8CD9 E69D218D 98158536 F92F8A1B A7F09AB6 B6A8E122
F242DABB 312F3F63 7A262174 D31D1B10 7FFFFFFF FFFFFFFF
Strength of group: 26 (decimal)
Length (32 bit words) 1
Data (hex):
00000042
任意のパラメタ: 共同注文の最も大きい主要因: 24 (10進)の長さ(32ビットの単語): 24のデータ(十六進法): グループの7FFFFFFF FFFFFFFF E487ED51 10B4611A62633145C06E0E68 94812704 4533E63A 0105DF53 1D89CD91 28A5043C C71A026E F7CA8CD9E69D218D98158536F92F8A1B A7F09AB6 B6A8E122 F242DABB 312F3F63 7A262174 D31D1B10 7FFFFFFF FFFFFFFF Strength: 26 (10進)の長さ(32ビットの単語)の1Data(十六進法): 00000042
E.2. Well-Known Group 2: A 1024 bit prime
E.2。 周知のグループ2: 1024年のビットの第1
The prime is 2^1024 - 2^960 - 1 + 2^64 * { [2^894 pi] + 129093 }.
Its decimal value is
179769313486231590770839156793787453197860296048756011706444
423684197180216158519368947833795864925541502180565485980503
646440548199239100050792877003355816639229553136239076508735
759914822574862575007425302077447712589550957937778424442426
617334727629299387668709205606050270810842907692932019128194
第1は2^1024です--2^960--1+2^64*。+ [2^894パイ]129093。 Its decimal value is 179769313486231590770839156793787453197860296048756011706444 423684197180216158519368947833795864925541502180565485980503 646440548199239100050792877003355816639229553136239076508735 759914822574862575007425302077447712589550957937778424442426 617334727629299387668709205606050270810842907692932019128194
Orman Informational [Page 46] RFC 2412 The OAKLEY Key Determination Protocol November 1998
決断プロトコル1998年11月に主要なOrmanの情報[46ページ]のRFC2412のオークリー
467627007
467627007
The primality of the number has been rigorously proven.
数のprimalityはきびしく立証されました。
The representation of the group in OAKLEY is
Type of group: "MODP"
Size of field element (bits): 1024
Prime modulus: 21 (decimal)
Length (32 bit words): 32
Data (hex):
FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED
EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE65381
FFFFFFFF FFFFFFFF
Generator: 22 (decimal)
Length (32 bit words): 1
Data (hex): 2
オークリーでのグループの代理はグループのTypeです: フィールド要素(ビット)の"MODP"Size: 1024は係数を用意します: 21 (10進)の長さ(32ビットの単語): 32のデータ(十六進法): FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024 08Eの8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651ECE65381 FFFFFFFF FFFFFFFFジェネレータ: 22 (10進)の長さ(32ビットの単語): 1つのデータ(十六進法): 2
Optional Parameters:
Group order largest prime factor: 24 (decimal)
Length (32 bit words): 32
Data (hex):
7FFFFFFF FFFFFFFF E487ED51 10B4611A 62633145 C06E0E68
94812704 4533E63A 0105DF53 1D89CD91 28A5043C C71A026E
F7CA8CD9 E69D218D 98158536 F92F8A1B A7F09AB6 B6A8E122
F242DABB 312F3F63 7A262174 D31BF6B5 85FFAE5B 7A035BF6
F71C35FD AD44CFD2 D74F9208 BE258FF3 24943328 F67329C0
FFFFFFFF FFFFFFFF
Strength of group: 26 (decimal)
Length (32 bit words) 1
Data (hex):
0000004D
任意のパラメタ: 共同注文の最も大きい主要因: 24 (10進)の長さ(32ビットの単語): 32のデータ(十六進法): 7FFFFFFF FFFFFFFF E487ED51 10B4611A 62633145 C06E0E68 94812704 4533E63A 0105DF53 1D89CD91 28A5043C C71A026E F7CA8CD9 E69D218D 98158536 F92F8A1B A7F09AB6 B6A8E122 F242DABB 312F3F63 7A262174 D31BF6B5 85FFAE5B 7A035BF6 F71C35FD AD44CFD2 D74F9208 BE258FF3 24943328 F67329C0 FFFFFFFF FFFFFFFF Strength of group: 26 (10進)の長さ(32ビットの単語)の1Data(十六進法): 0000004D
E.3. Well-Known Group 3: An Elliptic Curve Group Definition
E.3。 周知のグループ3: 楕円曲線グループ定義
The curve is based on the Galois field GF[2^155] with 2^155 field elements. The irreducible polynomial for the field is u^155 + u^62 + 1. The equation for the elliptic curve is
カーブは2^155個のフィールド要素があるガロア分野GF[2^155]に基づいています。 分野への既約多項式はu^155+u^62+1です。 楕円曲線のための方程式はそうです。
Y^2 + X Y = X^3 + A X + B
Y^2+X Yは+ X+BあたりX^3と等しいです。
X, Y, A, B are elements of the field.
X、Y、A、Bは分野の要素です。
For the curve specified, A = 0 and
そして指定されたカーブ、A=0。
B = u^18 + u^17 + u^16 + u^13 + u^12 + u^9 + u^8 + u^7 + u^3 + u^2 +
Bはu^18+u^17+u^16+u^13+u^12+u^9+u^8+u^7+u^3+u^2+と等しいです。
Orman Informational [Page 47] RFC 2412 The OAKLEY Key Determination Protocol November 1998
決断プロトコル1998年11月に主要なOrmanの情報[47ページ]のRFC2412のオークリー
u + 1.
u+1。
B is represented in binary as the bit string 1110011001110001111; in decimal this is 471951, and in hex 7338F.
Bはビット列1110011001110001111としてバイナリーで表されます。 小数では、7338F、これは、471951であり、十六進法でそうです。
The generator is a point (X,Y) on the curve (satisfying the curve equation, mod 2 and modulo the field polynomial).
ジェネレータがカーブのポイント(X、Y)である、(曲線方程式、モッズ風の2、および法を満たす、分野多項式)
X = u^6 + u^5 + u^4 + u^3 + u + 1
Xはu^6+u^5+u^4+u^3+u+1と等しいです。
and
そして
Y = u^8 + u^7 + u^6 + u^3.
Yはu^8+u^7+u^6+u^3と等しいです。
The binary bit strings for X and Y are 1111011 and 111001000; in decimal they are 123 and 456.
XとYのための2進のビット列は、1111011と111001000です。 小数では、それらは、123と456です。
The group order (the number of curve points) is
45671926166590716193865565914344635196769237316
which is 12 times the prime
共同注文(カーブポイントの数)は第1の12回である45671926166590716193865565914344635196769237316です。
3805993847215893016155463826195386266397436443.
(This prime has been rigorously proven.) The generating point (X,Y)
has order 4 times the prime; the generator is the triple of some
curve point.
3805993847215893016155463826195386266397436443. (この第1はきびしく立証されました。) 発生ポイント(X、Y)には、第1の4回の間のオーダーがあります。 ジェネレータは何らかのカーブポイントの三重です。
OAKLEY representation of this group:
Type of group: "EC2N"
Size of field element (bits): 155
Irreducible field polynomial: 21 (decimal)
Length (32 bit words): 5
Data (hex):
08000000 00000000 00000000 40000000 00000001
Generator:
X coordinate: 22 (decimal)
Length (32 bit words): 1
Data (hex): 7B
Y coordinate: 22 (decimal)
Length (32 bit words): 1
Data (hex): 1C8
Elliptic curve parameters:
A parameter: 23 (decimal)
Length (32 bit words): 1
Data (hex): 0
B parameter: 23 (decimal)
Length (32 bit words): 1
Data (hex): 7338F
このグループのオークリーの代理: グループのタイプ: フィールド要素(ビット)の"EC2N"Size: 155の削減できない分野多項式: 21 (10進)の長さ(32ビットの単語): 5つのデータ(十六進法): 08000000 00000000 00000000 40000000 00000001ジェネレータ: X座標: 22 (10進)の長さ(32ビットの単語): 1つのデータ(十六進法): 7B Yは調整します: 22 (10進)の長さ(32ビットの単語): 1つのデータ(十六進法): 1C8楕円曲線パラメタ: パラメタ: 23 (10進)の長さ(32ビットの単語): 1つのデータ(十六進法): 0Bパラメタ: 23 (10進)の長さ(32ビットの単語): 1つのデータ(十六進法): 7338F
Orman Informational [Page 48] RFC 2412 The OAKLEY Key Determination Protocol November 1998
決断プロトコル1998年11月に主要なOrmanの情報[48ページ]のRFC2412のオークリー
Optional Parameters:
Group order largest prime factor: 24 (decimal)
Length (32 bit words): 5
Data (hex):
00AAAAAA AAAAAAAA AAAAB1FC F1E206F4 21A3EA1B
Group order: 25 (decimal)
Length (32 bit words): 5
Data (hex):
08000000 00000000 000057DB 56985371 93AEF944
Strength of group: 26 (decimal)
Length (32 bit words) 1
Data (hex):
0000004C
任意のパラメタ: 共同注文の最も大きい主要因: 24 (10進)の長さ(32ビットの単語): 5つのデータ(十六進法): 00AAAAAA AAAAAAAA AAAAB1FC F1E206F4 21A3EA1B Groupは注文します: 25 (10進)の長さ(32ビットの単語): 5つのデータ(十六進法): グループの08000000 00000000 000057dBの56985371 93AEF944 Strength: 26 (10進)の長さ(32ビットの単語)の1Data(十六進法): 0000004C
E.4. Well-Known Group 4: A Large Elliptic Curve Group Definition
E.4。 周知のグループ4: 大きい楕円曲線グループ定義
This curve is based on the Galois field GF[2^185] with 2^185 field elements. The irreducible polynomial for the field is
このカーブは2^185個のフィールド要素があるガロア分野GF[2^185]に基づいています。 分野への既約多項式はそうです。
u^185 + u^69 + 1.
u^185+u^69+1。
The equation for the elliptic curve is
楕円曲線のための方程式はそうです。
Y^2 + X Y = X^3 + A X + B.
Y^2+X Yは+ X+BあたりX^3と等しいです。
X, Y, A, B are elements of the field. For the curve specified, A = 0 and
X、Y、A、Bは分野の要素です。 そして指定されたカーブ、A=0。
B = u^12 + u^11 + u^10 + u^9 + u^7 + u^6 + u^5 + u^3 + 1.
Bはu^12+u^11+u^10+u^9+u^7+u^6+u^5+u^3+1と等しいです。
B is represented in binary as the bit string 1111011101001; in decimal this is 7913, and in hex 1EE9.
Bはビット列1111011101001としてバイナリーで表されます。 小数では、これは、7913であり、十六進法1EE9でそうです。
The generator is a point (X,Y) on the curve (satisfying the curve equation, mod 2 and modulo the field polynomial);
ジェネレータがカーブのポイント(X、Y)である、(曲線方程式、モッズ風の2、および法を満たす、分野多項式)、。
X = u^4 + u^3 and Y = u^3 + u^2 + 1.
Xはu^4+u^3と等しいです、そして、Yはu^3+u^2+1と等しいです。
The binary bit strings for X and Y are 11000 and 1101; in decimal they are 24 and 13. The group order (the number of curve points) is
XとYのための2進のビット列は、11000と1101です。 小数では、それらは、24と13です。 共同注文(カーブポイントの数)はそうです。
49039857307708443467467104857652682248052385001045053116,
49039857307708443467467104857652682248052385001045053116,
which is 4 times the prime
どれが第1の4回ですか。
12259964326927110866866776214413170562013096250261263279.
12259964326927110866866776214413170562013096250261263279.
(This prime has been rigorously proven.)
(この第1はきびしく立証されました。)
Orman Informational [Page 49] RFC 2412 The OAKLEY Key Determination Protocol November 1998
決断プロトコル1998年11月に主要なOrmanの情報[49ページ]のRFC2412のオークリー
The generating point (X,Y) has order 2 times the prime; the generator is the double of some curve point.
発生ポイント(X、Y)には、第1の2回の間のオーダーがあります。 ジェネレータは何らかのカーブポイントの二重です。
OAKLEY representation of this group:
このグループのオークリーの代理:
Type of group: "EC2N"
Size of field element (bits): 185
Irreducible field polynomial: 21 (decimal)
Length (32 bit words): 6
Data (hex):
02000000 00000000 00000000 00000020 00000000 00000001
Generator:
X coordinate: 22 (decimal)
Length (32 bit words): 1
Data (hex): 18
Y coordinate: 22 (decimal)
Length (32 bit words): 1
Data (hex): D
Elliptic curve parameters:
A parameter: 23 (decimal)
Length (32 bit words): 1
Data (hex): 0
B parameter: 23 (decimal)
Length (32 bit words): 1
Data (hex): 1EE9
グループのタイプ: フィールド要素(ビット)の"EC2N"Size: 185の削減できない分野多項式: 21 (10進)の長さ(32ビットの単語): 6つのデータ(十六進法): 02000000 00000000 00000000 00000020 00000000 00000001ジェネレータ: X座標: 22 (10進)の長さ(32ビットの単語): 1つのデータ(十六進法): 18Y座標: 22 (10進)の長さ(32ビットの単語): 1つのデータ(十六進法): D楕円曲線パラメタ: パラメタ: 23 (10進)の長さ(32ビットの単語): 1つのデータ(十六進法): 0Bパラメタ: 23 (10進)の長さ(32ビットの単語): 1つのデータ(十六進法): 1EE9
Optional parameters:
Group order largest prime factor: 24 (decimal)
Length (32 bit words): 6
Data (hex):
007FFFFF FFFFFFFF FFFFFFFF F6FCBE22 6DCF9210 5D7E53AF
Group order: 25 (decimal)
Length (32 bit words): 6
Data (hex):
01FFFFFF FFFFFFFF FFFFFFFF DBF2F889 B73E4841 75F94EBC
Strength of group: 26 (decimal)
Length (32 bit words) 1
Data (hex):
0000005B
任意のパラメタ: 共同注文の最も大きい主要因: 24 (10進)の長さ(32ビットの単語): 6つのデータ(十六進法): 007FFFFF FFFFFFFF FFFFFFFF F6FCBE22 6DCF9210 5D7E53AF Groupは注文します: 25 (10進)の長さ(32ビットの単語): 6つのデータ(十六進法): グループの01FFFFFF FFFFFFFF FFFFFFFF DBF2F889 B73E4841 75F94EBC Strength: 26 (10進)の長さ(32ビットの単語)の1Data(十六進法): 0000005B
E.5. Well-Known Group 5: A 1536 bit prime
E.5。 周知のグループ5: 1536年のビットの第1
The prime is 2^1536 - 2^1472 - 1 + 2^64 * { [2^1406 pi] + 741804
}.
Its decimal value is
241031242692103258855207602219756607485695054850245994265411
694195810883168261222889009385826134161467322714147790401219
650364895705058263194273070680500922306273474534107340669624
第1は2^1536です--2^1472--1+2^64*。+ [1406年の2^パイ]741804。 デシマル値が241031242692103258855207602219756607485695054850245994265411である、694195810883168261222889009385826134161467322714147790401219、650364895705058263194273070680500922306273474534107340669624
Orman Informational [Page 50] RFC 2412 The OAKLEY Key Determination Protocol November 1998
決断プロトコル1998年11月に主要なOrmanの情報[50ページ]のRFC2412のオークリー
601458936165977404102716924945320037872943417032584377865919
814376319377685986952408894019557734611984354530154704374720
774996976375008430892633929555996888245787241299381012913029
459299994792636526405928464720973038494721168143446471443848
8520940127459844288859336526896320919633919
601458936165977404102716924945320037872943417032584377865919 814376319377685986952408894019557734611984354530154704374720 774996976375008430892633929555996888245787241299381012913029 459299994792636526405928464720973038494721168143446471443848 8520940127459844288859336526896320919633919
The primality of the number has been rigorously proven.
数のprimalityはきびしく立証されました。
The representation of the group in OAKLEY is
Type of group: "MODP"
Size of field element (bits): 1536
Prime modulus: 21 (decimal)
Length (32 bit words): 48
Data (hex):
FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED
EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE45B3D
C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8 FD24CF5F
83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D
670C354E 4ABC9804 F1746C08 CA237327 FFFFFFFF FFFFFFFF
Generator: 22 (decimal)
Length (32 bit words): 1
Data (hex): 2
オークリーでのグループの代理はグループのTypeです: フィールド要素(ビット)の"MODP"Size: 1536は係数を用意します: 21 (10進)の長さ(32ビットの単語): 48のデータ(十六進法): FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024 08Eの8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651ECE45B3D C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8FD24CF5F 83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D 670C354E 4ABC9804 F1746C08 CA237327 FFFFFFFF FFFFFFFFジェネレータ: 22 (10進)の長さ(32ビットの単語): 1つのデータ(十六進法): 2
Optional Parameters:
Group order largest prime factor: 24 (decimal)
Length (32 bit words): 48
Data (hex):
7FFFFFFF FFFFFFFF E487ED51 10B4611A 62633145 C06E0E68
94812704 4533E63A 0105DF53 1D89CD91 28A5043C C71A026E
F7CA8CD9 E69D218D 98158536 F92F8A1B A7F09AB6 B6A8E122
F242DABB 312F3F63 7A262174 D31BF6B5 85FFAE5B 7A035BF6
F71C35FD AD44CFD2 D74F9208 BE258FF3 24943328 F6722D9E
E1003E5C 50B1DF82 CC6D241B 0E2AE9CD 348B1FD4 7E9267AF
C1B2AE91 EE51D6CB 0E3179AB 1042A95D CF6A9483 B84B4B36
B3861AA7 255E4C02 78BA3604 6511B993 FFFFFFFF FFFFFFFF
Strength of group: 26 (decimal)
Length (32 bit words) 1
Data (hex):
0000005B
任意のパラメタ: 共同注文の最も大きい主要因: 24 (10進)の長さ(32ビットの単語): 48のデータ(十六進法): 7FFFFFFF FFFFFFFF E487ED51 10B4611A 62633145 C06E0E68 94812704 4533E63A 0105DF53 1D89CD91 28A5043C C71A026E F7CA8CD9 E69D218D 98158536 F92F8A1B A7F09AB6 B6A8E122 F242DABB 312F3F63 7A262174 D31BF6B5 85FFAE5B 7A035BF6 F71C35FD AD44CFD2 D74F9208 BE258FF3 24943328 F6722D9E E1003E5C 50B1DF82 CC6D241B 0E2AE9CD 348B1FD4 7E9267AF C1B2AE91 EE51D6CB 0E3179AB 1042A95D CF6A9483 B84B4B36 B3861AA7 255E4C02 78BA3604 6511B993 FFFFFFFF FFFFFFFF Strength of group: 26 (10進)の長さ(32ビットの単語)の1Data(十六進法): 0000005B
Orman Informational [Page 51] RFC 2412 The OAKLEY Key Determination Protocol November 1998
決断プロトコル1998年11月に主要なOrmanの情報[51ページ]のRFC2412のオークリー
Appendix F Implementing Group Operations
グループ操作を実行する付録F
The group operation must be implemented as a sequence of arithmetic operations; the exact operations depend on the type of group. For modular exponentiation groups, the operation is multi-precision integer multiplication and remainders by the group modulus. See Knuth Vol. 2 [Knuth] for a discussion of how to implement these for large integers. Implementation recommendations for elliptic curve group operations over GF[2^N] are described in [Schroeppel].
四則演算の系列としてグループ操作を実行しなければなりません。 正確な操作はグループのタイプに頼っています。 モジュールの羃法グループにおいて、操作は、グループ係数によるマルチ精度整数乗法と残りです。 大きい整数のためにどうこれらを実行するかに関する議論に関してクヌースVol.2[クヌース]を見てください。 GF[2^N]の上の楕円曲線グループ操作のための実現推薦は[Schroeppel]で説明されます。
Orman Informational [Page 52] RFC 2412 The OAKLEY Key Determination Protocol November 1998
決断プロトコル1998年11月に主要なOrmanの情報[52ページ]のRFC2412のオークリー
BIBLIOGRAPHY
図書目録
[RFC2401] Atkinson, R., "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[RFC2401] アトキンソン、R.、「インターネットプロトコルのためのセキュリティー体系」、RFC2401、1998年11月。
[RFC2406] Atkinson, R., "IP Encapsulating Security Payload (ESP)",
RFC 2406, November 1998.
[RFC2406]アトキンソン、R.、「セキュリティ有効搭載量(超能力)を要約するIP」、RFC2406、1998年11月。
[RFC2402] Atkinson, R., "IP Authentication Header", RFC 2402,
November 1998.
[RFC2402] アトキンソン、R.、「IP認証ヘッダー」、RFC2402、1998年11月。
[Blaze] Blaze, Matt et al., MINIMAL KEY LENGTHS FOR SYMMETRIC
CIPHERS TO PROVIDE ADEQUATE COMMERCIAL SECURITY. A
REPORT BY AN AD HOC GROUP OF CRYPTOGRAPHERS AND COMPUTER
SCIENTISTS... --
http://www.bsa.org/policy/encryption/cryptographers.html
[Blaze] Blaze, Matt et al., MINIMAL KEY LENGTHS FOR SYMMETRIC CIPHERS TO PROVIDE ADEQUATE COMMERCIAL SECURITY. 暗号使用者とコンピュータ科学者の専門家班によるレポート… -- http://www.bsa.org/policy/encryption/cryptographers.html
[STS] W. Diffie, P.C. Van Oorschot, and M.J. Wiener,
"Authentication and Authenticated Key Exchanges," in
Designs, Codes and Cryptography, Kluwer Academic
Publishers, 1992, pp. 107
[STS]W.ディフィー、P.C.ヴァンOorschot、M.J.Wiener、およびDesignsとCodesとCryptography、Kluwer Academic Publishers、1992、ページにおける「認証と認証された主要な交換」 107
[SECDNS] Eastlake, D. and C. Kaufman, "Domain Name System
Security Extensions", RFC 2065, January 1997.
[SECDNS]イーストレークとD.とC.コーフマン、「ドメインネームシステムセキュリティ拡大」、1997年1月のRFC2065。
[Random] Eastlake, D., Crocker, S. and J. Schiller, "Randomness
Recommendations for Security", RFC 1750, December 1994.
[無作為の] イーストレークとD.とクロッカーとS.とJ.シラー、「セキュリティのための偶発性推薦」、RFC1750、1994年12月。
[Kocher] Kocher, Paul, Timing Attack,
http://www.cryptography.com/timingattack.old/timingattack.html
[コッハー] コッハー、ポール、タイミング攻撃、 http://www.cryptography.com/timingattack.old/timingattack.html
[Knuth] Knuth, Donald E., The Art of Computer Programming, Vol.
2, Seminumerical Algorithms, Addison Wesley, 1969.
[クヌース]クヌース、ドナルドE.、コンピュータ・プログラミング、Vol.2、Seminumericalアルゴリズム、アディソン・ウエスリー、1969年の芸術。
[Krawcyzk] Krawcyzk, Hugo, SKEME: A Versatile Secure Key Exchange
Mechanism for Internet, ISOC Secure Networks and
Distributed Systems Symposium, San Diego, 1996
[Krawcyzk] Krawcyzk、ユーゴー、SKEME: インターネット、ISOC安全なネットワーク、および分散システムシンポジウムのための多能な安全な主要な交換メカニズム、サンディエゴ、1996
[Schneier] Schneier, Bruce, Applied cryptography: protocols,
algorithms, and source code in C, Second edition, John
Wiley & Sons, Inc. 1995, ISBN 0-471-12845-7, hardcover.
ISBN 0-471-11709-9, softcover.
[シュナイアー]シュナイアー、ブルース、Applied暗号: プロトコル、アルゴリズム、およびC、Second版、ジョン・ワイリー、およびソンスInc.1995におけるソースコード、ハードカバーISBN0-471-11709-9の、そして、ペーパーバックののISBN0-471-12845-7。
[Schroeppel] Schroeppel, Richard, et al.; Fast Key Exchange with
Elliptic Curve Systems, Crypto '95, Santa Barbara, 1995.
Available on-line as
ftp://ftp.cs.arizona.edu/reports/1995/TR95-03.ps (and
.Z).
[Schroeppel] Schroeppel、リチャード、他。 1995の楕円曲線システム、暗号95年、サンタバーバラとの速い主要な交換 利用可能である、 ftp://ftp.cs.arizona.edu/reports/1995/TR95-03.ps (そして、.Z)として、オンラインです。
Orman Informational [Page 53] RFC 2412 The OAKLEY Key Determination Protocol November 1998
決断プロトコル1998年11月に主要なOrmanの情報[53ページ]のRFC2412のオークリー
[Stinson] Stinson, Douglas, Cryptography Theory and Practice. CRC
Press, Inc., 2000, Corporate Blvd., Boca Raton, FL,
33431-9868, ISBN 0-8493-8521-0, 1995
[スティンソン]スティンソン、ダグラス、暗号理論、および習慣。 CRCはInc.、2000、法人のBlvd.、ボカラトン、フロリダ33431-9868、ISBN0-8493-8521-0、1995を押します。
[Zimmerman] Philip Zimmermann, The Official Pgp User's Guide,
Published by MIT Press Trade, Publication date: June
1995, ISBN: 0262740176
[ジンマーマン]フィリップZimmermann、PublicationがデートするOfficial Pgp Userのガイド(MIT Press TradeによるPublished): 1995年6月、ISBN: 0262740176
Orman Informational [Page 54] RFC 2412 The OAKLEY Key Determination Protocol November 1998
決断プロトコル1998年11月に主要なOrmanの情報[54ページ]のRFC2412のオークリー
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright(C)インターネット協会(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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Orman Informational [Page 55]
Orman情報です。[55ページ]
一覧
スポンサーリンク
