Liberty ID-FF Bindings and Profiles Specification - Liberty Alliance

Liberty Alliance Project:Liberty ID-FF Bindings and Profiles SpecificationVersion: 1.2-errata-v2.022042205220622072208220922102211Description: Some of the messages may carry a element, which is recommended to be integrityprotectedby the producer and optionally confidentiality-protected. If these practices are not followed, an adversarycould trigger unwanted side effects. In addition, by not confidentiality-protecting the value of this element, a legitimatesystem entity could inadvertently expose information to the identity provider or a passive attacker.Countermeasure: Follow the recommended practice of confidentiality- and integrity-protecting the data. Note: Because the value of this element is both produced and consumed by thesame system entity, symmetric cryptographic primitives could be utilized.4.4.2. Single Sign-On and Federation221222132214221522162217221822192220222122222223222422252226222722282229223022312232223322342235223622372238223922402241224222434.4.2.1. Common Interactions for All Single Sign-On and Federation ProfilesThreat: sent over insecure channelDescription: It is recommended that the initial exchange to access the intersite transfer service be conducted overa TLS-secured transport. Not following this recommendation can expose the exchange to both passive and activeattacks.Countermeasure: Deploy the intersite transfer service under an https scheme.Threat: Unsigned messageDescription: The signature element of an is optional and thus the absence of the signaturecould pose a threat to the identity provider or even the targeted service provider. For example, a spurious system entitycould generate an unsigned and redirect the user agent to the identity provider. The identityprovider must then consume resources.Countermeasure: Sign the . The IDP can also verify the identity of the Principal in theabsence of a signed request.Threat: Replay of an authentication assertionDescription: After obtaining a valid assertion from an identity provider, either legitimately or surreptitiously, theentity replays the assertion to the Service at a later time. A digital signature must cover the entire assertion, thuselements within the assertion cannot be corrupted without detection during the mandatory verification step. However,it is possible to fabricate an with the valid assertion.Countermeasure: The issuer should sign messages. Signing binds the of the response message to the assertion it contains. This binding accords the relyingparty the opportunity to temporally judge the response. Additionally, a valid signature over the responsebinds the element to the corresponding . (Specifying a shortperiod that the authentication assertion can be relied upon will minimize, but not mitigate this threat. Binding the to the request element may also be handy.)Threat: Fabricated denial of serviceDescription: An attacker captures the sent in an message by a serviceprovider to an identity provider, and sends several spurious messages to the service providerwith the same . Because the matches a that the service provider had used, the service provider goes through the process of validating the signature in themessage. Thus, it is subject to a denial of service attack.Countermeasure: A secure communication channel should be established before transferring requests and responses.Threat: Collusion between two PrincipalsLiberty Alliance Project65