メインコンテンツまでスキップ

3.5 Identification Payloads (識別ペイロード)

3.5 Identification Payloads (識別ペイロード)​

Identification ペイロードは本文書では IDi と IDr と記し, ピア同士が身元を主張するために用いる. ポリシー検索に使われてもよいが CERT の内容と一致する必要はない. 実装は両方をアクセス制御に使ってもよい. ID_IPV4_ADDR/ID_IPV6_ADDR を IDi/IDr で使う場合, IKEv2 は IKE パケットの IP ヘッダや TSi/TSr のアドレスと一致を要求しない. IDi/IDr の内容は相手に関するポリシーと認証データを取得するためだけに用いられる.

注: IKEv1 では各方向に 2 つの ID ペイロードがあり SA 上のデータ用 TS 情報を運んだ. IKEv2 では TS ペイロードがこれを担う (第 3.13 節).

RFC 4301 [IPSECARCH] の PAD (Peer Authorization Database) は IKEv2 における ID の使い方を述べ, 身元とポリシーの束縛の形式モデルを与える. PAD は SPD と IKE SA 管理を結ぶ. RFC 4301 の 4.4.3 節参照.

Identification ペイロードは汎用ヘッダの後に次のフィールドが続く.

                        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

  • ID Type (1 オクテット) - 識別の種類.

  • RESERVED - 送信時ゼロ (MUST), 受信時無視 (MUST).

  • Identification Data (可変長) - ID Type に従う値. 長さはペイロードヘッダから求める.

ペイロード型: IDi は 35, IDr は 36.

Identification Type の意味は下表. RFC 4306 時点. 最新は [IKEV2IANA].

ID TypeValue
ID_IPV4_ADDR1
ID_FQDN2
ID_RFC822_ADDR3
ID_IPV6_ADDR5
ID_DER_ASN1_DN9
ID_DER_ASN1_GN10
ID_KEY_ID11

  • ID_IPV4_ADDR - 4 オクテットの IPv4 アドレス 1 つ.

  • ID_FQDN - 完全修飾ドメイン名. 例 "example.com". NULL や CR などの終端を含んではならない (MUST NOT). 文字は ASCII. 国際化ドメイン名は [IDNA], 例 "xn--tmonesimerkki-bfbb.example.net".

  • ID_RFC822_ADDR - RFC 822 形式のメール. 例 "[email protected]". 終端なし. [EAI] により UTF-8 テキストとして扱うことが望ましい.

  • ID_IPV6_ADDR - 16 オクテットの IPv6 アドレス 1 つ.

  • ID_DER_ASN1_DN - ASN.1 X.500 DN [PKIX] の DER 符号化.

  • ID_DER_ASN1_GN - ASN.1 X.509 GeneralName [PKIX] の DER 符号化.

  • ID_KEY_ID - 不透明オクテット列. ベンダ固有の識別情報に用いる.

相互運用には双方が相手の受け入れ可能な ID 型を生成できることが必要である. 最大の相互運用のため, 実装は ID_IPV4_ADDR, ID_FQDN, ID_RFC822_ADDR, ID_KEY_ID の少なくとも 1 つを送るよう設定できなければならない (MUST), 4 つすべてを受け入れるよう設定できなければならない (MUST). これらすべてを生成・受信できることが望ましい (SHOULD). IPv6 対応実装はさらに ID_IPV6_ADDR を受け入れる設定ができなければならない (MUST). IPv6 のみの実装は IP アドレスとして ID_IPV4_ADDR の代わりに ID_IPV6_ADDR のみ送るよう設定してもよい (MAY).

EAP [EAP] は特定の識別子型を強制しないが, しばしば [NAI] の NAI と共に用いられる. NAI はメールに似るが [MAILFORMAT] のメールとは厳密に同じでない. realm を含む NAI には ID_RFC822_ADDR を使うべきである (SHOULD). 応答者は [MAILFORMAT] の厳密検証ではなく, 妥当な見た目の NAI を受け入れるべきである. realm がない NAI には ID_KEY_ID を使うべきである (SHOULD).

識別ペイロードと PKIX 証明書の対応は [RFC4945] を参照.

に最終更新