idnits 2.17.1 draft-enhanced-xml-digital-signature-algorithm-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 37 instances of too long lines in the document, the longest one being 39 characters in excess of 72. ** The abstract seems to contain references ([RFC3275]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 174 has weird spacing: '...BSXpath to ' and '' lines. Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'URI' is mentioned on line 130, but not defined == Unused Reference: 'RFC2807' is defined on line 398, but no explicit reference was found in the text == Unused Reference: 'I-D.narten-iana-considerations-rfc2434bis' is defined on line 409, but no explicit reference was found in the text == Unused Reference: 'RFC2629' is defined on line 415, but no explicit reference was found in the text == Unused Reference: 'RFC3552' is defined on line 419, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) Summary: 2 errors (**), 0 flaws (~~), 8 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IETF Jitendra Kumar 3 Internet-Draft Balaji Rajendran 4 Intended status: Experimental Bindhumadhava BS 5 Expires: July 13, 2019 C-DAC Bangalore 6 January 9, 2019 8 Enhanced XML Digital Signature Algorithm to Mitigate Wrapping Attacks 9 draft-enhanced-xml-digital-signature-algorithm-00 11 Abstract 13 XML signature standard as described in [RFC3275] and defined by IETF/ 14 W3C references or identifies signed elements by their unique 15 identities in the given XML document. Hence, signed XML elements can 16 be shifted from one location to another location in a XML 17 document,and still, it does not have any effect on its ability to 18 verify its signature. This flexibility paves the way for an attacker 19 to tweak original XML message without getting noticed by the 20 receiver. This document proposes to use absolute XPath as an 21 "Positional Token" and modifies existing XML Digital Signature 22 algorithm to overcome the XML Signature wrapping/rewriting attacks on 23 XML ignatures. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on July 13, 2019. 42 Copyright Notice 44 Copyright (c) 2019 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 61 2. XML Digital Signature structure . . . . . . . . . . . . . . . 3 62 3. Suggested Modified Algorithm . . . . . . . . . . . . . . . . 3 63 3.1. Algorithm for signing SOAP Request . . . . . . . . . . . 4 64 3.2. Algorithm for verification of Signature . . . . . . . . . 4 65 3.2.1. Verifying SignedInfo Element Digest with Decrypted 66 Digest from SignatureValue element . . . . . . . . . 5 67 4. Simple Example . . . . . . . . . . . . . . . . . . . . . . . 5 68 5. Algorithm Validation . . . . . . . . . . . . . . . . . . . . 9 69 5.1. Mitigation of XML Signature wrapping attacks . . . . . . 9 70 5.2. Mitigation of XML elements jumbling type of wrapping 71 attacks . . . . . . . . . . . . . . . . . . . . . . . . . 9 72 6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 9 73 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 74 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 75 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 76 9.1. Normative References . . . . . . . . . . . . . . . . . . 10 77 9.2. Informative References . . . . . . . . . . . . . . . . . 10 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 80 1. Introduction 82 Many researchers have shown that even a signed SOAP messages are 83 vulnerable to interception and further manipulation of its content. 84 McIntosh and Austel (described in wrapping_attack [wrapping_attack]) 85 have illustrated that a SOAP message content, protected by an XML 86 Digital Signature, as specified in WS-Security(refer, WS-Security 87 [WS-Security]) can be forged without invalidating the signature. 88 These attacks are termed as XML Signature wrapping attacks or XML 89 rewriting attacks.These types of attacks are possible because the XML 90 Digital Signature refers to a signed element in XML document in a way 91 that does not take care of its location inside the XML document into 92 consideration.Attackers inject additional nodes replacing signed 93 nodes while still preserving the signed nodes inside the document but 94 at different level in the hierarchy of the XML tree such that it 95 results in successful signature verification thereby resulting in XML 96 Re-Writing/Wrapping attack. 98 1.1. Requirements Language 100 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 101 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 102 document are to be interpreted as described in RFC 2119 [RFC2119]. 104 2. XML Digital Signature structure 106 XML Signatures (described in RFC3275 [RFC3275]) are applied to 107 arbitrary digital content (data objects).Data objects are digested, 108 the resulting value is placed in an element (with other information) 109 and that element is then digested and cryptographically signed.XML 110 digital signatures are represented by the Signature element which has 111 the following structure (where "?" denotes zero or one occurrence; 112 "+" denotes one or more occurrences; and "*" denotes zero or more 113 occurrences): 115 116 117 118 119 ( 120 ()? 121 122 123 )+ 124 125 126 ()? 127 ()* 128 130 Signatures are related to data objects via URIs [URI].Within an XML 131 document, signatures are related to local data objects via fragment 132 identifiers. 134 3. Suggested Modified Algorithm 136 As, SOAP requests are prone to XML wrapping attacks and this 137 vulnerabilities stems mostly because of usage of ID (Identity) to 138 identify the signed XML sub tree. There are many solutions proposed 139 to mitigate such attacks but still such attacks can't be fully 140 eliminated because of inherent limitation present in XML Digital 141 Signature standard.In this document, we have proposed an addition of 142 "Positional Token" as a doping to the XML element getting signed to 143 mitigate XML Signature wrapping attacks. We are also proposing a 144 little modification of existing XML Signature standard as to use of 145 "Absolute XPath" instead of ID in node's "URI" attribute 146 to refer the signed element. Use this absolute XPath as a 147 "Positional Token", as this token exactly points to the position of 148 element getting signed. Also, during signing process, add this 149 "Positional Token" as an attribute (e.g. PosToken= "Absolute XPath") 150 to the element subjected to be signed. This absolute XPath as a 151 "Positional Token" would identify the signed element in XML Signature 152 and addition of this "Positional Token" as an attribute to the 153 element getting signed eliminate the chances of XML Wrapping attacks 154 as in the case of forged SOAP requests, calculated digest of signed 155 element will not match with the respective digest value in 156 node during signature validation process.We propose a 157 modified XML signature algorithm which suggests usage of absolute 158 XPath as a "Positional Token" and it will be used during signing as 159 well as during signature validation process. The algorithms are as 160 follows.: 162 3.1. Algorithm for signing SOAP Request 164 1. KS=Load(Keystore.JKS) //Load certificates and keys 165 2. For each element subjected to be signed(represented 166 by its "id" attribute value) { 167 3. ABSXpath= "Absolute XPath" of element to be signed 168 as identified with its "Id" attribute value 169 4. ProtectTree=Node as identified by ABSXpath 170 5. MixedElement=AppendSyntacticToken(ProtectTree, ABSXpath) 171 /*Append a Positional Token as an attribute, 172 "PosToken= ABSXpath" to the ProtectTree */ 173 6. H=Hash(MixedElement) 174 7. Add ABSXpath to node as "URI" attribute value 175 8. Enclose H to node inside the node, 176 as defined in XML Signature standard. 177 9. } 178 10. SignedInfoHash=calculate hash of element 179 /* Calculate the digest of the element */ 180 11. SignedSOAP=Encrypt(SignedInfoHash , KS.PrivateKey) 181 /*Signing that digest and enclosing the signature value 182 in a element */ 184 3.2. Algorithm for verification of Signature 185 1. SignInfoDigest=Calculate digest of the element 186 2. SignatureValueContent= content inside node 187 3. Flag=VerifySignature(Public Key, SignatureValueContent, SignInInfoDigest) 188 4. If(Flag){ 189 5. Ids=All URI's in nodes inside the node 190 6. For each Id from Ids){ 191 7. ABSXpath=Get the content of Id 192 8. Subtree=Get the sub tree identified by ABSXpath 193 9. MixedElement =AppendSyntacticTokenSubTree(Subtree, ABSXpath) 194 /* Append a Positional Token as an attribute, 195 "PosToken= ABSXpath" to the Subtree */ 196 10. H=Hash (MixedElement)/* generate hash value of signed elements. */ 197 11. Digest=Get digest value under the 198 node and inside node, whose "URI" is equal to Id 199 12. If(H!=Digest){ 200 13. return "Signature Validation Failed" 201 14. }else{ 202 15. return "Signature Validation Successful" 203 16. } 204 17. } //For loop 205 18. else 206 19. return "Signature Validation Failed" 207 20. } 209 3.2.1. Verifying SignedInfo Element Digest with Decrypted Digest from 210 SignatureValue element 212 1. VerifySignature(PublicKey, SignatureValueContent, SignInInfoDigest){ 213 2. DecryptedDigest=Decrypt SignatureValueContent with PublicKey 214 3. If(DecryptedDigest!=SignInInfoDigest){ 215 4. return False 216 5. } 217 6. else{ 218 7. return True 219 8. } 220 9. } 222 4. Simple Example 223 The Lets consider an XML document for the example 224 purpose: 226 227 228 229 1234 230 ABC 231 Kidney Test 232 233 234 1235 235 DEF 236 Liver Test 237 238 240 Figure 1 242 Existing XML Signature algorithm would produce a element 243 for the XML document mentioned in Figure 1, as follows: 245 246 247 249 250 251 252 253 254 255 256 ................. 257 258 259 260 261 262 263 264 ................ 265 266 267 268 .......... 269 270 271 272 273 ............................. 274 275 276 277 278 The proposed XML Signature algorithm would produce a 279 element for the XML document mentioned in Figure 1, which is 280 described in Figure 2. Also, during signing process, "Positional 281 Token" as an attribute e.g.(PosToken= "Absolute XPath") has been used 282 in it, as per proposed algorithm in Section 3.1. Now, 283 elements inside element will also contain the trace of 284 "Positional Token", hence the relative position of signed elements in 285 the given XML document: 287 288 289 291 292 293 294 295 296 297 298 ................. 299 300 301 302 303 304 305 306 ................ 307 308 309 310 ............ 311 312 313 314 315 ............................. 316 317 318 319 321 Figure 2 323 5. Algorithm Validation 325 In this section we will discuss as how the suggested algorithm can 326 mitigate the various scenarios of XML wrapping attacks. 328 5.1. Mitigation of XML Signature wrapping attacks 330 This kind of attacks are possible because signature verification 331 algorithm identifies signed element using identity i.e. ID and 332 identifying position of signed element using ID has inherent flaw as 333 the signed element can easily be moved within the document and still 334 the document retains the ability to verify its signature. So, in our 335 algorithm, we have suggested the usage of absolute XPath in place of 336 ID for identifying the position of signed elements. Absolute XPath 337 has two fold advantages as it can easily identify the position of 338 signed element within the XML document and it fixes both the vertical 339 and horizontal axes of the signed element exactly. The absolute 340 XPath expression to identify signed element will not be same as 341 absolute XPath expression for signed element in forged document.The 342 signature validation will fail at step-8, of algorithm in 343 Section 3.2, as there is no such node, Further, if the attacker 344 modifies the URI attribute and tries to perform XML wrapping attack, 345 the digest of will not match and signature validation 346 will fail at step-4 of algorithm in Section 3.2. 348 5.2. Mitigation of XML elements jumbling type of wrapping attacks 350 This kind of wrapping attacks are possible as the attacker jumbles 351 the position of signed elements within the document as XML signature 352 process defined by specification takes only ID into consideration for 353 referencing the signed elements. The proposed algorithm suggests 354 using "Absolute XPath" for referencing the signed elements as well as 355 doping the elements subjected to be signed with it. Hence, the 356 digest of the signed element inside node has a trail of 357 the position of element; refer step-6 of algorithm in Section 3.1. 358 Hence, any changes in the position of signed elements by the 359 attackers will invalidate the signature validation; refer step-12 of 360 algorithm in Section 3.2, because calculated digest during signature 361 validation will not match with the digest contained in 362 of the forged SOAP request. 364 6. Conclusion 366 XML Signature wrapping attacks try to inject forged elements into the 367 XML document structure in such a way that the valid signature covers 368 the unmodified elements, while forged elements are processed by the 369 application logic. This results in a scenario, where an attacker can 370 perform arbitrary web service requests, while authenticating as a 371 legitimate user. The proposed algorithm takes help of the absolute 372 XPath as a "Positional Token" for identifying the signed elements and 373 adding this to the elements to be signed as an attribute before the 374 canonicalization process has a trace of both content of signed 375 element and its position in the XML document as well. Hence, the 376 proposed algorithm can solve the issue of XML wrapping attacks 377 elegantly without much change in the current standard. 379 7. IANA Considerations 381 This memo includes no request to IANA. 383 8. Security Considerations 385 This draft proposes a modification to the existing algorithm of XML 386 signature to counter XML Signature wrapping attacks. However other 387 forms of attack may be possible that could not be mitigated. 389 9. References 391 9.1. Normative References 393 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 394 Requirement Levels", BCP 14, RFC 2119, 395 DOI 10.17487/RFC2119, March 1997, 396 . 398 [RFC2807] Reagle, J., "XML Signature Requirements", RFC 2807, 399 DOI 10.17487/RFC2807, July 2000, 400 . 402 [RFC3275] Eastlake 3rd, D., Reagle, J., and D. Solo, "(Extensible 403 Markup Language) XML-Signature Syntax and Processing", 404 RFC 3275, DOI 10.17487/RFC3275, March 2002, 405 . 407 9.2. Informative References 409 [I-D.narten-iana-considerations-rfc2434bis] 410 Narten, T. and H. Alvestrand, "Guidelines for Writing an 411 IANA Considerations Section in RFCs", draft-narten-iana- 412 considerations-rfc2434bis-09 (work in progress), March 413 2008. 415 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 416 DOI 10.17487/RFC2629, June 1999, 417 . 419 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 420 Text on Security Considerations", BCP 72, RFC 3552, 421 DOI 10.17487/RFC3552, July 2003, 422 . 424 [wrapping_attack] 425 McIntosh, Michael. and Paula. Austel, "XML signature 426 element wrapping attacks and countermeasures", 2005, 427 . 429 [WS-Security] 430 OASIS., "OASIS Web Services Security (WSS) TC", 2006, 431 . 434 Authors' Addresses 436 Jitendra Kumar 437 C-DAC Bangalore 438 #68, Electronics City Hosur Road 439 Bangalore 560100 440 India 442 Email: jitendra@cdac.in 444 Balaji Rajendran 445 C-DAC Bangalore 446 #68, Electronics City Hosur Road 447 Bangalore 560100 448 India 450 Email: balaji@cdac.in 452 Bindhumadhava BS 453 C-DAC Bangalore 454 Old Madras Road, Opposite Hal Aero Engine Division 455 Bangalore 560038 456 India 458 Email: bindhu@cdac.in