< draft-enhanced-xml-digital-signature-algorithm-00.txt   draft-enhanced-xml-digital-signature-algorithm-01.txt >
IETF Jitendra Kumar IETF Jitendra Kumar
Internet-Draft Balaji Rajendran Internet-Draft Balaji Rajendran
Intended status: Experimental Bindhumadhava BS Intended status: Best Current Practice Bindhumadhava BS
Expires: July 13, 2019 C-DAC Bangalore Expires: August 8, 2019 C-DAC Bangalore
January 9, 2019 February 04, 2019
Enhanced XML Digital Signature Algorithm to Mitigate Wrapping Attacks Enhanced XML Digital Signature Algorithm to Mitigate Wrapping Attacks
draft-enhanced-xml-digital-signature-algorithm-00 draft-enhanced-xml-digital-signature-algorithm-01
Abstract Abstract
XML signature standard as described in [RFC3275] and defined by IETF/ XML signature standard [RFC3275]identifies signed elements by their
W3C references or identifies signed elements by their unique unique identities in the XML document. However this allows shifting
identities in the given XML document. Hence, signed XML elements can of XML elements from one location to another within the same XML
be shifted from one location to another location in a XML document, without affecting the ability to verify the signature.
document,and still, it does not have any effect on its ability to This flexibility paves the way for an attacker to tweak the original
verify its signature. This flexibility paves the way for an attacker XML message without getting noticed by the receiver, leading to XML
to tweak original XML message without getting noticed by the Signature wrapping or rewriting attacks. This document proposes to
receiver. This document proposes to use absolute XPath as an use absolute XPath as a "Positional Token" and modifies the existing
"Positional Token" and modifies existing XML Digital Signature XML Digital Signature algorithm to overcome this attack.
algorithm to overcome the XML Signature wrapping/rewriting attacks on
XML ignatures.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 13, 2019. This Internet-Draft will expire on August 8, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 18 skipping to change at page 2, line 16
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. XML Digital Signature structure . . . . . . . . . . . . . . . 3 2. XML Digital Signature structure . . . . . . . . . . . . . . . 3
3. Suggested Modified Algorithm . . . . . . . . . . . . . . . . 3 3. Suggested Modified Algorithm . . . . . . . . . . . . . . . . 3
3.1. Algorithm for signing SOAP Request . . . . . . . . . . . 4 3.1. Algorithm for XML Signature . . . . . . . . . . . . . . . 4
3.2. Algorithm for verification of Signature . . . . . . . . . 4 3.2. Algorithm for verification of Signature . . . . . . . . . 4
3.2.1. Verifying SignedInfo Element Digest with Decrypted 3.2.1. Verifying SignedInfo Element Digest with Decrypted
Digest from SignatureValue element . . . . . . . . . 5 Digest from SignatureValue element . . . . . . . . . 5
4. Simple Example . . . . . . . . . . . . . . . . . . . . . . . 5 4. Simple Example . . . . . . . . . . . . . . . . . . . . . . . 5
5. Algorithm Validation . . . . . . . . . . . . . . . . . . . . 9 5. Algorithm Validation . . . . . . . . . . . . . . . . . . . . 9
5.1. Mitigation of XML Signature wrapping attacks . . . . . . 9 5.1. Mitigation of XML Signature wrapping attacks . . . . . . 9
5.2. Mitigation of XML elements jumbling type of wrapping 5.2. Mitigation of XML elements jumbling type of wrapping
attacks . . . . . . . . . . . . . . . . . . . . . . . . . 9 attacks . . . . . . . . . . . . . . . . . . . . . . . . . 9
6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 9 6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 9
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
9.1. Normative References . . . . . . . . . . . . . . . . . . 10 9.1. Normative References . . . . . . . . . . . . . . . . . . 10
9.2. Informative References . . . . . . . . . . . . . . . . . 10 9.2. Informative References . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction 1. Introduction
Many researchers have shown that even a signed SOAP messages are McIntosh and Austel have illustrated that a SOAP message with XML
vulnerable to interception and further manipulation of its content. Digital Signature (described in wrapping_attack [wrapping_attack])
McIntosh and Austel (described in wrapping_attack [wrapping_attack]) can be forged without invalidating the signature and they have
have illustrated that a SOAP message content, protected by an XML further illustrated that a SOAP message content, protected by an XML
Digital Signature, as specified in WS-Security(refer, WS-Security Digital Signature, as specified in WS-Security(refer, WS-Security
[WS-Security]) can be forged without invalidating the signature. [WS-Security]) can be forged without invalidating the signature.
These attacks are termed as XML Signature wrapping attacks or XML This attack is possible because the XML Digital Signature refers to a
rewriting attacks.These types of attacks are possible because the XML signed element in XML document in a way without giving significance
Digital Signature refers to a signed element in XML document in a way to the position within the XML document. An attacker may inject
that does not take care of its location inside the XML document into additional nodes replacing the signed nodes while still preserving
consideration.Attackers inject additional nodes replacing signed the signed nodes inside the document at different levels in the
nodes while still preserving the signed nodes inside the document but hierarchy of the XML tree, such that it results in successful
at different level in the hierarchy of the XML tree such that it signature verification thereby resulting in XML Re-Writing or
results in successful signature verification thereby resulting in XML Wrapping attack.
Re-Writing/Wrapping attack.
1.1. Requirements Language 1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
2. XML Digital Signature structure 2. XML Digital Signature structure
XML Signatures (described in RFC3275 [RFC3275]) are applied to XML Signatures (described in RFC3275 [RFC3275]) are applied to
skipping to change at page 3, line 37 skipping to change at page 3, line 37
(<Transforms>)? (<Transforms>)?
<DigestMethod> <DigestMethod>
<DigestValue> <DigestValue>
</Reference>)+ </Reference>)+
</SignedInfo> </SignedInfo>
<SignatureValue> <SignatureValue>
(<KeyInfo>)? (<KeyInfo>)?
(<Object ID?>)* (<Object ID?>)*
</Signature> </Signature>
Signatures are related to data objects via URIs [URI].Within an XML Signatures are related to data objects via URIs [URI]. Within an XML
document, signatures are related to local data objects via fragment document, signatures are related to local data objects via fragment
identifiers. identifiers.
3. Suggested Modified Algorithm 3. Suggested Modified Algorithm
As, SOAP requests are prone to XML wrapping attacks and this As XML requests are prone to XML Signature wrapping attacks and these
vulnerabilities stems mostly because of usage of ID (Identity) to vulnerabilities stems from the usage of ID (Identity) to identify the
identify the signed XML sub tree. There are many solutions proposed signed XML subtree. There are many solutions proposed to mitigate
to mitigate such attacks but still such attacks can't be fully such attacks but still,such attacks can't be fully eliminated. In
eliminated because of inherent limitation present in XML Digital this document, we have proposed the addition of XPath as a doping to
Signature standard.In this document, we have proposed an addition of the XML element being signed to mitigate XML Signature wrapping
"Positional Token" as a doping to the XML element getting signed to attacks. We propose to use "Absolute XPath" instead of ID in
mitigate XML Signature wrapping attacks. We are also proposing a <Reference> node's "URI" attribute to refer to the signed element.
little modification of existing XML Signature standard as to use of Absolute XPath can be used as "Positional Token", as this token
"Absolute XPath" instead of ID in <Reference> node's "URI" attribute exactly points to the position of the element being signed. During
to refer the signed element. Use this absolute XPath as a the signing process, this "Positional Token" gets added as an
"Positional Token", as this token exactly points to the position of attribute e.g. PosToken= "Absolute XPath") to the element that is
element getting signed. Also, during signing process, add this subjected to be signed.This absolute XPath as a "Positional Token"
"Positional Token" as an attribute (e.g. PosToken= "Absolute XPath") would identify the signed element in XML Signature and addition of
to the element subjected to be signed. This absolute XPath as a this "Positional Token" as an attribute to the element being signed
"Positional Token" would identify the signed element in XML Signature would eliminate the chances of XML Signature Wrapping attacks wherein
and addition of this "Positional Token" as an attribute to the the calculated digest of the signed element in forged XML document
element getting signed eliminate the chances of XML Wrapping attacks will not match with the respective digest value in <DigestValue> node
as in the case of forged SOAP requests, calculated digest of signed during signature validation process. We propose a modified XML
element will not match with the respective digest value in signature algorithm which suggests usage of absolute XPath as a
<DigestValue> node during signature validation process.We propose a "Positional Token" and it will be used during signing as well as
modified XML signature algorithm which suggests usage of absolute during signature validation process. The algorithms proposed are as
XPath as a "Positional Token" and it will be used during signing as follows:
well as during signature validation process. The algorithms are as
follows.:
3.1. Algorithm for signing SOAP Request 3.1. Algorithm for XML Signature
1. KS=Load(Keystore.JKS) //Load certificates and keys 1. KS=Load(Keystore.JKS) //Load certificates and keys
2. For each element subjected to be signed(represented 2. For each element subjected to be signed(represented
by its "id" attribute value) { by its "id" attribute value) {
3. ABSXpath= "Absolute XPath" of element to be signed 3. ABSXpath= "Absolute XPath" of element to be signed
as identified with its "Id" attribute value as identified with its "Id" attribute value
4. ProtectTree=Node as identified by ABSXpath 4. ProtectTree=Node as identified by ABSXpath
5. MixedElement=AppendSyntacticToken(ProtectTree, ABSXpath) 5. MixedElement=AppendSyntacticToken(ProtectTree, ABSXpath)
/*Append a Positional Token as an attribute, /*Append a Positional Token as an attribute,
"PosToken= ABSXpath" to the ProtectTree */ "PosToken= ABSXpath" to the ProtectTree */
6. H=Hash(MixedElement) 6. H=Hash(MixedElement)
7. Add ABSXpath to <Reference> node as "URI" attribute value 7. Add ABSXpath to <Reference> node's "URI" attribute value
8. Enclose H to <DigestValue> node inside the <Reference> node, 8. Enclose H to <DigestValue> node inside the <Reference> node,
as defined in XML Signature standard. as defined in XML Signature standard.
9. } 9. }
10. SignedInfoHash=calculate hash of <SignedInfo> element 10. SignedInfoHash=calculate hash of <SignedInfo> element
/* Calculate the digest of the <SignedInfo> element */ /* Calculate the digest of the <SignedInfo> element */
11. SignedSOAP=Encrypt(SignedInfoHash , KS.PrivateKey) 11. SignedXML=Encrypt(SignedInfoHash , KS.PrivateKey)
/*Signing that digest and enclosing the signature value /*Signing that digest and enclosing the signature value
in a <SignatureValue> element */ in a <SignatureValue> element */
3.2. Algorithm for verification of Signature 3.2. Algorithm for verification of Signature
1. SignInfoDigest=Calculate digest of the <SignedInfo> element 1. SignInfoDigest=Calculate digest of the <SignedInfo> element
2. SignatureValueContent= content inside <SignatureValue> node 2. SignatureValueContent= content inside <SignatureValue> node
3. Flag=VerifySignature(Public Key, SignatureValueContent, SignInInfoDigest) 3. Flag=VerifySignature(Public Key, SignatureValueContent, SignInInfoDigest)
4. If(Flag){ 4. If(Flag){
5. Ids=All URI's in <Reference> nodes inside the <SignedInfo> node 5. Ids=All URI's in <Reference> nodes inside the <SignedInfo> node
6. For each Id from Ids){ 6. For each Id from Ids){
skipping to change at page 6, line 4 skipping to change at page 6, line 4
2. DecryptedDigest=Decrypt SignatureValueContent with PublicKey 2. DecryptedDigest=Decrypt SignatureValueContent with PublicKey
3. If(DecryptedDigest!=SignInInfoDigest){ 3. If(DecryptedDigest!=SignInInfoDigest){
4. return False 4. return False
5. } 5. }
6. else{ 6. else{
7. return True 7. return True
8. } 8. }
9. } 9. }
4. Simple Example 4. Simple Example
The <Signature> Lets consider an XML document for the example The <Signature> Lets consider an XML document as an example:
purpose:
<?xml version="1.0"?> <?xml version="1.0"?>
<PatientRecord> <PatientRecord>
<Visit date="10pm March 2018"> <Visit date="10pm March 2018">
<Account id="id1">1234</Account> <Account id="id1">1234</Account>
<Name>ABC</Name> <Name>ABC</Name>
<Diagnosis>Kidney Test</Diagnosis> <Diagnosis>Kidney Function Test</Diagnosis>
</Visit> </Visit>
<Visit date="12pm May 2018"> <Visit date="12pm May 2018">
<Account id="id2">1235</Account> <Account id="id2">1235</Account>
<Name>DEF</Name> <Name>DEF</Name>
<Diagnosis>Liver Test</Diagnosis> <Diagnosis>Liver Function Test</Diagnosis>
</Visit> </Visit>
</PatientRecord> </PatientRecord>
Figure 1 Figure 1
Existing XML Signature algorithm would produce a <Signature> element Existing XML Signature algorithm would produce a <Signature> element
for the XML document mentioned in Figure 1, as follows: for the XML document mentioned in Figure 1, as follows:
<Signature xmlns="http://www.w3.org/2000/09/xmldsig#"> <Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
<SignedInfo> <SignedInfo>
skipping to change at page 8, line 6 skipping to change at page 8, line 6
<KeyInfo> <KeyInfo>
<X509Data> <X509Data>
<X509Certificate> <X509Certificate>
............................. .............................
</X509Certificate> </X509Certificate>
</X509Data> </X509Data>
</KeyInfo> </KeyInfo>
</Signature> </Signature>
The proposed XML Signature algorithm would produce a <Signature> The proposed XML Signature algorithm would produce a <Signature>
element for the XML document mentioned in Figure 1, which is element for the XML document mentioned in Figure 1, which is
described in Figure 2. Also, during signing process, "Positional described in Figure 2. The "Positional Token" as an attribute
Token" as an attribute e.g.(PosToken= "Absolute XPath") has been used e.g.(PosToken= "Absolute XPath") is used according to the proposed
in it, as per proposed algorithm in Section 3.1. Now, <DigestValue> algorithm Section 3.1. Now, <DigestValue> elements inside
elements inside <Signature> element will also contain the trace of <Signature> element will also contain the trace of "Positional
"Positional Token", hence the relative position of signed elements in Token", hence the relative position of signed elements in the given
the given XML document: XML document:
<Signature xmlns="http://www.w3.org/2000/09/xmldsig#"> <Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
<SignedInfo> <SignedInfo>
<CanonicalizationMethod <CanonicalizationMethod
Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#WithComments" /> Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#WithComments" />
<SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1" /> <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1" />
<Reference URI="/PatientRecord/Visit[1]/Account[@id='id1']"> <Reference URI="/PatientRecord/Visit[1]/Account[@id='id1']">
<Transforms> <Transforms>
<Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" /> <Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" />
<Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" /> <Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
skipping to change at page 9, line 7 skipping to change at page 9, line 7
............................. .............................
</X509Certificate> </X509Certificate>
</X509Data> </X509Data>
</KeyInfo> </KeyInfo>
</Signature> </Signature>
Figure 2 Figure 2
5. Algorithm Validation 5. Algorithm Validation
In this section we will discuss as how the suggested algorithm can In this section, we evaluate how the suggested algorithm can mitigate
mitigate the various scenarios of XML wrapping attacks. the various scenarios of XML wrapping attacks.
5.1. Mitigation of XML Signature wrapping attacks 5.1. Mitigation of XML Signature wrapping attacks
This kind of attacks are possible because signature verification XML Signature Wrapping attacks are possible because of the inherent
algorithm identifies signed element using identity i.e. ID and flaw in the signature verification algorithm that identifies the
identifying position of signed element using ID has inherent flaw as position of signed element using ID. This makes it possible to move
the signed element can easily be moved within the document and still the signed element anywhere easily within the document and still, the
the document retains the ability to verify its signature. So, in our document would retains its ability to verify its signature.So, in our
algorithm, we have suggested the usage of absolute XPath in place of proposed algorithm, we have suggested the use of absolute XPath in
ID for identifying the position of signed elements. Absolute XPath place of ID for identifying the position of signed elements.Absolute
has two fold advantages as it can easily identify the position of XPath has two-fold advantages as it can easily identify the position
signed element within the XML document and it fixes both the vertical of the signed element within the XML document and it fixes both the
and horizontal axes of the signed element exactly. The absolute vertical and horizontal axis of the signed element exactly. The
XPath expression to identify signed element will not be same as absolute XPath expression to identify the signed element will not be
absolute XPath expression for signed element in forged document.The same in a forged document. The signature validation will fail at
signature validation will fail at step-8, of algorithm in step-8, of algorithm in Section 3.2, as there is no such node,
Section 3.2, as there is no such node, Further, if the attacker Further, if the attacker modifies the URI attribute and tries to
modifies the URI attribute and tries to perform XML wrapping attack, perform XML Signature wrapping attack, the digest of <SignedInfo>
the digest of <SignedInfo> will not match and signature validation will not match and signature validation will fail at step-4 of the
will fail at step-4 of algorithm in Section 3.2. algorithm in Section 3.2.
5.2. Mitigation of XML elements jumbling type of wrapping attacks 5.2. Mitigation of XML elements jumbling type of wrapping attacks
This kind of wrapping attacks are possible as the attacker jumbles This type of XML Signature wrapping attacks are possible as the
the position of signed elements within the document as XML signature attacker jumbles the position of signed elements within the document
process defined by specification takes only ID into consideration for exploiting the existing XML Signing algorithm that takes ID into
referencing the signed elements. The proposed algorithm suggests consideration for referencing the elements being signed.The proposed
using "Absolute XPath" for referencing the signed elements as well as algorithm suggests using "Absolute XPath" for referencing the signed
doping the elements subjected to be signed with it. Hence, the elements as well as doping the elements subjected to be signed with
digest of the signed element inside <DigestValue> node has a trail of it. Hence, the digest of the signed element inside <DigestValue>
the position of element; refer step-6 of algorithm in Section 3.1. node has a trace of the position of element; refer step-6 of
Hence, any changes in the position of signed elements by the algorithm in Section 3.1. Hence, any changes in the position of
attackers will invalidate the signature validation; refer step-12 of signed elements by the attackers will invalidate the signature; refer
algorithm in Section 3.2, because calculated digest during signature step-12 of algorithm in Section 3.2,as the calculated digest during
validation will not match with the digest contained in <DigestValue> signature validation will not match with the digest contained in
of the forged SOAP request. <DigestValue> the forged XML document.
6. Conclusion 6. Conclusion
XML Signature wrapping attacks try to inject forged elements into the XML Signature wrapping attacks try to inject forged elements into the
XML document structure in such a way that the valid signature covers XML document structure in such a way that the valid signature covers
the unmodified elements, while forged elements are processed by the the unmodified elements, while forged elements are processed by the
application logic. This results in a scenario, where an attacker can application logic. This results in a scenario, where an attacker can
perform arbitrary web service requests, while authenticating as a perform arbitrary web service requests, while authenticating as a
legitimate user. The proposed algorithm takes help of the absolute legitimate user. The proposed algorithm takes help of the absolute
XPath as a "Positional Token" for identifying the signed elements and XPath as a "Positional Token" for identifying the signed elements and
adding this to the elements to be signed as an attribute before the adding this to the elements being signed as an attribute before the
canonicalization process has a trace of both content of signed canonicalization process has a trace of both content of signed
element and its position in the XML document as well. Hence, the element and its position in the XML document as well. Hence, the
proposed algorithm can solve the issue of XML wrapping attacks proposed algorithm can solve the issue of XML signature wrapping
elegantly without much change in the current standard. attacks elegantly without much change in the current standard.
7. IANA Considerations 7. IANA Considerations
This memo includes no request to IANA. This memo includes no request to IANA.
8. Security Considerations 8. Security Considerations
This draft proposes a modification to the existing algorithm of XML This draft proposes a modification to the existing algorithm of XML
signature to counter XML Signature wrapping attacks. However other signature to counter XML Signature wrapping attacks. However other
forms of attack may be possible that could not be mitigated. forms of attack may be possible that could not be mitigated.
 End of changes. 21 change blocks. 
104 lines changed or deleted 98 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/