OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: [OASIS Issue Tracker] Updated: (SECURITY-16) PE: Mitigation for XML Encryption CBC deficiencies

     [ http://tools.oasis-open.org/issues/browse/SECURITY-16?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Scott Cantor updated SECURITY-16:

The Encryption section in Core is already chopped up by errata, with an older section related to how Signature and Encryption interact removed. I don't recall why, I guess we felt it was redundant. I suggest we add back that section (formally replace section 6.2 in the original Core):

6.2 Encryption and Integrity Protection

SAML allows for assertions containing encrypted elements to be integrity protected, and allows for encrypted assertions to be included inside protocol response elements that are themselves integrity protected (typically via XML Signature, or in some cases through binding-specific mechanisms such as TLS).

Recent practical attacks against the most common algorithms (at the time of this writing) used for bulk data encryption in [XMLEnc], which operate in CBC-mode, necessitate the enforcement of integrity protection by a relying party prior to processing encrypted data. As a result, when CBC-mode algorithms are used for data encryption, relying parties SHOULD require the presence of integrity protection before processing encrypted SAML assertions or assertions containing encrypted data. The exact appropriate means of achieving this will vary by profile, but may involve the use of authenticated TLS requests, or a requirement for an authenticated digital signature at a layer above that of the encrypted elements.

Other countermeasures, such as attempting to mitigate timing attacks, or limiting reuse of encryption keys, tend to be impractical for most implementations and the use of integrity protection, when properly implemented, is the suggested solution if authenticated encryption modes are unavailable.

Initial proposal for Core, need to suggest text for Profiles also.

> PE: Mitigation for XML Encryption CBC deficiencies
> --------------------------------------------------
>                 Key: SECURITY-16
>                 URL: http://tools.oasis-open.org/issues/browse/SECURITY-16
>             Project: OASIS Security Services (SAML) TC
>          Issue Type: Improvement
>          Components: Core
>    Affects Versions: Version 2.0
>            Reporter: Scott Cantor
>             Fix For: 2.0 incorporating Approved Errata
> A published paper (http://www.nds.rub.de/media/nds/veroeffentlichungen/2011/10/22/HowToBreakXMLenc.pdf) has described vulnerabilities in the use of CBC algorithms for data encryption when the ciphertext is not integrity-protected. The algorithms that provide built-in protection are not widely implemented yet, and the most effective mitigation for SAML implementations is to encourage the use of XML Signature or transport authentication at a layer above the use of XML Encryption. In particular, the ability to sign Responses (and require their use) is an effective strategy in many SAML profles. This is to some extent a reversal of conventional wisdom that it's more efficient and just as secure to limit signing to the Assertion layer (and then encrypt the result).

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators: http://tools.oasis-open.org/issues/secure/Administrators.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]