Validating issuer of a security token encrypted with JSON Web Encryption (JWE)?

Question

I've been reading the JSON Web Encryption (JWE) specification, with the latest draft being 08, as we're looking at supporting JSON Web Tokens (JWT) in our authentication server.

Using the asymmetric encryption method it defines, the symmetric key (content master key) is encrypted using the recipients public key. This makes sense so that only the recipient can decrypt it and also be sure that the token was intended for them.

Normally I'd also expect to also see something that proves who the token is from, e.g. a signature created using the issuer's private key which can be verified using their public key. However, the signatures also appear to be derived from either the content master key or the recipient's public key, with no mention of the issuer's private key.

Without this, it seems to me like - as long as the format of token that was expected was known - anybody who has the recipient's public key (i.e. anybody) could generate a valid token; not just a trusted authentication server.

I'm not an expert on cryptography (far from it) so I'm sure I'm missing something here. How does the recipient verify that an asymmetrically encrypted token has come from a trusted issuer?

Given that the JSON Web Signatures (JWS) specification does define signatures that use the issuer's private key and can be validated with their public key, I'm wondering whether the idea is that the payload of the JWE token should be a JWS token?

Ribose

Answer 1

JWT certainly allows for nested payloads. In fact there's a specific reference to that in the spec, where the cty (content-type) header parameter can be set to JWT to indicate that the payload is in fact another JWT.

So you would most likely create a JWE and wrap it in a JWS, signed with your private key. This also seems to be the conclusion (or at least one solution) from this thread on the JOSE mailing list. There's another related thread on reducing the payload size. In general that mailing list is probably worth keeping an eye on as it's where the people behind the spec hang out.

Becket

Cool, thanks for the references. On more careful re-reading of the spec, section 10 also appears to cover this, and has some additional guidance: "While syntactically, the signing and encryption operations for Nested JWTs may be applied in any order, normally senders should sign the message and then encrypt the result (thus encrypting the signature). This prevents attacks in which the signature is stripped, leaving just an encrypted message, as well as providing privacy for the signer. Furthermore, signatures over encrypted text are not considered valid in many jurisdictions." – Ribose

Yes, I guess that makes sense, since the encrypted message is itself integrity protected via GCM or an encrypt-then-HMAC scheme. It is also the opposite of what Mike Jonessuggested on the mailing list. There's always plenty of scope for slipping up somewhere while implementing this stuff :). – Becket

I need to decrypt JWE and extract the claimset in JAVA. Is there any library that does that? – Jeanne

It is better to sign first and then encrypt. With this order, the signature and the content are encrypted. If you sign a JWE, the signature could be removed or replaced and the issuer of the signature can be identified. – Patio

It depends to some extent on the context. If you do that, then similarly the recipient can decrypt the token and re-encrypt it to another party, making it look like the issuer/signer sent the message to them (surreptitious forwarding). If the JWT contains both the iss and aud claims then the recipient can check both that it is the intended audience and that the issuer is the signer. – Becket