9. Claims 编码格式
9. Claims 编码格式
图 8 展示了一种希望添加远程认证的关系:
.-------------. .------------. 评估请求
| +-------------->| | 是否符合
| Attester | 访问某些资源 | Relying | 安全策略
| | | Party |
'-------------' '------------'
图 8:典型的资源访问
在此图中,Attester 和 Relying Party 之间的协议可以是任何新的或现有的协议(例如,HTTP(S)、CoAP(S)、面向资源的轻量级信息交换 (ROLIE) [RFC8322]、802.1x、OPC UA [OPCUA] 等),具体取决于使用场景。
通常,这些协议已经具有用于传递安全信息以进行身份验证和授权的机制。常见格式包括 JSON Web Tokens (JWTs) [RFC7519]、CWTs [RFC8392] 和 X.509 证书。
为已部署的协议添加远程认证需要将 RATS 概念消息添加到现有数据流中。这必须以不降低所涉及系统安全属性的方式进行,并应使用底层协议提供的扩展机制。例如,如果要为 TLS 握手扩展远程认证能力,则可以将认证 Evidence 嵌入到专用的 X.509 证书扩展中(例如,[TCG-DICE])或嵌入到新的 TLS 证书类型中(例如,[TLS-CWT])。
特别是对于受限节点,希望最小化 Relying Party 中所需的解析代码量,以便同时最小化占用空间和攻击面。虽然可以将 CWT 嵌入 JWT 中,或将 JWT 嵌入 X.509 扩展中等,但希望以 Relying Party 已经支持的格式编码信息。
这促使需要一个通用的"信息模型",以与编码无关的方式描述远程认证相关信息集,并允许多种编码格式(CWT、JWT、X.509 等)将相同的信息编码为 Relying Party 所需的 Claims 格式。
图 9 展示了 Evidence 和 Attestation Results 可能通过多种潜在的编码格式表达,以便可以通过各种现有协议传输。它还说明了为什么 Verifier 可能还负责接受以一种格式编码 Claims 的 Evidence,同时发布以不同格式编码 Claims 的 Attestation Results。
Evidence Attestation Results
.--------------. CWT CWT .-------------------.
| Attester-A +-----------. .---------->| Relying Party V |
'--------------' | | `-------------------'
v |
.--------------. JWT .---------+--. JWT .-------------------.
| Attester-B +-------->| +-------->| Relying Party W |
'--------------' | | `-------------------'
| |
.--------------. X.509 | | X.509 .-------------------.
| Attester-C +-------->| Verifier +-------->| Relying Party X |
'--------------' | | `-------------------'
| |
.--------------. TPM | | TPM .-------------------.
| Attester-D +-------->| +-------->| Relying Party Y |
'--------------' '---------+--' `-------------------'
^ |
.--------------. other | | other .-------------------.
| Attester-E +-----------' '---------->| Relying Party Z |
'--------------' `-------------------'
图 9:使用不同格式的多个 Attesters 和 Relying Parties