RFC5996(IKEv2)_3

3.3.2. Transform Substructure

Figure 8: Transform Substructure

o 0 (last) or 3 (more) (1 octet) - Specifies whether this is the
last Transform Substructure in the Proposal. This syntax is
inherited from ISAKMP, but is unnecessary because the last
transform could be identified from the length of the proposal.
The value (3) corresponds to a payload type of Transform in IKEv1,
and the first four octets of the Transform structure are designed
to look somewhat like the header of a payload.
Proposalの最後のTransform Substructureであることを示す。このシンタックスはISAKMPから継承されている。ただし、最後のtransformはproposal lengthから特定できるため不要である。3はIKEv1におけるTransformのpayload typeで
TransformはProposalのlengthから特定できるため不要である。3はIKEv1のTransformのpayload typeに対応し、Transform structureの最初の4オクテットがpayload headerになるように設計されている。

o RESERVED - MUST be sent as zero; MUST be ignored on receipt.
0で送信し、受信側は無視すること。

Kaufman, et al. Standards Track [Page 79]

RFC 5996 IKEv2bis September 2010

o Transform Length - The length (in octets) of the Transform
Substructure including Header and Attributes.
HeaderとAttiributeを含むTransform Substructureのオクテット長。

o Transform Type (1 octet) - The type of transform being specified
in this transform. Different protocols support different
Transform Types. For some protocols, some of the transforms may
be optional. If a transform is optional and the initiator wishes
to propose that the transform be omitted, no transform of the
given type is included in the proposal. If the initiator wishes
to make use of the transform optional to the responder, it
includes a transform substructure with Transform ID = 0 as one of
the options.
このTransformで指定されるTransform type。異なるprotocolは異なるTransform Typeをサポートする。いくつかのProtocolにおいては、Transformはオプションである。Trasnsformがオプションで、initiatorが省略するtransformを提案する場合、TransfromのTypeはProposalに含まれない。initiatorはresponderにオプションのTransformを使用することを示すため、オプションの一つとしてTransform ID=0のTransform Substructureを含める。

o Transform ID (2 octets) - The specific instance of the Transform
Type being proposed.
提案されたTransform Type。

The Transform Type values are listed below. The values in the
following table are only current as of the publication date of RFC
4306. Other values may have been added since then or will be added
after the publication of this document. Readers should refer to
[IKEV2IANA] for the latest values.
Transform Typeを下記に示す。下記はRFC4306発行時のものである。以降に追加された値は[IKEV2IANA]参照。

Description Trans. Used In
Type
------------------------------------------------------------------
Encryption Algorithm (ENCR) 1 IKE and ESP
Pseudorandom Function (PRF) 2 IKE
Integrity Algorithm (INTEG) 3 IKE*, AH, optional in ESP
Diffie-Hellman group (D-H) 4 IKE, optional in AH & ESP
Extended Sequence Numbers (ESN) 5 AH and ESP

(*) Negotiating an integrity algorithm is mandatory for the
Encrypted payload format specified in this document. For example,
[AEAD] specifies additional formats based on authenticated
encryption, in which a separate integrity algorithm is not
negotiated.
このドキュメントにおいて、Integrity algorithmをネゴシエーションすることはEncrypted paylaodを指定する場合、必須である。例えば、[AEAD]では独立したintegrity algorithmはネゴシエーションされず、認証された暗号化方式に基づき、追加のフォーマットを指定する。

For Transform Type 1 (Encryption Algorithm), the Transform IDs are
listed below. The values in the following table are only current as
of the publication date of RFC 4306. Other values may have been
added since then or will be added after the publication of this
document. Readers should refer to [IKEV2IANA] for the latest values.
Transform Type 1(Encryption Algorithm)におけるTransform IDは下記である。下記はRFC4306をもとにしており、最新の値は[IKEV2IANA]にある。

Kaufman, et al. Standards Track [Page 80]

RFC 5996 IKEv2bis September 2010

Name Number Defined In
---------------------------------------------------
ENCR_DES_IV64 1 (UNSPECIFIED)
ENCR_DES 2 (RFC2405), [DES]
ENCR_3DES 3 (RFC2451)
ENCR_RC5 4 (RFC2451)
ENCR_IDEA 5 (RFC2451), [IDEA]
ENCR_CAST 6 (RFC2451)
ENCR_BLOWFISH 7 (RFC2451)
ENCR_3IDEA 8 (UNSPECIFIED)
ENCR_DES_IV32 9 (UNSPECIFIED)
ENCR_NULL 11 (RFC2410)
ENCR_AES_CBC 12 (RFC3602)
ENCR_AES_CTR 13 (RFC3686)

For Transform Type 2 (Pseudorandom Function), the Transform IDs are
listed below. The values in the following table are only current as
of the publication date of RFC 4306. Other values may have been
added since then or will be added after the publication of this
document. Readers should refer to [IKEV2IANA] for the latest values.
Transform Type 2(Pseudorandom Function)におけるTransform IDは下記である。下記はRFC4306をもとにしており、最新の値は[IKEV2IANA]にある。

Name Number Defined In
------------------------------------------------------
PRF_HMAC_MD5 1 (RFC2104), [MD5]
PRF_HMAC_SHA1 2 (RFC2104), [SHA]
PRF_HMAC_TIGER 3 (UNSPECIFIED)

For Transform Type 3 (Integrity Algorithm), defined Transform IDs are
listed below. The values in the following table are only current as
of the publication date of RFC 4306. Other values may have been
added since then or will be added after the publication of this
document. Readers should refer to [IKEV2IANA] for the latest values.
Transform Type 3(Integrity Algorithm)におけるTransform IDは下記である。下記はRFC4306をもとにしており、最新の値は[IKEV2IANA]にある。

Name Number Defined In
----------------------------------------
NONE 0
AUTH_HMAC_MD5_96 1 (RFC2403)
AUTH_HMAC_SHA1_96 2 (RFC2404)
AUTH_DES_MAC 3 (UNSPECIFIED)
AUTH_KPDK_MD5 4 (UNSPECIFIED)
AUTH_AES_XCBC_96 5 (RFC3566)

For Transform Type 4 (Diffie-Hellman group), defined Transform IDs
are listed below. The values in the following table are only current
as of the publication date of RFC 4306. Other values may have been
added since then or will be added after the publication of this
document. Readers should refer to [IKEV2IANA] for the latest values.
Transform Type 4(Diffie-Hellman group)におけるTransform IDは下記である。下記はRFC4306をもとにしており、最新の値は[IKEV2IANA]にある。

Kaufman, et al. Standards Track [Page 81]

RFC 5996 IKEv2bis September 2010

Name Number Defined In
----------------------------------------
NONE 0
768-bit MODP 1 Appendix B
1024-bit MODP 2 Appendix B
1536-bit MODP 5 [ADDGROUP]
2048-bit MODP 14 [ADDGROUP]
3072-bit MODP 15 [ADDGROUP]
4096-bit MODP 16 [ADDGROUP]
6144-bit MODP 17 [ADDGROUP]
8192-bit MODP 18 [ADDGROUP]

Although ESP and AH do not directly include a Diffie-Hellman
exchange, a Diffie-Hellman group MAY be negotiated for the Child SA.
This allows the peers to employ Diffie-Hellman in the CREATE_CHILD_SA
exchange, providing perfect forward secrecy for the generated Child
SA keys.
ESP/AHはDiffie-Hellman exchangeが含まれていないが、Diffie-Hellman groupはChild SAのためにネゴシエーションされる。これは、生成されたChild SA keyにforward secrecyを提供し、CREATE_CHILD_SA exchangeにおいてpeerがDiffie-Hellmanを使うことを可能とする。

For Transform Type 5 (Extended Sequence Numbers), defined Transform
IDs are listed below. The values in the following table are only
current as of the publication date of RFC 4306. Other values may
have been added since then or will be added after the publication of
this document. Readers should refer to [IKEV2IANA] for the latest
values.
   Transform Type 5(Extended Sequence Numbers)におけるTransform IDは下記である。下記はRFC4306をもとにしており、最新の値は[IKEV2IANA]にある。

Name Number
--------------------------------------------
No Extended Sequence Numbers 0
Extended Sequence Numbers 1

Note that an initiator who supports ESNs will usually include two ESN
transforms, with values "0" and "1", in its proposals. A proposal
containing a single ESN transform with value "1" means that using
normal (non-extended) sequence numbers is not acceptable.
ESNをサポートするinitiatorは、通常、Proposalに2つのESN Transform 1、0が含まれることに注意せよ。1のESN Transformのみ含むProposalはnon-extended sequence numberを許可しないことを示す。

Numerous additional Transform Types have been defined since the
publication of RFC 4306. Please refer to the IANA IKEv2 registry for
details.
RFC 4306の発行後、多くのTransform Typeが追加された。詳細は[IKEV2IANA]参照。

3.3.3. Valid Transform Types by Protocol

The number and type of transforms that accompany an SA payload are
dependent on the protocol in the SA itself. An SA payload proposing
the establishment of an SA has the following mandatory and optional
Transform Types. A compliant implementation MUST understand all
mandatory and optional types for each protocol it supports (though it
need not accept proposals with unacceptable suites). A proposal MAY
omit the optional types if the only value for them it will accept is
NONE.
SA payloadのTrsnform Typeと数はSAのプロトコルに依存する。SAの確立を提案するSA payloadには必須/オプションのTransform Typeがある。準拠した実装では、実装がサポートするプロトコル毎の必須/オプションを識別する必要がある（許容できないsuiteのproposalは許可する必要はない）。唯一許容する値がNONEの場合、ProposalのOptional Typeを省略してよい。

Protocol Mandatory Types Optional Types
---------------------------------------------------
IKE ENCR, PRF, INTEG*, D-H
ESP ENCR, ESN INTEG, D-H
AH INTEG, ESN D-H

The specification of suites that MUST and SHOULD be supported for
interoperability has been removed from this document because they are
likely to change more rapidly than this document evolves. At the
time of publication of this document, [RFC4307] specifies these
suites, but note that it might be updated in the future, and other
RFCs might specify different sets of suites.
相互運用性とドキュメントが変化する可能性がある関係で必須のsuiteは規定しない。このドキュメント発行時点ではRFC4307に基づくsuiteを規定するが、将来更新され他のRFCの異なるsuiteが規定される可能性があることに注意せよ。。

An important lesson learned from IKEv1 is that no system should only
implement the mandatory algorithms and expect them to be the best
choice for all customers.
IKEv1から学んだ重要なことは、必須のアルゴリズムのみを実装しており、れが全ての顧客が最も期待しているというシステムはないことである。

It is likely that IANA will add additional transforms in the future,
and some users may want to use private suites, especially for IKE
where implementations should be capable of supporting different
parameters, up to certain size limits. In support of this goal, all
implementations of IKEv2 SHOULD include a management facility that
allows specification (by a user or system administrator) of Diffie-
Hellman parameters (the generator, modulus, and exponent lengths and
values) for new Diffie-Hellman groups. Implementations SHOULD
provide a management interface through which these parameters and the
associated Transform IDs may be entered (by a user or system
administrator), to enable negotiating such groups.
   IANAが将来transformを追加し、private suiteとしてユーザーが使用することができ、特定のサイズ制限内でIKEの実装はそれらのパラメータをサポートすることができる。この目的のため、IKEv2の実装では新しいDiffie-Hellman groupのDiffie-Hellman parameters(the generator, modulus, and exponent lengths and values)を設定できる（ユーザー or システム管理者により）管理機能を含めるべきである。実装ではそのようなgroupのネゴシエーションが可能なように、parameterと関連するTransform IDが入力できる（ユーザー or システム管理者から）管理インターフェースを提供するべきである。

All implementations of IKEv2 MUST include a management facility that
enables a user or system administrator to specify the suites that are
acceptable for use with IKE. Upon receipt of a payload with a set of
Transform IDs, the implementation MUST compare the transmitted
Transform IDs against those locally configured via the management
controls, to verify that the proposed suite is acceptable based on
local policy. The implementation MUST reject SA proposals that are
not authorized by these IKE suite controls. Note that cryptographic
suites that MUST be implemented need not be configured as acceptable
to local policy.
   IKEv2のすべての実装は、IKEで使用することを許容するsuiteを指定することをユーザーorシステム管理者に可能とする管理機能を含めること。Transform IDのsetのpayloadを受信すると、実装は、提案されたsuiteがローカルポリシーに基づき許可されるかを検証するため、management controlを経由してローカル設定と送信されたTransform IDを比較すること。実装は、これらのIKE suite制御によって、許容しないSAのproposalを拒絶すること。実装が必須なcryptographic suiteはローカルポリシーで許容されるように設定される必要はないことに注意せよ。

3.3.5. Transform Attributes

Each transform in a Security Association payload may include
attributes that modify or complete the specification of the
transform. The set of valid attributes depends on the transform.
Currently, only a single attribute type is defined: the Key Length
attribute is used by certain encryption transforms with variable-
length keys (see below for details).
Security Association payloadのTransformはtransformの仕様を設定/決定するAttributeを含めてよい。設定可能なAttributeはTransformによって異なる。現在一つのAttribute typeが定義されている。Key Length attributeは特定のEncryption Transfromの可変キー長を指定する(詳細は下記参照)。

The attributes are type/value pairs and are defined below.
Attributes can have a value with a fixed two-octet length or a
variable-length value. For the latter, the attribute is encoded as
type/length/value.
Attributeはtype/valueのペアで以下のように定義される。Attirubuteは2オクテットまたは可変長の値である。後者の場合、Attributeはtype/length/valueにエンコードされる。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A| Attribute Type | AF=0 Attribute Length |
|F| | AF=1 Attribute Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AF=0 Attribute Value |
| AF=1 Not Transmitted |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 9: Data Attributes

o Attribute Format (AF) (1 bit) - Indicates whether the data
attribute follows the Type/Length/Value (TLV) format or a
shortened Type/Value (TV) format. If the AF bit is zero (0), then
the attribute uses TLV format; if the AF bit is one (1), the TV
format (with two-byte value) is used.
AttibuteがType/Length/Value(TLV)か短縮形のType/Value(TV)かを示す。AFが0の場合、attributeはTLV形式を使用する。AFが1の場合、TV（2バイトvalue）を使用する。

o Attribute Type (15 bits) - Unique identifier for each type of
attribute (see below).
Attributeのtypeを識別する識別子。下記参照。

o Attribute Value (variable length) - Value of the attribute
associated with the attribute type. If the AF bit is a zero (0),
this field has a variable length defined by the Attribute Length
field. If the AF bit is a one (1), the Attribute Value has a
length of 2 octets.
Attribute typeに関連するAttributeのvalue。AF bitが0の場合、このfieldはAttribute Length filedで定義された変数長をもつ。AFが1の場合、Attirbute Valueは2オクテットである。

The only currently defined attribute type (Key Length) is fixed
length; the variable-length encoding specification is included only
for future extensions. Attributes described as fixed length MUST NOT
be encoded using the variable-length encoding unless that length
exceeds two bytes. Variable-length attributes MUST NOT be encoded as
fixed-length even if their value can fit into two octets. Note: This
is a change from IKEv1, where increased flexibility may have
simplified the composer of messages but certainly complicated the
parser.
現在、固定長のKey Lengthのみがattribute typeとして定義されている。可変長エンコーディングは今後の拡張のために含まれている。固定長として定義されるAttributeは2オクテットを超えない場合、可変長エンコーディングしないこと。可変長として定義されるAttirbuteは2オクテット内になる場合でも固定長エンコーディングしないこと。注意：これはIKEv1からの変更で、メッセージの構成に柔軟性はあるが、パースが複雑になる。

The values in the following table are only current as of the
publication date of RFC 4306. Other values may have been added since
then or will be added after the publication of this document.
Readers should refer to [IKEV2IANA] for the latest values.
下記はRFC4306発行時のものである。以降に追加された値は[IKEV2IANA]参照。

Attribute Type Value Attribute Format
------------------------------------------------------------
Key Length (in bits) 14 TV

Values 0-13 and 15-17 were used in a similar context in IKEv1, and
should not be assigned except to matching values.
0～13、15～17は同じコンテキストとしてIKEv1で使用されるため、一致する値以外には割り当てないこと。

The Key Length attribute specifies the key length in bits (MUST use
network byte order) for certain transforms as follows:
Key Length attributeは以下のように特定のTransformでkey lengthのbit長(ネットワークバイトオーダーを使用すること)を規定する。

o The Key Length attribute MUST NOT be used with transforms that use
a fixed-length key. For example, this includes ENCR_DES,
ENCR_IDEA, and all the Type 2 (Pseudorandom function) and Type 3
(Integrity Algorithm) transforms specified in this document. It
is recommended that future Type 2 or 3 transforms do not use this
attribute.
Key Length attributeは固定長のkeyを使用するTransformに使用しないこと。例えば、ENCR_DES、ENCR_IDEAとType 2(Pseudorandom function)Transfrom、Type 3(Integrity Algorith) Transfromである。将来のType 2、Type3のTransformもこのAttributeを使用しないことを推奨する。

o Some transforms specify that the Key Length attribute MUST be
always included (omitting the attribute is not allowed, and
proposals not containing it MUST be rejected). For example, this
includes ENCR_AES_CBC and ENCR_AES_CTR.
いくつかのTransformはKey Length attribtuteを常に含む(Attributeが含まれないことが許容されない場合、Proposalは拒否されること)。例えば、ENCR_AES_CBC、ENCR_AES_CTRがある。

o Some transforms allow variable-length keys, but also specify a
default key length if the attribute is not included. For example,
these transforms include ENCR_RC5 and ENCR_BLOWFISH.
いくつかのTransformは可変長キーを許可し、attributeを含まない場合、デフォルトのkey lengthを用いる。例えば、ENCR_RC5、ENCR_BLIWFISHがある。

Implementation note: To further interoperability and to support
upgrading endpoints independently, implementers of this protocol
SHOULD accept values that they deem to supply greater security. For
instance, if a peer is configured to accept a variable-length cipher
with a key length of X bits and is offered that cipher with a larger
key length, the implementation SHOULD accept the offer if it supports
use of the longer key.
Support for this capability allows a responder to express a concept
of "at least" a certain level of security -- "a key length of _at
least_ X bits for cipher Y". However, as the attribute is always
returned unchanged (see the next section), an initiator willing to
accept multiple key lengths has to include multiple transforms with
the same Transform Type, each with a different Key Length attribute.
   実装上の注意：相互運用性の向上およびエンドポイントのアップグレードを提供するため、プロトコルの実装では高いセキュリティを提供するための値を許容すること。例えば、peerがkey length X bitの可変長暗号を許容するように設定されていて、より長いキー長を要求された場合、長いキーをサポートする場合は、実装はその要求を許容するべきである。この機能の提供はresponderが最低限のsecurity levelを表すことを可能にする（暗号Yのkey lengthは最低でもX bit）。しかし、attributeは変更されずに返されるため（次のセクション参照）、複数のkey lengthを受け入れるinitiatorは、同じTransfomr Type、異なるKey Length attributeの複数のtransformを含める。

3.3.6. Attribute Negotiation

During Security Association negotiation initiators present offers to
responders. Responders MUST select a single complete set of
parameters from the offers (or reject all offers if none are
acceptable). If there are multiple proposals, the responder MUST
choose a single proposal. If the selected proposal has multiple
transforms with the same type, the responder MUST choose a single
one. Any attributes of a selected transform MUST be returned
unmodified. The initiator of an exchange MUST check that the
accepted offer is consistent with one of its proposals, and if not
MUST terminate the exchange.
Security Associationのネゴシエーション中、initiatorはresponderに要求する際。Responderは要求から、パラメータの一つを選択する(すべての要求を許容できない場合、拒否する)。複数のproposalがある場合、responderは一つのproposalを選択すること。選択されたproposalが同じtypeのtransformを複数もつ場合、responderは一つを選択すること。選択したいずれかのattibuteを変更せずに応答すること。exchangeのinitiatorは応答がinitiatorのproposalと一致しているか確認すること。一致していない場合、exchangeを終了する。

If the responder receives a proposal that contains a Transform Type
it does not understand, or a proposal that is missing a mandatory
Transform Type, it MUST consider this proposal unacceptable; however,
other proposals in the same SA payload are processed as usual.
Similarly, if the responder receives a transform that it does not
understand, or one that contains a Transform Attribute it does not
understand, it MUST consider this transform unacceptable; other
transforms with the same Transform Type are processed as usual. This
allows new Transform Types and Transform Attributes to be defined in
the future.
responderが解釈できないTransfrom Type、必須のTransform TypeのないProposalを受信した場合、Proposalは許容しないこと。ただし、同じSA payloadの他のProposalは通常通り処理される。同様にresponderは解釈できないTransform、解釈できないTransform Attributeを含むtrasnfromについても許容しないこと。ただし、同じTransform Typeをもつ他のTransformは通常通り処理されること。これは、将来、新しいTransform Type、Transform Attributeが定義されることを許容する。

Negotiating Diffie-Hellman groups presents some special challenges.
SA offers include proposed attributes and a Diffie-Hellman public
number (KE) in the same message. If in the initial exchange the
initiator offers to use one of several Diffie-Hellman groups, it
SHOULD pick the one the responder is most likely to accept and
include a KE corresponding to that group. If the responder selects a
proposal using a different Diffie-Hellman group (other than NONE),
the responder will indicate the correct group in the response and the
initiator SHOULD pick an element of that group for its KE value when
retrying the first message. It SHOULD, however, continue to propose
its full supported set of groups in order to prevent a man-in-the-
middle downgrade attack. If one of the proposals offered is for the
Diffie-Hellman group of NONE, and the responder selects that Diffie-
Hellman group, then it MUST ignore the initiator's KE payload and
omit the KE payload from the response.
Diffie-Hellman groupのネゴシエーションにはいくつかの特別な課題がある。SAの要求は同じメッセージにproposal attributeとDiffie-Hellman public number(KE)を含む。initial exchangeでinitiatorが複数のDiffie-Hellman groupから一つの使用を要求する場合、initiatorはresponderがそれを選ぶようにKEに対応するgroupを含める。responderが異なるDiffie-Hellman group (NONEを除く)を選択する場合、responderは適切なgroupをresponseで示し、initiatorはそのgroupをKEに選択し、最初のメッセージを再試行する。ただし、initiatorはman-in-the-middle downgrade attackを防ぐためにgroupのフルセットをproposeし続けること。要求された一つがDiffie-Hellman group NONEであり、responderがそのDiffie-Hellman groupを選択した場合、responderはinitiatorのKE payloadを無視し、initiatorは応答のKE paylaodを切り捨てること。

3.4. Key Exchange Payload

The Key Exchange payload, denoted KE in this document, is used to
exchange Diffie-Hellman public numbers as part of a Diffie-Hellman
key exchange. The Key Exchange payload consists of the IKE generic
payload header followed by the Diffie-Hellman public value itself.
Key Exchange payloadはKEと表記され、Diffie-Hellman鍵交換の一部として、Diffie-Hellman public numberを交換するために使用される。Key Exchange paloadはIKE generic payloadとDiffie-Hellman public valueで構成される。

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload |C| RESERVED | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Diffie-Hellman Group Num | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Key Exchange Data ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 10: Key Exchange Payload Format

A Key Exchange payload is constructed by copying one's Diffie-Hellman
public value into the "Key Exchange Data" portion of the payload.
The length of the Diffie-Hellman public value for modular
exponentiation group (MODP) groups MUST be equal to the length of the
prime modulus over which the exponentiation was performed, prepending
zero bits to the value if necessary.
Key Exchange payloadはpayloadのKey Exchange DataにDiffie-Hellman public valueを設定する。(modular exponentiation group)MODP groupのDiffie-Hellman public valueの値はprime module(素数)と同じ長さであること。必要であれば0で埋めること。

The Diffie-Hellman Group Num identifies the Diffie-Hellman group in
which the Key Exchange Data was computed (see Section 3.3.2). This
Diffie-Hellman Group Num MUST match a Diffie-Hellman group specified
in a proposal in the SA payload that is sent in the same message, and
SHOULD match the Diffie-Hellman group in the first group in the first
proposal, if such exists. If none of the proposals in that SA
payload specifies a Diffie-Hellman group, the KE payload MUST NOT be
present. If the selected proposal uses a different Diffie-Hellman
group (other than NONE), the message MUST be rejected with a Notify
payload of type INVALID_KE_PAYLOAD. See also Sections 1.2 and 2.7.
Diffie-Hellman Group NumはKey Exchange Dataが算出されるDiffie-Hellman groupを識別する（Section 3.3.2参照）。Diffie-Hellman Group Numは同じメッセージで送信されたSA payloadのproposalで規定されたDiffie-Hellman groupと一致すること。さらに、最初proposalと一致すること。SA payloadでDiffie-Hellman groupがporoposalされない場合、KE payloadを提供しないこと。選択されたproposalが異なるdifferent Diffie-Hellman group (NONE以外)の場合、messageはINVALID_KE_PAYLOADでrejectすること。Section 1.2と2.7参照。

The payload type for the Key Exchange payload is thirty-four (34).
Key Exchange payloadのpayload typeは34である。

3.5. Identification Payloads

The Identification payloads, denoted IDi and IDr in this document,
allow peers to assert an identity to one another. This identity may
be used for policy lookup, but does not necessarily have to match
anything in the CERT payload; both fields may be used by an
implementation to perform access control decisions. When using the
ID_IPV4_ADDR/ID_IPV6_ADDR identity types in IDi/IDr payloads, IKEv2
does not require this address to match the address in the IP header
of IKEv2 packets, or anything in the TSi/TSr payloads. The contents
of IDi/IDr are used purely to fetch the policy and authentication
data related to the other party.
Identification PayloadはIDi、IDrと表現され、peerが相互に他方にIDを通知するために使用する。このIDはpolicy検索に使用できるが、CERT payloadとマッチする必要はない。両方のfieldはアクセス制御の決定をするために実装で使用される。IDi/IDr paylaodでID_IPV4_ADDR/ID_IPV6_ADDR identity typesを使用する場合、IKEv2ではIKEv2のIP headerアドレスまたはTSi/TSr paylaodと一致することを必要としない。IDi/IDrは相手のpolicyと認証データを照会するために使用される。

NOTE: In IKEv1, two ID payloads were used in each direction to hold
Traffic Selector (TS) information for data passing over the SA. In
IKEv2, this information is carried in TS payloads (see Section 3.13).
NOTE: IKEv1では2つのID payloadが各方向でSA上でデータを通過させるためのTraffic Selector情報を保持するために使われる。IKEv2ではこの情報はTS payloadで設定される(Section 3.13)。

The Peer Authorization Database (PAD) as described in RFC 4301
[IPSECARCH] describes the use of the ID payload in IKEv2 and provides
a formal model for the binding of identity to policy in addition to
providing services that deal more specifically with the details of
policy enforcement. The PAD is intended to provide a link between
the SPD and the IKE Security Association management. See Section
4.4.3 of RFC 4301 for more details.
RFC 4301[IPSECARCH]にあるように、Peer Authorization Database(PAD)はIKEのID payloadの使用方法とpolicyの適用方法を具体化するための形式的なモデルを提供する。PADはSPDとIKE Security Association managementとのリンクを提供する。詳細はRFC 4301 Section 4.4.3を参照。

The Identification payload consists of the IKE generic payload header
followed by identification fields as follows:
Identification payloadはIKE generic paylaod headerと下記のidentification fieldで構成される。

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload |C| RESERVED | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ID Type | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Identification Data ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 11: Identification Payload Format

o ID Type (1 octet) - Specifies the type of Identification being
used.
Identificationのtypeを規定する。

o RESERVED - MUST be sent as zero; MUST be ignored on receipt.
0を設定し、受信者は無視すること。

o Identification Data (variable length) - Value, as indicated by the
Identification Type. The length of the Identification Data is
computed from the size in the ID payload header.
Identification Typeで規定される値。Identification DataのlengthはID paylaod header内のsizeから計算される。

The payload types for the Identification payload are thirty-five (35)
for IDi and thirty-six (36) for IDr.
Identificatin paylaodのpayload typeはIDiが35、IDrが36である。

The following table lists the assigned semantics for the
Identification Type field. The values in the following table are
only current as of the publication date of RFC 4306. Other values
may have been added since then or will be added after the publication
of this document. Readers should refer to [IKEV2IANA] for the latest
values.
下記の表はIdentification Type filedに割り当てられたセマンティクスである。最新の情報は[IKEV2IANA]参照。下記の表はRFC4306発行時のものである。その他の値が追加される可能性もある。最新の情報は[IKEV2IANA]参照。

ID Type Value
-------------------------------------------------------------------
ID_IPV4_ADDR 1
A single four (4) octet IPv4 address.
4オクテットのIPv4アドレス。

ID_FQDN 2
A fully-qualified domain name string. An example of an ID_FQDN
is "example.com". The string MUST NOT contain any terminators
(e.g., NULL, CR, etc.). All characters in the ID_FQDN are ASCII;
for an "internationalized domain name", the syntax is as defined
in [IDNA], for example "xn--tmonesimerkki-bfbb.example.net".
FQDMの文字列。ID_FQDNの例は"example.com"である。文字列はNULL、CRなどで終端しないこと。ID_FQDNの文字はすべてASCIIである。[IDNA]で定義されたinternationalized domain nameで例えばxn--tmonesimerkki-bfbb.example.netである。

ID_RFC822_ADDR 3
A fully-qualified RFC 822 email address string. An example of a
ID_RFC822_ADDR is "jsmith@example.com". The string MUST NOT
contain any terminators. Because of [EAI], implementations would
be wise to treat this field as UTF-8 encoded text, not as
pure ASCII.
完全修飾のRFC 822のemail addressの文字列。ID_RFC822_ADDRの例はjsmith@example.comである。文字列には終端を含まないこと。[EAI]により実装ではASCIIではなくUTF-8 encoded textとして扱ったほうがよい。

ID_IPV6_ADDR 5
A single sixteen (16) octet IPv6 address.
16オクテットのIPv6アドレス。

ID_DER_ASN1_DN 9
The binary Distinguished Encoding Rules (DER) encoding of an
ASN.1 X.500 Distinguished Name [PKIX].
ASN.1 X.500[PKIX]のバイナリDER encoding。

ID_DER_ASN1_GN 10
The binary DER encoding of an ASN.1 X.509 GeneralName [PKIX].
ASN.1 X.509[PKIX]のバイナリDER encoding。

ID_KEY_ID 11
An opaque octet stream that may be used to pass vendor-
specific information necessary to do certain proprietary
types of identification.
オクテット列でベンダー仕様の独自のID typeを渡すために使用してよい。

Two implementations will interoperate only if each can generate a
type of ID acceptable to the other. To assure maximum
interoperability, implementations MUST be configurable to send at
least one of ID_IPV4_ADDR, ID_FQDN, ID_RFC822_ADDR, or ID_KEY_ID, and
MUST be configurable to accept all of these four types.
Implementations SHOULD be capable of generating and accepting all of
these types. IPv6-capable implementations MUST additionally be
configurable to accept ID_IPV6_ADDR. IPv6-only implementations MAY
be configurable to send only ID_IPV6_ADDR instead of ID_IPV4_ADDR for
IP addresses.
お互いが他方が許容できるIDタイプを生成できる場合、2つの実装（2種類のID）が相互運用する。最大の相互運用性を保証するためには、実装はID_IPV4_ADDR, ID_FQDN, ID_RFC822_ADDR, or ID_KEY_IDの少なくとも一つを送信し、4つのどのタイプでも許容できることが可能であること。実装は全てのタイプを生成でき、許容できること。IPv6に対応した実装ではID_IPV6_ADDRを許容できること。IPv6のみの実装ではID_IPV4_ADDRの代わりにID_IPV6_ADDRのみを送信してもよい。

EAP [EAP] does not mandate the use of any particular type of
identifier, but often EAP is used with Network Access Identifiers
(NAIs) defined in [NAI]. Although NAIs look a bit like email
addresses (e.g., "joe@example.com"), the syntax is not exactly the
same as the syntax of email address in [MAILFORMAT]. For those NAIs
that include the realm component, the ID_RFC822_ADDR identification
type SHOULD be used. Responder implementations should not attempt to
verify that the contents actually conform to the exact syntax given
in [MAILFORMAT], but instead should accept any reasonable-looking
NAI. For NAIs that do not include the realm component, the ID_KEY_ID
identification type SHOULD be used.
EAPは特定のIDタイプを指定しないが、たいてい[NAI]で定義されたNetwork Access Identifiers(NAI)が使用される。NAIはemail addressのように見えるが（例：joe@example.com）、構文は[MAILFORMAT]とは厳密には同じではない。realmを含むNAIはID_RFC822_ADDRのIDタイプを使用すること。responderの実装は、[MAILFORMAT]によるチェックではなく、NAIの定義によりチェックすること。NAIがrealmを含まない場合、ID_KEY_ID identification typeを使用すること。

3.6. Certificate Payload

The Certificate payload, denoted CERT in this document, provides a
means to transport certificates or other authentication-related
information via IKE. Certificate payloads SHOULD be included in an
exchange if certificates are available to the sender. The Hash and
URL formats of the Certificate payloads should be used in case the
peer has indicated an ability to retrieve this information from
elsewhere using an HTTP_CERT_LOOKUP_SUPPORTED Notify payload. Note
that the term "Certificate payload" is somewhat misleading, because
not all authentication mechanisms use certificates and data other
than certificates may be passed in this payload.
Certificate payload はCERTと表記され、IKEによる証明書や認証関連情報の転送を提供する。証明書を送信者が利用する場合、Certificate payloadがexchangeに含まれること。peerがHTTP_CERT_LOOKUP_SUPPORTED Notify payloadを使用し、この情報を取得する能力を通知してから、Certificate payloadのHash and URL formatが使用されること。"Certificate payload"は誤解を招くのに注意せよ。なぜなら、すべての認証メカニズムが証明書を使用するとは限らず、証明書以外のデータも送信されるため。

The Certificate payload is defined as follows:
Certificate 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload |C| RESERVED | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cert Encoding | |
+-+-+-+-+-+-+-+-+ |
~ Certificate Data ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 12: Certificate Payload Format

o Certificate Encoding (1 octet) - This field indicates the type of
certificate or certificate-related information contained in the
Certificate Data field. The values in the following table are
only current as of the publication date of RFC 4306. Other values
may have been added since then or will be added after the
publication of this document. Readers should refer to [IKEV2IANA]
for the latest values.
このfieldはCertificate Data fieldに含まれる証明書または証明書関連情報のtypeを示す。下記の値および以降に追加されてた値が設定される。下記はRFC4306発行時のものである。以降に追加された値は[IKEV2IANA]参照。

Certificate Encoding Value
----------------------------------------------------
PKCS #7 wrapped X.509 certificate 1 UNSPECIFIED
PGP Certificate 2 UNSPECIFIED
DNS Signed Key 3 UNSPECIFIED
X.509 Certificate - Signature 4
Kerberos Token 6 UNSPECIFIED
Certificate Revocation List (CRL) 7
Authority Revocation List (ARL) 8 UNSPECIFIED
SPKI Certificate 9 UNSPECIFIED
X.509 Certificate - Attribute 10 UNSPECIFIED
Raw RSA Key 11
Hash and URL of X.509 certificate 12
Hash and URL of X.509 bundle 13

o Certificate Data (variable length) - Actual encoding of
certificate data. The type of certificate is indicated by the
Certificate Encoding field.
証明書データのencoding。証明書のtypeはCertificate Encoding fieldで示される。

The payload type for the Certificate payload is thirty-seven (37).
Certificate payloadのpayload typeは37である。

Specific syntax for some of the certificate type codes above is not
defined in this document. The types whose syntax is defined in this
document are:
上記の証明書 type codeのすべてのシンタックスは本ドキュメントでは規定しない。本ドキュメントでは下記のtypeのシンタックスを定義する。

o "X.509 Certificate - Signature" contains a DER-encoded X.509
certificate whose public key is used to validate the sender's AUTH
payload. Note that with this encoding, if a chain of certificates
needs to be sent, multiple CERT payloads are used, only the first
of which holds the public key used to validate the sender's AUTH
payload.
"X.509 Certificate - Signature"は、送信者のAUTH payloadを検証するために使用されるpublic keyの DER-encoded X.509証明書が含まれる。エンコーディングは、証明書チェーンを送信する必要がある場合、複数のCERT payloadが使用され、最初のpayloadだけ送信者のAUTH payloadを検証するために使用されるpublic keyを含む。

o "Certificate Revocation List" contains a DER-encoded X.509
certificate revocation list.
"Certificate Revocation List"はDER-encoded X.509の証明書の失効リストが含まれる。

o "Raw RSA Key" contains a PKCS #1 encoded RSA key, that is, a DER-
encoded RSAPublicKey structure (see [RSA] and [PKCS1]).
"Raw RSA Key"はPKCS #1 encoded RSA keyつまり、DER-encoded RSAPublicKey structureが含まれる（[RSA]、[PKCS1]参照）。

o Hash and URL encodings allow IKE messages to remain short by
replacing long data structures with a 20-octet SHA-1 hash (see
[SHA]) of the replaced value followed by a variable-length URL
that resolves to the DER-encoded data structure itself. This
improves efficiency when the endpoints have certificate data
cached and makes IKE less subject to DoS attacks that become
easier to mount when IKE messages are large enough to require IP
fragmentation [DOSUDPPROT].
Hash and URL encodingにより、長いdata structuresをDER-encoded data structureに対応する可変長URLに続く20-octet SHA-1 hashに置き換えることで、IKE messageを短くすることができる。これにより、証明書データがキャッシュされているときの効率化と、IP fragmentを利用したDoS攻撃の防止になる[DOSUDPPROT]。

The "Hash and URL of a bundle" type uses the following ASN.1
definition for the X.509 bundle:
"Hash and URL of a bundle" typeは下記のX.509 bundleのASN.1定義を使用する。

CertBundle
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-cert-bundle(34) }

DEFINITIONS EXPLICIT TAGS ::=
BEGIN

IMPORTS
Certificate, CertificateList
FROM PKIX1Explicit88
{ iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7)
id-mod(0) id-pkix1-explicit(18) } ;

CertificateOrCRL ::= CHOICE {
cert [0] Certificate,
crl [1] CertificateList }

CertificateBundle ::= SEQUENCE OF CertificateOrCRL

END

Implementations MUST be capable of being configured to send and
accept up to four X.509 certificates in support of authentication,
and also MUST be capable of being configured to send and accept the
Hash and URL format (with HTTP URLs). Implementations SHOULD be
capable of being configured to send and accept Raw RSA keys. If
multiple certificates are sent, the first certificate MUST contain
the public key used to sign the AUTH payload. The other certificates
may be sent in any order.
実装は認証をサポートする4つのX.509証明書の送受信が構成できること。また、Hash and URL formatの送受信が構成できること。実装はRaw RSA keyの送受信を構成できること。複数の証明書を送信する場合、最初の証明書はAUTH payloadの署名に使用するpublic keyを含めること。その他の証明書は任意の順番で送信してよい。

Implementations MUST support the HTTP [HTTP] method for hash-and-URL
lookup. The behavior of other URL methods [URLS] is not currently
specified, and such methods SHOULD NOT be used in the absence of a
document specifying them.
実装は、hash-and-URL lookupのためのHTTP methodをサポートすること。他のURL method[URLS]は現在規定されず、そのようなmethodはそれらを規定するドキュメントが存在しない場合に使用しないこと。

3.7. Certificate Request Payload

The Certificate Request payload, denoted CERTREQ in this document,
provides a means to request preferred certificates via IKE and can
appear in the IKE_INIT_SA response and/or the IKE_AUTH request.
Certificate Request payloads MAY be included in an exchange when the
sender needs to get the certificate of the receiver.
Certificate Request payloadはCERTREQと表記され、IKEで証明書を要求する手段を提供し、IKE_INIT_SA responseとIKE_AUTH requestで送信される。Certificate Request payloadは、送信者が受信者の証明書を取得する必要がある場合、Certificate Request payloadがexchangeに含まれてよい。

The Certificate Request payload is defined as follows:
Certificate Request 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload |C| RESERVED | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cert Encoding | |
+-+-+-+-+-+-+-+-+ |
~ Certification Authority ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 13: Certificate Request Payload Format

o Certificate Encoding (1 octet) - Contains an encoding of the type
or format of certificate requested. Values are listed in
Section 3.6.
要求された証明書の種類、encoding typeが含まれる。値のリストはSection 3.6参照。

o Certification Authority (variable length) - Contains an encoding
of an acceptable certification authority for the type of
certificate requested.
要求された証明書のタイプの認証局のencodingが含まれる。

The payload type for the Certificate Request payload is thirty-eight
(38).
Certificate Request payloadのpaylaod typeは38である。

The Certificate Encoding field has the same values as those defined
in Section 3.6. The Certification Authority field contains an
indicator of trusted authorities for this certificate type. The
Certification Authority value is a concatenated list of SHA-1 hashes
of the public keys of trusted Certification Authorities (CAs). Each
is encoded as the SHA-1 hash of the Subject Public Key Info element
(see section 4.1.2.7 of [PKIX]) from each Trust Anchor certificate.
The 20-octet hashes are concatenated and included with no other
formatting.
Certificate Encoding fieldはSection 3.6の定義と同じ値である。Certification Authority fieldは証明書typeの認証局のindicatorが含まれる。Certification Authority valueは、認証局(CA)のpublic keyのSHA-1ハッシュの連結リストである。それぞれが、Subject Public Key Info element(see section 4.1.2.7 of [PKIX])のSHA-1ハッシュとしてそれぞれのTrust Anchor certificateからencodeされる。20-octetのハッシュには他のフォーマットが連結されず、含まれない。

The contents of the "Certification Authority" field are defined only
for X.509 certificates, which are types 4, 12, and 13. Other values
SHOULD NOT be used until Standards-Track specifications that specify
their use are published.
"Certification Authority" fieldの内容はX.509証明書のみ定義され、typeは4、12、13である。他の値は他の値を規定する仕様が公開されるまで使用しないこと。

Kaufman, et al. Standards Track [Page 93]

RFC 5996 IKEv2bis September 2010

Note that the term "Certificate Request" is somewhat misleading, in
that values other than certificates are defined in a "Certificate"
payload and requests for those values can be present in a Certificate
Request payload. The syntax of the Certificate Request payload in
such cases is not defined in this document.
"Certificate Request"は誤解を招くことに注意せよ。"Certificate" payloadに証明書以外の値が定義され、Certificate Request payloadによりそれらの値が要求される場合がある。それらの場合におけるCertificate Request payloadのsyntaxはこのドキュメントでは定義されない。

The Certificate Request payload is processed by inspecting the "Cert
Encoding" field to determine whether the processor has any
certificates of this type. If so, the "Certification Authority"
field is inspected to determine if the processor has any certificates
that can be validated up to one of the specified certification
authorities. This can be a chain of certificates.
Certificate Request payloadはprocessorがどのタイプの証明書を持っているかを"Cert Encoding" fieldを検証して処理する。"Certification Authority" fieldは認証局を検証できる証明書を持っているか判断するために検証される。これは証明書チェーンをすることができる。

If an end-entity certificate exists that satisfies the criteria
specified in the CERTREQ, a certificate or certificate chain SHOULD
be sent back to the certificate requestor if the recipient of the
CERTREQ:
CERTREQの条件を満たすend-entity証明書が存在する場合、CERTREQの受信者は証明書または証明書チェーンを証明書の要求者に送信すること。

o is configured to use certificate authentication,
証明書認証を使用することが設定されている。

o is allowed to send a CERT payload,
CERT payloadの送信が許容される。

o has matching CA trust policy governing the current negotiation,
and
ネゴシエーション中のCA trust policyに一致する。

o has at least one time-wise and usage-appropriate end-entity
certificate chaining to a CA provided in the CERTREQ.
CERTREQ内のCAに提供された使用可能なend-entity証明書チェーンがある。

Certificate revocation checking must be considered during the
chaining process used to select a certificate. Note that even if two
peers are configured to use two different CAs, cross-certification
relationships should be supported by appropriate selection logic.
証明書の失効チェックは証明書を選択するために使用されるチェーン処理中に考慮されること。2つのpeerが2つの異なるCAを使うように構成されている場合、cross-certification relationshipがselection logicによってサポートされることに注意せよ。

The intent is not to prevent communication through the strict
adherence of selection of a certificate based on CERTREQ, when an
alternate certificate could be selected by the sender that would
still enable the recipient to successfully validate and trust it
through trust conveyed by cross-certification, CRLs, or other out-of-
band configured means. Thus, the processing of a CERTREQ should be
seen as a suggestion for a certificate to select, not a mandated one.
If no certificates exist, then the CERTREQ is ignored. This is not
an error condition of the protocol. There may be cases where there
is a preferred CA sent in the CERTREQ, but an alternate might be
acceptable (perhaps after prompting a human operator).
CERTREQの処理は、証明書の取得命令ではなく選択の提案としてみなされる。証明書が存在しない場合、CERTREQは無視される。これはprotocolエラー状態ではない。CERTREQのCAよりよいCAがあるが、代替が許容される場合がある（オペレーターが指定した場合）。

The HTTP_CERT_LOOKUP_SUPPORTED notification MAY be included in any
message that can include a CERTREQ payload and indicates that the
sender is capable of looking up certificates based on an HTTP-based
URL (and hence presumably would prefer to receive certificate
specifications in that format).
HTTP_CERT_LOOKUP_SUPPORTED notificationがCERTREQ payloadを含む任意のメッセージに含まれてよく、送信者がHTTP-based URLによる証明書のlook upができることを示す（つまり、その形式の証明書を受信することを望んでいる）。

3.8. Authentication Payload

The Authentication payload, denoted AUTH in this document, contains
data used for authentication purposes. The syntax of the
Authentication data varies according to the Auth Method as specified
below.
Authentication payloadはAUTHと表記され、認証に使用されるデータが含まれる。Authentication dataの構文は下記に示すように認証方法によって異なる。

The Authentication payload is defined as follows:
Authentication 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload |C| RESERVED | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Auth Method | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Authentication Data ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 14: Authentication Payload Format

o Auth Method (1 octet) - Specifies the method of authentication
used. The types of signatures are listed here. The values in the
following table are only current as of the publication date of RFC
4306. Other values may have been added since then or will be
added after the publication of this document. Readers should
refer to [IKEV2IANA] for the latest values.
使用される認証方法を規定する。署名の種類は下記の通り。この値はRFC4306のものである。最新の値は[IKEV2IANA]を参照。

Mechanism Value
-----------------------------------------------------------------
RSA Digital Signature 1
Computed as specified in Section 2.15 using an RSA private key
with RSASSA-PKCS1-v1_5 signature scheme specified in [PKCS1]
(implementers should note that IKEv1 used a different method for
RSA signatures). To promote interoperability, implementations
that support this type SHOULD support signatures that use SHA-1
as the hash function and SHOULD use SHA-1 as the default hash
function when generating signatures. Implementations can use the
certificates received from a given peer as a hint for selecting a
mutually understood hash function for the AUTH payload signature.
[PKCS1]で規定されたRSASSA-PKCS1-v1_5 signature schemeのRSA秘密鍵を使用してSection 2.15で規定された方法で計算される。（実装は、IKEv1ではRSA signatureのために別のmethodを使用したことに注意せよ。）
相互運用性の保証のため、このタイプの署名をサポートする実装では、ハッシュ関数としてSHA-1を使用してsignatureを生成するときはデフォルトのハッシュ関数としてSHA-1を使用するsignatureをサポートすること。実装は、相互にAUTH payload署名のハッシュ関数を特定し、選択するためにpeerから受信した証明書を使用できる。

Note, however, that the hash algorithm used in the AUTH payload
signature doesn't have to be the same as any hash algorithm(s)
used in the certificate(s).
AUTH paylaodのsignatureに使用されるハッシュアルゴリズムは証明書で使用されるハッシュアルゴリズムと同じである必要はない。

Shared Key Message Integrity Code 2
Computed as specified in Section 2.15 using the shared key
associated with the identity in the ID payload and the negotiated
PRF.
           ID payloadのidentityと関連付けられるshared keyとネゴシエーションされたPRFを使用し、Section 2.15で規定された方法で計算される。

DSS Digital Signature 3
Computed as specified in Section 2.15 using a DSS private key
(see [DSS]) over a SHA-1 hash.
SHA-1ハッシュのDSS秘密鍵を使用してSection 2.15の方法で計算される。([DSS]参照)

o Authentication Data (variable length) - see Section 2.15.
Section 2.15参照。

The payload type for the Authentication payload is thirty-nine (39).
   Authentication payloadのpayload typeは39である。

3.9. Nonce Payload

The Nonce payload, denoted as Ni and Nr in this document for the
initiator's and responder's nonce, respectively, contains random data
used to guarantee liveness during an exchange and protect against
replay attacks.
Nonce payloadはNi/Nrと表現され、replay攻撃に対する保護のためと、echangeの間の生存性を保証するためのランダムデータを含む。

The Nonce payload is defined as follows:
Nonce 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload |C| RESERVED | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Nonce Data ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 15: Nonce Payload Format

o Nonce Data (variable length) - Contains the random data generated
by the transmitting entity.
送信エンティティによって生成されたランダムデータが含まれる。

The payload type for the Nonce payload is forty (40).
Nonce payloadのpayload typeは40である。

The size of the Nonce Data MUST be between 16 and 256 octets,
inclusive. Nonce values MUST NOT be reused.
Nonce Dataは16～256オクテットであること。Nonce valueは再利用しないこと。

3.10. Notify Payload

The Notify payload, denoted N in this document, is used to transmit
informational data, such as error conditions and state transitions,
to an IKE peer. A Notify payload may appear in a response message
(usually specifying why a request was rejected), in an INFORMATIONAL
Exchange (to report an error not in an IKE request), or in any other
message to indicate sender capabilities or to modify the meaning of
the request.
Notify payload（Nと表記される）はIKE peerにエラー状態や状態遷移などの情報データを送信するために使用される。Notify payloadは応答メッセージ(通常はrequestを拒否した理由を示す)、INFORMATIONAL Exchange(IKE requestでないエラーの報告)、送信者の機能、requestの意味(meaning)の変更に使用される。

The Notify payload is defined as follows:
Notify 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload |C| RESERVED | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol ID | SPI Size | Notify Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Security Parameter Index (SPI) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Notification Data ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 16: Notify Payload Format

o Protocol ID (1 octet) - If this notification concerns an existing
SA whose SPI is given in the SPI field, this field indicates the
type of that SA. For notifications concerning Child SAs, this
field MUST contain either (2) to indicate AH or (3) to indicate
ESP. Of the notifications defined in this document, the SPI is
included only with INVALID_SELECTORS and REKEY_SA. If the SPI
field is empty, this field MUST be sent as zero and MUST be
ignored on receipt.
このnotificationがSPI fieldで示されるSPIをもつ既存のSAに関係する場合、このfiledはSAの種類を示す。Child SAに関するnotificationの場合、このfiledはAH(2)かESP(3)であること。このドキュメントで定義されたnotificationの中で、SPIはINVALID_SELECTORS、REKEY_SAにのみ含まれる。SPI filedが空の場合、このfiledは0で送信され、受信者はそれを無視すること。

o SPI Size (1 octet) - Length in octets of the SPI as defined by the
IPsec protocol ID or zero if no SPI is applicable. For a
notification concerning the IKE SA, the SPI Size MUST be zero and
the field must be empty.
IPsec protocol IDで定義されたSPIのオクテット長。SPIが有効でない場合は0。IKE SAに関するnotificationは、SPI Sizeは0であり、field（SPI field:variable lengthのこと）は空であること。

o Notify Message Type (2 octets) - Specifies the type of
notification message.
           notification messageのタイプを指定する。

o SPI (variable length) - Security Parameter Index.
Security Parameter Index(SPI)。

o Notification Data (variable length) - Status or error data
transmitted in addition to the Notify Message Type. Values for
this field are type specific (see below).
Statusまたはerror dataがNotify Message Typeに加えて送信される。このfieldの値はtypeによって決まる(下記参照)。

The payload type for the Notify payload is forty-one (41).
Notify payloadのpaylaod typeは41である。

「RFC5996(IKEv2)_3」をウィキ内検索

最終更新：2015年10月11日 22:52

今日	- 人
昨日	- 人
合計	- 人

Codeまとめby長谷川

メニュー

リンク

他のサービス

カウンター

更新履歴

RFC5996(IKEv2)_3