idnits 2.17.00 (12 Aug 2021) /tmp/idnits25435/draft-pashalidis-sip-saml-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 634. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 645. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 652. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 658. 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 is 1 instance of too long lines in the document, the longest one being 4 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 7, 2008) is 5065 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'SIDP URI' is mentioned on line 146, but not defined == Missing Reference: 'SP URI' is mentioned on line 152, but not defined == Missing Reference: 'SAMLART' is mentioned on line 388, but not defined ** Obsolete normative reference: RFC 2396 (Obsoleted by RFC 3986) Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Session Initiation Protocol A. Pashalidis 3 SIP Working Group J. Girao 4 Internet-Draft NEC Europe Ltd. 5 Intended status: Experimental July 7, 2008 6 Expires: January 8, 2009 8 SIP SAML Profile and Binding 9 draft-pashalidis-sip-saml-00 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on January 8, 2009. 36 Abstract 38 This document specifies the SIP/SAML profile and binding, i.e. a 39 protocol for the use of Security Assertion Markup Language (SAML) 40 assertions for the purposes of authentication and the exchange of 41 attributes in a Session Initiation Protocol (SIP) environment. 43 Table of Contents 45 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 46 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 47 3. SIP/SAML Direct Variant . . . . . . . . . . . . . . . . . . . 6 48 4. SIP-Artifact Variant . . . . . . . . . . . . . . . . . . . . . 9 49 5. Error handling . . . . . . . . . . . . . . . . . . . . . . . . 12 50 6. The SIP/SAML bindings . . . . . . . . . . . . . . . . . . . . 13 51 6.1. SIP/SAML message encoding . . . . . . . . . . . . . . . . 13 52 6.2. SIP/SAML artifact encoding . . . . . . . . . . . . . . . . 13 53 6.2.1. SIP/SAML URI artifact encoding . . . . . . . . . . . . 13 54 6.2.2. SIP/SAML Content artifact encoding . . . . . . . . . . 14 55 6.2.3. SIP/SAML artifact header . . . . . . . . . . . . . . . 14 56 6.3. The SAML-Endpoint Header . . . . . . . . . . . . . . . . . 14 57 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 58 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 59 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 60 10. Normative References . . . . . . . . . . . . . . . . . . . . . 19 61 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 62 Intellectual Property and Copyright Statements . . . . . . . . . . 21 64 1. Introduction 66 This document specifies the SIP/SAML profile and binding, i.e. a 67 protocol for the authentication of Session Initiation Protocol (SIP) 68 users by means of Security Assertions Markup Language (SAML) 69 assertions, and for the exchange of user attributes over the SIP 70 protocol. 72 SAML is a set of protocol specifications that provide, among other 73 things, seamless Single Sign-On (SSO) in a distributed environment 74 where a user wishes to log into multiple Service Providers (SPs). In 75 particular, once a user has authenticated himself towards a trusted 76 entity called the "Identity Provider" (IDP), the SAML protocols 77 enable the IDP and the SPs to exchange information about the user's 78 authentication status at the IDP in a secure manner and in a way that 79 takes into account the user's privacy. Moreover, the SAML protocols 80 enable the SPs and the IDP to exchange information about the user in 81 the form of attributes. This feature is useful in the context of 82 identity management systems that perform such attribute exchanges in 83 an automated way, while enabling the user to exercise control over 84 the dissemination of his personal information. 86 However, the SAML protocols are not self-contained in the sense that 87 they require a transport mechanism. In particular, SAML messages 88 need to be conveyed from one party to the other by some underlying 89 transport protocol. The encoding of SAML messages in such transport 90 protocols is called a SAML binding; multiple such bindings have been 91 specified in the past. Examples are the HTTP REDIRECT binding, the 92 HTTP POST binding, and the SOAP binding [SAMLBINDINGS]. 94 With each newly specified SAML profile and binding, the number and 95 the diversity of applications and services that can interoperate with 96 any given SAML-based IDP increases. This adds value to the overall 97 system, because it enables the user to log into a larger and more 98 diverse set of services in a seamless manner. Moreover, the number 99 of services that can query the user's attributes from the IDP 100 increases, resulting in a potentially more personalised experience 101 for the user. 103 This document specifies the SIP/SAML profile. This profile is used 104 in the case where the service provider is a SIP proxy. The main use 105 case for this profile is a user who would like to register at this a 106 SIP proxy by means of the SIP REGISTER method, and who would like to 107 be authenticated at the SIP proxy by means of a SAML Assertion that 108 is issued by his IDP. 110 The remainder of this document is structured as follows. 112 o Section 2 provides an overview of the terminology and the 113 abbreviations used in this document. 115 o Section 3 specifies the `Direct' variant of the SIP/SAML profile. 117 o Section 4 specifies the `Artifact' variant of the SIP/SAML 118 profile. 120 o Section 5 specifies how certain errors are handled in the SIP/SAML 121 profile. 123 o Section 6 specifies the SIP/SAML binding. 125 o Section 7 discusses important security aspects of the protocols. 127 2. Terminology 129 This document makes use of terms defined in [RFC3261] and [SAML]. In 130 addition, the keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, 131 SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear 132 in this document, are to be interpreted as described in [RFC2119]. 134 3. SIP/SAML Direct Variant 136 In this section, the Direct Variant of the SIP/SAML profile is 137 specified. In the following, UA denotes the user agent (client), SP 138 denotes a SIP Proxy, and IDP denotes a SAML-based Identity Provider. 139 This specification relies on a new SIP header, called the `SAML- 140 Endpoint (SAML-EP)' header. This header contains a URI endpoint 141 pointing to the user's SAML-based IDP. The format of the SAML-EP 142 header is specified in section Section 6.3 in detail. 144 1. UA -> SP : SIP REGISTER + SAML-EP header(s) 146 2. SP -> UA : SIP 302 REDIRECT [SIDP URI] + SAML request 148 3. UA -> IDP : SIP REGISTER + SAML request 150 4. UA <-> IDP: AUTHENTICATION 152 5. UA <- IDP : SIP 302 REDIRECT [SP URI] + SAML response 154 6. UA -> SP : SIP REGISTER + SAML response 156 Figure 1: The Direct Variant of the SIP/SAML Profile 158 Figure 1 shows the direct variant of the SAML/SIP profile in full 159 i.e. where the user authenticates himself at the IDP for the first 160 time. The figure shows individual steps that occur during the 161 protocol execution. With the exception of step 4, all the steps 162 uniquely correspond to a particular message that is exchanged in the 163 corresponding step. In the following, we say `message X' in order to 164 refer to the message that is exchanged in step X of the protocol. 166 First, the UA constructs a SIP REGISTER message and sends it to the 167 SP (message 1). This message MUST contain one or more SAML-EP 168 headers, where the value of each SAML-EP header MUST be one or more 169 URIs. All the indicated URIs MUST belong to some SAML-based IDP that 170 is able to consume SIP REGISTER messages conforming to the format of 171 message 3. The population of the SAML-EP header values is the 172 responsibility of the UA. If multiple SAML-EP header values are 173 present in message 1 (either in the same or in multiple SAML-EP 174 headers), then each URI within a SAML-EP header value MUST refer to a 175 different IDP. Also, each URI within a SAML-EP header value MUST 176 refer to an IDP where the user maintains an active account. However, 177 there is no requirement to include more than IDP URI, even if the 178 user maintains accounts at multiple IDPs. Moreover, the order of the 179 URIs within SAML-EP header values SHOULD reflect the user's 180 preferences, most preferred first. That is, if the user prefers to 181 be authenticated by IDP A in preference to IDP B, then the URI 182 referring to IDP A SHOULD be included in a SAML-EP header before the 183 URI referring to IDP B. 185 The following two possibilities exist when message 1 is received by 186 the SP. Case 1: the SP does not support the SIP/SAML profile 187 specified in this document. In this case, the SAML-EP header(s) are 188 ignored, and the SP responds 'normally', i.e. as in standard SIP. 189 The UA MUST be able to correctly handle a message conforming to 190 standard SIP (instead of message 2 in Figure 1) as a response to 191 message 1. Case 2: the SP supports the SIP/SAML profile. In this 192 case, it MUST examine the SAML-EP headers and check whether or not an 193 agreement exists with at least one of the indicated IDPs. If an 194 agreement exists with at least one of them, then it MUST pick one of 195 those with whom an agreement exists; the one it selects is denoted by 196 SIDP. The SP SHOULD select the IDP that corresponds to the first URI 197 within any SAML-EP header with whom an agreement exists. If no 198 agreement consists with any of the IDPs then the SP MUST act as if it 199 does not support the SIP/SAML profile specified in this document, 200 i.e. respond with a message conforming to 'standard' SIP. 202 After the SIDP has been selected, the SP MUST decide with which SAML/ 203 SIP profile it would like to proceed. This decision MAY be based on 204 a policy or similar criteria. If the 'SIP Artifact' profile profile 205 is selected, then the remainder of the processing and the protocol is 206 as described in section Section 4. Otherwise, i.e. if the 'direct' 207 profile is selected, then processing continues as follows. 209 Message 2 is constructed as follows. The SP constructs a SIP 302 210 REDIRECT message where the value of the 'Contact' header is equal to 211 the value of the SAML-EP header (from message 1) that corresponds to 212 the SIDP. This value is denoted by SIDP URI in Figure 1. Moreover, 213 message 2 MUST contain a SAML Request, which MUST be constructed 214 according to [SAML]. This SAML Request MUST be included into message 215 2 according to the SIP/SAML binding specified in Section 6.1. 217 Upon reception of message 2, the UA SHOULD check that the SIDP URI 218 indicated in the 'Connect' header is one of those proposed in message 219 1. If this is not the case, then the UA MAY abort the protocol 220 execution at this point. It also MAY inform the user about the 221 inconsistency, and it MAY ask for the user's permission on whether to 222 proceed with the given SIDP URI. It is RECOMMENDED that the UA does 223 not proceed with the protocol execution if the indicated SIDP URI is 224 not one of the ones proposed in message 1, unless the user explicitly 225 allows the protocol execution to continue. 227 After reception of message 2, the UA MUST decide how to proceed in 228 trying to obtain a SAML Response that matches the SP's SAML Request 229 in message 2. Multiple possibilities MAY exist for this, and this 230 specification does not impose the UA to use any particular method. 231 However, if the UA decides to continue with the `Direct Variant' of 232 the SIP/SAML profile, then it MUST proceed as follows. 234 It constructs message 3 as a new SIP REGISTER message, which is sent 235 to the SIDP URI. The message contains the SAML Request from message 236 2, which is included according to the SIP/SAML binding specified in 237 Section 6.1. Note that, since message 3 is sent to an IDP (which is 238 NOT a SIP Proxy), its purpose it not to register at a SIP Proxy; its 239 purpose is to trigger authentication at the IDP. 241 In step 4 of the protocol, IDP authenticates the user. This may 242 involve multiple messages between the UA and the IDP. This 243 specification does not impose any particular authentication 244 mechanism. However, in order to guarantee minimal interoperability, 245 the standard SIP user authentication mechanism (Digest 246 Authentication, see section 22 of [RFC3261]) MUST be implemented at 247 both the IDP and the UA. However, whether or not the IDP will choose 248 this method or some other method, is dependent on policy. 250 After the authentication of the user towards the IDP, the IDP 251 constructs message 5. This is a SIP 302 REDIRECT message where the 252 'Contact' header MUST contain a value that is extracted from the SAML 253 request in 3, according to [SAML]. According to [SAML], the SAML 254 Response contains the description of an authentication context if the 255 user's authentication in step 4 has been successful. If this is the 256 case, the authentication context in the SAML Response MUST describe 257 the user's authentication context that resulted from the 258 authentication in step 4. The SAML Response is included in message 5 259 according to the SIP/SAML binding, as specified in Section 6.1. 261 Finally, the UA constructs a new SIP REGISTER message and sends this 262 to the SP in step 6. This SIP REGISTER message MUST contain the SAML 263 Response from message 5, according to the SIP/SAML binding specified 264 in Section 6.1. Upon reception of that message, the SP MUST examine 265 the SAML Response according to [SAML]. If the SP is satisfied, the 266 user is recorded as 'registered' in the SIP Proxy, and the remaining 267 processing continues according to standard SIP [RFC3261]. 269 4. SIP-Artifact Variant 271 This section specifies the SIP-Artifact Variant of the SIP/SAML 272 Profile. The main difference between the SIP-Artifact Variant and 273 the Direct Variant is that, in the SIP-Artifact Profile, the UA 274 cannot see the SAML messages that are exchanged between the SP and 275 the IDP. Instead, the SP and the IDP exchange SAML messages 276 directly. Special identifiers that identify individual SAML 277 messages, called `SAML Artifacts' are tunneled through the UA. 279 1. UA -> SP : SIP REGISTER + a SAML-EP header(s) 281 2. SP -> UA : SIP 302 REDIRECT [SIDP URI + Artifact] + SAML-EP header 283 3. UA -> IDP : SIP REGISTER + Artifact + SAML-EP header 285 4. IDP <-> SP: Artifact Resolution 287 5. UA <-> IDP: AUTHENTICATION 289 6. UA <- IDP : SIP 302 REDIRECT [SP URI + Artifact] + SAML-EP header 291 7. UA -> SP : SIP REGISTER + Artifact + SAML-EP header 293 8. SP <-> IDP: Artifact Resolution 295 Figure 2: The SIP-Artifact Variant of the SIP/SAML Profile 297 Figure 2 shows the SIP-Artifact variant of the SAML/SIP profile in 298 full i.e. where the user authenticates himself at the IDP for the 299 first time. The figure shows individual steps that occur during the 300 protocol execution. With the exception of steps 4, 5, and 8 all the 301 steps uniquely correspond to a particular message that is exchanged 302 in the corresponding step. In the following, we say `message X' in 303 order to refer to the message that is exchanged in step X of the 304 protocol. 306 First, the UA constructs a SIP REGISTER message and sends it to the 307 SP (message 1). This message is constructed in a manner identical to 308 the construction of the first message in the `direct' variant, as 309 specified in the section above. The behaviour of the SP after having 310 received message 1 is identical to the behaviour specified for the 311 `direct' variant in the section above, up to the point where the SP 312 decides which variant to use. If the SP decides to use the 313 `Artifact' variant, the processing is as follows. 315 The SP MUST construct a SAML Artifact pointing to a SAML Request 316 message for consumption by the SIDP, according to [SAML]. Message 2 317 is then constructed as a SIP 302 REDIRECT message, where the 318 `Contact' header MUST take as value the URI indicated by the SAML- 319 Endpoint header (from message 1) that corresponds to the SIDP, 320 modified as follows. The SAML Artifact MUST be encoded into the URI, 321 according to the binding specified in Section 6.2. 323 Moreover, message 2 MUST contain exactly one SAML-EP header, where 324 the value is the URI at which the SP will accept a SAML Artifact 325 Resolution request from the SIDP. 327 Upon reception of message 2, the UA SHOULD check that the SIDP URI 328 indicated in the 'Connect' header is one of those proposed in message 329 1. If this is not the case, then the UA MAY abort the protocol 330 execution at this point. It also MAY inform the user about the 331 inconsistency, and it MAY ask for the user's permission on whether to 332 proceed with the given SIDP URI. It is RECOMMENDED that the UA does 333 not proceed with the protocol execution if the indicated SIDP URI is 334 does not correspond to any of those that were proposed in message 1, 335 unless the user explicitly allows the protocol execution to continue. 337 The UA constructs message 3 as a new SIP REGISTER message, which is 338 sent to the SIDP URI. Message 3 MUST contain a single SAML-EP 339 header, with a value identical to the value of the SAML-EP header 340 from message 2. Since message 3 is sent to an IDP (which is NOT a 341 SIP Proxy), its purpose it not to register at a SIP Proxy; its 342 purpose is to trigger authentication at the IDP. 344 In step 4 of the protocol, the IDP resolves the SAML Artifact found 345 in the query string of the URI from message 3, into a SAML Request 346 message. This is done by means of the Artifact Resolution protocol 347 specified in [SAMLART]. The SAML binding the is used for this 348 exchange MUST be the the SIP/SAML binding specified in section 349 Section 6. Moreover, the SAML Endpoint that the IDP uses for 350 initiating the exchange is the one indicated in the SAML-EP header in 351 message 3. 353 If the SAML Artifact has sucessfully been resolved into a SAML 354 Request message, in step 5 of the protocol the IDP authenticates the 355 user. This corresponds to step 4 in the 'direct' variant specified 356 in the previous section, and the requirements concerning this steps 357 are identical to the requirements in the 'direct' variant. 359 After the authentication of the user towards the IDP, the IDP MUST 360 construct a SAML Artifact pointing to a SAML Response message for 361 consumption by the SP, according to [SAML]. Message 6 is then 362 constructed as a SIP 302 REDIRECT message, where the `Contact' header 363 MUST take the value of an specific URI that is extracted from the 364 SAML request in 3, according to [SAML], modified as follows. The 365 SAML Artifact MUST be encoded into the URI, according to the binding 366 specified in Section 6.2. 368 The SAML Response to which the SAML Artifact points, MUST contain the 369 description of an authentication context if the user's authentication 370 in step 5 has been successful. If this is the case, the 371 authentication context in the SAML Response MUST describe the user's 372 authentication context that resulted from the authentication in step 373 5. 375 Moreover, message 6 MUST contain exactly one SAML-Endpoint header, 376 where the value is the URI at which the IDP will accept a SAML 377 Artifact Resolution request from the SP. 379 Upon reception of message 6, the UA constructs message 7 as a new SIP 380 REGISTER message. Message 7 MUST contain exactly one SAML-Endpoint 381 header, where the value is identical to the value of the SAML- 382 Endpoint header from message 6. Message 7 is then sent to the URI 383 indicated in the 'Contact' header of message 6. 385 In step 8 of the protocol, the IDP resolves the SAML Artifact found 386 in the query string of the URI from message 7, into a SAML Response 387 message. This is done by means of the Artifact Resolution protocol 388 specified in [SAMLART]. The SAML binding the is used for this 389 exchange MUST be the the SIP/SAML binding specified in section 390 Section 6. Moreover, the SAML Endpoint that the SP uses for 391 initiating the exchange is the one indicated in the SAML-Endpoint 392 header of message 7. 394 5. Error handling 396 This section specifies how certain errors are handled within SIP/SAML 397 Profile. 399 TBD. 401 6. The SIP/SAML bindings 403 This section specifies the SIP transport for SAML messages and SAML 404 Artifacts. 406 6.1. SIP/SAML message encoding 408 A SIP message that carries a SAML message MUST include the SAML 409 message as the SIP message body. A 'Content-Type' header MUST be 410 included in the SIP message, with a value of 'text/xml'. The message 411 body MUST consist solely of the SAML message which MUST be 412 constructed according to [SAML]. The SIP message MUST otherwise 413 conform to the format of a standard SIP message. This includes 414 respecting the rules regarding the character encoding and the 415 presence of a 'Content-Length' header - see [RFC3261] 417 6.2. SIP/SAML artifact encoding 419 There are three mechanisms to embed the SAML artifact into the 420 message: in the SIP URI, a SIP header or in the body of the SIP 421 message. While the advantage of the first lies in freeing the body 422 of the SIP message to carry other information, the other two conform 423 better to existing SIP specifications. This specification mandates 424 that, should the SIP/SAML artifact binding be supported, then 425 Section 6.2.3 MUST be supported, while Section 6.2.1 and 426 Section 6.2.2 are optional. 428 6.2.1. SIP/SAML URI artifact encoding 430 A SAML Artifact is encoded into a URI that occurs in a SIP message. 431 A URI into which a SAML Artifact is encoded is said to 'carry' the 432 SAML Artifact. Multiple URIs in the same SIP message MAY carry a 433 SAML Artifact. However, each URI MUST carry at most one SAML 434 Artifact. Whether or not a SAML Artifact is carried by a URI 435 occurring in a SIP message, is specified in the SIP/SAML profiles. 437 A SAML Artifact is encoded into a URI as follows. If the URI does 438 not have a query string component, then the URI MUST be appended with 439 a query component containing the parameter 'SAMLart' with the value 440 being the SAML Artifact in question. If the URI already contains a 441 query string component with other parameters, then the other 442 parameters MUST remain intact. If the URI already contains a query 443 string parameter with the name "SAMLart", where the matching 444 algorithm MUST be case-insensitive, then this parameter MUST be 445 replaced. 447 6.2.2. SIP/SAML Content artifact encoding 449 A SAML Artifact is encoded into the body of a SIP message as follows. 450 A 'Content-Type' header MUST be included in the SIP message with the 451 value 'text/xml'. The message body MUST contain only the artifact in 452 XML format, which is detailed below. Otherwise, the message should 453 abide to the format of a standard SIP message. 455 The XML message will belong to the namespace described in [SAML] and 456 MUST contain only one element of type 457 'urn:oasis:names:tc:SAML:2.0:protocol:Artifact' with the name 458 'SAMLart'. This element MUST contain the artifact value. 460 6.2.3. SIP/SAML artifact header 462 This section specifies the format of the SAML Artifact Header. The 463 SAML Artifact header follows the header and grammar rules as 464 specified in section 7.1 of [RFC3261]. 466 header = "SAMLart" HCOLON SAMLart-value 468 Figure 3: The SAML-Endpoint Header Format 470 The SAMLart-value MUST be a valid base-64 encoded string. 472 6.3. The SAML-Endpoint Header 474 This section specifies the format of the SAML-Endpoint Header. The 475 SAML-Endpoint header follows the header and grammar rules as they are 476 specified in section 7.1 of [RFC3261]. 478 header = "SAML-Endpoint" HCOLON header-value *(COMMA URI-value) 480 Figure 4: The SAML-Endpoint Header Format 482 The URI-value MUST be a valid URI as specified in [RFC2396]. 484 7. Security Considerations 486 This specification introduces SAML-based user authentication in the 487 context of the SIP REGISTER method. As such, the privacy and 488 security considerations described in [SAMLSEC] apply to this 489 specification. The remainder of this section discusses requirements 490 that are specific to this document. 492 It is important to keep in mind that a SAML Assertion (which is part 493 of the SAML Response from the IDP) is sensitive information that must 494 be kept secret. Similarly, the SAML Artifact, which is part of the 495 IDP's response in the Artifact variant, is also sensitive 496 information. This is because knowledge of the assertion, in 497 particular the IDP's signature which is part of it, or knowledge of 498 the artifact, enables one to login (i.e. register) in the name of the 499 subject for which the assertion or artifact was generated. 501 The SAML assertion / artifact MUST therefore be conveyed from the IDP 502 to the SP in a way that preserves its confidentiality and its 503 integrity. The only exception to this rule is the case where the 504 authentication mechanism with which the user is authenticated at the 505 IDP involves the user's password being transmitted over the network 506 in the clear. In this case, the confidentiality and the integrity of 507 the SAML assertion / artifact SHOULD be protected along its way from 508 the IDP to the SP. The use of a user authentication mechanism which 509 involves the transmission of the user's password in the clear is NOT 510 RECOMMENDED. 512 In the "Direct" variant, protecting the SAML Assertion's 513 confidentiality and integrity requires protection both during the 514 transmission of the assertion from the IDP to the UA, and its 515 transmission from the UA of the SP. The protection mechanism that is 516 used MUST provide confidentiality and integrity protection against 517 active attackers. It is RECOMMENDED that a TLS channel with server- 518 side certificates is used both for the transmission of the assertion 519 from the IDP to the UA, and from the UA to the SP. 521 If a TLS channel is used for the transmission on the path IDP->UA, 522 then the IDP MUST NOT propose or select a TLS ciphersuite with an 523 effective key strength which is lower than the effective key strength 524 of its signature over the SAML Assertion. The IDP MUST use 525 independently generated keys for TLS and for signing SAML Assertions. 527 If a TLS channel is used for the transmission on the path US->SP, 528 then the UA MUST NOT propose or select a TLS ciphersuite with an 529 effective key strength which is lower than the effective key strength 530 of the signature over the SAML Assertion. 532 In the "Artifact" variant, too, the use of TLS with server-side 533 certificates is RECOMMENDED. The same considerations and 534 requirements as above apply. Moreover, the communication between the 535 IDP and the SP for the purposes of SAML Artifact Resolution MUST be 536 authenticated, and the integrity and the confidentiality of this 537 communication MUST be protected. The following alternatives for the 538 protection of the direct communication between IDP and the SP are 539 RECOMMENDED. Note that all these alternatives result in a 'secure 540 channel' between the IDP and the SP. 542 o A long-lived TLS connection that is authenticated based on server- 543 side and client-side certificates. 545 o A long-lived IPsec connection where both parties are authenticated 546 based on a certificate. 548 The session key of secure channel MUST be at least as strong as the 549 key used by the IDP to sign SAML Assertions. It is the 550 responsibility of the IDP to reject incomong connection attempts from 551 SPs that do not provide for the minimum required protection level. 553 [RFC3766] SHOULD be used in order to compare the effective key 554 strengths. 556 8. IANA Considerations 558 TBD. (None?) 560 9. Acknowledgements 562 TBD. 564 10. Normative References 566 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 567 Requirement Levels", RFC 2119, March 1997. 569 [RFC2396] Berners-Lee, T., Fielding, R., and L. Masinter, "RFC 2396: 570 Uniform Resource Identifiers (URI): Generic Syntax", 571 RFC 2396, August 1998. 573 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 574 A., Peterson, J., Sparks, R., Handley, M., and E. 575 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 576 June 2002. 578 [RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For 579 Public Keys Used For Exchanging Symmetric Keys", RFC 3766, 580 April 2004. 582 [SAML] Cantor, S., Kemp, J., Philpott, R., and E. Maler, 583 "Assertions and Protocols for the OASIS Security Assertion 584 Markup Language (SAML) V2.0", March 2005. 586 [SAMLBINDINGS] 587 Cantor, S., Hirsch, F., Kemp, J., Philpott, R., and E. 588 Maler, "Bindings for the OASIS Security Assertion Markup 589 Language (SAML) V2.0", March 2005. 591 [SAMLSEC] Hirsch, F., Philpott, R., and E. Maler, "Security and 592 Privacy Considerations for the OASIS Security Assertion 593 Markup Language (SAML) V2.0", March 2005. 595 [utf8] Yergeau, F., "UTF-8, a transformation format of ISO 596 10646", RFC 3629. 598 Authors' Addresses 600 Andreas Pashalidis 601 NEC Europe Ltd. 602 Kurfuersten Anlage 36 603 Heidelberg D-69115 604 Germany 606 Phone: +49 (0)6221 4342 205 607 Fax: +49 (0)6221 4342 155 608 Email: andreas.pashaldis@nw.neclab.eu 610 Joao Girao 611 NEC Europe Ltd. 612 Kurfuersten Anlage 36 613 Heidelberg D-69115 614 Germany 616 Phone: +49 (0)6221 4342 117 617 Fax: +49 (0)6221 4342 155 618 Email: joao.girao@nw.neclab.eu 620 Full Copyright Statement 622 Copyright (C) The IETF Trust (2008). 624 This document is subject to the rights, licenses and restrictions 625 contained in BCP 78, and except as set forth therein, the authors 626 retain all their rights. 628 This document and the information contained herein are provided on an 629 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 630 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 631 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 632 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 633 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 634 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 636 Intellectual Property 638 The IETF takes no position regarding the validity or scope of any 639 Intellectual Property Rights or other rights that might be claimed to 640 pertain to the implementation or use of the technology described in 641 this document or the extent to which any license under such rights 642 might or might not be available; nor does it represent that it has 643 made any independent effort to identify any such rights. Information 644 on the procedures with respect to rights in RFC documents can be 645 found in BCP 78 and BCP 79. 647 Copies of IPR disclosures made to the IETF Secretariat and any 648 assurances of licenses to be made available, or the result of an 649 attempt made to obtain a general license or permission for the use of 650 such proprietary rights by implementers or users of this 651 specification can be obtained from the IETF on-line IPR repository at 652 http://www.ietf.org/ipr. 654 The IETF invites any interested party to bring to its attention any 655 copyrights, patents or patent applications, or other proprietary 656 rights that may cover technology that may be required to implement 657 this standard. Please address the information to the IETF at 658 ietf-ipr@ietf.org.