Posts Tagged ‘Threat Model

SAML Threat Model

The general Internet threat model described in the IETF guidelines for security considerations is the basis for the SAML threat model. We assume here that the two or more endpoints of a SAML (Security Assertion Markup Language) transaction are uncompromised, but that the attacker has complete control over the communications channel. Additionally, due to the nature of SAML as a multi-party authentication and authorization statement protocol, cases must be considered where one or more of the parties in a legitimate SAML transaction—who operate legitimately within their role for that transaction—attempt to use information gained from a previous transaction maliciously in a subsequent transaction.

The following scenarios describe possible attacks:

1. Collusion: The secret cooperation between two or more system entities to launch an attack, for example:

2. Denial-of-Service Attacks: The prevention of authorized access to a system resource or the delaying of system operations and functions.

3. Man-in-the-Middle Attacks: A form of active wiretapping attack in which the attacker intercepts and selectively modifies communicated data to masquerade as one or more of the entities involved in a communication association.

4. Replay Attacks: An attack in which a valid data transmission is maliciously or fraudulently repeated, either by the originator or by an adversary who intercepts the data and retransmits it,possibly as part of a masquerade attack.

5. Session Hijacking: A form of active wiretapping in which the attacker seizes control of a previously established communication association.

In all cases, the local mechanisms that systems will use to decide whether or not to generate assertions are out of scope. Thus, threats arising from the details of the original log in at an authentication authority,for example, are out of scope as well. If an authority issues a false assertion, then the threats arising from the consumption of that assertion by downstream systems are explicitly out of scope.

The direct consequence of such a scoping is that the security of a system based on assertions as inputs is only as good as the security of the system used to generate those assertions, and of the correctness of the data and processing on which the generated assertions are based. When determining what issuers to trust, particularly in cases where the assertions will be used as inputs to authentication or authorization decisions, the risk of security compromises arising from the consumption of false but validly issued assertions is a large one. Trust policies between asserting and relying parties should always be written to include significant consideration of liability and implementations should provide an appropriate audit trail.

Tags : , , , , , , , , , , , , ,