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

    Proposal: 
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 most 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.

I propose the following Profile changes:

Change paragraph in Section 4.1.3.5, lines 497-500 to:

"It is RECOMMENDED that the HTTP requests in this step be made over either SSL 3.0 [SSL3] or TLS 1.0 [RFC2246] to maintain confidentiality and message integrity. For the purposes of the profile, either the <Response> or the <Assertion> element(s) in the <Response> MUST be signed, if the HTTP POST binding is used, and MAY be signed if the HTTP-Artifact binding is used. If an <EncryptedAssertion> element is present and a CBC-mode algorithm is used, then the <Response> SHOULD be signed to ensure the ciphertext is integrity protected (see section 6.2 of [SAMLCore]).

Add text to Section 4.1.4.3, after line 591:

"Note that if <EncryptedAssertion> elements are present and a CBC-mode algorithm is used, then the <Response> SHOULD be signed to ensure the ciphertext is integrity protected (see section 6.2 of [SAMLCore]). Some deployments may require both the <Response> and any <Assertion> elements be signed to address both the encryption issue and non-repudiation of the assertion (the latter being outside the scope of SAML)."

Change paragraph in Section 4.2.5, lines 1071-1074 to:

"The <AuthnRequest> message SHOULD be signed. Per the rules specified by the browser SSO profile, the assertions enclosed in the <Response>, or the <Response> itself, MUST be signed. The delivery of the response in the SOAP envelope via PAOS is essentially analogous to the use of the HTTP POST binding and security countermeasures appropriate to that binding are used.

"Note that if <EncryptedAssertion> elements are present and a CBC-mode algorithm is used, then the <Response> SHOULD be signed to ensure the ciphertext is integrity protected (see section 6.2 of [SAMLCore]). Some deployments may require both the <Response> and any <Assertion> elements be signed to address both the encryption issue and non-repudiation of the assertion (the latter being outside the scope of SAML)."

Add text to Section 6.4.2, after line 1562:

"Note that if <EncryptedAssertion> elements are present and a CBC-mode algorithm is used, then the <Response> SHOULD be signed or otherwise integrity protected (such as with a binding-specific mechanism) to ensure the ciphertext is integrity protected (see section 6.2 of [SAMLCore]). Some deployments may require both the <Response> and any <Assertion> elements be signed to address both the encryption issue and non-repudiation of the assertion (the latter being outside the scope of SAML)."

I propose the following Security Considerations changes:

Add text to section 4.2.2, at line 371:

"See section 4.6 for additional considerations related to the use of XML Encryption."

Add a new section 4.6 after line 492:

"4.6 XML Encryption Considerations

The XML Encryption specification [XMLEnc] includes important information for implementers and deployers that should be reviewed in conjunction with the use of the specification. In addition, take note that subsequent to the publication of the original 1.0 specification, vunerabilities have been found with some of the algorithms defined as mandatory to implement and that are in common usage [Ref], [Ref].

For example, the use of PKCS 1.5 as a Key Transport algorithm is subject to attacks that require mitigation by implementations The use of RSA-OAEP as an alternative algorithm is recommended as a replacement, regardless of the type or size of symmetric key.

In addition, the use of CBC mode algorithms for data encryption have been found vulnerable to attacks when used without a surrounding layer of integrity protection. Mitigating these attacks is difficult and in some cases impractical, and it is strongly advised that data encrypted with these algorithms only be processed with integrity protection in place. The use of TLS or XML Signature is often used for this purpose. Alternatively, implementatioons may be able to migrate to newer algorithms that include integrity protection as a feature, such as Galois/Counter Mode (ref. to http://csrc.nist.gov/publications/nistpubs/800-38D/SP-800-38D.pdf).

Implementers are encouraged to review all of the available literature to fully understand these issues."

  was:
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 most 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.

I propose the following Profile changes:

Change paragraph in Section 4.1.3.5, lines 497-500 to:

"It is RECOMMENDED that the HTTP requests in this step be made over either SSL 3.0 [SSL3] or TLS 1.0 [RFC2246] to maintain confidentiality and message integrity. Either the <Response> (or the <Assertion> element(s) in the <Response>) MUST be signed, if the HTTP POST binding is used, and MAY be signed if the HTTP-Artifact binding is used. If an <EncryptedAssertion> element is present and a CBC-mode algorithm is used, then the <Response> SHOULD be signed to ensure the ciphertext is integrity protected (see section 6.2 of [SAMLCore])."

Add text to Section 4.1.4.3, after line 591:

"Note that if <EncryptedAssertion> elements are present and a CBC-mode algorithm is used, then the <Response> SHOULD be signed to ensure the ciphertext is integrity protected (see section 6.2 of [SAMLCore])."

Change paragraph in Section 4.2.5, lines 1071-1074 to:

"The <AuthnRequest> message SHOULD be signed. Per the rules specified by the browser SSO profile, the assertions enclosed in the <Response>, or the <Response> itself, MUST be signed. The delivery of the response in the SOAP envelope via PAOS is essentially analogous to the use of the HTTP POST binding and security countermeasures appropriate to that binding are used.

"Note that if <EncryptedAssertion> elements are present and a CBC-mode algorithm is used, then the <Response> SHOULD be signed to ensure the ciphertext is integrity protected (see section 6.2 of [SAMLCore])."

Add text to Section 6.4.2, after line 1562:

"Note that if <EncryptedAssertion> elements are present and a CBC-mode algorithm is used, then the <Response> SHOULD be signed or otherwise integrity protected (such as with a binding-specific mechanism) to ensure the ciphertext is integrity protected (see section 6.2 of [SAMLCore])."

I propose the following Security Considerations changes:

Add text to section 4.2.2, at line 371:

"See section 4.6 for additional considerations related to the use of XML Encryption."

Add a new section 4.6 after line 492:

"4.6 XML Encryption Considerations

The XML Encryption specification [XMLEnc] includes important information for implementers and deployers that should be reviewed in conjunction with the use of the specification. In addition, take note that subsequent to the publication of the original 1.0 specification, vunerabilities have been found with some of the algorithms defined as mandatory to implement and that are in common usage [Ref], [Ref].

For example, the use of PKCS 1.5 as a Key Transport algorithm is subject to attacks that require mitigation by implementations The use of RSA-OAEP as an alternative algorithm is recommended as a replacement, regardless of the type or size of symmetric key.

In addition, the use of CBC mode algorithms for data encryption have been found vulnerable to attacks when used without a surrounding layer of integrity protection. Mitigating these attacks is difficult and in some cases impractical, and it is strongly advised that data encrypted with these algorithms only be processed with integrity protection in place. The use of TLS or XML Signature is often used for this purpose. Alternatively, implementatioons may be able to migrate to newer algorithms that include integrity protection as a feature, such as Galois/Counter Mode (ref. to http://csrc.nist.gov/publications/nistpubs/800-38D/SP-800-38D.pdf).

Implementers are encouraged to review all of the available literature to fully understand these issues."


Added some language about non-repduiation per John Bradley.

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