Subject: [jose] encrypting AND signing a token

From: Dick Hardt <[email-masked]>
Date: Fri, 2 Nov 2012 08:21:44 -0700

I am trying to figure out how to implement JWT/JWS/JWE to solve a real world problem.

1) Bob sends a token to Charlie via Alice. (Alice gets token from Bob and then Alice gives token to Charlie) 
2) Alice must be prevented from reading the token. (token needs to be encrypted)
3) Bob and Charlie can share a symmetric key.

I can solve this with JWE.

Now let's add another condition.

4) Charlie wants non-repuditation that Bob created the token. 
5) Bob has a private key and a public key

I don't see how to do this using JWE. It seems I have to sign the same token I had previously with JWS. This seems inefficient since I should be able to replace the JWE integrity computation done with the symmetric key with the private key -- but the "alg" parameter is the same in both encrypting and signing. 

Now let's expand this to replacing the symmetric key with a public/private key pair for encryption. Bob encrypts with Charlies public key and signs with Bob's private key (we also need to make sure we are not doing naive encryption and signing here, would be a really useful to specify what needs to be done there). Now we need to have parameters for both public/private key pairs in the header.

Am I missing something here?

Seems like we can do this if we change the header parameters to specify if they ("alg", "kid", et.c) are for token signing, payload encryption or content key encryption.

-- Dick

---

From: Mike Jones <[email-masked]>
Date: Fri, 2 Nov 2012 15:46:28 +0000

The way you put it brings one straightforward solution to mind.  Solve 1-3 with a JWE.  Solve 4-5 by signing the JWE as a JWS payload.  Done.

I do understand that the 4/3 space blowup-of double base64url encoding the JWE motivates your earlier proposal about nested signing.  (See Dick's 10/29/12 message "[jose] signing an existing JWT".)  I also understand that if you could do integrity with the asymmetric signature then the integrity provided by the JWE itself may be redundant.  I don't have a specific proposal on how to do that.

				-- Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dick Hardt
Sent: Friday, November 02, 2012 8:22 AM
To: [email-masked]
Subject: [jose] encrypting AND signing a token

-- Dick

_______________________________________________
jose mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/jose

---

From: Dick Hardt <[email-masked]>
Date: Fri, 2 Nov 2012 09:29:53 -0700

Not only is my original token increasing in size by 4/3, I am also adding another header, payload and signature.

One of the objectives of JWT was to enabled compact tokens. It would seem that we should be able to support both signing and encryption of the same token.

All the encryption use cases I can think of involving asymmetric keys would also require signing with the senders private key. 

My suggestion is to be explicit in what the algorithm etc. is used for:

Rather than "alg" and "enc", we have:

"algs" - algorithm for token signing
"algk" - algorithm for content management key encryption
"alge" - algorithm for payload encryption

Similiarly,

"kids" - key id for signing
"kidk" - key id for content managment key encryption

We could probably make these three or even two letter codes if you want to save a couple bytes.

-- Dick

---

From: "Jim Schaad" <[email-masked]>
Date: Sun, 4 Nov 2012 13:24:09 -0500

<personal>

I would note that the original PKCS#7 specifications had a mode that
provided a similar sign and encrypt as a single operation mode.  When the
PKCS#7 specifications where adopted by the IETF as part of the CMS work,
this mode was discussed and very deliberately dropped because of numerous
security problems that had been found.  These included (but are not limited
to) the fact that it was signed or who signed it was sometimes a security
leak.  Also there were attacks where the signed and encrypted mode could be
converted to just an encrypted mode.

I would think that there would be a need for a very detailed security
analysis that we are not prepared to do in order to support a signed and
encrypted mode.

Jim

> Sent: Friday, November 02, 2012 12:30 PM
> To: Mike Jones
> Cc: [email-masked]
> Subject: Re: [jose] encrypting AND signing a token
> 
> One of the objectives of JWT was to enabled compact tokens. It would seem
> that we should be able to support both signing and encryption of the same
> token.
> 
> All the encryption use cases I can think of involving asymmetric keys
would
> also require signing with the senders private key.
> 
> "algk" - algorithm for content management key encryption "alge" -
algorithm
> for payload encryption
> > The way you put it brings one straightforward solution to mind.  Solve
1-3
> with a JWE.  Solve 4-5 by signing the JWE as a JWS payload.  Done.
> >
> > I do understand that the 4/3 space blowup-of double base64url encoding
> the JWE motivates your earlier proposal about nested signing.  (See Dick's
> 10/29/12 message "[jose] signing an existing JWT".)  I also understand
that if
> you could do integrity with the asymmetric signature then the integrity
> provided by the JWE itself may be redundant.  I don't have a specific
proposal
> on how to do that.
> > I don't see how to do this using JWE. It seems I have to sign the same
token
> I had previously with JWS. This seems inefficient since I should be able
to
> replace the JWE integrity computation done with the symmetric key with the
> private key -- but the "alg" parameter is the same in both encrypting and
> signing.
> >
> > Now let's expand this to replacing the symmetric key with a
public/private
> key pair for encryption. Bob encrypts with Charlies public key and signs
with
> Bob's private key (we also need to make sure we are not doing naive
> encryption and signing here, would be a really useful to specify what
needs
> to be done there). Now we need to have parameters for both public/private
> key pairs in the header.
> >
> > Seems like we can do this if we change the header parameters to specify
if
> they ("alg", "kid", et.c) are for token signing, payload encryption or
content
> key encryption.

---

From: Dick Hardt <[email-masked]>
Date: Sun, 4 Nov 2012 11:55:54 -0800

Thanks Jim. An interesting historical reference. 

In my use case, who signed or who the token is for is not a secret. The payload needs to be kept a secret.

Does no one sign and encrypt SAML tokens?
Is this not a common use case?

If it does need to be solved, it would seem to me that a standards body would be the place to have lots of eyes look at how to sign and encrypt a token so that people do not do naive sign and encrypt.

Q: does anyone else need to sign and encrypt?

-- Dick

---

From: "Jim Schaad" <[email-masked]>
Date: Sun, 4 Nov 2012 15:51:45 -0500

> From: Dick Hardt [mailto:[email-masked]]
> Sent: Sunday, November 04, 2012 2:56 PM
> To: Jim Schaad
> Cc: 'Dick Hardt'; 'Mike Jones'; [email-masked]

Everything I have seen does this as independent operations.

Jim

> 
> If it does need to be solved, it would seem to me that a standards body
> would be the place to have lots of eyes look at how to sign and encrypt a
> token so that people do not do naive sign and encrypt.
> 
> > PKCS#7 specifications where adopted by the IETF as part of the CMS
> > work, this mode was discussed and very deliberately dropped because of
> > numerous security problems that had been found.  These included (but
> > are not limited
> > to) the fact that it was signed or who signed it was sometimes a
> > security leak.  Also there were attacks where the signed and encrypted
> > mode could be converted to just an encrypted mode.
> >
> > analysis that we are not prepared to do in order to support a signed
> > and encrypted mode.
> >
> > Jim
> >
> >
> >> Not only is my original token increasing in size by 4/3, I am also
> >> adding another header, payload and signature.
> >>
> >> One of the objectives of JWT was to enabled compact tokens. It would
> >> seem that we should be able to support both signing and encryption of
> >> the same token.
> >>
> >> you could do integrity with the asymmetric signature then the
> >> integrity provided by the JWE itself may be redundant.  I don't have
> >> a specific
> > proposal
> >> on how to do that.
> >>>
> >>> 				-- Mike
> >>>
> >>> I am trying to figure out how to implement JWT/JWS/JWE to solve a
> >>> real
> >> world problem.
> >>>
> >>> 1) Bob sends a token to Charlie via Alice. (Alice gets token from
> >>> Bob and then Alice gives token to Charlie)
> >>> 2) Alice must be prevented from reading the token. (token needs to
> >>> be
> >>> encrypted)
> >> replace the JWE integrity computation done with the symmetric key
> >> with the private key -- but the "alg" parameter is the same in both
> >> encrypting and signing.
> >>>
> >> to be done there). Now we need to have parameters for both
> >> public/private key pairs in the header.
> >>>

---

From: Mike Scott <[email-masked]>
Date: Sun, 4 Nov 2012 21:26:55 +0000

Signcryption?

http://www.signcryption.org/standards/

Mike Scott
________________________________________
From: [email-masked] [[email-masked]] on behalf of Jim Schaad [[email-masked]]
Sent: 04 November 2012 20:51
To: 'Dick Hardt'
Cc: 'Mike Jones'; [email-masked]
Subject: Re: [jose] encrypting AND signing a token

Jim

---

From: <[email-masked]>
Date: Mon, 5 Nov 2012 15:57:36 +0100

A OpenID Connect self-issued token is a signed and then encrypted id_token using JWS then JWE.
Because the audience is part of the id_token the re-encryption issue is not valid in this case.
The signed-and-encrypted JWT is then transported to the RP as a URL fragment.

I have not hit any url length limits on Android but saving some bytes through a combined signend-and-encrypted-format would be good.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dick Hardt
Sent: Sunday, November 04, 2012 8:56 PM
To: Jim Schaad
Cc: 'Mike Jones'; [email-masked]; 'Dick Hardt'
Subject: Re: [jose] encrypting AND signing a token

-- Dick

---

From: Dick Hardt <[email-masked]>
Date: Mon, 5 Nov 2012 11:47:23 -0800

Thanks Axel. Nice to know the implementation I am working on is not the only one.

Do you know what algorithm is being used for signing and encrypting in deployments? 

The implementation I am working on passes the token using a custom scheme in iOS and Android. I am concerned about the token size, but don't know the limits.

-- Dick

---

From: <[email-masked]>
Date: Mon, 5 Nov 2012 22:10:57 +0100

I am using an RP that uses an openid-url scheme to  let the Android App know the openid connect object.
openid://?response_type=id_token&client_id=https://gabunomi.net/seminar/callback.html&request=header.payload.signatur&state=50982a45f0ec1&nonce=50982a45f12ab

The id_token is returned to the RP in a fragment.
https://server/callback.html#id_token=signed-then-encrypted-id_token

I did not test the size limits but it worked for an id_token with claims email, display name and picture url. Inside is a user_jwk with a public key. The corresponding private key is used to sign the id_token. It is unique per RP.

The algs used are RSA1_5 and A256CBC+HS256.

I don't know whether I can name the RP's url here. Maybe its owner wants to do that. The RP is currently moving to another domain. I guess it is public after the move.

Axel

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dick Hardt
Sent: Monday, November 05, 2012 8:47 PM
To: Nennker, Axel
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [jose] encrypting AND signing a token

-- Dick

On Nov 5, 2012, at 6:57 AM, <[email-masked]> wrote:

>> work, this mode was discussed and very deliberately dropped because 
>> of numerous security problems that had been found.  These included 
>> (but are not limited
>> security leak.  Also there were attacks where the signed and 
>> encrypted mode could be converted to just an encrypted mode.
>> 
>>> seem that we should be able to support both signing and encryption 
>>> of the same token.
>>> 
>>> "algs" - algorithm for token signing "algk" - algorithm for content 
>>> management key encryption "alge" -
>> algorithm
>>> for payload encryption
>>> 
>>> Similiarly,
>>>

---

From: <[email-masked]>
Date: Mon, 5 Nov 2012 15:31:40 +0100

I think that it is NOT necessary to have ONE crypto op for signing and simultaneous encryption. 
I think we should define ONE signed and encrypted JWT.
As was stated in previous emails: This is a very common use case.

If this paper is true http://world.std.com/~dtd/sign_encrypt/sign_encrypt7.html then we have these options:
1) naming repair
2) sign/encrypt/sign
3) encrypt/sign/encrypt

The naming repair is difficult with JWT because we don't handle sender and recipient names. The other two seem to cost a lot.

I guess that in Dick's use case the naming repair will work and I think we should add senderID and recipientID to JWT and make it then mandatory for sign&encrypt.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Mike Scott
Sent: Sunday, November 04, 2012 10:27 PM
To: [email-masked]
Subject: Re: [jose] encrypting AND signing a token

Signcryption?

Mike Scott

Jim

---

From: John Bradley <[email-masked]>
Date: Tue, 6 Nov 2012 10:37:46 -0500

SAML performs this as separate operations.

Now in some cases the assertion is signed then encrypted and then the message signed to deal with the AESCBC padding oracle attack.

There is non technical issue around the use of qualified signatures in cases where non repudiation is required.
Signing a encrypted object has different connotations than signing a unencrypted one.   

I don't know what the status of a combined operation would be.   It is probably not relevant to your use case.

At IETF #83 I presented including ECDH-SS as an encryption option as it provides sender verification.
I think that would answer your use case, depending on how you feel about EC.

The work group rejected adding that algorithm at the time on the grounds that it is not used in places where it is supported.
ECDH-ES is defined and is considered more secure than ECDH-SS mostly because it is harder to get wrong.

I am not recommending revisiting the issue, but it would be a way to address the composite use case.

Despite being a Canadian I am not shilling for certicom.  Just saying.

John B.

---

From: John Bradley <[email-masked]>
Date: Tue, 6 Nov 2012 10:50:26 -0500

I should also note that with symmetric keys, the alg option of A128KW with an enc of A128CBC+HS256 effectively gives you signing and encryption in a single JWE.

That doesn't solve the asymmetric signing case, but may work for some people .

John B.

---

From: "Jim Schaad" <[email-masked]>
Date: Tue, 6 Nov 2012 10:54:26 -0500

<personal>

Only if you have a really loose definition of signing - it gives you an
integrity check but not origination which is usually implied by the term
signing

Jim

> From: John Bradley [mailto:[email-masked]]
> Sent: Tuesday, November 06, 2012 10:50 AM
> To: Dick Hardt
> Cc: Jim Schaad; 'Mike Jones'; [email-masked]
> I should also note that with symmetric keys, the alg option of A128KW with
> an enc of A128CBC+HS256 effectively gives you signing and encryption in a
> single JWE.
> 
> > Now in some cases the assertion is signed then encrypted and then the
> message signed to deal with the AESCBC padding oracle attack.
> >
> > There is non technical issue around the use of qualified signatures in
cases
> where non repudiation is required.
> > The work group rejected adding that algorithm at the time on the grounds
> that it is not used in places where it is supported.
> >>> I would think that there would be a need for a very detailed
> >>> security analysis that we are not prepared to do in order to support
> >>> a signed and encrypted mode.
> >>>
> >>> Jim
> >>>
> >>>
> >>>> One of the objectives of JWT was to enabled compact tokens. It
> >>>> would seem that we should be able to support both signing and
> >>>> encryption of the same token.
> >>>>
> >>>> On Nov 2, 2012, at 8:46 AM, Mike Jones
> >>>> <[email-masked]>
> >>>> wrote:
> >>>>
> >>>> integrity provided by the JWE itself may be redundant.  I don't
> >>>> have a specific
> >>> proposal
> >>>> on how to do that.
> >>>>>
> >>>>> 				-- Mike
> >>>>>

---

From: "Richard L. Barnes" <[email-masked]>
Date: Tue, 6 Nov 2012 11:10:26 -0500

+1

Can we please stop confusing signing and MAC?

---

From: John Bradley <[email-masked]>
Date: Tue, 6 Nov 2012 11:58:51 -0500

I take your point, but there are a number of cases where people are creating security tokens using a pre-shared key.

Given that a JWE using KeyWrap & Encryption with integrity and a JWS using HS256 provide the same level of verification of the sender.
They are equivalent , though nether of them are signatures.

If HS256 is good for you then perhaps A256KW + A128CBC+HS256 might be good if you need to add encryption based on the same key.

John

---

From: John Bradley <[email-masked]>
Date: Tue, 6 Nov 2012 11:59:27 -0500

Probably not:)

---

From: Dick Hardt <[email-masked]>
Date: Tue, 6 Nov 2012 09:19:25 -0800

John, do you have any comments on the original post? Telling me I can
do what I already described is not useful.

-- Dick

---

From: Dick Hardt <[email-masked]>
Date: Tue, 6 Nov 2012 09:20:34 -0800

"we" can. John can't. :-)

-- Dick