[Openid-specs-ab] Encryption
John Bradley
ve7jtb at ve7jtb.com
Mon Oct 31 18:02:58 UTC 2011
I am not opposed to it.
However there are multiple details that need to be sorted out.
If we are going that far, you probably don't want to use the same key for encrypting and integrity.
That would argue for a KDF to be used to crate multiple keys from a master.
Not hard ConcatKDF would work specifying different use strings.
Though that may not be available packaged everywhere it is easy enough to make one if you have SHA256.
This opens questions of specifying KDF
Specifying hash for KDF (some default to SHA1 and others SHA256)
Specifying the integrity HMAC alg.
So complexity can get out of control.
I think we could do something like say always:
1. concatKDF with a MAC of SHA256
2 "Encrypt" as the U input for encryption key
3 "Integrity" as the U input for the integrity key
4 The HMAC is SHA256
5 The HMAC is calculated over the base64url encoded envelope, key wrap, and message when directly concatenated together in that order.
6 the base64url encoded output is prepended with a period and appended to the first three segments to form a JWE.
That adds 13 bytes to each JWE so that is not an issue.
While for us it may be nice to have lots of knobs to fiddle with, we should pick one way to add integrity to keep it simple for developers.
It will add some complexity though arguably necessary if you want privacy & integrity.
This is new functionality over John Panzer's proposal.
I am good with documenting this proposal if you are:)
John B.
On 2011-10-31, at 2:07 PM, Breno de Medeiros wrote:
> On Mon, Oct 31, 2011 at 10:03, John Bradley <jbradley at mac.com> wrote:
>> Is encryption with integrity better? Yes.
>>
>> Without AES GCM being available in common libraries we need to force a composite operation doing both encryption and HMAC.
>
> The additional cost is negligible.
>
>>
>> That is arguably not necessary if the thing you are encrypting is already signed. (as long as you don't leave your implementation open to a padding oracle attack)
>
> That happens at a different layer. It's basic rule-of-thumb in
> cryptography design that having security provide by loosely coupled
> layers that moreover are designed for independent re-use is risky and
> likely to introduce vulnerabilities in unanticipated (but valid) use
> cases.
>
>>
>> There is a fair argument for forcing HMAC if not using GCM or an equivalent. It however adds complexity and likely forces us to add an additional segment.
>> Envelope.wraped_key.content.HMAC
>
> That's not optional complexity in my view.
>
>>
>> You probably want the HMAC to be over all three proceeding elements, that is why I put it on the end.
>>
>> That is too big a change to get in before the upcoming IETF meeting though we should probably start that discussion.
>>
>> The alternative is getting GWC into a shipping version of openssl and other libraries. (I think bouncy castle is OK)
>>
>> John
>> On 2011-10-31, at 1:50 PM, Breno de Medeiros wrote:
>>
>>> I remember repeatedly arguing that non-mac'ed symmetric encryption was
>>> not useful and that the JWE spec should _not_ specify how to do that.
>>>
>>> On Sat, Oct 29, 2011 at 10:26, Mike Jones <Michael.Jones at microsoft.com> wrote:
>>>> I don't have a specific patch proposal at this time. Nat or John or Axel (or any of the rest of you!), if any of you are able to help Rob add GCM support to the PHP release in the short term, that could be a huge win.
>>>>
>>>> -- Mike
>>>>
>>>> -----Original Message-----
>>>> From: Rob Richards [mailto:rrichards at cdatazone.org]
>>>> Sent: Saturday, October 29, 2011 3:17 AM
>>>> To: Mike Jones
>>>> Cc: Anthony Nadalin; Axel.Nennker at telekom.de; jbradley at mac.com; openid-specs-ab at lists.openid.net
>>>> Subject: Re: [Openid-specs-ab] Encryption
>>>>
>>>> Mike,
>>>>
>>>> Do you have a patch for the support already? As long as there's no BC issues I might be able to get it into the 5.4 candidate before it's released. I had just started looking at adding support due to the xml enc issue but would be extremely helpful if you already had a patch.
>>>> Also if you happen to know which openssl versions the patch works with as it appears there are a number of ways to use GCM depending upon the version.
>>>>
>>>> Rob
>>>>
>>>> On 10/28/11 12:18 PM, Mike Jones wrote:
>>>>> We pretty much reached the same conclusion during the encryption working group session at IIW. The only problem, as Nat pointed out, is that PHP libraries, as currently distributed, do not support GCM (although the underlying OpenSSL libraries that PHP uses do). Of course, maybe we can use this as a forcing function to get PHP to support GCM by default (without requiring recompilation, which is possible now).
>>>>>
>>>>> -- Mike
>>>>>
>>>>> -----Original Message-----
>>>>> From: openid-specs-ab-bounces at lists.openid.net
>>>>> [mailto:openid-specs-ab-bounces at lists.openid.net] On Behalf Of Anthony
>>>>> Nadalin
>>>>> Sent: Friday, October 28, 2011 9:13 AM
>>>>> To: Axel.Nennker at telekom.de; jbradley at mac.com
>>>>> Cc: openid-specs-ab at lists.openid.net
>>>>> Subject: Re: [Openid-specs-ab] Encryption
>>>>>
>>>>> As I see it we need to require the GCM mode of operation (an authenticated encryption mode) for AES (moving AES-GCM from option to mandatory).
>>>>>
>>>>> -----Original Message-----
>>>>> From: openid-specs-ab-bounces at lists.openid.net
>>>>> [mailto:openid-specs-ab-bounces at lists.openid.net] On Behalf Of
>>>>> Axel.Nennker at telekom.de
>>>>> Sent: Friday, October 28, 2011 8:55 AM
>>>>> To: jbradley at mac.com
>>>>> Cc: openid-specs-ab at lists.openid.net
>>>>> Subject: Re: [Openid-specs-ab] Encryption
>>>>>
>>>>> Here is the link to the paper:
>>>>> http://www.nds.rub.de/media/nds/veroeffentlichungen/2011/10/22/HowToBr
>>>>> eakXMLenc.pdf
>>>>>
>>>>> The authors recommend "One possibility to avoid our attack is to use a symmetric cryptographic primitive that does not only provide confidentiality, but also integrity. This can for instance be achieved by replacing the CBC mode of operation with a mode that provides message integrity. Adequate choices have for instance been standardized in ISO/IEC 19772:2009. We consider this solution as very recommendable for future versions of the XML Encryption standard. Unfortunately, this may bring deployment and backwards compatibility issues."
>>>>>
>>>>> http://www.iso.org/iso/catalogue_detail?csnumber=46345
>>>>>
>>>>> -Axel
>>>>>
>>>>> -----Original Message-----
>>>>> From: John Bradley [mailto:jbradley at mac.com]
>>>>> Sent: Freitag, 28. Oktober 2011 16:22
>>>>> To: Nennker, Axel
>>>>> Cc: Nat Sakimura; Michael Jones; openid-specs-ab at lists.openid.net
>>>>> Subject: Re: [Openid-specs-ab] Encryption
>>>>>
>>>>> We don't encryption it, but we do support it.
>>>>>
>>>>> I haven't seen the original paper only analysis of it.
>>>>>
>>>>> Mike should be able to get it.
>>>>>
>>>>> I don't think we should panic. I have known about this for a week or so.
>>>>>
>>>>> While the problem involves CBC it is not necessarily a CBC algorithm vulnerability in itself.
>>>>>
>>>>> The problem is likely the xmlenc API error messages and having them reported back over SOAP.
>>>>>
>>>>> As long as we are careful about not communicating too much in the error message and implementers protect against side channel timing attacks, JWE probably is OK as is with appropriate security considerations.
>>>>>
>>>>> I would be surprised if the attack works agains AES-CBC + RSA.
>>>>>
>>>>> It also probably is ineffective agains AES-CBC+keywrap.
>>>>>
>>>>> Yes GWC is better that is why it was created.
>>>>>
>>>>> We need the paper before trying to fix things that may not need fixing.
>>>>>
>>>>> John B.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On 2011-10-28, at 10:13 AM, Axel.Nennker at telekom.de wrote:
>>>>>
>>>>>> Do we actually require encryption in the openid connect standards? I thought we refer to JWS and JWS and that's it?
>>>>>> Axel
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: openid-specs-ab-bounces at lists.openid.net
>>>>>> [mailto:openid-specs-ab-bounces at lists.openid.net] On Behalf Of
>>>>>> sakimura
>>>>>> Sent: Freitag, 28. Oktober 2011 13:36
>>>>>> To: Mike Jones; John Bradley; Anthony Nadalin; Openid specs ab
>>>>>> Subject: [Openid-specs-ab] Encryption
>>>>>>
>>>>>> So I was going over the recent XML Encryption vulnerability.
>>>>>> http://www.informationweek.com/news/security/vulnerabilities/23190153
>>>>>> 2
>>>>>>
>>>>>> The flaw is that of CBC mode of operation combined with
>>>>>> unauthenticated encryption.
>>>>>> It is a kind of padding oracle attack.
>>>>>>
>>>>>> We have two choices here:
>>>>>>
>>>>>> 1) Require authenticated encryption mode such as GCM
>>>>>> 2) Require message authentication to be applied to the cipher text.
>>>>>>
>>>>>> Ideally 1) should be taken as operational efficiency is much greater
>>>>>> than 2), but in reality we do not have support for GCM in many
>>>>>> languages.
>>>>>>
>>>>>> Thus, while RECOMMENDing 1), we should REQUIRE HMAC to be applied on
>>>>>> the encrypted text (cipher text) in CBC mode.
>>>>>>
>>>>>> Thus, we should make it REQUIRED to sig+enc+mac, instead of sig+enc,
>>>>>> and REQUIRE the verifier to first verify the mac and if the mac is
>>>>>> not correct the process should abend returning mac error.
>>>>>>
>>>>>> Also, although same public-private keypair can be used for encryption
>>>>>> and signature in case of RSA, we should probably use two separate
>>>>>> keypair. That is safer.
>>>>>> Perhaps we would not REQUIRE it, but we should RECOMMEND it.
>>>>>>
>>>>>> =nat
>>>>>>
>>>>>> _______________________________________________
>>>>>> Openid-specs-ab mailing list
>>>>>> Openid-specs-ab at lists.openid.net
>>>>>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>>>>> _______________________________________________
>>>>> Openid-specs-ab mailing list
>>>>> Openid-specs-ab at lists.openid.net
>>>>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Openid-specs-ab mailing list
>>>>> Openid-specs-ab at lists.openid.net
>>>>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>>>>>
>>>>> _______________________________________________
>>>>> Openid-specs-ab mailing list
>>>>> Openid-specs-ab at lists.openid.net
>>>>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Openid-specs-ab mailing list
>>>> Openid-specs-ab at lists.openid.net
>>>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>>>>
>>>
>>>
>>>
>>> --
>>> --Breno
>>> _______________________________________________
>>> Openid-specs-ab mailing list
>>> Openid-specs-ab at lists.openid.net
>>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>>
>>
>
>
>
> --
> --Breno
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20111031/7ad877a4/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4767 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20111031/7ad877a4/attachment.p7s>
More information about the Openid-specs-ab
mailing list