1 2 3 4 5 6 7 SAML & XML-Signature Syntax and Processing This version: File : draft-sstc-dsig-02.doc Date : October 24, 2001 8 9 10 Authors o Krishna Sankar [ksankar@cisco.com] o 11 12 13 14 15 16 Contributors o Scott Cantor [cantor.2@osu.edu] o Prateek Mishra [pmishra@netegrity.com] o Stephen Farrell [stephen.farrell@baltimore.ie] o Philip Hallam-Baker [pbaker@verisign.com] 17 18 19 20 21 22 Abstract XML Signature is used in SAML for assertion integrity, assertion authentication and signer authentication as defined in [SIG]. The XML Signature specification [SIG] defines how this can be achieved and provides many options. This document details the use of XML Signature for SAML assertions and protocols. 23 24 25 26 27 Referenced Documents [SIG] XML-Signature Syntax and Processing, W3C Proposed Recommendation. http://www.w3.org/tr/2001/pr-xmldsig-core-20010820/ [RFC3126] RFC 3126 : Electronic Signature Formats for long term electronic signatures draft-sstc-dsig-02.doc 10/24/01 1
28 29 [RFC3125] RFC 3125 : Electronic Signature Policies 30 31 32 33 34 Notational Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in Key Words for Use in RFC s to Indicate Requirement Levels (RFC 2119). 35 36 37 Status of this Document This document represents work in progress upon which no reliance should be made. 38 39 40 41 Document Version History o Version 0.001: o Version 0.002: 42 43 44 45 46 Related Files The web site http://www.oasis-open/committees/security/xxxxx contains the current version of all the related files. draft-sstc-dsig-02.doc 10/24/2001 2
46 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 Table of Contents 1 Role of Digital Signatures in SAML...4 2 Signing Assertions...5 3 Request/Response Signing...5 4 Signature Inheritance (a.k.a. super-signatures & sub-messages)...6 4.1 Context...6 4.2 Proposal...6 5 XML Signature Profile...6 5.1 Signing formats...7 5.2 CanonicalizationMethod...7 5.3 Transforms...7 5.4 KeyInfo...7 5.5 Object...Error! Bookmark not defined. 5.6 Binding between statements in a multi-statement assertion...7 5.6.1 MultipleAssertionType...7 5.6.2 Multiple Assertions in a ResponseType...8 5.7 Security considerations...8 5.7.1 Replay Attack...8 6 Issues, To Do...9 65 66 67 draft-sstc-dsig-02.doc 10/24/2001 3
67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 1 Role of Digital Signatures in SAML SAML Assertions, Request and Response messages may be signed, with the following benefits: An Assertion signed by the issuer (AP). This supports : (1) Message integrity (2) Authentication of the issuer to a relying party (3) If the signature is based on the issuer's public-private key pair, then it also provides for non-repudiation of origin. A SAML request or a SAML response message signed by the message originator. This supports : (1) Message integrity (2) Authentication of message origin to a destination (3) If the signature is based on the originator's public-private key pair, then it also provides for non-repudiation of origin. Note : SAML documents may be the subject of signatures from in many different packaging contexts. [SIG] provides a framework for signing in XML and is the framework of choice. However, signing may also take place in the context of S/MIME or Java objects that contain SAML documents. One goal is to ensure compatibility with this type of "foreign" digital signing. It is useful to characterize situations when a digital signature is NOT required in SAML. (1) Assertions: asserting party has provided the assertion to the relying party and authenticated by means other than digital signature. In other words, the RP has obtained the assertion from the AP directly (no intermediaries) and the AP has authenticated to the RP. (2) Request/Response messages: the originator has authenticated to the destination and the destination has obtained the assertion directly from the originator (no intermediaries). Many different techniques are available for "direct" authentication between two parties. The list includes SSL, HMAC, password-based login etc. [QUESTION: Do we need to constrain this list further?] All other contexts require the use of digital signature for assertions and request and response messages. Specifically: (1) An assertion obtained by a relying party from an entity other than the asserting party MUST be signed by the issuer. draft-sstc-dsig-02.doc 10/24/2001 4
116 117 118 119 120 121 122 123 124 (2) SAML message obtained arriving at a destination from an entity other than the originating site MUST be signed by the origin site. 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 2 Signing Assertions All SAML assertions MAY be signed using the XML Signature. This is reflected in the schema : <element name = "Assertion" type = "saml:assertionabstracttype"/> <complextype name = "AssertionAbstractType" abstract = "true"> <sequence> <element ref = "saml:conditions" minoccurs = "0"/> <element ref = "saml:advice" minoccurs = "0"/> <element ref = ds:signature minoccurs= 0 maxoccurs= 1 /> </sequence> <attribute name = "MajorVersion" use = "required" type = "integer"/> <attribute name = "MinorVersion" use = "required" type = "integer"/> <attribute name = "AssertionID" use = "required" type = "saml:idtype"/> <attribute name = "Issuer" use = "required" type = "string"/> <attribute name = "IssueInstant" use = "required" type = "timeinstant"/> </complextype> 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 3 Request/Response Signing All SAML requests and responses MAY be signed using the XML Signature. This is reflected in the schema : <complextype name="requestabstracttype" abstract="true"> <attribute name="requestid" type="saml:idtype" use="required"/> <attribute name="majorversion" type="integer" use="required"/> <attribute name="minorversion" type="integer" use="required"/> <element ref = ds:signature minoccurs= 0 maxoccurs= 1 /> </complextype> <complextype name="responseabstracttype" abstract="true"> <attribute name="responseid" type="saml:idtype" use="required"/> <attribute name="inresponseto" type="saml:idtype" use="required"/> <attribute name="majorversion" type="integer" use="required"/> draft-sstc-dsig-02.doc 10/24/2001 5
157 158 159 160 <attribute name="minorversion" type="integer" use="required"/> <element ref = ds:signature minoccurs= 0 maxoccurs= 1 /> </complextype> 161 162 4 Signature Inheritance (a.k.a. super-signatures & sub-messages) 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 4.1 Context SAML assertions may be embedded within request or response messages or other XML messages, which may be signed. Request or response messages may themselves be contained within other messages that are based on other XML messaging frameworks (e.g., SOAP) and the composite object may be the subject of a signature. Another possibility is that SAML assertions or request/response messages are embedded within a non-xml messaging object (e.g., MIME package) and signed. In such a case, the SAML sub-message (Assertion, request, response) may be viewed as inheriting a signature from the "super-signature" over the enclosing object, provided certain constraints are met. (1) An assertion may be viewed as inheriting a signature from a super signature, if the super signature applies all of the mandatory elements within the assertion. (2) A SAML request or response may be viewed as inheriting a signature from a super signature, if the super signature applies to all of the mandatory elements within the response. 185 186 187 188 189 190 191 4.2 Proposal Signatures MAY inherited in the SAML domain. i.e. if a SAML request/response has a signature, then if any of the assertions in the res/resp packages are not signed, they inherit the super-signature. But if assertions need to be passed around by themselves, or embedded in other message they would need to be signed as per section 2.1 192 193 194 195 196 197 5 XML Signature Profile The [SIG] specification calls out a general XML syntax for signing data with many flexibilities and choices. This section details the constraints on these facilities so that SAML processors do not have to deal with the full generality of [SIG] processing. draft-sstc-dsig-02.doc 10/24/2001 6
198 199 200 201 202 203 204 205 5.1 Signing formats XML Signature has three ways of representing signature in a document viz: enveloping, enveloped and detached. SAML assertions and protocols would use the enveloped signatures for signing assertions. 206 207 5.2 CanonicalizationMethod 208 209 210 211 [Sig] REQUIRES the Canonical XML (omits comments) (http://www.w3.org/tr/2001/rec-xml-c14n-20010315). SAML RECOMMENDS the Canonical XML with Comments (http://www.w3.org/tr/2001/rec-xml-c14n- 20010315#WithComments) 212 213 5.3 Transforms 214 215 216 [Sig] REQUIRES the enveloped signature transform http://www.w3.org/2000/09/xmldsig#enveloped-signature 217 218 219 220 221 5.4 KeyInfo Any valid key which is acceptable by the [SIG] is acceptable to SAML as well. SAML does not restrict or impose any additions in this area. Which means it is possible NOT to have the KeyInfo element and then arrive at the keyinfo by context. 222 223 5.5 Object The Object element SHOULD NOT be present in the signature block 224 5.6 Binding between statements in a multi-statement assertion 225 226 227 5.6.1 MultipleAssertionType This structure packs multiple related statements as one assertion. The relationships between these assertions are implied. draft-sstc-dsig-02.doc 10/24/2001 7
228 229 230 231 232 233 5.6.2 Multiple Assertions in a ResponseType This structure packs multiple assertions in a response message. The relationship between the assertions in this case is arbitrary i.e. no inter-assertion relationship should be assumed just because all the assertions were packaged in the sane response message 234 5.7 Security considerations 235 236 237 238 239 5.7.1 Replay Attack The mechanisms stated here-in does not offer any counter measures against a replay attack. Other mechanisms like sequence numbers, time stamps, expiration et al need to be explored to prevent a replay attack. 240 241 draft-sstc-dsig-02.doc 10/24/2001 8
241 242 243 244 6 Issues, To Do Issue Binding between different SAML fragments Replay Attack? Granularity Multiple signers Signing multiple assertions Detached signature as attribute assertions to tie payload? Or a new assertion payload assertion? Trust assertion due to bearer or the stated issuer? [Kelvin Beeck] Encryption? Counter Signature Multiple Signature Manifest Bearer Assertion N/A Status Added security considerations Para Use MultipleAssertionType for related statements or have multiple assertions in response for unrelated assertions?? Stated issuer draft-sstc-dsig-02.doc 10/24/2001 9