Security Analysis
...
| Secondary authenticators: Secondary authenticators include assertions in the direct model, session keys in Kerberos, assertion references in the indirect model, and cookies used for authentication. | Mitigation Required at LoA | |||||
|---|---|---|---|---|---|---|
Threat | SP800-63 Mitigations | 1 | 2 | 3 | 4 | OIDC Code Flow - |
Secondary authenticator manufacture: An Attacker may attempt to generate a valid secondary authenticator and use it to impersonate a Subscriber. | To mitigate this threat, one of the following mechanisms may be implemented: 1. The secondary authenticator may contain sufficient entropy that an Attacker without direct access to the Verifier’s random number generator cannot guess the value of a valid secondary authenticator. 2. The secondary authenticator may contain timely assertion data that is signed by the Verifier or integrity protected using a key shared between the Verifier and the RP. 3. The Subscriber may authenticate to the RP directly using his or her long term token and avoid the need for a secondary authenticator altogether. | Y | Y | Y | Y |
|
Secondary authenticator capture: The Attacker may use a session hijacking attack to capture the secondary authenticator when the Verifier transmits it to the Subscriber after the primary authentication step, or the Attacker may use a man-in-the-middle attack to obtain the secondary authenticator as it is being used by the Subscriber to authenticate to the RP. If, as in the indirect model, the RP needs to send the secondary authenticator back to the Verifier in order to check its validity or obtain the corresponding assertion data, an Attacker may similarly subvert the communication protocol between the Verifier and the RP to capture a secondary authenticator. In any of the above scenarios, the secondary authenticator can be used to impersonate the Subscriber. | To mitigate this threat, adequate protections shall be in place throughout the lifetime of any secondary authenticators used in the assertion protocol. 1. In order to protect the secondary authenticator while it is in transit between the Verifier and the Subscriber, the secondary authenticator shall be sent via a protected session established during the primary authentication of the Subscriber using his or her token. This requirement is the same as the requirement in Section 8, regarding the Authentication Process, to protect sensitive data (in this case the secondary authenticator)from session hijacking attacks. 2. In order to protect the secondary authenticator from capture as it is submitted to the RP, the secondary authenticator shall be used in an authentication protocol which protects against eavesdropping and man-inthe-middle attacks. 3. In order to protect the secondary authenticator after it has been used, it shall never be transmitted on an unprotected session or to an unauthenticated party while it is still valid. The secondary authenticator may be sent in the clear only if the sending party has strong assurances that the secondary authenticator will not subsequently be accepted by any other RP. This is possible if the secondary authenticator is specific to a single RP, and if that RP will not accept secondary authenticators with the same value until the maximum lifespan of the corresponding assertion has passed. | N | Y | Y | Y |
|
| Assertion Binding: the binding between the secret used to authenticate to the RP and the assertion data referring to the Subscriber shall be strong. | Mitigation Required at LoA | |||||
|---|---|---|---|---|---|---|
Threat | SP800-63 Mitigations | 1 | 2 | 3 | 4 | OIDC Mitigations |
Assertion substitution:A subscriber may attempt to impersonate a more privileged subscriber by subverting the communication channel between the Verifier and RP, for example by reordering the messages, to convince the RP that his or her secondary authenticator corresponds to assertion data sent on behalf of the more privileged subscriber. This is primarily a threat to the indirect model, since in the direct model, assertion data is directly encoded in the secondary authenticator. | To mitigate this threat, one of the following mechanisms may be implemented: 1. Responses to assertion requests, signed or integrity protected by the Verifier, may contain the value of the assertion reference used in the request or some other nonce that was cryptographically bound to the request by the RP. 2. Responses to assertion requests may be bound to the corresponding requests by message order, as in HTTP, provided that assertions and requests are protected by a protocol such as TLS that can detect and disallow malicious reordering of packets. | N | Y | Y | Y |
|
...