Page Comparison

Assertion manufacture/modification: An Attacker may generate a bogus assertion or modify the assertion content (such as the authentication or attribute statements) of an existing assertion, causing the RP to grant inappropriate access to the Subscriber.

1. The assertion may be digitally signed by the Verifier. The RP should check the digital signature to verify that it was issued by a legitimate Verifier.

2. The assertion may be sent over a protected session such as TLS/SSL. In order to protect the integrity of assertions from malicious attack, the Verifier shall be authenticated.

Y

Y

Y

• OIDC Core, Section 16.11: “For the HTTP binding defined by this specification, the responses to Token Requests are bound to the corresponding requests by message order in HTTP, as both the response containing the token and requests are protected by TLS, which will detect and prevent packet reordering.”
• JSON Web Signature

In OIDC Core,i t’s not clear where the requirement that the “assertion consumer” endpoint, i.e., JWT consumer endpoint, MUST be TLS .   This could be addressed in the profile, under Client Registration

Assertion disclosure: Assertions may contain authentication and attribute statements that include sensitive Subscriber information. Disclosure of the assertion contents can make the Subscriber vulnerable to other types of attacks.

1. The assertion may be sent over a protected session to an authenticated RP.

2. If assertions are signed by the Verifier, they may be encrypted for a specific RP with no additional integrity protection.

N

Y

Y

• OIDC Core, Section 3.1.3 Communication with the Token Endpoint MUST utilize TLS.
• JSON Web Encryption

Assertion repudiation by the Verifier: An assertion may be repudiated by a Verifier if the proper mechanisms are not in place. For example, if a Verifier does not digitally sign an assertion, the Verifier can claim that it was not generated through the services of the Verifier.

The assertion may be digitally signed by the Verifier using a key that supports non-repudiation. The RP should check the digital signature to verify that it was issued by a legitimate Verifier.

N

N

Y

• JSON Web Signature

Assertion repudiation by the Subscriber: Since it is possible for a compromised or malicious subscriber to issue assertions to the wrong party, a subscriber can repudiate any transaction with the RP that was authenticated using only a bearer assertion.

To mitigate this threat, the Verifier may issue holder of key, rather than bearer assertions. The Subscriber can then prove possession of the asserted key to the RP. If the asserted key matches the subscriber’s long term credential (as provided by the CSP) it will be clear to all parties involved that it was the Subscriber who authenticated to the RP rather than a compromised Verifier impersonating the Subscriber.

N

N

N

• This is currently being worked on in OAuth for JWT.  For use in general deployment browser support for channel ID is required.  Support for a limited set of web clients with TLS client Auth support(like SAML POP) will be available first.
• PoP support for binding AT to clients is also part of this work.

Assertion redirect: An Attacker uses the assertion generated for one RP to obtain access to a second RP.

To mitigate this threat, the assertion may include the identity of the RP for whom it was generated. The RP verifies that incoming assertions include its identity as the recipient of the assertion.

N

Y

Y

• OIDC ID Tokens are JWT. 
• OIDC Core, Section 2:
  aud:REQUIRED. Audience(s) that this ID Token is intended for. It MUST contain the OAuth 2.0 client_id of the Relying Party as an audience value.
• OIDC Core, Section 3.1.3.7
  The Client MUST validate that the aud (audience) Claim contains its client_id value registered at the Issuer identified by the iss (issuer) Claim as an audience.

Assertion reuse: An Attacker attempts to use an assertion that has already been used once with the intended RP.

To mitigate this threat, the following mechanisms may be used:

1. The assertion includes a timestamp and has a short lifetime of validity.The RP checks the timestamp and lifetime values to ensure that the assertion is currently valid. The lifetime value may either be in the assertion or set by the RP.

2. The RP keeps track of assertions that were consumed within a (configurable) time window to ensure that an assertion cannot be used more than once within that time window.

Y

Y

Y

• OIDC Core, Section 3.1.3.7
  9. The current time MUST be before the time represented by the exp Claim.
  10. The iat Claim can be used to reject tokens that were issued too far away from the current time, limiting the amount of time that nonces need to be stored to prevent attacks. The acceptable range is Client specific.

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

• JSON Web Signature
• TLS?