Thanks for the comments and questions Neil. With the help of the draft co-authors, I've tried to reply (probably inadequately!) inline below.
On Tue, Oct 24, 2023 at 3:48 AM Neil Madden <neil.e.mad...@gmail.com> wrote: > I’ve had a look through this new draft and I have some comments and > questions. Some of which are similar to comments I already raised [1], but > haven’t been addressed. > > Are we concerned about Holders and Issuers colluding? > With SD-JWT or plain JWT or really any similar signed token construct the Verifier has to trust the Issuer ultimately to act/issue honestly. So colluding Holders and Issuers just isn't part of the threat model. I don't honestly know how that could be different. The Issuer, if malicious, can issue a token with whatever content they want. > For example, now that claim names are blinded an Issuer can add the same > claim multiple times with different, potentially contradictory, values and > then the Holder can selectively release one disclosure to one Verifier and > a completely different one to another Verifier. This seems problematic at > least, that the “same” credential could be interpreted differently by > different parties. > A well behaving Holder would reject such a credential based on the verification and processing rules (this one specifically <https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-06.html#section-8.1-4.3.2.3.2.2.2.3>). While malicious Issuers and colluding Holders and Issuers are outside the threat model for the reasons explained above. So this situation is handled as much as it can be (as best I know anyway) in the draft. A more sophisticated version of this “attack” illustrates the need for > collision resistance in the hash function, not just preimage resistance as > stated in the draft (and already raised by me in [1]). If the hash is not > CR then a malicious Issuer can find colliding [salt, key, value] triplets > that have the same hash value, give one to the Holder and then later claim > that they actually signed the other one. (This is not just theoretical, > similar attacks have been used to create fraudulent SSL certificates [2]). > The draft currently says that second-preimage resistance is needed, which prevents a malicious Holder from finding a different Disclosure value that results in a digest that's the same as one in the signed credential. Protecting against a malicious user effectively forging or modifying disclosed claim names/values is the security objective. Second-preimage resistance is not as strong as collision resistance but I believe is correct and sufficient for the context of use. And a malicious Issuer isn't something that's in scope and could do all kinds of other bad things. This is the section of the security considerations with that: https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-06.html#section-11.5 > This also indicates that the security strength of the signature scheme is > bounded by the collision resistance of the hash function - e.g. there’s > little point using ES512 with SHA-256, for example. Probably the security > considerations should suggest matching hash functions to signature > algorithms. > Yeah, saying something about matching the strength of hash function and signature algorithm would probably be worthwhile. Furthermore, preimage resistance is not a sufficient property to ensure > confidentiality of withheld claims. Preimage resistance holds if the > attacker cannot recover the exact input that produced a given hash value, > but it doesn’t preclude the attacker being able to recover partial > information about that value. For example, consider the hash function H(x) > = SHA-256(x) || x[x.len-10..x.len] (where || is concatenation). This hash > function when applied to SD-JWT is preimage resistant (assuming the salt is > strong), but leaks the last 10 bytes of the claim value. > Preimage resistance maybe isn’t the term to use there. It’s used in that section-11.5 <https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-06.html#section-11.5> along with some text that says that it needs to be “infeasible to calculate the salt and claim value that result in a particular digest”. We are trying to say that the hash has to have the property that it can’t be reversed (or even partially reversed, to your point). There’s probably a better way to state that the hash function has to be not at all reversible. Can you perhaps suggest some text? Or could we just replace “preimage resistant” with “irreversible” in that text in 11.5? And maybe qualify that text a bit more too with something like “infeasible to calculate the salt and claim value (or any portion thereof) that results in a particular digest”. > The appropriate security definition for SD-JWT is some form of > cryptographic commitment scheme [3], with the associated security notions > of hiding and binding. Honestly, I still think that this WG is not an > appropriate venue for this kind of novel (in the OAuth world) cryptographic > scheme and external review by experts would be helpful. > I can’t exactly argue with that. But for better or worse this WG is the current venue. And as the end of the draft’s intro states, “this specification aims to be easy to implement and to leverage established and widely used data formats and cryptographic algorithms” which is why a regular old secure hash function is being used - SHA-256 specifically and as the default, which I believe is completely suitable for the purpose. It seems like some tightening up or changes around the approach provided for hash algorithm agility might be in order. But I think the overall salted hash based approach is okay/appropriate/sufficient. > > All of this suggests that simply referring the the IANA hash function > registry is not sufficient, as probably *most* of the entries there are not > actually suitable for use in SD-JWT for one reason or another. > The security considerations for hash algorithm choice does say that “inclusion in the [...] registry alone does not indicate a hash algorithm's suitability for use in SD-JWT” after attempting to describe what makes a hash algorithm suitable for use with SD-JWT. We wanted to allow for some hash algorithm agility but really didn’t want to create yet another hash algorithm registry. That "Named Information Hash Algorithm Registry" isn’t an ideal fit but was the best one we were able to find. Pointing to that registry and having the associated security considerations seemed like a reasonably reasonable approach. > Some other comments: > > The original JWT RFC [4] has this to say about the order of encryption and > signatures: > > signatures over encrypted text are not considered valid in many > jurisdictions. > > > Presumably the same argument holds about signatures over blinded values? > That should perhaps be noted at least. > I honestly don’t know if it holds (or even of the validity of the statement originally) and I’m very reluctant to make any such statements that venture into legal territory. > > The draft repeatedly says that a symmetric signature algorithm (MAC) must > not be used. Perhaps I’m missing something here, but why not? It doesn’t > seem like it compromises any of the intended security properties. Use of a > symmetric MAC may also limit the privacy impacts on users as it provides > some measure of deniability (similar to that mentioned in section 12.1), as > any Verifier in possession of the secret key could also have produced any > claims that are subsequently leaked, allowing the user to deny that they > were produced by the supposed Issuer. (This deniability property holds even > without subsequent leaking of old signing keys). > The thinking behind that was basically that this Issuer-Holder-Verifier model implies/assumes that an Issuer issues a token with no idea of where it’ll be presented and having a shared symmetric key seemed really weird in that situation. Also had to explain why or how a shared symmetric key would work in that situation too. That said, there’s been some talk about loosening that restriction - largely around the same reasoning on deniability that you cite - I guess your comment here should be taken as supportive of that prospective change? > The security considerations about salt entropy should probably reference > RFC 4086 (BCP 106) or something more up to date (maybe RFC 8937 too). > Good point, yeah. > > I think section 11.8 about selectively disclosing contraints on the use of > a SD-JWT is completely inadequate and will almost certainly lead to > attacks. Requiring Verifiers to hard-wire the set of constraints they > enforce is likely to be damaging to future evolution of the standard as new > security constraints are added. It would seem especially problematic to > allow selective disclosure of a “cnf” claim for example, and yet nothing > forbids it and the history of JWT usage suggests that anything not > forbidden will at some point happen (and even some things that are > forbidden). I suggest establishing a registry of claims that are really > usage constraints and forbidding issuers from allowing anything in that > list to be selectively-disclosed. (There are perhaps some exceptions here, > e.g. “aud” is a constraint in this sense but it probably _does_ make sense > for it to be selectively disclosed, but only on a per-array-item basis: > that way a Holder cannot remove the constraint entirely but can still hide > other “recipients”). > It is admittedly a potentially fraught area. But I’d argue that having a hard-wired set of claims/constraints enforced/required by verifiers is appropriate and necessary even when selective disclosure isn’t at play. It’s how regular JWT works (or should work) in practice already. And don’t think it harms future evolution because any new security constraints would necessarily need updates all around because they won’t be understood otherwise. The 11.8 section could perhaps be stronger in saying that claims controlling the validity of the token shouldn’t be made selectively disclosable. But what exactly constitutes such a claim is actually rather murky and there are undoubtedly exceptions like you point out with “aud”. And I know some have expressed the need/desire to have key/holder binding type claims (such as “cnf” but not only that) be made selectively disclosable for privacy reasons. I also don’t think a new registry would really help the situation. At this level we're describing a generic mechanism and don’t necessarily even have a list of all claims that could be interpreted as constraints in a particular context or application. Note, for example though, that https://datatracker.ietf.org/doc/draft-ietf-oauth-sd-jwt-vc/ does say that certain claims must be included directly and not made selectively disclosable. Which leads back to ultimately needing that requirement that Verifiers ensure that all the claims they deem necessary are present (in the clear or disclosed) when checking the validity and accepting the token. > On a related note, section 11.6 says that to avoid this kind of attack, > Verifiers MUST NOT take into account whether a Key Binding is present or > not to decide whether to require Key Binding. This seems to preclude > Verifiers that can handle different levels of access with different > security requirements and is the sort of requirement that makes it near > impossible to incrementally evolve tougher security requirements over time. > It effectively becomes an all-or-nothing switch that will have the likely > effect of making the use of Key Binding less attractive. Security hardening > should be the easy path if we want to see it adopted. > > It’s not meant to preclude that kind of thing (and reading it again, I don’t think it does preclude it). But rather to just say that whatever the Verifier’s requirements on key binding are have to be based on its policy and not on the content of the token (some of which could be manipulated by the holder). A Verifier’s policy could, as you describe, afford different levels of access based on different security characteristics of the presented token/credential. Or the Verifier’s requirements could, for example, say that for credential type A, Key Binding is always required, while for credentials of type B, it is only required when the credential was issued by an issuer that is known to issue credentials supporting Key Binding. > Best wishes, > > Neil > > [1]: > https://mailarchive.ietf.org/arch/msg/oauth/NOPT1WNtvMvlygLaZH7YvLFVpKo/ > [2]: > https://www.cnet.com/news/privacy/web-browser-flaw-could-put-e-commerce-security-at-risk/ > [3]: https://en.wikipedia.org/wiki/Commitment_scheme > > On 23 Oct 2023, at 17:17, internet-dra...@ietf.org wrote: > > Internet-Draft draft-ietf-oauth-selective-disclosure-jwt-06.txt is now > available. It is a work item of the Web Authorization Protocol (OAUTH) WG > of > the IETF. > > Title: Selective Disclosure for JWTs (SD-JWT) > Authors: Daniel Fett > Kristina Yasuda > Brian Campbell > Name: draft-ietf-oauth-selective-disclosure-jwt-06.txt > Pages: 90 > Dates: 2023-10-23 > > Abstract: > > This specification defines a mechanism for selective disclosure of > individual elements of a JSON object used as the payload of a JSON > Web Signature (JWS) structure. It encompasses various applications, > including but not limited to the selective disclosure of JSON Web > Token (JWT) claims. > > The IETF datatracker status page for this Internet-Draft is: > https://datatracker.ietf.org/doc/draft-ietf-oauth-selective-disclosure-jwt/ > > There is also an HTML version available at: > > https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-06.html > > A diff from the previous version is available at: > > https://author-tools.ietf.org/iddiff?url2=draft-ietf-oauth-selective-disclosure-jwt-06 > > Internet-Drafts are also available by rsync at: > rsync.ietf.org::internet-drafts > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > -- _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you._
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
