RFC 9261 Quiz

TLS の Exported Authenticator

0 / 0

References (URLs)

Q1: RFC 9261 の Exported Authenticator は何をする仕組みか

Multiple Choice
**Explanation:** RFC 9261が提供するのはconnection-boundな暗号部品であり, tenant identity, attestationの意味, authorizationはapplication側で定めます. **Exported Authenticator**はcertificate identityに対応するprivate keyの所有を証明します. **post-handshake**はTLSまたはDTLS connectionがすでに確立した後という意味です. A: RFC 9261 は X.509 を置き換えません. X.509 certificate などの identity を使います. B: CertificateVerifyがprivate key possessionを証明し, authenticatorは既存connectionとauthenticator transcriptへ結びつきます. C: tenant, workload, agent, authorization policy などは application protocol や verifier policy 側で定義します.

Q2: RFC 9261自体が提供しない責務または効果はどれか. 複数選択

Multi-Select
**Explanation:** RFCはconnection-boundなauthenticatorの作成・検証を定めますが, application上の意味は割り当てず, underlying TLS connection stateも変更しません. **verifier policy** は提示された identity や attestation を受け入れるかを決める規則です. **application-level meaning** は tenant, service, task などの文脈です. A: RFC 9261 は tenant や workload の意図を自動では知りません. B: connection 由来の材料を使うことは RFC 9261 の中核です. C: これは application, verifier, deployment が決めます. D: authenticator は independent かつ unidirectional で, 作成や検証で TLS state が明示的に変わるわけではありません.

Q3: certificate_request_context について正しいものはどれか. 複数選択

Multi-Select
**Explanation:** certificate_request_contextのuniquenessとunpredictabilityは, replayとcontext confusionを防ぐsecurity controlです. **certificate_request_context** は request を識別する opaque value です. **opaque** は protocol が中身を名前として解釈しない byte string という意味です. A: request と response を結びつけます. B: 再利用は replay や context confusion の原因になります. C: 同じ connection 内で unique である必要があります. D: 一時的な private key exposure による precomputation を避ける意味があります.

Q4: non-empty authenticator で検証すべきものはどれか

Multiple Choice
non-empty authenticator は certificate chain だけではありません.
Certificate identity chain CertificateVerify 秘密鍵の証明 Finished MAC check
**Explanation:** non-empty authenticatorはcertificate validation, private key possessionの証明, connectionとtranscriptへ結びつくFinishedを組み合わせます. **CertificateVerify** は authenticator transcript に対して private key の所有を示します. **Finished** は TLS connection と transcript から導いた材料で MAC を確認します. A: proof と transcript check を落としています. B: RFC 9261 の non-empty authenticator validation は connection, request, authenticator transcript に依存します. C: certificate name check だけでは足りません.

Q5: cross-connection reuse はどう評価すべきか

Multiple Choice
別 connection で作った proof は, そのまま別 connection で通るべきではありません.
Connection A authenticator 作成 reuse attempt Connection B proof 検証 Fail context mismatch
**Explanation:** RFC 9261 Section 5.2.2は,異なるconnectionでgenerationとvalidationを行うとHandshake Contextが異なり,CertificateVerify validationに失敗すると定めます. **Handshake Context** は connection と authenticator data から導かれる値です. **channel binding** は proof を特定の TLS/DTLS connection に結びつけることです. A: 同じ certificate だけでは不十分です. B: full validation path を省いた model は proof obligation を示すもので, RFC 9261 全体の破綻証明ではありません. C: generation と validation が別 connection なら CertificateVerify validation は失敗します.

Q6: empty authenticator は何を意味するか

Multiple Choice
**Explanation:** empty authenticatorはprotocol-definedなauthenticated refusalです. validate APIはwell-formedなempty authenticatorをinvalidとして返し, 追加identityを返しません. **empty authenticator** は Certificate や CertificateVerify を持たない Finished-only の object です. **authenticated refusal** は, 拒否そのものに integrity があるという意味です. A: well-formed empty authenticator は refusal であり, identity validation としては invalid と扱われます. B: identity や attestation は認証されていません. C: TLS version upgrade とは関係ありません.

Q7: aTLS deployment で empty authenticator を扱うときの policy check はどれか. 複数選択

Multi-Select
**Explanation:** RFC 9261 Section 6はempty authenticatorをauthenticated refusalと定義し,Section 7.4はwell-formed empty authenticatorをinvalidとして返します. **attestation required** は application 側の policy です. **no attestation identity** は, policy が承認できる identity evidence が返っていない状態です. A: identity がないのに attestation success と返すのは危険です. B: valid EA processing と attestation verified は別の outcome です. C: empty authenticator は refusal であって attestation success ではありません. D: policy enforcement のために結果を明確に分ける必要があります.

Q8: modelの結果をどこまで一般化できるか

Multiple Choice

same-endpointのformal analysisが, full CertificateVerifyとFinished transcript checkを含むRFC 9261 validationの一部を省いたreduced modelを使っているとします.

**Explanation:** RFC 9261 Sections 5.2.2から5.2.4がCertificateVerify,Finished,full authenticator validationを定めます.それらを省いたreduced modelはproof obligationを示せても,同じ強さのfull-system claimは支えられません. **reduced model** は一部の詳細を省いた model です. **proof obligation** は full system でまだ確認すべき主張です. A: model の範囲を超えた強い読みです. B: full CertificateVerify / Finished transcript check を抽象化しているため, proof obligation として読むのが適切です. C: non-empty authenticator validation ではそれらの check が重要です.

Q9: このfindingをどうscopeすべきか

Multiple Choice

deployment-specificなattestation analysisが, 独自attestation binderで使うexporter-label parameterを指摘しています. RFC 9261のregistered label自体の誤りは指摘していません.

**Explanation:** RFC 9261 Section 5.1がExported Authenticatorのexporter labelを固定し,Section 8.2が登録します.deployment-specificなbinder parameterはそのregistered labelとは別であり,支えるclaimも異なります. **exporter label** は TLS exporter の用途を分ける文字列です. **attestation binder** は attestation evidence を protocol context に結びつける application-specific value です. A: RFC 9261 の registered label が間違っているという話ではありません. B: label や binder parameter は policy design に関係することがあります. C: scope は deployment-specific な parameter と verifier policy です.

Q10: このmissing-attestation caseをどう分類すべきか

Multiple Choice

deploymentがauthenticated refusalを表すwell-formedなempty authenticatorを受信しました. application policyはattestation successを返す前にattestation identityを必須としています.

**Explanation:** RFC 9261 Section 6がauthenticated refusalを定義し,Section 7.4はwell-formed empty authenticatorをinvalidとして返します.そのno-identity resultがattestation requirementを満たすかはapplication policyで判断します. **missing attestation** は policy が必要とする attestation identity が返っていない状態です. **verified attestation** は verifier が policy に基づいて evidence を承認した状態です. A: application は no-attestation を attestation success と混同してはいけません. B: RFC 9261 は empty authenticator を許しています. C: authenticated refusal は protocol の一部です.