ToppyMicroServices

RFC 5705 Quiz (JA)

TLS Keying Material Exporters

ENJA
0 / 0

参照（URL）

範囲: ここではTLS 1.2とRFC 5705のconstructionを扱います.TLS 1.3のexporter constructionはRFC 8446で定義されます.RFC 5705はkeying materialを提供しますが,context encoding,proof semantics,key handling,gateway trustはapplication profileが定義します.

Q1: RFC 5705のexported keying materialを決めるinputはどれか

単一選択

二つのTLS 1.2 peerが, 確立済みTLS sessionから同じapplication固有の32-byte値を導出したいと考えています.

**解説:** A: cipher suiteはTLS sessionを通じて関与しますが, application purposeやcontextは識別しません. B: RFC 5705 Section 4は,TLS-session state,label,提供される場合のcontext value,要求lengthからexporterを定義します.contextなしのconstructionは,zero-length contextを提供する場合と異なります.同じoutputには双方で同じinputが必要です. C: applicationがcontextへ選択したsemanticsをencodeする場合はありますが, これらは暗黙のexporter inputではありません. D: specified exporter constructionで導出しないshared stringはexported keying materialではありません.

Q2: applicationはexporterのpurposeとcontextをどう確立すべきか

単一選択

A2A protocolがTLS handshake後にexporter利用をnegotiateします. そのcontextにはapplication messageで送るtask identifierが含まれます.

**解説:** A: RFC 5705 Sections 3 and 5はpurpose separationへlabelを使います. generic labelはそのseparationを弱めます. B: Section 3は, context確立に使うupper-layer messageがTLS Finishedで自動的にcoverされないと説明します. C: semanticsが似ていてもbyteが異なるcontextは異なるoutputとなり, interpretation gapを生みます. D: Section 3はapplication contextを安全に確立し, exporter利用をsignalするよう求めます. labelがapplication purposeを識別します.

Q3: backendはforwardされたexporter bytesを自身のchannel evidenceとして扱えるか

単一選択

gatewayがclient TLS 1.2 sessionを終端してRFC 5705 outputを導出し, 別のTLS sessionでbackendへbytesをforwardします. backendは, clientがbackend connectionのkeying materialをshareするproofとして使おうとしています.

**解説:** A: RFC 5705 Section 4はoutputを一つのTLS session, label, contextへ対応付けます. transportしてもoriginは変わりません. B: 異なるTLS stateのsessionでlabelが等しくても, 一つのshared channelのevidenceにはなりません. C: exporter scopeとgateway trust modelを分離しています. assertionのintegrity, authentication, semanticsはA2A profileが定義します. D: applicationはsecurity designに従ってderived valueを利用, transportできます. 問題はforward値へ付けるclaimです.

Q4: 二つのexporter purposeをどう分離すべきか

単一選択

同じTLS sessionから32-byteのrequest-proof keyと32-byteのaudit-chain keyを導出します. draftは両方に同じlabelとcontextを使い, 呼び出しfunctionだけで区別します.

**解説:** A: 一つのsessionでexporter inputが同じなら, callerのfunction nameに関係なく同じmaterialが得られます. B: RFC 5705 Section 5は, 同じmaster_secretで同じlabelを異なるpurposeへ使わないよう求めます. 異なるlabelがpurposeを分離し, contextはSections 3 and 4で説明されるprofile-defined roleを持ちます. C: 導出後の比較ではkey reuseを取り消せません. D: lengthの操作はdisjoint purpose labelの代替にならず, materialがoverlapする可能性があります.

Q5: RFC 5705のindependenceにより,このMAC keyのloggingは安全になるか

単一選択

A2A serviceはexporter値を導出し, request proofのMAC keyとして直接使います. diagnosticsのためoperations teamが読めるlogへ値を記録します. teamはRFC 5705のexporter independenceにより安全だと主張しています.

**解説:** A: independenceはexporter useとTLS内部のcompromise範囲を制限しますが, discloseしたkeyを無効にしません. B: traffic secretをprivateに保っても, logにあるapplication keyのconfidentialityは保てません. C: この設計ではkey自体がdirect MAC useに十分です. D: RFC 5705 Section 5はindependence propertyを説明します. そのpropertyはexporter outputをpublicにはしません. applicationは用途に応じてmaterialを保護する必要があります.

Q6: gateway retryでexporter-bound proofをどう維持すべきか

単一選択

clientがvalidなgrantと, TLS session Aから導出したproofをgatewayへ送ります. gatewayはTLS session Bでbackendへrequestをretryします. resourceを所有するbackendは, proofがretry後のmethod, target, bodyをcoverしたか知る必要があります.

**解説:** A: RFC 5705 Section 4はoutputをTLS sessionとexporter inputへscopeします. 二つの案はverifierとtrust boundaryを正確に配置し, request contextを維持します. backend authorizationは別です. B: grant validityとTLS-session bindingは独立した保証です. C: session B outputはsession B endpointのknowledgeを示し, 元client endpointのknowledgeは示しません. D: grantだけではexporter possessionやretry requestのintegrityを証明しません.