RFC 3552 Quiz

Q1: What should a good Security Considerations section primarily do?

Multiple Choice

A. Restate every protocol message while leaving threat and failure assumptions implicit B. Describe realistic threats, assumptions, and mitigations relevant to the spec C. State that the design is secure without identifying attackers or residual risks

**Explanation:** A Security Considerations section is not a formality added after the protocol is designed. It should let implementers and users understand the relevant threats and the limits of the design. A **Security Considerations section** connects the protocol to its security properties, threats, failure modes, assumptions, and countermeasures. RFC 3552 Sections 1 and 5 say the section should inform readers of relevant security issues and clearly describe foreseeable threats, protections, and residual risks. A: Repeating the protocol does not identify its security consequences. B: Correct. Threats, assumptions, protections, and remaining risk give readers reviewable claims. C: No protocol is simply “secure” in every threat model. The section must state scope and limitations. The useful question is not “does the document claim security,” but “under which assumptions does it provide which protections.”

Q2: Which additions are required to make this protection claim reviewable?

Multi-Select

An A2A profile says, “TLS protects Agent messages.” TLS terminates at a gateway; the gateway forwards selected headers and the body to a backend over a separate connection. The draft does not identify which endpoint is authenticated or whether the second hop is protected.

A. Identify the protected fields and whether each gets confidentiality, integrity, or authentication B. State the authenticated TLS endpoint and the trust assumption at the gateway C. Describe second-hop exposure and residual risk after gateway processing D. Replace the details with a compliance badge showing that TLS is enabled

**Explanation:** RFC 3552 Section 5 requires authors using a lower-layer security protocol to specify the services expected from it and the resulting properties of the combined system. It also requires protected portions and properties to be identified and residual risk to be described. A: Selected. “Protected” is ambiguous without naming data and security properties. B: Selected. TLS authenticates a connection endpoint; the profile must say how gateway termination affects the trust model. C: Selected. The first TLS hop says nothing by itself about the second connection or post-termination processing. D: Not selected. A badge is not a threat analysis or a combined-system security claim.

Q3: Which replacement for “no new security considerations” is adequate?

Multiple Choice

An extension lets an Agent Card declare aliases for protected resource identifiers. It adds no new transport messages, so the draft says, “This extension has no new security considerations.” Alias sources, collision handling, and the behavior of implementations without alias support are unspecified.

A. Keep the sentence because unchanged transport implies unchanged authorization B. Analyze alias injection, collisions, trusted sources, unsupported peers, mitigations, and remaining risk C. Cite the base profile without examining how aliases compose with its resource matching D. State that implementations should be secure and leave alias acceptance to local intuition

**Explanation:** RFC 3552 Section 5 requires due diligence for known or foreseeable risks, including misapplication and interaction with related mechanisms. A change to accepted resource identity can alter authorization without adding a wire message. A: Transport stability does not imply stable authorization semantics. B: Correct. It names the new attack surface, compatibility boundary, controls, and residual risk. C: A base reference does not analyze the extension-specific composition. D: “Secure” and local intuition do not give implementers a testable trust rule.

Q4: Which revision makes this lower-layer dependency reviewable?

Multiple Choice

A draft says, “Use modern TLS for session-bound proof.” TLS terminates at a gateway, which forwards an exporter value in a header to the backend. The backend cannot verify the original TLS channel, and the draft does not define header integrity or the gateway trust boundary.

A. List an approved cipher suite and call the forwarded header session-bound B. Require TLS at the gateway and leave the backend's acceptance rule undocumented C. Define the TLS endpoints, exporter derivation, header integrity, gateway trust, and replay/substitution risks D. Treat a valid access grant as proof that the forwarded exporter came from the same TLS session

**Explanation:** RFC 3552 Section 5 says naming a lower-layer security protocol is insufficient: expected services and the resulting combined-system properties must be specified. The exporter header crosses the endpoint where TLS terminates. A: A cipher suite does not bind a forwarded header to the original channel. B: This leaves the decisive backend trust and integrity assumptions undefined. C: Correct. It makes the channel, derivation, transition of trust, enforcement, and remaining attacks reviewable. D: Grant validity and channel provenance are independent properties unless the protocol explicitly binds them.

Q5: Which mitigation analysis best fits this denial-of-service threat?

Multiple Choice

An unauthenticated request makes a gateway allocate task state and perform three signature verifications. A spoofed-source attacker can send requests without receiving replies. A stateless cookie can prove return routability before allocation, but a botnet can still answer cookies.

A. Call denial of service out of scope because not every distributed attack can be stopped B. Require a cookie before costly work; state its spoofing benefit, cost, and residual botnet risk C. Perform all signature checks first because cryptography makes the request trustworthy D. Claim the cookie prevents denial of service once return routability succeeds

**Explanation:** RFC 3552 Sections 4.6, 4.6.3.2, and 5 require denial-of-service susceptibility and countermeasures to be described pragmatically. Proving receipt can raise the cost of a blind spoofed attack without stopping every DDoS source. A: Inability to stop every attack does not excuse analysis of this cheap, severe path. B: Correct. It connects the control to the attack, orders costly work, and states the remaining distributed risk. C: Unauthenticated cryptographic work can itself be the resource-exhaustion target. D: Return routability narrows spoofing; it does not prove benign intent or sufficient client cost.

Q6: Which revision corrects the threat-model error?

Multiple Choice

A profile sends encrypted Agent requests but has no peer authentication or message-integrity mechanism. Its Security Considerations evaluates only passive eavesdroppers and says deployment behind a firewall removes active network attackers.

A. Keep the model because encryption converts every active attacker into a passive one B. Keep the model if the firewall vendor describes the internal network as trusted C. Analyze insertion, deletion, modification, replay, and MITM, then justify any scope limit D. Remove the threat model because endpoint compromise is difficult for protocols to solve

**Explanation:** RFC 3552 Sections 3, 3.5, and 5 assume near-complete attacker control of the communications channel and require at least eavesdropping, replay, insertion, deletion, modification, MITM, and denial of service to be considered. The minimum environment crosses administrative boundaries without assuming firewalls. A: Encryption alone does not prevent active manipulation or identify the peer. B: A deployment label cannot replace the minimum Internet analysis and justification. C: Correct. It restores the required attack classes while allowing an explicit, reasoned applicability limit. D: An endpoint-compromise exclusion does not eliminate channel attacks.

Q7: Which logging requirement preserves the stated threat boundary?

Multiple Choice

The threat model treats any raw access token, client secret, or session proof reaching an application, proxy, or diagnostic log as a successful attack. Request IDs and explicit non-secret error codes remain useful for incident response.

A. Permit raw secrets when log access is authenticated and retention is short B. Redact only application logs and leave proxy and diagnostic sinks to local defaults C. Remove defined secrets before every covered sink; allow only named non-secret diagnostic identifiers D. Encrypt secrets reversibly in logs so the stored values are not plaintext

**Explanation:** RFC 3552 Sections 2.3, 3, and 5 require system-security goals, assets, attacker capabilities, countermeasures, and residual risk to be explicit. The no-secret-logging policy comes from this profile's threat model, not from a universal RFC 3552 prohibition. A: Authenticated readers can still be overprivileged or compromised, and the premise admits no secret-bearing sink. B: An omitted sink preserves the same attack path. C: Correct. It defines data, enforcement coverage, and allowed diagnostics without weakening the stated boundary. D: Reversible content still reaches a sink and exposes credentials with the decryption capability.

Q8: Which revision closes the ambiguous-input attack surface?

Multiple Choice

A gateway authorizes an Agent identifier after Unicode and case normalization. Signature verification covers the received bytes, and a backend applies a different normalizer. The draft says only, “Implementations validate input.” Different encodings can therefore identify different principals at the three checks.

A. Let every component normalize independently because all transformations are locally valid B. Compare only the raw bytes for signatures and ignore the authorization identity mismatch C. Define accepted syntax and one canonical identity at ingress, bind checks to it, and reject ambiguous forms D. Log every raw value and resolve disagreements manually after authorization

**Explanation:** RFC 3552 Sections 3.3.4 and 5 require message-modification threats, authentication assumptions, and combined-system behavior to be analyzed. It does not itself prescribe a Unicode canonicalization algorithm. The concrete canonicalization rule is an application design response to the demonstrated parser differential. A: Independent normalizers let one message acquire different security identities. B: Signature validity over bytes does not repair a different authorization interpretation. C: Correct. A single ingress contract makes parsing, signature semantics, and authorization identity reviewable and rejects disagreement before trust is granted. D: Post-authorization logging neither prevents the confused-identity decision nor fits the secret-logging boundary.

Q9: What conclusion follows from a valid signed grant?

Multiple Choice

A backend verifies the signature on an identity grant and trusts the issuer. The grant names Agent A, but the resource policy permits only Agent B to delete the task. A reviewer proposes accepting the request because authentication succeeded.

A. Accept, because a trusted signature grants every operation to the authenticated subject B. Reject unless authorization policy permits Agent A to delete this task C. Accept if TLS is also valid, because two authentication mechanisms imply authorization D. Ignore the grant identity and authorize by the gateway's network address

**Explanation:** RFC 3552 Section 4.4 distinguishes authentication from authorization. A valid signature can support who issued a claim and which subject it names; resource policy still controls what that subject may do. A: Authentication does not create unrestricted permission. B: Correct. The authenticated subject and requested action must be evaluated against the resource policy. C: More authentication evidence does not substitute for an authorization rule. D: The gateway address neither replaces the grant subject nor expresses task-level permission.

Q10: Which statements belong in the combined-system security analysis?

Multi-Select

An Agent Card signature is valid, an OAuth grant is unexpired, and the client authenticated the gateway with TLS. The gateway forwards identity and session-binding headers to a backend, which verifies neither original artifact. Header integrity, freshness, replay handling, and gateway compromise are not yet specified.

A. Card, grant, TLS, and forwarded-header checks provide distinct properties at distinct boundaries B. Backend acceptance depends on an explicit gateway trust and protected-header contract C. Freshness, replay, header substitution, and gateway compromise remain to be analyzed D. Any three successful controls prove the composed request is secure E. A valid grant proves the forwarded session binding originated on the client's TLS channel

**Explanation:** RFC 3552 Sections 2, 3, and 5 require security goals, attacker capabilities, mechanism assumptions, combined-system properties, and residual risk to be stated separately. A: Selected. Each mechanism answers a different question and terminates at a particular verifier. B: Selected. Without original verification, the backend's evidence is the gateway assertion and the protection given to that assertion. C: Selected. None of the successful checks in the premise resolves these unspecified attack paths. D: Not selected. Control count is not a composition proof. E: Not selected. Grant validity and channel provenance are independent unless an explicit binding is verified.

Writing Security Considerations

References (URLs)

Q1: What should a good Security Considerations section primarily do?

Q2: Which additions are required to make this protection claim reviewable?

Q3: Which replacement for “no new security considerations” is adequate?

Q4: Which revision makes this lower-layer dependency reviewable?

Q5: Which mitigation analysis best fits this denial-of-service threat?

Q6: Which revision corrects the threat-model error?

Q7: Which logging requirement preserves the stated threat boundary?

Q8: Which revision closes the ambiguous-input attack surface?

Q9: What conclusion follows from a valid signed grant?

Q10: Which statements belong in the combined-system security analysis?