Hi John, I agree with your points, there is way to have a tight and secure system with JOSE at is it now. I have no doubts about this. It's just the realisation that if "alg" was properly recognised as optional, it would come as more obvious that JOSE doesn't impose a trust model and that this is the application's job. And many security considerations, up the security stack, would not have been necessary. But I guess we have to live with this for now.
> Yes if Connect had required that alg be part of the key material in all cases > then the alg in the JWS would be redundant. \ The ID token must be verified with the alg set at client registration time, else RS256 is assumed. This is what the OIDC ID token verification spec currently says. There is no mention what to do if the RSA JWK alg clashes with that, but the logical thing to do is also signal an error I suppose. > It may be that things we considered obvious like not using an encryption key > to verify a signature, or don't return a key if the alg doesn't match any > possible algs for that key type may need more explaining in a BCP of some > sort. > > Perhaps we need to say that you should be passing in the key type, use and > alg from the JWK if present to the JOSE lib so that it can do the check along > with the acceptable algs for the issuer. This is a good idea. I just re-read JWS / JWA -40 and I don't see this explicitly mentioned. http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-40#section-5.2 Where would it be a good place to put this? Vladimir > > There are other things like not accepting weak RSA keys as well. > > John B. > > Sent from my iPhone > >> On Apr 4, 2015, at 5:28 AM, Vladimir Dzhuvinov <[email protected]> >> wrote: >> >> >> >>> On 3.04.2015 12:39, Anders Rundgren wrote: >>>> On 2015-04-03 10:33, Vladimir Dzhuvinov wrote: >>>> The evidence is that the alg / alg+enc parameters are not critical and >>>> required in all cases, and therefore redundant, and could be declared >>>> optional. >>>> >>>> Could they be scrapped altogether? To me that's a different question, >>>> which requires investigation to be confident that no valid case is missed >>>> where their presence is actually needed. >>> Hi Vladimir, >>> They are probably quite needed. >>> >>> If everything is based on OOB-arrangements you can probably drop a bunch of >>> parameters. If not don't you need alg to for example deal with RS256 and >>> RS512 in a reasonable way? >> One would need the "alg" for RSA signatures if we have the public RSA key >> communicated OOB, but the algorithm is omitted. The JWK spec however gives >> us the optional "alg" parameter to communicate precisely this. So when a JWS >> is received, the "alg" can be obtained when one looks up the public RSA JWK. >> >> The argument is that including "alg" in the JWS header turns out to be >> redundant in common real-world cases. And if this is true, then we can >> regard it as optional :) >> >> Consider OpenID Connect for example: >> >> 1. The provider publishes the public JWK set at a URL, and each key must be >> given a "kid". >> 2. The ID token JWS "alg" is set by the "id_token_signed_response_alg" >> parameter at client registration. For ID token JWE there is >> "id_token_encrypted_response_alg" and "id_token_encrypted_response_enc". >> 3. The ID token JWS "kid" header parameter is required to select the JWK for >> verification. >> >> Which "alg" is actually used to validate the ID token - the one from the JWS >> header or the one obtained at registration? >> >> http://openid.net/specs/openid-connect-core-1_0.html#IDTokenValidation : >> >> "The alg value SHOULD be the default of RS256 or the algorithm sent by the >> Client in the id_token_signed_response_alg parameter during Registration." >> >> "If the ID Token is encrypted, decrypt it using the keys and algorithms that >> the Client specified during Registration that the OP was to use to encrypt >> the ID Token. If encryption was negotiated with the OP at Registration time >> and the ID Token is not encrypted, the RP SHOULD reject it." >> >> The JWS "alg" is not really required by OIDC, but it's there because JOSE >> says it's mandatory. >> >>> By making a things optional you effectively introduce additional >>> complexity. >> This is a matter of perspective I believe. >> >> Image we looked at things this way: >> >> 1. Each application defines a trust model and corresponding process for >> signing / verification (encryption / decryption). >> 2. JOSE provides a set of available parameters to pick from. >> 3. The application defines which ones are required and which not. >> >> Let's consider OIDC again: There the "kid" is a required parameter to allow >> the JWK to be looked up, even though JOSE says it's an optional parameter. >> >> The JWT claims spec provides a good analogy: A set of standard claims to >> pick from, the application then defines which ones are must (e.g. iss, sub, >> aud, exp in OIDC) and which optional. >> >> >> >> Vladimir >> >> >> >> >>> Anders >>> >>>> That the alg / alg+enc parameters are currently specified as mandatory >>>> apparently confuses people into thinking "alg" should be the prime >>>> determinant when processing received JWS / JWE objects. Applications >>>> should actually specify this prime determinant, i.e. the header parameters >>>> to include to enable the recipient to verify / decrypt the object. For >>>> OpenID Connect that is "kid" for example. >>>> >>>> I agree with John that "kid" goes not guarantee correct implementations. >>>> But to me that's a different concern, and I don't think we can use that as >>>> an argument for / against the mandatory use of alg. >>>> >>>> I'm grateful Tim brought this up, to illustrate the importance of letting >>>> the application determine the actual required JOSE parameters, and how >>>> this may translate to better and safer implementations. >>>> >>>> I'm a bit sad that we haven't fully realised this, at some earlier stage, >>>> now that JOSE is almost final and is widely deployed. >>>> >>>> But I hope this could still flow into the new binary encodings and are >>>> being developed now. >>>> >>>> >>>> Cheers, >>>> >>>> Vladimir >>>> >>>> >>>>> On 3.04.2015 00:19, Tim McLean wrote: >>>>> On Thu, Apr 2, 2015 at 3:46 PM, John Bradley<[email protected]> wrote: >>>>> >>>>>> Without alg we would have a problem with crypto agility. >>>>>> >>>>>> At some point algorithms are deprecated and you need a window to move >>>>>> from >>>>>> one to another. They may both use the same key, such as HMACSHA1 and >>>>>> HMACSHA256. >>>>>> >>>>>> The receiver of a signed object may need to determine from the object: >>>>>> 1. Who it is from “iss” >>>>>> 2. The algorithm to use >>>>>> 3. What key they used “kid”, “jku” or implicit if there is only one >>>>>> key >>>>>> for a alg. >>>>>> >>>>>> It is the application that needs to determine the trust relationship. >>>>>> >>>>>> Removing “alg” from the wire level protocol would not be a good idea. >>>>>> >>>>>> It however might be better to have lower level crypto libs that don’t >>>>>> have >>>>>> a view into the trust model only accept keys and algs that are >>>>>> explicitly >>>>>> passed in rather than splitting the logic into two places. >>>>>> >>>>>> What keys, algorithms, and issuers are permissible on given channels is >>>>>> something that needs to happen outside the low level crypto lib. >>>>>> >>>>>> It is also possible that a relying party might receive a token with a >>>>>> kid >>>>>> alg and sig that all verify perfectly, but if Issuer A is signing the >>>>>> token >>>>>> and inserting Issuer B in the “iss” and the RP is not checking that the >>>>>> key retrieved via the kid belongs to issuer B then we also have a >>>>>> problem. >>>>>> >>>>>> In looking at the libraries that were able to be tricked into using a >>>>>> RSA >>>>>> (and probably EC) public key as a HMAC key they seam to be in weakly >>>>>> typed >>>>>> languages. >>>>>> The attack worked because the keys were coerced into the needed type. >>>>>> >>>>>> I give you full credit for finding this, and am grateful that you are >>>>>> looking at implementations. >>>>>> >>>>>> John B. >>>>> Good point about crypto agility, John. I think that's worth >>>>> investigating >>>>> further. >>>>> >>>>> I think algorithm updates/changes can be achieved via key rotation. >>>>> Given >>>>> a "key1" that is defined to use algorithm A: >>>>> - Create a "key2" that uses algorithm B. >>>>> - Publish "key2" to all parties planning to receive JWSs. >>>>> - Switch all relevant devices from signing with "key1" to signing with >>>>> "key2". >>>>> - (optional) Publish the fact that "key1" should no longer be accepted. >>>>> >>>>> If needed, the only difference between "key1" and "key2" could be that >>>>> they >>>>> are defined to use different algorithms -- the underlying key material >>>>> could be identical. I don't think that would be advisable though; >>>>> reusing >>>>> keys between algorithms might give up any benefit of the upgrade (or >>>>> could >>>>> completely destroy security if the algorithms have unexpected >>>>> interactions). >>>>> >>>>> Cheers, >>>>> Tim >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> jose mailing list >>>>> [email protected] >>>>> https://www.ietf.org/mailman/listinfo/jose >>>> -- >>>> Vladimir Dzhuvinov ::[email protected] >>>> >>>> >>>> _______________________________________________ >>>> jose mailing list >>>> [email protected] >>>> https://www.ietf.org/mailman/listinfo/jose >>> >>> >>> >>> _______________________________________________ >>> jose mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/jose >> -- >> Vladimir Dzhuvinov :: [email protected] >> _______________________________________________ >> jose mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/jose -- Vladimir Dzhuvinov :: [email protected] _______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
