[Openid-specs-ab] Encryption

Mike Jones Michael.Jones at microsoft.com
Sat Oct 29 22:10:12 UTC 2011


For what it's worth, the JSMS spec required integrity for all encryption operations.  You can read how they did it by searching for the word "integrity" in http://tools.ietf.org/html/draft-rescorla-jsms-00.  So you wouldn't get opposition from Eric and Joe for your proposal.  (It does require, in the general case, specifying another key, however.)

                                                            -- Mike

From: Nat Sakimura [mailto:sakimura at gmail.com]
Sent: Saturday, October 29, 2011 3:06 PM
To: Mike Jones
Cc: John Bradley; openid-specs-ab at lists.openid.net
Subject: Re: [Openid-specs-ab] Encryption

Let us bring it up in Taipei, then.

FYI, I initially thought the same as you, but after some contemplation, I changed my opinion.
My reasoning for HMACing with encryption was:

1) Encrypt then hmac in nested operation, it will blow up the size.
2) Encrypt then hmac in nested operation, how to exchange the key for the hmac becomes an issue.

I cannot come up with a good solution for these as long as I keep them as two separate steps.

If Encrypt and hmac is done as a combined operation to create a JWT, then both problems goes away.

=nat
On Sun, Oct 30, 2011 at 5:13 AM, Mike Jones <Michael.Jones at microsoft.com<mailto:Michael.Jones at microsoft.com>> wrote:
I'd bring it up on Taipei.  In-person discussions on topics of this complex nature are more likely to generate consensus (in my experience) during face-to-face discussions than on e-mail lists.

As a technical point, I'd hate to see HMAC be required when nested Encryption and Signing operations are another perfectly valid mechanism for achieving the same ends.

                                                            -- Mike

From: openid-specs-ab-bounces at lists.openid.net<mailto:openid-specs-ab-bounces at lists.openid.net> [mailto:openid-specs-ab-bounces at lists.openid.net<mailto:openid-specs-ab-bounces at lists.openid.net>] On Behalf Of Nat Sakimura
Sent: Saturday, October 29, 2011 1:11 PM
To: John Bradley

Cc: openid-specs-ab at lists.openid.net<mailto:openid-specs-ab at lists.openid.net>
Subject: Re: [Openid-specs-ab] Encryption

HMACing with CEK and have that in JWE spec as REQUIRED in case of CBC would be really nice.

Maybe I should post it in Jose list or bring it up in Taipei.

=nat via iPhone

On 2011/10/30, at 3:54, John Bradley <ve7jtb at ve7jtb.com<mailto:ve7jtb at ve7jtb.com>> wrote:

On 2011-10-29, at 3:42 PM, Nat Sakimura wrote:



=nat via iPhone

On 2011/10/30, at 2:52, John Bradley <ve7jtb at ve7jtb.com<mailto:ve7jtb at ve7jtb.com>> wrote:

The reality is that we are not going to be able to REQUIRE AES-GWC any time soon.

+1 though keep pressuring the implementations to support GCM etc. should continue.


I think that libraries not providing padding oracles and other side channels is important to be clear about.

AES-CBC is still something important to support.

One possible combination is using zip

gzip I guess.

JWE refers to it as zip, but it is deflate in a gzip container (not zlib).  I am looking for some better wording for the JWE spec.


with AES-CBC and not differentiating between padding and inflate errors.  The CRC32 integrity check over the uncompressed source would foil the oracle attack.

That should make it significantly harder though it may not be impossible.

There are a bunch of implementation details around error reporting that would determine that.  one would be how you report invalid content type if someone removed the zip flag from the envelope.

So perfect is hard,  however we do have other tools like reporting signing and encrypting errors as a composite value where we encrypt a signed object.

GWC also has some issues with long cypher texts so is not pure magic on it's own.

John B.


John B.
On 2011-10-29, at 7:17 AM, Rob Richards wrote:

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> [mailto: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<mailto:Axel.Nennker at telekom.de>; jbradley at mac.com<mailto:jbradley at mac.com>
Cc: openid-specs-ab at lists.openid.net<mailto: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> [mailto: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<mailto:Axel.Nennker at telekom.de>
Sent: Friday, October 28, 2011 8:55 AM
To: jbradley at mac.com<mailto:jbradley at mac.com>
Cc: openid-specs-ab at lists.openid.net<mailto: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/HowToBreakXMLenc.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<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<mailto: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<mailto: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>
[mailto: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/231901532

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<mailto: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<mailto: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<mailto: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<mailto: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<mailto:Openid-specs-ab at lists.openid.net>
http://lists.openid.net/mailman/listinfo/openid-specs-ab




--
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20111029/bb774eaf/attachment-0001.html>


More information about the Openid-specs-ab mailing list