跳到主要内容

4. 消息格式 (Message Formats)

以下各节描述 TEAP 中使用的消息格式. 字段按网络字节序 (network byte order) 从左到右传输.

4.1. TEAP 消息格式 (TEAP Message Format)​

TEAP Request/Response packet 格式概要如下.

    0                   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Code      |   Identifier  |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |   Flags | Ver |        Message Length         :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :         Message Length        |         Outer TLV Length
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :     Outer TLV Length          |         TLS Data...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       Outer TLVs...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Code

Code 字段长度为 1 个八位字节 (octet), 定义如下:

      1  Request

      2  Response

Identifier

Identifier 字段为 1 个八位字节, 用于辅助匹配响应与请求. 每个 Request packet 中的 Identifier 字段 MUST 改变. Response packet 中的 Identifier 字段 MUST 与对应 request 中的 Identifier 字段匹配.

Length

Length 字段为 2 个八位字节, 指示 EAP packet 的长度, 包括 Code, Identifier, Length, Type, Flags, Ver, Message Length, TLS Data 和 Outer TLVs 字段. 超出 Length 字段范围的八位字节应当被视为 Data Link Layer padding, 接收时应当忽略.

Type

55 表示 TEAP.

Flags

       0 1 2 3 4
      +-+-+-+-+-+
      |L M S O R|
      +-+-+-+-+-+

L: 包含长度 (Length included). 设置后表示存在 4 个八位字节的 Message Length 字段. 对于分片消息的第一个分片, 该位 MUST 存在. 对任何其他消息, 该位 MUST NOT 存在.

M: 更多分片 (More fragments). 除最后一个分片外, 所有分片均设置该位.

S: TEAP start. 在服务器发往 peer 的 TEAP Start message 中设置.

O: 包含 Outer TLV 长度 (Outer TLV length included). 设置后表示存在 4 个八位字节的 Outer TLV Length 字段. 该位 MUST 仅出现在初始 request 和 response 消息中. 如果初始消息被分片, 则该位 MUST 仅出现在第一个分片中.

R: Reserved, MUST 为 0, 接收时忽略.

Ver

该字段包含协议版本. 本文档描述 TEAP 版本 1, 即二进制 001.

Message Length

Message Length 字段为 4 个八位字节, 仅当 L bit 被设置时才存在. 该字段给出消息的总长度, 该消息可以跨多个 packet 的数据字段分片.

Outer TLV Length

Outer TLV Length 字段为 4 个八位字节, 仅当 O bit 被设置时才存在. 如果存在 Outer TLVs, 该字段给出 Outer TLVs 的总长度.

TLS Data

当 TLS Data 字段存在时, 它由 TLS record format 中封装的 TLS packet 组成. 带有 Flags 和 Version 字段, 但 TLS Data 字段长度为 0 的 TEAP packet 用于表示 TEAP acknowledgment, 适用于分片消息, TLS Alert message 或 TLS Finished message.

Outer TLVs

Outer TLVs 由 TLV 格式的可选数据组成, 用于帮助建立 TLS tunnel. 它们只允许出现在 TEAP 的前两个消息中, 即第一个 EAP-server-to-peer 消息和第一个 peer-to-EAP-server 消息. Outer TLVs 的起始位置可以由 EAP Length 字段和 Outer TLV Length 字段推导.

4.2. TEAP TLV 格式和支持 (TEAP TLV Format and Support)​

这里定义的 TLV 是 TLV object. TLV object 可用于在受保护的 TLS tunnel 内, 在 EAP peer 与 EAP server 之间携带任意参数.

EAP peer 不一定实现 EAP server 支持的所有 TLV. 为了支持互操作性, TLV 被设计为允许 EAP server 使用 NAK TLV 发现 EAP peer 是否支持某个 TLV. TLV 中的 mandatory bit 指示是否要求支持该 TLV. 如果 peer 或 server 不支持标记为 mandatory 的 TLV, 则它 MUST 在响应中发送 NAK TLV, 且消息中的所有其他 TLV MUST 被忽略. 如果 EAP peer 或 server 发现一个标记为 optional 的不受支持 TLV, 它可以忽略该不受支持 TLV. 只有在 TLV 被标记为 mandatory 且无法理解时, 才 MUST 发送 NAK TLV, 除此之外 MUST NOT 发送 NAK TLV. 如果消息中的所有 TLV 都标记为 optional, 且 peer 无法理解其中任何 TLV, 则 SHOULD 向另一端发送 Result TLV 以继续会话. 当消息中所有 TLV 都标记为 optional 时, 也可以发送 NAK TLV.

注意, peer 或 server 可能支持设置了 mandatory bit 的 TLV, 但可能无法理解其内容. 对于内容无法理解的受支持 TLV, 适当响应由各个 TLV 规范定义.

符合本规范的 EAP 实现 MUST 支持 TLV exchange, 并支持处理 TLV 上的 mandatory/optional 设置. 符合本规范的实现 MUST 支持以下 TLV:

  • Authority-ID TLV
  • Identity-Type TLV
  • Result TLV
  • NAK TLV
  • Error TLV
  • Request-Action TLV
  • EAP-Payload TLV
  • Intermediate-Result TLV
  • Crypto-Binding TLV
  • Basic-Password-Auth-Req TLV
  • Basic-Password-Auth-Resp TLV

4.2.1. 通用 TLV 格式 (General TLV Format)​

TLV 按如下方式定义. 字段从左到右传输.

如果 peer 或 server 收到格式不正确的 TLV, 该 TLV MUST 被丢弃. 通常记录错误或调试消息是有用的, 该消息指明哪个 TLV 存在问题以及问题是什么. 但是, 格式错误的 TLV 是无效的, 不能使用.

    0                   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |M|R|            TLV Type       |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              Value...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

M

      0  Optional TLV

      1  Mandatory TLV

R

Reserved, 设置为 0.

TLV Type

14 bit 字段, 表示 TLV type. 已分配类型包括:

      0  Unassigned

      1  Authority-ID TLV (Section 4.2.2)

      2  Identity-Type TLV (Section 4.2.3)

      3  Result TLV (Section 4.2.4)

      4  NAK TLV (Section 4.2.5)

      5  Error TLV (Section 4.2.6)

      6  Channel-Binding TLV (Section 4.2.7)

      7  Vendor-Specific TLV (Section 4.2.8)

      8  Request-Action TLV (Section 4.2.9)

      9  EAP-Payload TLV (Section 4.2.10)

      10  Intermediate-Result TLV (Section 4.2.11)

      11  PAC TLV (DEPRECATED)

      12  Crypto-Binding TLV (Section 4.2.13)

      13  Basic-Password-Auth-Req TLV (Section 4.2.14)

      14  Basic-Password-Auth-Resp TLV (Section 4.2.15)

      15  PKCS#7 TLV (Section 4.2.16)

      16  PKCS#10 TLV (Section 4.2.17)

      17  Trusted-Server-Root TLV (Section 4.2.18)

      18  CSR-Attributes TLV (Section 4.2.19)

      19  Identity-Hint TLV (Section 4.2.20)

Length

Value 字段的长度, 单位为八位字节.

Value

TLV 的值.

4.2.2. Authority-ID TLV​

    0                   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |M|R|         TLV Type          |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              ID...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

M: 0 - Optional TLV.

R: Reserved, 设置为 0.

TLV Type: 1 - Authority-ID.

Length: Length 字段为 2 个八位字节, 包含 ID 字段的长度, 单位为八位字节.

ID: 服务器身份提示, 用于帮助 peer 匹配可用于该服务器的凭据. 它在部署范围内应当唯一.

4.2.3. Identity-Type TLV​

Identity-Type TLV 允许 EAP server 发送提示, 帮助 EAP peer 选择正确的身份类型, 例如 user 或 machine. TEAPv1 实现 MUST 支持此 TLV. 在 TEAP request 或 response packet 中 SHOULD 只存在一个 Identity-Type TLV.

发送 Identity-Type TLV 的 server MUST 同时包含 EAP-Payload TLV 或 Basic-Password-Auth-Resp TLV. 发送 Identity-Type TLV 的 peer MUST 同时包含 EAP-Payload TLV 或 Basic-Password-Auth-Resp TLV.

收到 Identity-Type request 的 EAP peer SHOULD 用具有所请求类型的 Identity-Type TLV 进行响应. 如果 Identity-Type 字段不包含已知值之一, 或者 EAP peer 没有与请求的 identity type 对应的身份, 则 peer SHOULD 用包含某个可用 identity type 的 Identity-Type TLV 进行响应.

server 在 response 中收到 Identity-Type 时, MUST 检查 response 中的 Identity-Type 值是否与 request 中发送的 Identity-Type 值匹配. 匹配表示 server 可以继续认证.

但是, 如果值不匹配, 当且仅当以下两个条件都满足时, server 可以继续认证. 如果以下任一条件不满足, server MUST 以 Failure 的 Result TLV 响应.

  1. Identity-Type 包含 server configuration 允许的值.
  2. Identity-Type 值此前未用于成功认证.

第一个条件允许 server 被配置为仅允许 user authentication, 或仅允许 machine authentication. server 也可以使用 response 中发送的 Identity-Hint TLV, 对不同身份允许不同类型的认证. server 还可以基于其他信息允许或禁止不同类型的认证, 例如 outer EAP Identity, outer EAP client certificate 中的字段, 或随 TEAP session 一起在 RADIUS 或 Diameter packet 中收到的其他字段. 并不要求 server 必须为所有 TEAP session 同时支持 user 和 machine authentication.

第二个条件确保如果某个 Inner Method 成功, server 不会为相同 Identity-Type 尝试后续 Inner Method. 例如, 如果 user 已通过 EAP-TLS 的 Inner Method 认证, 再通过不同 Inner Method 请求额外认证没有收益. 同样, 为同一 user 重复认证 session 也没有收益, 结果不会改变.

第二个条件也禁止通过 Basic-Password-Auth-Req TLV 进行多轮 challenge/response authentication. TEAPv1 仅支持一轮 Basic-Password-Auth-Req 后跟 Basic-Password-Auth-Resp. 该轮的结果 MUST NOT 是另一个 Basic-Password-Auth-Req TLV.

第二个条件还表示 server MUST NOT 发送与此前成功认证使用的值相同的 Identity-Hint TLV.

Identity-Type TLV 定义如下:

    0                   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |M|R|         TLV Type          |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Identity-Type         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

M: Mandatory, 设置为 1.

R: Reserved, 设置为 0.

TLV Type: 2 - Identity-Type TLV.

Length: 2.

Identity-Type: Identity-Type 字段为 2 个八位字节. 值包括:

      1  User

      2  Machine

4.2.4. Result TLV​

Result TLV 为 TEAP 内受保护的终止提供带确认的 success 和 failure 消息支持. 如果 Status 字段不包含已知值之一, peer 或 EAP server MUST 将其视为 Unexpected TLVs Exchanged 致命错误. Result TLV 的行为在 Section 3.6.6 和 Section 3.9.3 中进一步讨论.

指示 failure 的 Result TLV MUST NOT 伴随以下 TLV: NAK, EAP-Payload 或 Crypto-Binding.

指示 success 的 Result TLV MUST 伴随 Crypto-Binding TLV.

Result TLV 定义如下:

    0                   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |M|R|         TLV Type          |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             Status            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

M: Mandatory, 设置为 1.

R: Reserved, 设置为 0.

TLV Type: 3 - Result TLV.

Length: 2.

Status: Status 字段为 2 个八位字节. 值包括:

      1  Success

      2  Failure

4.2.5. NAK TLV​

NAK TLV 允许 peer 检测另一方不支持的 TLV. 一个 TEAP packet 可以包含 0 个或多个 NAK TLV. NAK TLV 不应伴随其他 TLV. 对包含 Result TLV 的消息, MUST NOT 发送 NAK TLV 作为响应, 而应发送 failure 的 Result TLV 并用 Unexpected TLVs Exchanged 的 Error TLV 指示 failure. NAK TLV 定义如下:

    0                   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |M|R|         TLV Type          |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Vendor-Id                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            NAK-Type           |           TLVs...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

M: Mandatory, 设置为 1.

R: Reserved, 设置为 0.

TLV Type: 4 - NAK TLV.

Length: >=6.

Vendor-Id: Vendor-Id 字段为 4 个八位字节, 包含不受支持 TLV 的 Vendor-Id. 高阶八位字节为 0, 低阶 3 个八位字节是 Vendor 的 Structure of Management Information (SMI) Network Management Private Enterprise Number, 采用网络字节序. 对于不是 Vendor-Specific TLV 的 TLV, Vendor-Id 字段 MUST 为 0.

NAK-Type: NAK-Type 字段为 2 个八位字节. 该字段包含不受支持 TLV 的 type. 前一个 packet 中 MUST 已包含此类型的 TLV.

TLVs: 此字段包含 0 个或多个 TLV 的列表, 每个 TLV MUST NOT 设置 mandatory bit. 这些 optional TLV 用于未来扩展, 以传达为什么判定出错 TLV 不受支持.

4.2.6. Error TLV​

Error TLV 允许 EAP peer 或 server 向另一方指示错误. 一个 TEAP packet 可以包含 0 个或多个 Error TLV. Error-Code 字段描述错误类型. Error code 1-999 表示成功结果, 即信息性消息, 1000-1999 表示 warning, 2000-2999 表示 fatal error. 致命 Error TLV MUST 伴随指示 failure 的 Result TLV, 且会话按 Section 3.9.3 所述终止.

下面许多 error code 涉及 Inner Method processing 中的错误, 如果 inner method 提供这些错误, 则可以取回. 实现 MUST 注意错误消息不要向攻击者泄露过多信息. 例如, NOT RECOMMENDED 使用错误消息 1031 (User account credentials incorrect), 因为它允许攻击者通过将该响应与其他响应区分开来确定有效用户名. 它应当仅用于故障排查.

Error TLV 定义如下:

    0                   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |M|R|         TLV Type          |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Error-Code                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

M: Mandatory, 设置为 1.

R: Reserved, 设置为 0.

TLV Type: 5 - Error TLV.

Length: 4.

Error-Code: Error-Code 字段为 4 个八位字节. 当前定义的 Error-Code 值包括:

      1  User account expires soon
      2  User account credential expires soon
      3  User account authorizations change soon
      4  Clock skew detected
      5  Contact administrator
      6  User account credentials change required
      1001  Inner Method Error
      1002  Unspecified authentication infrastructure problem
      1003  Unspecified authentication failure
      1004  Unspecified authorization failure
      1005  User account credentials unavailable
      1006  User account expired
      1007  User account locked: try again later
      1008  User account locked: admin intervention required
      1009  Authentication infrastructure unavailable
      1010  Authentication infrastructure not trusted
      1011  Clock skew too great
      1012  Invalid inner realm
      1013  Token out of sync: administrator intervention required
      1014  Token out of sync: PIN change required
      1015  Token revoked
      1016  Tokens exhausted
      1017  Challenge expired
      1018  Challenge algorithm mismatch
      1019  Client certificate not supplied
      1020  Client certificate rejected
      1021  Realm mismatch between inner and outer identity
      1022  Unsupported Algorithm In Certificate Signing Request
      1023  Unsupported Extension In Certificate Signing Request
      1024  Bad Identity In Certificate Signing Request
      1025  Bad Certificate Signing Request
      1026  Internal CA Error
      1027  General PKI Error
      1028  Inner Method's channel-binding data required but not supplied
      1029  Inner Method's channel-binding data did not include required information
      1030  Inner Method's channel binding failed
      1031  User account credentials incorrect [USAGE NOT RECOMMENDED]
      1032  Inner Method not supported
      2001  Tunnel Compromise Error
      2002  Unexpected TLVs Exchanged
      2003  The Crypto-Binding TLV is invalid (Version, Received-Ver, or Sub-Type)
      2004  The first Inner Method did not derive EMSK
      2005  The Crypto-Binding TLV did not include a required MSK Compound MAC
      2006  The MSK Compound MAC fails verification
      2007  The Crypto-Binding TLV did not include a required EMSK Compound MAC
      2008  The EMSK Compound MAC fails verification
      2009  The EMSK Compound MAC exists, but the Inner Method did not derive EMSK

4.2.7. Channel-Binding TLV​

Channel-Binding TLV 提供一种机制, 用于按 [RFC6677] 所述从 peer 向 EAP server 携带 channel-binding data, 并从 EAP server 向 peer 携带 channel-binding response. TEAPv1 实现 MAY 支持此 TLV, 该 TLV 不能用 NAK TLV 响应. 如果 Channel-Binding data 字段不包含已知值之一, 或者 EAP server 不支持此 TLV, 则 server MUST 忽略该值. Channel-Binding TLV 定义如下:

    0                   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |M|R|         TLV Type          |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Data ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

M: 0 - Optional TLV.

R: Reserved, 设置为 0.

TLV Type: 6 - Channel-Binding TLV.

Length: variable.

Data: data 字段包含 [RFC6677] Section 5.3 中定义的 channel-binding message.

4.2.8. Vendor-Specific TLV​

Vendor-Specific TLV 可用于允许供应商支持不适合通用使用的自有扩展属性. Vendor-Specific TLV attribute 可以包含一个或多个 TLV, 称为 Vendor TLV. 特定 Vendor TLV 的 TLV type 由供应商定义. 单个 Vendor-Specific TLV 内的所有 Vendor TLV 属于同一供应商. 同一消息中可以有来自不同供应商的多个 Vendor-Specific TLV. Vendor TLV 中的错误处理可以使用供应商自有的特定错误处理机制, 或使用已定义的标准 TEAP error code.

Vendor TLV 可以是 optional 或 mandatory. 随 Result TLV 发送的 Vendor TLV MUST 标记为 optional. 如果 Vendor-Specific TLV 被标记为 mandatory, 则接收方预期需要识别 vendor ID, 解析其中所有 Vendor TLV, 并按供应商定义处理 Vendor-Specific TLV 内的错误.

当 Vendor-Specific TLV 在 Inner Method 中承载 authentication protocol 时, 它 MUST 为 MSK 和 EMSK 定义值. 如果这些值无法从 cryptographic primitive 派生, 则它们 MUST 设置为 0, 与使用 Basic-Password-Auth-Req 时相同.

Vendor-Specific TLV 定义如下:

    0                   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |M|R|         TLV Type          |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Vendor-Id                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Vendor TLVs....
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

M: 0 or 1.

R: Reserved, 设置为 0.

TLV Type: 7 - Vendor-Specific TLV.

Length: 4 + 所有包含的 Vendor TLV 的累计长度.

Vendor-Id: Vendor-Id 字段为 4 个八位字节, 包含 TLV 的 Vendor-Id. 高阶八位字节为 0, 低阶 3 个八位字节是 Vendor 的 SMI Network Management Private Enterprise Number, 采用网络字节序.

Vendor TLVs: 此字段长度不定. 它包含 Vendor-Specific TLV, 格式由供应商定义.

4.2.9. Request-Action TLV​

Request-Action TLV MAY 在任何时候发送. Request-Action TLV 允许 peer 或 server 请求另一方协商额外的 Inner Method, 或处理 Request-Action TLV 内传递的 TLV.

接收方 MUST 处理此 TLV. TLV 的处理如下:

接收实体 MAY 选择处理消息中包含的任何 TLV.

如果接收实体选择 NOT 处理列表中的任何 TLV, 则它发送 Result TLV, 其中 Status 字段使用 Request-Action TLV 中相同的 code.

如果 request 中有多个 Request-Action TLV, 只要任意 Request-Action TLV 中的任意 TLV 被处理, session 就可以继续.

如果 request 中有多个 Request-Action TLV 且均未被处理, 则返回的 Result TLV 中应使用最严重的 status. 如果接收实体不理解 Request-Action TLV 中的 status code, 则 SHOULD 将其视为 fatal error. 否则, 接收实体 MAY 发送包含值为 2002 (Unexpected TLVs Exchanged) 的 Error TLV 的 Request-Action TLV.

处理 request 中的 TLV 或 Inner Method 后, MUST 再进行一轮 Result TLV exchange, 以在双方同步最终 status.

peer 或 server MAY 向另一方发送多个 Request-Action TLV. 如果两个 Request-Action TLV 具有相同 Status value, 它们 MUST NOT 出现在同一个 TEAP packet 中. 多个 Request-Action TLV 的处理顺序取决于实现. 如果接收方先处理 optional (non-fatal) 项, fatal 项可能稍后消失. 如果接收方先处理 fatal 项, 通信时间会更短.

在一个或多个请求项已被处理且另一方已表示希望结束 EAP conversation 后, peer 或 server MAY 返回一组新的 Request-Action TLV.

Request-Action TLV 定义如下:

    0                   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |M|R|         TLV Type          |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Status   |      Action    |                TLVs....
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-

M: Mandatory, 设置为 1.

R: Reserved, 设置为 0.

TLV Type: 8 - Request-Action TLV.

Length: 2 + 所有包含的 TLV 的累计长度.

Status: Status 字段为 1 个八位字节. 它指示接收此 TLV 的一方不处理 action 时的结果. 值包括:

      1  Success

      2  Failure

Action: Action 字段为 1 个八位字节. 值包括:

      1  Process-TLV

      2  Negotiate-EAP

TLVs: 此字段长度不定. 它包含 peer 希望 server 处理的 TLV.

4.2.10. EAP-Payload TLV​

为了允许将 EAP request 或 response 与其他 TLV 合并, 定义了 EAP-Payload TLV. 它包含一个封装的 EAP packet 和一个 optional TLV 列表. optional TLV 用于未来扩展, 以提供有关当前 EAP authentication 的提示. 一条消息中只允许一个 EAP-Payload TLV. EAP-Payload TLV 定义如下:

    0                   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |M|R|         TLV Type          |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          EAP packet...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             TLVs...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

M: Mandatory, 设置为 1.

R: Reserved, 设置为 0.

TLV Type: 9 - EAP-Payload TLV.

Length: embedded EAP packet 的长度 + additional TLV 的累计长度.

EAP packet: 此字段包含完整 EAP packet, 包括 EAP header (Code, Identifier, Length, Type) 字段. 此字段长度由封装 EAP packet 的 Length 字段决定.

TLVs: 此 optional 字段包含与 EAP packet 字段关联的 TLV 列表. TLV MUST NOT 设置 mandatory bit. 此字段的总长度等于 EAP-Payload TLV 的 Length 字段减去 EAP packet 字段的 EAP header 中的 Length 字段.

4.2.11. Intermediate-Result TLV​

Intermediate-Result TLV 为所有 inner method 指示中间 Success 和 Failure 消息. Intermediate-Result TLV MUST 用于所有 Inner Method.

指示 success 的 Intermediate-Result TLV MUST 伴随 Crypto-Binding TLV.

指示 failure 的 Intermediate-Result TLV SHOULD 伴随 Error TLV, 以指示认证失败原因.

与此 TLV 关联的 optional TLV 用于未来扩展, 以提供有关当前结果的提示. Intermediate-Result TLV 定义如下:

    0                   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |M|R|         TLV Type          |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             Status            |        TLVs...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

M: Mandatory, 设置为 1.

R: Reserved, 设置为 0.

TLV Type: 10 - Intermediate-Result TLV.

Length: 2 + embedded associated TLV 的累计长度.

Status: Status 字段为 2 个八位字节. 值包括:

      1  Success

      2  Failure

TLVs: 此字段长度不定, 包含 0 个或多个与 Intermediate Result TLV 关联的 TLV. 此字段中的 TLV MUST NOT 设置 mandatory bit.

4.2.12. PAC TLV​

[RFC7170] 定义了 Protected Access Credential (PAC), 用于映射 EAP-FAST [RFC4851]. 但是, 实现经验和分析确定 PAC 并非必要. 相反, TEAP 使用 [RFC9190] Section 2.1.2 和 Section 2.1.3 中定义的 NewSessionTicket message 执行 session resumption. 因此, PAC TLV 已被废弃.

由于 PAC TLV 已废弃, 收到它的实体 SHOULD 发送指示 failure 的 Result TLV 和 Unexpected TLVs Exchanged 的 Error TLV.

4.2.13. Crypto-Binding TLV​

Crypto-Binding TLV 用于证明 peer 和 server 都参与了 tunnel establishment 和 authentication 序列. 它还提供对 TEAP type, 协商版本, 以及 TLS tunnel establishment 前交换的 Outer TLV 的验证.

Crypto-Binding MUST 伴随指示 success 的 Intermediate-Result TLV.

无论是否存在 Inner Method, 在检查任何 Intermediate-Result 或 Result TLV value 之前, Crypto-Binding TLV MUST 被交换并验证. 在一组 inner method 中, 每个成功 Inner Method 之后, 继续另一个 Inner Method 之前, 它 MUST 与 Intermediate-Result TLV 一起包含, 以执行 cryptographic binding. 如果尚未生成 MSK 或 EMSK 且需要 Crypto-Binding TLV, 则 MSK Compound MAC 字段包含按 Section 6.3 生成的密钥所计算的 MAC.

Crypto-Binding TLV 仅在其内容通过以下检查时有效:

  • Version 字段包含已知值.
  • Received-Ver 字段与接收方在 EAP version negotiation 期间发送的 TEAP version 匹配.
  • Sub-Type 字段设置为本次 exchange 的正确值.
  • Flags 字段设置为已知值.
  • Compound MAC 均正确验证.

如果上述任一检查失败, 则该 TLV 无效. 无效 Crypto-Binding TLV 是 fatal error, 并按 Section 3.9.3 所述处理.

关于 Compound MAC 字段如何构造和验证的更详细讨论见 Section 6.

Crypto-Binding TLV 定义如下:

    0                   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |M|R|         TLV Type          |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Reserved   |    Version    |  Received-Ver.| Flags|Sub-Type|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                             Nonce                             ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                   EMSK Compound MAC                           ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                    MSK Compound MAC                           ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

M: Mandatory, 设置为 1.

R: Reserved, 设置为 0.

TLV Type: 12 - Crypto-Binding TLV.

Length: 76.

Reserved: Reserved, 设置为 0.

Version: Version 字段是单个八位字节, 设置为 TEAP method 正在使用的 Crypto-Binding TLV 版本. 对符合 TEAPv1 的实现, 版本号 MUST 设置为 1.

Received-Ver: Received-Ver 字段是单个八位字节, MUST 设置为 version negotiation 期间收到的 TEAP version number. 注意, 该字段只为 downgrade attack 提供保护, 在 downgrade attack 中, 要求支持此 TLV 的 EAP 版本在双方都被要求使用. 对于 TEAPv1, 此版本号 MUST 设置为 1.

Flags: Flags 字段为 4 bit. 已定义值包括:

      1  EMSK Compound MAC is present

      2  MSK Compound MAC is present

      3  Both EMSK and MSK Compound MAC are present

Flags 字段的所有其他值均无效.

Sub-Type: Sub-Type 字段为 4 bit. 已定义值包括:

      0  Binding Request

      1  Binding Response

Sub-Type 字段的所有其他值均无效.

Nonce: Nonce 字段为 32 个八位字节. 它包含 256 bit nonce, 该 nonce 在时间上唯一, 用于每端的 Compound MAC key derivation. request 中的 nonce MUST 将其 least significant bit 设置为 0, response 中的 nonce MUST 与 request nonce 具有相同值, 但 least significant bit MUST 设置为 1.

EMSK Compound MAC: EMSK Compound MAC 字段为 20 个八位字节. 它可以是 Server MAC (B1_MAC) 或 Client MAC (B2_MAC). MAC 的计算见 Section 6.3.

注意, 此字段长度始终为 20 个八位字节. 任何更大的 MAC 都会直接截断. 所有验证或比较 MUST 基于截断值完成.

MSK Compound MAC: MSK Compound MAC 字段为 20 个八位字节. 它可以是 Server MAC (B1_MAC) 或 Client MAC (B2_MAC). MAC 的计算见 Section 6.3.

注意, 此字段长度始终为 20 个八位字节. 任何更大的 MAC 都会直接截断. 所有验证或比较 MUST 基于截断值完成.

4.2.14. Basic-Password-Auth-Req TLV​

Basic-Password-Auth-Req TLV 由 authentication server 用于向 peer 请求 username 和 password. 它包含 request 的 optional user prompt message. peer 预期获取 username 和 password, 并在 Basic-Password-Auth-Resp TLV 中发送它们.

Basic-Password-Auth-Req TLV 定义如下:

    0                   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |M|R|         TLV Type          |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Prompt ....
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

M: Mandatory, 设置为 1.

R: Reserved, 设置为 0.

TLV Type: 13 - Basic-Password-Auth-Req TLV.

Length: variable.

Prompt: UTF-8 [RFC3629] 格式的 optional user prompt message.

4.2.15. Basic-Password-Auth-Resp TLV​

Basic-Password-Auth-Resp TLV 由 peer 用于以 username 和 password 响应 Basic-Password-Auth-Req TLV. 该 TLV 包含 username 和 password. username 和 password 采用 UTF-8 [RFC3629] 格式.

Basic-Password-Auth-Resp TLV 定义如下:

    0                   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |M|R|         TLV Type          |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Userlen     |             Username
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         ...     Username    ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Passlen     |             Password
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         ...     Password    ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

M: Mandatory, 设置为 1.

R: Reserved, 设置为 0.

TLV Type: 14 - Basic-Password-Auth-Resp TLV.

Length: variable.

Userlen: Username 字段长度, 单位为八位字节. Userlen 的值 MUST NOT 为 0.

Username: UTF-8 [RFC3629] 格式的 Username. Username 内容 SHOULD 遵循 [RFC9427] Section 3.1 中的指南.

Passlen: Password 字段长度, 单位为八位字节. Passlen 的值 MUST NOT 为 0.

Password: UTF-8 [RFC3629] 格式的 Password.

注意, 并不要求 password 必须可由人类阅读. password 中的八位字节可以具有小于 0x20 的值, 包括 0x00.

4.2.16. PKCS#7 TLV​

PKCS#7 TLV 由 EAP server 用于向 peer 交付 certificate. 其格式由二进制 DER encoding [X.690] 的 certificate 或 certificate chain 组成, 位于 [RFC5652] 定义的 degenerate Certificates Only PKCS#7 SignedData Content 中.

当用于响应来自 peer 的 Trusted-Server-Root TLV request 时, EAP server MUST 在 Trusted-Server-Root TLV 内发送 PKCS#7 TLV. 当用于响应来自 peer 的 PKCS#10 certificate enrollment request 时, EAP server MUST 发送不带 Trusted-Server-Root TLV 的 PKCS#7 TLV. PKCS#7 TLV 始终标记为 optional, 不能用 NAK TLV 响应. 支持 Trusted-Server-Root TLV 或 PKCS#10 TLV 的 TEAP 实现 MUST 支持此 TLV. Peer MUST NOT 假设 PKCS#7 TLV 中的 certificate 按任何顺序排列.

TEAP server MAY 返回 self-signed certificate. 处理 self-signed certificate 或 trust anchor 的 peer MUST NOT 仅因这些 certificate 出现在 certificate bag 中就隐式信任它们. 注意: 建议 peer 在决定是否将收到的 certificate 用作 trust anchor 时非常谨慎. 接收 PKCS#7 bag 的 tunnel 具有 authenticated 性质, 可为其中包含的 certificate 提供一定级别的真实性. 建议 peer 考虑 EAP server 的隐含 authority, 并限制它可通过 PKCS#7 TLV 中收到的 trust anchor 获得的信任.

PKCS#7 TLV 定义如下:

    0                   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |M|R|         TLV Type          |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           PKCS#7 Data...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

M: 0 - Optional TLV.

R: Reserved, 设置为 0.

TLV Type: 15 - PKCS#7 TLV.

Length: PKCS#7 Data 字段的长度.

PKCS#7 Data: 此字段包含 DER-encoded X.509 certificate 或 certificate chain, 位于 Certificates-Only PKCS#7 SignedData message 中.

4.2.17. PKCS#10 TLV​

PKCS#10 TLV 由 peer 用于发起 [RFC5272] 中的 "Simple PKI" Request/Response. request 的格式按 [RFC4945] Section 6.4 规定. PKCS#10 TLV 始终标记为 optional, 不能用 NAK TLV 响应.

PKCS#10 TLV 定义如下:

    0                   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |M|R|         TLV Type          |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           PKCS#10 Data...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

M: 0 - Optional TLV.

R: Reserved, 设置为 0.

TLV Type: 16 - PKCS#10 TLV.

Length: PKCS#10 Data 字段的长度.

PKCS#10 Data: 此字段包含 DER-encoded PKCS#10 certificate request.

4.2.18. Trusted-Server-Root TLV​

Trusted-Server-Root TLV 便于请求和交付 trusted server root certificate. Trusted-Server-Root TLV 可以在常规 TEAP authentication mode 或 provisioning mode 中交换. Trusted-Server-Root TLV 始终标记为 optional, 且不能用 NAK TLV 响应. Trusted-Server-Root TLV MUST 仅作为 Inner TLV 发送, 即位于 tunnel 的保护之内.

在 peer 已确定其成功认证 EAP server 并验证 Crypto-Binding TLV 后, 它 MAY 发送一个或多个标记为 optional 的 Trusted-Server-Root TLV, 以向 EAP server 请求 trusted server root certificate. EAP server MAY 在 Trusted-Server-Root TLV 内通过 Public Key Cryptographic System #7 (PKCS#7) TLV 发送一个或多个 root certificate. EAP server MAY 也可以选择不满足该 request.

Trusted-Server-Root TLV 允许 peer 向 EAP server 发送 trusted root 列表请求. server 可以用 PKCS#7 [RFC2315] 格式的一个或多个 root certificate 响应.

如果 EAP server 将 credential format 设置为 PKCS#7-Server-Certificate-Root, 则 Trusted-Server-Root TLV 应包含发给 EAP server 的 certificate 的 certificate chain root, 并封装在 PKCS#7 TLV 中. 如果 server certificate 是 self-signed certificate, 则 root 就是该 self-signed certificate.

如果 Trusted-Server-Root TLV credential format 包含 peer 未知的值, 则 EAP peer 应当忽略该 TLV.

Trusted-Server-Root TLV 定义如下:

    0                   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |M|R|         TLV Type          |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Credential-Format   |     Cred TLVs...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

M: 0 - Optional TLV.

R: Reserved, 设置为 0.

TLV Type: 17 - Trusted-Server-Root TLV.

Length: >=2 octets.

Credential-Format: Credential-Format 字段为 2 个八位字节. 值包括:

      1 - PKCS#7-Server-Certificate-Root

Cred TLVs: 此字段长度不定. 它包含与 credential format 关联的 TLV. 当使用此 TLV 请求 server trust root 时, peer 可以将此字段留空.

4.2.19. CSR-Attributes TLV​

CSR-Attributes TLV 从 server 向 peer 提供有关应如何形成 certificate signing request 的信息. CSR attribute 的目的见 [RFC7030] Section 4.5. server MAY 在 TLS session 建立后直接发送 CSR-Attributes TLV. server MAY 在同一消息中还发送用于 PKCS#10 TLV 的 Request-Action frame. 这向 peer 指示 server 希望 peer 使用此 TLV 中提供的参数更新其 certificate. server 应按 [RFC7030] Section 4.5.2 指定构造 CSR-Attributes TLV 的内容, 但 DER encoding MUST NOT 使用 base64 编码. [RFC7030] 使用 base64 encoding, 因为其 transport protocol 要求 textual encoding. 相比之下, TEAP attribute 可以传输任意 binary data.

创建 CSR-Attributes TLV 时, server 和 peer MUST 遵循 [RFC9908] 提供的指南. 如果 peer 无法做到这一点, MAY 忽略 TLV 内容, 但之后 server 可能不会处理 PKCS#10 certificate request, 无论是因该原因还是任何其他原因.

CSR-Attributes TLV 定义如下:

    0                   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |M|R|         TLV Type          |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                DER Encoded CSR Attributes                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

M: 0 - Optional TLV.

R: Reserved, 设置为 0.

TLV Type: 18 - CSR-Attributes.

Length: >=2 octets.

4.2.20. Identity-Hint TLV​

Identity-Hint TLV 是 optional TLV, 可以由 peer 在 Phase 2 TEAP conversation 开始时发送给 server. 该 TLV 的目的是提供一个关于 peer 将通过后续 Inner Method 使用的 identity 或 identities 的 "hint".

此 TLV 的目的在于解决 server 的 "bootstrapping" 问题. 为执行认证, server 必须选择一个 Inner Method. 但是, server 并不知道 peer 支持哪些 method. 如果没有 identity hint, server 需要提出一个 method, 然后让 peer 返回响应以指示所请求 method 不可用. 这种协商会增加 TEAP 结束所需的 round trip 数量, 且没有额外收益.

使用 Identity-Hint 时, peer 可以指示其可用的 identity, 这使 server 能够选择适合该 identity 的 Inner Method.

peer SHOULD 为其可用的每个 Identity-Type 发送一个 Identity-Hint TLV. 例如, 如果 peer 可同时执行 machine 和 user authentication, 它可以发送两个 Identity-Hint TLV, 值分别为 "host/name.example.com" (对于 hostname 为 "name.example.com" 的 machine) 和 "[email protected]" (对于 identity 为 "[email protected]" 的 person).

Identity-Hint TLV 的内容 SHOULD 采用 NAI [RFC7542] 格式, 但我们注意到, 如上例所示, Machine identity 可能不遵循该格式. 由于这些 identity 从不用于 [RFC7542] Section 3 中讨论的 AAA routing, 这些 identity 的格式和定义完全是 site local 的. 健壮实现 MUST 支持此 TLV 内容中的任意数据, 包括 binary octet.

由于 Identity-Hint TLV 是 "hint", server 实现可以自由忽略给出的 hint, 并执行 site-local policy 所要求的任何操作.

Identity-Hint TLV 仅作为选择要使用哪些 Inner Method 时的指南. 该 TLV 没有其他含义, 且 MUST NOT 用于任何其他目的. 具体而言, server 实现 MUST NOT 将此 TLV 中给出的 identity 与稍后作为 Inner Method 一部分给出的 identity 进行比较. hint 与随后使用的任何 identity 不匹配并不是问题.

Identity-Hint TLV MUST NOT 用于 server unauthenticated provisioning. 此 TLV 仅作为正常认证的 hint 使用.

Identity-Hint TLV 定义如下:

    0                   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |M|R|         TLV Type          |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Identity Hint                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

M: 0 - Optional TLV.

R: Reserved, 设置为 0.

TLV Type: 19 - Identity-Hint.

Length: >=2 octets.

4.3. TLV 规则 (TLV Rules)​

为了节省 round trip, 可以在单个 TEAP packet 中发送多个 TLV. 但是, 在本版本中不支持在一个 TEAP packet 中发送多个 EAP Payload TLV, 多个 Basic Password Authentication TLV, 或同时发送 EAP Payload TLV 和 Basic Password Authentication TLV, 且 MUST NOT 发送. 如果 peer 或 EAP server 收到多个 EAP Payload TLV, 则它 MUST 使用 Result TLV 终止连接. TEAP packet 中 TLV 的编码顺序并不重要. 但是, packet 中 TLV 的处理存在顺序:

  1. Crypto-Binding TLV
  2. Intermediate-Result TLV
  3. Result TLV or Request-Action TLV
  4. Identity-Type TLV
  5. EAP-Payload TLV (Identity-Request) or Basic-Password-Auth-Req TLV
  6. Other TLVs

也就是说, 在使用任何 result 前先检查 cryptographic binding, 并在提出 Inner Method 前先检查 identity, 因为 identity 可能影响所选 Inner Method.

以下定义下面各节表项的含义:

   0  This TLV MUST NOT be present in the message.

   0+  Zero or more instances of this TLV MAY be present in the message.

   0-1  Zero or one instance of this TLV MAY be present in the message.

   1  Exactly one instance of this TLV MUST be present in the message.

4.3.1. Outer TLVs​

下表给出哪些 TLV 可以包含在 TLS channel 外的 TEAP packet 中, 可以出现在何种 packet 中, 以及数量约束:

       +=========+==========+=========+=========+=================+
       | Request | Response | Success | Failure | TLVs            |
       +=========+==========+=========+=========+=================+
       | 0-1     | 0        | 0       | 0       | Authority-ID    |
       +---------+----------+---------+---------+-----------------+
       | 0-1     | 0-1      | 0       | 0       | Identity-Type   |
       +---------+----------+---------+---------+-----------------+
       | 0+      | 0+       | 0       | 0       | Vendor-Specific |
       +---------+----------+---------+---------+-----------------+

                                 Table 1

Outer TLV MUST 标记为 optional. 当 Vendor-Specific TLV 内的 Vendor TLV 被包含在 Outer TLV 中时, Vendor TLV MUST 标记为 optional. 在 peer 和 EAP-server 分别发送的前两个 TEAP 消息之后, MUST NOT 包含 Outer TLV. 也就是说, 只允许第一个 EAP-server-to-peer 消息和第一个 peer-to-EAP-server 消息. 如果消息被分片, 整组消息计为一条消息. 如果 Outer TLV 被包含在前两个 TEAP 消息之后的消息中, 它们 MUST 被忽略.

4.3.2. Inner TLVs​

下表给出哪些 Inner TLV 可以在 TEAP Phase 2 中封装于 TLS 内, 可以出现在何种 packet 中, 以及数量约束. 消息含义如下: Request 是 TEAP Request, Response 是 TEAP Response, Success 是包含 successful Result TLV 的消息, Failure 是包含 failed Result TLV 的消息.

    +=======+==========+=========+=========+==========================+
    |Request| Response | Success | Failure | TLVs                     |
    +=======+==========+=========+=========+==========================+
    |0-1    | 0-1      | 0       | 0       | Identity-Type            |
    +-------+----------+---------+---------+--------------------------+
    |0-1    | 0-1      | 1       | 1       | Result                   |
    +-------+----------+---------+---------+--------------------------+
    |0+     | 0+       | 0       | 0       | NAK                      |
    +-------+----------+---------+---------+--------------------------+
    |0+     | 0+       | 0+      | 0+      | Error                    |
    +-------+----------+---------+---------+--------------------------+
    |0-1    | 0-1      | 0       | 0       | Channel-Binding          |
    +-------+----------+---------+---------+--------------------------+
    |0+     | 0+       | 0+      | 0+      | Vendor-Specific          |
    +-------+----------+---------+---------+--------------------------+
    |0+     | 0+       | 0+      | 0+      | Request-Action           |
    +-------+----------+---------+---------+--------------------------+
    |0-1    | 0-1      | 0       | 0       | EAP-Payload              |
    +-------+----------+---------+---------+--------------------------+
    |0-1    | 0-1      | 0-1     | 0-1     | Intermediate-Result      |
    +-------+----------+---------+---------+--------------------------+
    |0-1    | 0-1      | 0-1     | 0-1     | Crypto-Binding           |
    +-------+----------+---------+---------+--------------------------+
    |0-1    | 0        | 0       | 0       | Basic-Password-Auth-Req  |
    +-------+----------+---------+---------+--------------------------+
    |0      | 0-1      | 0       | 0       | Basic-Password-Auth-Resp |
    +-------+----------+---------+---------+--------------------------+
    |0-1    | 0        | 0-1     | 0       | PKCS#7                   |
    +-------+----------+---------+---------+--------------------------+
    |0      | 0-1      | 0       | 0       | PKCS#10                  |
    +-------+----------+---------+---------+--------------------------+
    |0-1    | 0-1      | 0-1     | 0       | Trusted-Server-Root      |
    +-------+----------+---------+---------+--------------------------+
    |0-1    | 0        | 0       | 0       | CSR-Attributes TLV       |
    +-------+----------+---------+---------+--------------------------+
    |0      | 0+       | 0       | 0       | Identity-Hint TLV        |
    +-------+----------+---------+---------+--------------------------+

                                  Table 2

NOTE: 随 Result TLV 发送的 Vendor TLV, 即包含在 Vendor-Specific TLV 中的 Vendor TLV, MUST 标记为 optional. 此外, CSR-Attributes TLV 从不由 peer 传输, 因此在此表中被视为 request.

最后于 更新