跳到主要内容

3.5 Identification Payloads (标识载荷)

3.5 Identification Payloads (标识载荷)​

Identification 载荷在本文档中记为 IDi 与 IDr, 使对等方能向对方声明身份. 该身份可用于策略查找, 但不必与 CERT 载荷中的内容一致; 实现可将两个字段都用于访问控制决策. 在 IDi/IDr 中使用 ID_IPV4_ADDR/ID_IPV6_ADDR 身份类型时, IKEv2 不要求该地址与 IKEv2 分组的 IP 首部地址或 TSi/TSr 载荷中的任何内容一致. IDi/IDr 的内容纯粹用于获取与对方相关的策略与认证数据.

注意: 在 IKEv1 中, 每个方向使用两个 ID 载荷承载经 SA 传输数据的流量选择器 (TS) 信息. 在 IKEv2 中, 此类信息由 TS 载荷携带 (见第 3.13 节).

RFC 4301 [IPSECARCH] 所述的对等授权数据库 (Peer Authorization Database, PAD) 说明了 IKEv2 中 ID 载荷的用法, 并给出身份与策略绑定的形式化模型, 以及更具体涉及策略执行细节的服务. PAD 旨在连接 SPD 与 IKE 安全关联管理. 更多内容见 RFC 4301 第 4.4.3 节.

Identification 载荷由 IKE 通用载荷首部及下列标识字段组成:

                        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 - 发送时必须为 0; 接收时必须忽略.

  • Identification Data (变长) - 由标识类型决定的取值. 长度由 ID 载荷首部中的尺寸推算.

Identification 载荷的载荷类型编号: 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 地址.

  • ID_FQDN - 完全限定域名 (FQDN) 字符串. ID_FQDN 示例为 "example.com". 字符串不得包含任何终结符 (如 NULL, CR 等). ID_FQDN 中字符均为 ASCII; 对 "国际化域名", 语法见 [IDNA], 例如 "xn--tmonesimerkki-bfbb.example.net".

  • ID_RFC822_ADDR - 完全限定的 RFC 822 电子邮件地址字符串. 示例为 "[email protected]". 字符串不得包含终结符. 鉴于 [EAI], 实现宜将本字段视为 UTF-8 文本, 而非纯 ASCII.

  • ID_IPV6_ADDR - 单个十六 (16) 字节 IPv6 地址.

  • ID_DER_ASN1_DN - ASN.1 X.500 可分辨名 [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 之一, 且必须可配置为接受上述四种类型全部. 实现应该能够生成并接受所有这些类型. 支持 IPv6 的实现还必须可配置为接受 ID_IPV6_ADDR. 纯 IPv6 实现可以配置为对 IP 地址仅发送 ID_IPV6_ADDR 而不发送 ID_IPV4_ADDR.

EAP [EAP] 不强制使用特定标识符类型, 但常与 [NAI] 定义的网络接入标识符 (NAI) 一起使用. 尽管 NAI 形似电子邮件地址 (如 "[email protected]"), 其语法与 [MAILFORMAT] 中的电子邮件地址并不完全相同. 对包含 realm 分量的 NAI, 应该使用 ID_RFC822_ADDR 标识类型. 响应方实现不应试图验证内容严格符合 [MAILFORMAT] 的语法, 而应接受任何外观合理的 NAI. 对不含 realm 分量的 NAI, 应该使用 ID_KEY_ID.

Identification 载荷与 PKIX 证书内容的匹配详见 "The Internet IP Security PKI Profile of IKEv1/ISAKMP, IKEv2, and PKIX" ([RFC4945]).

最后于 更新