[Openid-specs-ab] Encryption

Mon Oct 31 19:42:10 UTC 2011

On Mon, Oct 31, 2011 at 11:02, John Bradley <ve7jtb at ve7jtb.com> wrote:
> 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.

At the very least we need to specify a companion MAC algorithm for
each encryption scheme. For instance, if someone is using a 512-bit
encryption key (conceivably in the future that will happen) the MAC
should use a 512-bit key as well. I am fine if the coupling of
encryption and mac is hard, i.e., specifying the encryption algorithm
automatically specifies the MAC algorithm. But having a single MAC
algorithm for all ciphers doesn't work.

The same goes for the hash algorithm in the KDF.

>
> 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
>
>

-- 
--Breno