Protocol run identifier such as nonce or PKCE should be required

[Nat Sakimura]

Comments

Both OpenID Connect and OAuth 1.1 protects the integrity of the entire protocol run using nonce and PKCE parameters respectively. Perhaps this fact should be pointed out somewhere.

Proposal

I am unsure of where to put this, but perhaps something in the line of the following could be inserted somewhere:

JARM can be used both for OAuth and OpenID Connect. When using OAuth 2.0 without OpenID Connect, PKCE MUST be used to protect the integrity of the entire protocol run. When using OpenID Connect with response type without id_token in it, the Authorization Server MUST return nonce in the ID Token even though the ID Token is being returned from the token endpoint.

Note: OAuth 2.1 has builting PKCE in it.

‌

[Joseph Heenan]

When using OpenID Connect with response type without id_token in it, the Authorization Server MUST return nonce in the ID Token even though the ID Token is being returned from the token endpoint.

This would be a normative change to FAPI2-advanced. That’s not necessarily a problem (given that document hasn’t reached implementor’s draft yet), but I think overall it might be better to just require PKCE in all cases?

‌

[Brian Campbell]

https://lists.openid.net/pipermail/openid-specs-fapi/2022-July/002636.html

you mean and alignment with security BCP and FAPI? I would rather prefer to stay away from stating things already covered in other places (and might change). This is a small addition to OAuth to allow for signing and encryption of the response. The content of the response should be defined wherever the response type is defined or refined.

‌

https://lists.openid.net/pipermail/openid-specs-fapi/2022-July/002637.html

That is beyond the scope of JARM, which is intended to be only a small simple extension spec that allows for signing and encryption of the authorization response. Use of PKCE and/or state are discussed somewhat in the security considerations and maybe could be covered better. But JARM shouldn't be placing requirements on other unrelated protocol elements. That's more appropriate from things like the security BCP, FAPI security profiles, and OAuth 2.1.

‌

[Nat Sakimura]

@Joseph Heenan Thanks. Normative changes to drafts and implementer’s draft are just fine when it is deemed to be needed. Regarding requiring PKCE when the client and the server is using OpenID Connect is a bit too much, I think.

‌

[Brian Campbell]

The FAPI 1.0 security profiles, which are final, have a dependency on JARM. So considerations around breaking normative changes is a bit more subtle than that.

[Nat Sakimura]

@Brian Campbell So, perhaps some text in Security consideration drawing attention would be good. Having said that, I started to think that 5.4 Code Leakage is a subset of the problem of protocol run integrity. It is titled “Code Leakage” but in the note it says “An encrypted response doesn't remove the need for additional protections provided by mechanisms like PKCE [RFC7636] or the use of state parameter as described in Section 5.2.”

Leveraging that, I have created the following text.

5.5 Protocol run integrity

OAuth protocol run is made of many distinct message exchanges between the client and server to complete the issuance of Access and Refresh Tokens. Even if every message itself is integrity protected, it is still conceivable that one or more of the messages are exchanged with another message created for a different protocol run. The leakage and reuse of encrypted messages in Section 5.4 is an example of such problems. To mitigate this problem, it is considered good practice to implement additional protection provided by PKCE [RFC7636] or use nonce in the case of OpenID Connect where it would be returned in the ID Token coming back from the Token Endpoint.

BTW, Section 5.4 states the following:

5.4. Code Leakage

Authorization servers MAY encrypt the authorization response therewith providing a means to prevent leakage of authorization codes in the user agent (e.g. during transmission, in browser history or via referrer headers). Note, however, that the entire response is then potentially subject to leakage. An encrypted response doesn't remove the need for additional protections provided by mechanisms like PKCE [RFC7636] or the use of state parameter as described in Section 5.2.

In the last sentence, it is saying that the state parameter mitigates this attack but does it? The browser in this case is attacker-controlled so it may be able to set any state value, would it not? The state value certainly helps with something like CSRF against the honest user’s browser, but …

Also, I felt that having a sentence like below between 5 and 5.1 might be appropriate.

As JARM is used as a component in OAuth, much of the security considerations listed in OAuth 2.0 Security Best Current Practice [I-D.ietf-oauth-security-topics] applies. In addition, for the mechanisms described in this document, the following security considerations apply.

‌

[Nat Sakimura]

@Brian Campbell I think Joseph was talking about FAPI 2.0. Now, for FAPI 1.0, it is FINAL, but if it has an unintended bug or oversight, we should fix it with an errata. It has always been the security goal of FAPI 1.0 Advanced to keep the protocol run integrity per BCR principle. Changing normative language to fix normative requirements has precedence in OpenID Connect.

[Torsten Lodderstedt]

I suggest to remove 5.2 and advise implementers to follow the existing mechanisms for protecting the integrity of the authorization response, similar as the last sentence in Section 5.4..

[Nat Sakimura]

Accepted in principle. Add 5.5 in the spirit of Nat's text, then remove "or the use of state parameter as described in Section 5.2." from 5.4. Fix 5.2 for state.

[Brian Campbell]

PR #355 aims to do those things.