ToppyMicroServices

RFC 5056 Quiz (JA)

Channel Bindingの使い方

ENJA
0 / 0

参照（URL）

Q1: channel bindingが答えられるsecurity上の問いはどれか

単一選択

agentがTLS connection内のSASL mechanismでauthenticationを行います. profileは, 攻撃者がTLSを終端し, application authenticationを別のTLS connectionへrelayする攻撃を検出したいと考えています.

**解説:** A: authorizationは, applicationまたはdeploymentが別に判断します. B: RFC 5056 Sections 2 and 3は, application-layer authenticationをsecure channelへ結び付け, 双方が同じbindingを観測したと確認できる仕組みを定義します. これによりchannel relayを検出できます. C: certificate path validationは, RFC 5056が定義するchannel-binding機能ではありません. D: business messageの同一性には, channel bindingが提供しないapplication semanticsが必要です.

Q2: nested channelでauthenticationをどうbindすべきか

単一選択

A2A connectionには, 同じchannel-binding typeのsecure channelが二重にnestしています. 独立したimplementationは, 選択したbinding dataをserializeして比較します.

**解説:** A: RFC 5056 Section 2.1は, 同じtypeのnested channelでは最も内側を選び, canonical octet encodingを使うよう求めます. B: RFC 5056は, nesting規則として連結を定義していません. implementation固有のstructureも相互運用可能な比較値になりません. C: このscenarioに関係するSection 2.1の三点, typeの指定, 最も内側のsame-type channelの選択, canonical bytesの使用を満たします. D: 確立順序やlocal successだけでは, 双方が同じbindingを比較したと確認できません.

Q3: backendはforwardされたbinding値から何を結論できるか

単一選択

gatewayがclient TLS connectionを終端してchannel bindingを導出し, 別のgateway-to-backend TLS connection上の通常のHTTP headerでその値を転送します. backendは, 自身のapplication authenticationがclient TLS channelへ直接bindされていると主張したいと考えています.

**解説:** A: 二つのTLS hopは別のchannel instanceです. 値をcopyしてもendpointは一体化しません. B: gateway authenticationはdelegated trust modelを構成できますが, 保護されていないheaderはbackendに対する真正なgateway assertionになりません. C: RFC 5056はtrusted intermediaryを禁止していません. security claimを, 実際にbindしたchannelとapplication authenticationへ一致させる必要があります. D: RFC 5056 Sections 3 and 8に従い, application authenticationとchannel-binding constructionを組み合わせて分析します. gateway assertionも別の設計として成立し得ますが, そのtrust boundaryとintegrityはlocal profileの責務です.

Q4: per-sessionのreplay要件に合うbindingはどれか

単一選択

profileは, 一つのsecure-channel sessionで取得されたauthentication proofが, 同じserver certificateを使う場合でも, 新しいsessionを確立した後には失敗することを求めています.

**解説:** A: RFC 5056 Section 2.1は, 複数のchannel instanceでendpointを識別し得るendpoint bindingと, unique bindingを区別します. B: replayを検出するには, threat modelに含まれるsession間でbindingがuniqueでなければなりません. Section 8.1は, 再確立時のnon-unique bindingのriskを説明します. C: application authenticationは必要ですが, 再利用されるbinding値をper-session値には変えません. D: lifetimeを延ばすとcontinuityが強まり, 提示されたreplay基準とは逆になります.

Q5: 別exchangeでbinding dataを比較するとき何が不足しているか

単一選択

二つのagentがsecure channelから同じtypeのchannel bindingを導出します. その後, messageを改変可能な別exchangeを介してbinding値をA2A coordinatorへ送り, coordinatorは値の一致を元channelのbinding証明として扱います.

**解説:** A: 正しいderivationは, 値を運ぶ別exchangeを保護しません. B: RFC 5056 Section 3は, 別のprotected exchangeを使う場合に少なくともintegrityを求めます. また, coordinatorは誰の観測を比較するのか知るためにapplication authenticationを必要とします. C: 比較のintegrityと, channel-binding modelに必要なidentity associationの両方を提供します. D: 値を増やしても, 攻撃者が改変できるcarrierはauthenticateされません.

Q6: 正確なsecurity claimを保つgateway設計はどれか

単一選択

gatewayがagent grantをvalidateし, agent authenticationがclient-to-gateway channelへbindされていることをverifyします. 別のTLS connectionにあるbackendが要求resourceを所有し, 最終authorizationを判断します. backendが受け取るのはgateway生成のassertionだけです.

**解説:** A: RFC 5056 Sections 3 and 8はgatewayのclient-channel claimを支えます. 一方, protected assertionとbackend authorizationは, 明示されたcompositionおよびlocal trust decisionです. gatewayが観測したchannelをclient-to-backendの直接channelと言い換えてはいけません. B: 同じ管理範囲でも, binding dataを導出したendpointやinstanceは変わりません. C: grant validationとchannel bindingは独立した問いへ答えます. 一方から他方は導けません. D: authenticationをchannelへbindしても, backend所有resourceへのpermissionは付与されません.