ToppyMicroServices

RFC 3552 Quiz

Security Considerationsの書き方

🇺🇸 🇯🇵
0 / 0

References (URLs)

範囲: RFC 3552はBCP 72です. security analysisに必要なdue diligenceを定めますが, その構成に従っただけでprotocolの安全性が証明されるわけではありません.

Q1: 良いSecurity Considerations sectionの役割として最も適切なのはどれか?

Multiple Choice
**Explanation:** Security Considerations sectionを形式的な付録にすると, 仕様のどこが危険で, 何を前提に安全と判断したのかが伝わりません. **Security Considerations section** は, protocol や mechanism の security property, threat, failure mode, mitigation を spec に結び付けて説明する節です. 宣伝文句を書く場所ではありません. RFC 3552 Sections 1と5は, relevant security issue, foreseeable threat, protection, residual riskを読み手へ伝えることを求めます. A: protocolの言い換えだけではsecurity consequenceを特定できません. B: 正解. threat, assumption, protection, remaining riskを結び付けるとreview可能な主張になります. C: あらゆるthreat modelで単に「安全」なprotocolはありません. scopeとlimitationが必要です. 良い節は implementer と operator の両方が読んで役に立ちます. protocol の美しさではなく, 失敗の仕方を説明できるかが重要です.

Q2: protection claimをreview可能にするため必要な追加はどれか?

Multi-Select

A2A profileには「TLSがAgent messageを保護する」とあります. TLSはgatewayで終端され, gatewayは選択したheaderとbodyを別connectionでbackendへ転送します. 認証されるendpointと第2 hopの保護は未定義です.

**Explanation:** RFC 3552 Section 5はlower-layer security protocolを使う場合, 期待するserviceとcombined systemのpropertyを明示するよう求めます. 保護する部分と性質, residual riskの記述も必要です. A: 選択. dataとsecurity propertyを示さなければ「protected」は曖昧です. B: 選択. TLSはconnection endpointを認証するため, gateway終端がtrust modelへ与える影響を示す必要があります. C: 選択. 最初のTLS hopだけでは第2 connectionと終端後処理を説明できません. D: 非選択. badgeはthreat analysisでもcombined-system claimでもありません.

Q3: 「新しいsecurity considerationはない」を適切に置き換える記述はどれか?

Multiple Choice

extensionはAgent Cardが保護対象resource identifierのaliasを宣言できるようにします. transport messageは増えないためdraftは「新しいsecurity considerationはない」とします. alias source, collision handling, alias非対応実装の動作は未定義です.

**Explanation:** RFC 3552 Section 5はknownまたはforeseeable risk, misapplication, related mechanismとのinteractionをdue diligenceとして扱います. 受理するresource identityの変更はwire messageを増やさなくてもauthorizationを変え得ます. A: transportの不変性はauthorization semanticsの不変性を意味しません. B: 正解. 新しいattack surface, compatibility boundary, control, residual riskを示します. C: base文書の参照だけではextension固有のcompositionを分析できません. D: 「安全」とlocal intuitionではtest可能なtrust ruleになりません.

Q4: このlower-layer dependencyをreview可能にする改訂はどれか?

Multiple Choice

draftには「session-bound proofにはmodern TLSを使う」とあります. TLSはgatewayで終端され, gatewayはexporter値をheaderでbackendへ転送します. backendは元TLS channelを検証できず, header integrityとgateway trust boundaryは未定義です.

**Explanation:** RFC 3552 Section 5はlower-layer security protocol名だけでは不十分とし, 期待serviceとcombined-system propertyを明記するよう求めます. exporter headerはTLS終端点を越えます. A: cipher suiteはforwarded headerを元channelへbindしません. B: 決定的なbackend trustとintegrity assumptionを未定義のまま残します. C: 正解. channel, derivation, trust transition, enforcement, remaining attackをreview可能にします. D: grant validityとchannel provenanceは明示的にbindして検証しない限り独立です.

Q5: このdenial-of-service threatに最も合うmitigation analysisはどれか?

Multiple Choice

unauthenticated requestによりgatewayはtask stateを割り当て, 3回のsignature verificationを行います. spoofed-source attackerはreplyを受け取らずに送信できます. stateless cookieでallocation前にreturn routabilityを証明できますが, botnetはcookieへ応答できます.

**Explanation:** RFC 3552 Sections 4.6, 4.6.3.2, and 5はDoS susceptibilityとcountermeasureをpragmaticに説明するよう求めます. receiptの証明はblind spoofed attackのcostを上げますが, 全DDoS sourceを止めません. A: 全attackを止められないことは, このcheap and severe pathの分析を省く理由になりません. B: 正解. controlをattackへ結び付け, costly workを後段へ移し, distributed residual riskを示します. C: unauthenticated cryptographic work自体がresource exhaustionの標的になります. D: return routabilityはspoofingを狭めますが, benign intentや十分なclient costを証明しません.

Q6: threat-model errorを修正する改訂はどれか?

Multiple Choice

profileはAgent requestをencryptしますが, peer authenticationもmessage integrity mechanismもありません. Security Considerationsはpassive eavesdropperだけを評価し, firewall内のdeploymentではactive network attackerが消えるとします.

**Explanation:** RFC 3552 Sections 3, 3.5, and 5はcommunication channelをほぼ完全に支配するattackerを想定し, 少なくともeavesdropping, replay, insertion, deletion, modification, MITM, DoSの検討を求めます. minimum environmentはfirewallを仮定せずadministrative boundaryを越えます. A: encryptionだけではactive manipulationを防がずpeerも識別しません. B: deployment labelはminimum Internet analysisと正当化の代わりになりません. C: 正解. 必要attack classを戻し, 明示的で根拠あるapplicability limitを許します. D: endpoint-compromise exclusionを置いてもchannel attackは消えません.

Q7: 宣言したthreat boundaryを維持するlogging要件はどれか?

Multiple Choice

threat modelはraw access token, client secret, session proofのいずれかがapplication, proxy, diagnostic logへ到達することをsuccessful attackとして扱います. request IDと明示的なnon-secret error codeはincident responseに使えます.

**Explanation:** RFC 3552 Sections 2.3, 3, and 5はsystem-security goal, asset, attacker capability, countermeasure, residual riskを明示するよう求めます. no-secret-logging policyはRFC 3552のuniversal prohibitionではなく, このprofileのthreat modelから来ます. A: authenticated readerでもoverprivilegedまたはcompromisedになり得て, 前提はsecret-bearing sinkを許しません. B: 未対象sinkから同じattack pathが残ります. C: 正解. data, enforcement coverage, allowed diagnosticを定義し, 境界を弱めません. D: reversible contentはsinkへ到達し, decryption capabilityを持つ者へcredentialを露出します.

Q8: ambiguous inputのattack surfaceを閉じる改訂はどれか?

Multiple Choice

gatewayはUnicodeとcaseをnormalizeした後にAgent identifierをauthorizeします. signature verificationは受信byteを対象とし, backendは別normalizerを使います. draftには「実装はinputをvalidateする」としかありません. encoding差により3つのcheckが異なるprincipalを識別できます.

**Explanation:** RFC 3552 Sections 3.3.4 and 5はmessage modification threat, authentication assumption, combined-system behaviorの分析を求めます. RFC自体はUnicode canonicalization algorithmを規定しません. 具体的なcanonicalization ruleは, このparser differentialへのapplication設計上の対応です. A: independent normalizerにより1つのmessageが異なるsecurity identityを持ちます. B: byte上のsignature validityはauthorization interpretationの相違を直しません. C: 正解. 1つのingress contractでparsing, signature semantics, authorization identityをreview可能にし, trust付与前に不一致を拒否します. D: authorization後のloggingはconfused-identity decisionを防がず, secret-logging boundaryにも反します.

Q9: 有効なsigned grantから導ける結論はどれか?

Multiple Choice

backendはidentity grantのsignatureを検証し, issuerを信頼します. grantはAgent Aを示しますが, resource policyはAgent Bだけにtask削除を許可します. reviewerはauthentication成功を理由にrequest受理を提案します.

**Explanation:** RFC 3552 Section 4.4はauthenticationとauthorizationを区別します. valid signatureはclaimのissuerとsubjectを確かめる材料になりますが, resource policyがそのsubjectのoperationを決めます. A: authenticationは無制限のpermissionを作りません. B: 正解. authenticated subjectとrequested actionをresource policyへ照合します. C: authentication evidenceが増えてもauthorization ruleの代わりになりません. D: gateway addressはgrant subjectを置き換えずtask-level permissionも表しません.

Q10: combined-system security analysisに含めるべき記述はどれか?

Multi-Select

Agent Card signatureはvalidで, OAuth grantは期限内で, clientはTLSでgatewayを認証しました. gatewayはidentityとsession-binding headerをbackendへ転送し, backendは元artifactを検証しません. header integrity, freshness, replay handling, gateway compromiseは未定義です.

**Explanation:** RFC 3552 Sections 2, 3, and 5はsecurity goal, attacker capability, mechanism assumption, combined-system property, residual riskを分けて記述するよう求めます. A: 選択. 各mechanismは異なる問いに答え, 特定verifierで終端します. B: 選択. 元artifactを検証しないbackendにとってevidenceはgateway assertionとそのprotectionです. C: 選択. 前提中のsuccessful checkは未定義attack pathを解決しません. D: 非選択. control数はcomposition proofになりません. E: 非選択. grant validityとchannel provenanceは明示的なbindingを検証しない限り独立です.