Dear all,
In the call yesterday I was asked to provide some information on
SHA256 in Web Services.
1) SHA256 is supported as a digest algorithm in WS-SecurityPolicy:
http://docs.oasis-open.org/ws-sx/ws-securitypolicy/v1.3/os/ws-securitypolicy-1.3-spec-os.html#_Toc212617835
Many vendors implement WS-SecurityPolicy, they should have no issue
with an upgrade of BSP, section 9.6.1, to require SHA256 instead of
SHA1.
2) Section 9.7.1 of BSP currently recommends RSA-SHA1 as signature
algorithm. For signature, RSA-SHA1 is hardwired in
WS-SecurityPolicy. It unfortunately does not support
http://www.w3.org/2001/04/xmldsig-more#rsa-sha256 as an alternative
signature algorithm. However, some products that use
WS-SecurityPolicy only treat RSA-SHA1 as a default that a developer
can override.
Some discussion (including some important interop issues):
https://access.redhat.com/site/documentation/en-US/JBoss_Fuse/6.0/html/Web_Services_Security_Guide/files/MsgProtect-SOAP-SpecifyAlgorithmSuite.html
http://cxf.547215.n5.nabble.com/CXF-Security-policy-signature-method-td5732250.html
http://www.fokkog.com/2011/01/ws-security-interoperability-issue.html
3) Some vendors are adding support for RSA-SHA256, here is
information for two products (result of a quick Web search only, so
there are probably more besides these two):
http://publib.boulder.ibm.com/infocenter/ieduasst/v1r1m0/topic/com.ibm.iea.was_v8/was/8.0.0.4/Security/WAS8004_Support_SHA_Algorithms.pdf
http://pic.dhe.ibm.com/infocenter/wasinfo/v8r5/index.jsp?topic=%2Fcom.ibm.websphere.wlp.express.doc%2Fae%2Fcwlp_wssec_defaultconfig.html
https://blogs.oracle.com/gfsecurity/entry/what_s_new_in_metro
https://blogs.oracle.com/SureshMandalapu/entry/support_of_rsa_sha256_and
4) On end user requirements, some communities I am working with are
looking to implement data exchanges that are secured using
WS-Security. These are new, large scale exchanges, and some are in
the energy sector supporting "critical infrastructures". Therefore
the intention is to start with a state-of-the-art, secure foundation
that (based on current insights) will be sufficiently secure for at
least the next decade.
Hope this is useful ..
Kind Regards,
Pim van der Eijk
On 05/01/2014 06:04 PM, Pim van der
Eijk wrote:
Dear all,
Here is some input for today's meeting on SHA1, summarizing the
issues and potential solutions.
First of all, there are (apart from Jacques' proposal, which is
more a short term "quick fix") two options to address the SHA1
issue for the cases in 9.6.1 and 9.7.1 (see email below):
1) Generalizing the recommendation to reference the W3C
recommendations instead of mentioning specific values.
2) Upgrading some references to algorithms based on SHA256 (which
is the minimal recommendation as of 2014).
Second and more problematic are dependencies on other standards
that have SHA1 hard-wired:
1) Section 13.2.6 mentions http://docs.oasis-open.org/wss/oasis-wss-soap-message-security-1.1#ThumbprintSHA1,
which is defined in WS-Security SOAP Message Security
[1].
2) Section 15.2.2 mentions http://docs.oasis-open.org/wss/oasis-wss-kerberos-token-profile-1.1#Kerberosv5APREQSHA1 which is defined in the WS-Security Kerberos
profile [2]. (Actually, BSP 15.2.2 has a typo: "tokenprofile" instead of "token-profile").
These two referenced specifications do not include identifiers for
SHA-256-based (or better) variants of these algorithms. This is
an issue for the WSS-M TC, which unfortunately has been inactive
since July 2012 ..
A separate third issue for implementations is that upgrading some
algorithms, e.g. from RSA-SHA1 to RSA-SHA256, may be problematic
for security toolkits that can only be configured using
WS-SecurityPolicy, as that specification only supports RSA-SHA1.
This is also not an issue for this WS-BRSP TC but rather for the
WS-SX TC. I raised this on their mailing list [3], but that TC
also seems to be no longer active.
Kind Regards,
Pim van der Eijk
[1]
http://docs.oasis-open.org/wss-m/wss/v1.1.1/os/wss-SOAPMessageSecurity-v1.1.1-os.html
[2]
http://docs.oasis-open.org/wss-m/wss/v1.1.1/os/wss-KerberosTokenProfile-v1.1.1-os.html
[3] https://lists.oasis-open.org/archives/ws-sx/201401/msg00000.html
On 03/20/2014 06:28 PM, Pim van der
Eijk wrote:
Hello Jacques,
I would propose to indeed change the "preferred" status of
SHA-1. It is not consistent with current information security
guidance, which states (this is from a European agency, the
content is consistent with guidelines from agencies in other
geographies):
"Hash Functions: For near term use we recommend SHA-256 and
for long term use SHA-512."
(Page 34 in http://www.enisa.europa.eu/activities/identity-and-trust/library/deliverables/algorithms-key-sizes-and-parameters-report)
http://www.w3.org/TR/2013/REC-xmldsig-core1-20130411/#sec-MessageDigests
writes:
"This specification defines several possible digest
algorithms for the DigestMethod element, including REQUIRED algorithm
SHA-256. Use of SHA-256 is strongly recommended over SHA-1
because recent advances in cryptanalysis (see e.g. [SHA-1-Analysis])
have cast doubt on the long-term collision resistance of
SHA-1. Therefore, SHA-1 support is REQUIRED in this specification only
for backwards-compatibility reasons."
To be consistent with the W3C XML Signature and XML Encryption
recommendations, we could reference the W3C recommendation
directly and replace:
9.6.1 SHA-1 Preferred
The SHA-1 Digest algorithm is widely-implemented and
interoperable hence the recommendation that it be used for
signature digests.
R5420 Any DIGEST_METHOD Algorithm attribute SHOULD have the
value "http://www.w3.org/2000/09/xmldsig#sha1".
By:
9.6.1 Message Digest Algorithms
R5420? Message Digests SHOULD use message digest algorithms that
are consistent with recommendations in http://www.w3.org/TR/2013/REC-xmldsig-core1-20130411/#sec-MessageDigests.
In some cases, the W3C recommendation lists quite a lot of
options, and we could be more specific and pick a common one:
9.7.1 Algorithms
The two algorithms listed are widely-implemented and
interoperable. Two algorithms are needed, one symmetric, one
asymmetric.
R5421 Any SIGNATURE_METHOD Algorithm attribute SHOULD have a
value of "http://www.w3.org/2000/09/xmldsig#hmac-sha1"
or "http://www.w3.org/2000/09/xmldsig#rsa-sha1".
By:
9.7.1 Algorithms
R5421? Signatures SHOULD be computed using either http://www.w3.org/2001/04/xmldsig-more#hmac-sha256
or http://www.w3.org/2001/04/xmldsig-more#rsa-sha256
algorithms.
Problematic are the SHA1 references in 13.2.6 and 13.2.7 , since
there is only a http://docs.oasis-open.org/wss/oasis-wss-soap-message-security-1.1#ThumbprintSHA1
and no equivalent for SHA256.
All examples in the spec are based on SHA1 and would then need
to be reviewed as well.
Kind Regards,
Pim
|