As I have pointed out in the earlier mail, being a variant of padding oracle attack, not giving out information when error occurs is one key part of mitigation, as it seems. Integrity checking / authenticating the cipher text is one way to do it. Fortunately, we do not have flaws like XML Signature Wrapping attack. So applying HMAC seems to be adequate to mitigate this attack. This actually has to be a part of JWE, I suppose. <div>
<br></div><div>While checking these, I found bugs in Messages: </div><div><br></div><div>Messages - 3.1.2.1 iss and aud </div><div><br></div><div>It states "<span class="Apple-style-span" style="font-family: verdana, charcoal, helvetica, arial, sans-serif; background-color: rgb(255, 255, 255); ">If signed, the OpenID Request Object SHOULD contain the standard JWT "</span><tt style="color: rgb(0, 51, 102); font-family: 'Courier New', Courier, monospace; background-color: rgb(255, 255, 255); ">iss</tt><span class="Apple-style-span" style="font-family: verdana, charcoal, helvetica, arial, sans-serif; background-color: rgb(255, 255, 255); ">" and "</span><tt style="color: rgb(0, 51, 102); font-family: 'Courier New', Courier, monospace; background-color: rgb(255, 255, 255); ">aud</tt><span class="Apple-style-span" style="font-family: verdana, charcoal, helvetica, arial, sans-serif; background-color: rgb(255, 255, 255); ">" claims." It MUST contain them to thwart surrepetitious forwarding etc. </span></div>
<div><span class="Apple-style-span" style="font-family: verdana, charcoal, helvetica, arial, sans-serif; background-color: rgb(255, 255, 255); "><br></span></div><div><span class="Apple-style-span" style="font-family: verdana, charcoal, helvetica, arial, sans-serif; background-color: rgb(255, 255, 255); ">Messages - 3.3.2 Must require iss and aud for signed response</span></div>
<div><span class="Apple-style-span" style="font-family: verdana, charcoal, helvetica, arial, sans-serif; background-color: rgb(255, 255, 255); "><br></span></div><div><span class="Apple-style-span" style="font-family: verdana, charcoal, helvetica, arial, sans-serif; background-color: rgb(255, 255, 255); ">I will check if they are already ticketed, and if not, will ticket them. </span></div>
<div><span class="Apple-style-span" style="font-family: verdana, charcoal, helvetica, arial, sans-serif; background-color: rgb(255, 255, 255); "><br></span></div><div><span class="Apple-style-span" style="font-family: verdana, charcoal, helvetica, arial, sans-serif; background-color: rgb(255, 255, 255); ">Nat</span></div>
<div><font class="Apple-style-span" face="verdana, charcoal, helvetica, arial, sans-serif"><br></font></div><div><font class="Apple-style-span" face="verdana, charcoal, helvetica, arial, sans-serif"><br></font><br><div class="gmail_quote">
On Sat, Oct 29, 2011 at 1:52 AM, John Bradley <span dir="ltr"><<a href="mailto:ve7jtb@ve7jtb.com">ve7jtb@ve7jtb.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
It is a complicated attack.  One of the main things it relies on is an ability to differentiate between decryption (padding) errors and XML validation errors.<br>
<br>
Part of it is also based on XML syntax.  Though I suspect that you could do the same thing for JSON.<br>
<br>
Having an integrity check so that the attacker only gets back deception errors is one way to stop the attack.<br>
<br>
Updating PHP and other things will take time no matter what we want.<br>
<br>
We should better understand the problem and other potential mitigations before completely throwing out AES-CBC.<br>
<br>
John B.<br>
<div><div></div><div class="h5">On 2011-10-28, at 1:18 PM, Mike Jones wrote:<br>
<br>
> 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).<br>

><br>
>                               -- Mike<br>
><br>
> -----Original Message-----<br>
> From: <a href="mailto:openid-specs-ab-bounces@lists.openid.net">openid-specs-ab-bounces@lists.openid.net</a> [mailto:<a href="mailto:openid-specs-ab-bounces@lists.openid.net">openid-specs-ab-bounces@lists.openid.net</a>] On Behalf Of Anthony Nadalin<br>

> Sent: Friday, October 28, 2011 9:13 AM<br>
> To: <a href="mailto:Axel.Nennker@telekom.de">Axel.Nennker@telekom.de</a>; <a href="mailto:jbradley@mac.com">jbradley@mac.com</a><br>
> Cc: <a href="mailto:openid-specs-ab@lists.openid.net">openid-specs-ab@lists.openid.net</a><br>
> Subject: Re: [Openid-specs-ab] Encryption<br>
><br>
> 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).<br>
><br>
> -----Original Message-----<br>
> From: <a href="mailto:openid-specs-ab-bounces@lists.openid.net">openid-specs-ab-bounces@lists.openid.net</a> [mailto:<a href="mailto:openid-specs-ab-bounces@lists.openid.net">openid-specs-ab-bounces@lists.openid.net</a>] On Behalf Of <a href="mailto:Axel.Nennker@telekom.de">Axel.Nennker@telekom.de</a><br>

> Sent: Friday, October 28, 2011 8:55 AM<br>
> To: <a href="mailto:jbradley@mac.com">jbradley@mac.com</a><br>
> Cc: <a href="mailto:openid-specs-ab@lists.openid.net">openid-specs-ab@lists.openid.net</a><br>
> Subject: Re: [Openid-specs-ab] Encryption<br>
><br>
> Here is the link to the paper:<br>
> <a href="http://www.nds.rub.de/media/nds/veroeffentlichungen/2011/10/22/HowToBreakXMLenc.pdf" target="_blank">http://www.nds.rub.de/media/nds/veroeffentlichungen/2011/10/22/HowToBreakXMLenc.pdf</a><br>
><br>
> 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."<br>

><br>
> <a href="http://www.iso.org/iso/catalogue_detail?csnumber=46345" target="_blank">http://www.iso.org/iso/catalogue_detail?csnumber=46345</a><br>
><br>
> -Axel<br>
><br>
> -----Original Message-----<br>
> From: John Bradley [mailto:<a href="mailto:jbradley@mac.com">jbradley@mac.com</a>]<br>
> Sent: Freitag, 28. Oktober 2011 16:22<br>
> To: Nennker, Axel<br>
> Cc: Nat Sakimura; Michael Jones; <a href="mailto:openid-specs-ab@lists.openid.net">openid-specs-ab@lists.openid.net</a><br>
> Subject: Re: [Openid-specs-ab] Encryption<br>
><br>
> We don't encryption it, but we do support it.<br>
><br>
> I haven't seen the original paper only analysis of it.<br>
><br>
> Mike should be able to get it.<br>
><br>
> I don't think we should panic.   I have known about this for a week or so.<br>
><br>
> While the problem involves CBC it is not necessarily a CBC algorithm vulnerability in itself.<br>
><br>
> The problem is likely the xmlenc API error messages and having them reported back over SOAP.<br>
><br>
> 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.<br>
><br>
> I would be surprised if the attack works agains AES-CBC + RSA.<br>
><br>
> It also probably is ineffective agains AES-CBC+keywrap.<br>
><br>
> Yes GWC is better that is why it was created.<br>
><br>
> We need the paper before trying to fix things that may not need fixing.<br>
><br>
> John B.<br>
><br>
><br>
><br>
><br>
> On 2011-10-28, at 10:13 AM, <a href="mailto:Axel.Nennker@telekom.de">Axel.Nennker@telekom.de</a> wrote:<br>
><br>
>> Do we actually require encryption in the openid connect standards? I thought we refer to JWS and JWS and that's it?<br>
>> Axel<br>
>><br>
>><br>
>><br>
>><br>
>> -----Original Message-----<br>
>> From: <a href="mailto:openid-specs-ab-bounces@lists.openid.net">openid-specs-ab-bounces@lists.openid.net</a><br>
>> [mailto:<a href="mailto:openid-specs-ab-bounces@lists.openid.net">openid-specs-ab-bounces@lists.openid.net</a>] On Behalf Of<br>
>> sakimura<br>
>> Sent: Freitag, 28. Oktober 2011 13:36<br>
>> To: Mike Jones; John Bradley; Anthony Nadalin; Openid specs ab<br>
>> Subject: [Openid-specs-ab] Encryption<br>
>><br>
>> So I was going over the recent XML Encryption vulnerability.<br>
>> <a href="http://www.informationweek.com/news/security/vulnerabilities/231901532" target="_blank">http://www.informationweek.com/news/security/vulnerabilities/231901532</a><br>
>><br>
>> The flaw is that of CBC mode of operation combined with<br>
>> unauthenticated encryption.<br>
>> It is a kind of padding oracle attack.<br>
>><br>
>> We have two choices here:<br>
>><br>
>> 1) Require authenticated encryption mode such as GCM<br>
>> 2) Require message authentication to be applied to the cipher text.<br>
>><br>
>> Ideally 1) should be taken as operational efficiency is much greater<br>
>> than 2), but in reality we do not have support for GCM in many<br>
>> languages.<br>
>><br>
>> Thus, while RECOMMENDing 1), we should REQUIRE HMAC to be applied on<br>
>> the encrypted text (cipher text) in CBC mode.<br>
>><br>
>> Thus, we should make it REQUIRED to sig+enc+mac, instead of sig+enc,<br>
>> and REQUIRE the verifier to first verify the mac and if the mac is not<br>
>> correct the process should abend returning mac error.<br>
>><br>
>> Also, although same public-private keypair can be used for encryption<br>
>> and signature in case of RSA, we should probably use two separate<br>
>> keypair. That is safer.<br>
>> Perhaps we would not REQUIRE it, but we should RECOMMEND it.<br>
>><br>
>> =nat<br>
>><br>
>> _______________________________________________<br>
>> Openid-specs-ab mailing list<br>
>> <a href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a><br>
>> <a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
><br>
> _______________________________________________<br>
> Openid-specs-ab mailing list<br>
> <a href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a><br>
> <a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
><br>
><br>
><br>
><br>
> _______________________________________________<br>
> Openid-specs-ab mailing list<br>
> <a href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a><br>
> <a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
><br>
> _______________________________________________<br>
> Openid-specs-ab mailing list<br>
> <a href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a><br>
> <a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
<br>
</div></div><br>_______________________________________________<br>
Openid-specs-ab mailing list<br>
<a href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br>Nat Sakimura (=nat)<div>Chairman, OpenID Foundation<br><a href="http://nat.sakimura.org/" target="_blank">http://nat.sakimura.org/</a><br>@_nat_en</div><br>

</div>