idnits 2.17.1 draft-ietf-abfab-aaa-saml-04.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 18, 2012) is 4207 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-12) exists of draft-ietf-radext-radsec-09 == Outdated reference: A later version (-06) exists of draft-perez-radext-radius-fragmentation-01 -- Obsolete informational reference (is this intentional?): RFC 3588 (Obsoleted by RFC 6733) -- Obsolete informational reference (is this intentional?): RFC 4282 (Obsoleted by RFC 7542) == Outdated reference: A later version (-01) exists of draft-jones-diameter-abfab-00 == Outdated reference: A later version (-13) exists of draft-ietf-abfab-arch-03 Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ABFAB J. Howlett 3 Internet-Draft Janet 4 Intended status: Informational S. Hartman 5 Expires: April 21, 2013 Painless Security 6 October 18, 2012 8 A RADIUS Attribute, Binding and Profiles for SAML 9 draft-ietf-abfab-aaa-saml-04 11 Abstract 13 This document specifies a RADIUS attribute, a binding and two 14 profiles for the Security Assertion Mark-up Language (SAML). The 15 attribute provides RADIUS encapsulation of SAML protocol messages, 16 and the binding describes the use of this attribute, and the SAML 17 protocol messages within, with RADIUS transport. The two profiles 18 describe the application of this binding for ABFAB authentication and 19 assertion query/request respectively. The SAML RADIUS attribute and 20 binding are defined generically to permit application in other 21 scenarios, such as network access. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on April 21, 2013. 40 Copyright Notice 42 Copyright (c) 2012 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. TODO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 3. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 4. RADIUS SAML-Message Attribute . . . . . . . . . . . . . . . . 5 61 5. SAML RADIUS Binding . . . . . . . . . . . . . . . . . . . . . 6 62 5.1. Required Information . . . . . . . . . . . . . . . . . . . 6 63 5.2. Operation . . . . . . . . . . . . . . . . . . . . . . . . 6 64 5.2.1. Use of XML Signatures . . . . . . . . . . . . . . . . 7 65 5.2.2. Metadata Considerations . . . . . . . . . . . . . . . 8 66 6. ABFAB Authentication Profile . . . . . . . . . . . . . . . . . 8 67 6.1. Required Information . . . . . . . . . . . . . . . . . . . 8 68 6.2. Profile Overview . . . . . . . . . . . . . . . . . . . . . 8 69 6.3. Profile Description . . . . . . . . . . . . . . . . . . . 10 70 6.3.1. User Agent Request to Relying Party . . . . . . . . . 10 71 6.3.2. Relying Party Issues to 72 Identity Provider . . . . . . . . . . . . . . . . . . 10 73 6.3.3. Identity Provider Identifies Principal . . . . . . . . 11 74 6.3.4. Identity Provider Issues to 75 Relying Party . . . . . . . . . . . . . . . . . . . . 11 76 6.3.5. Relying Party Grants or Denies Access to Principal . . 11 77 6.4. Use of Authentication Request Protocol . . . . . . . . . . 11 78 6.4.1. Usage . . . . . . . . . . . . . . 12 79 6.4.2. Usage . . . . . . . . . . . . 12 80 6.4.3. samlp:Response Message Processing Rules . . . . . . . 13 81 6.4.4. Unsolicited Responses . . . . . . . . . . . . . . . . 13 82 6.4.5. Use of the SAML RADIUS Binding . . . . . . . . . . . . 13 83 6.4.6. Use of XML Signatures . . . . . . . . . . . . . . . . 13 84 6.4.7. Metadata Considerations . . . . . . . . . . . . . . . 14 85 7. ABFAB Assertion Query/Request Profile . . . . . . . . . . . . 14 86 7.1. Required Information . . . . . . . . . . . . . . . . . . . 14 87 7.2. Profile Overview . . . . . . . . . . . . . . . . . . . . . 14 88 7.3. Profile Description . . . . . . . . . . . . . . . . . . . 15 89 7.3.1. Differences from the SAML V2.0 Assertion 90 Query/Request Profile . . . . . . . . . . . . . . . . 15 91 7.3.2. Use of the SAML RADIUS Binding . . . . . . . . . . . . 15 92 7.3.3. Use of XML Signatures . . . . . . . . . . . . . . . . 16 93 7.3.4. Metadata Considerations . . . . . . . . . . . . . . . 16 94 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 95 9. Security Considerations . . . . . . . . . . . . . . . . . . . 16 96 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 97 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 98 11.1. Normative References . . . . . . . . . . . . . . . . . . . 16 99 11.2. Informative References . . . . . . . . . . . . . . . . . . 17 101 1. TODO 103 o Clean up use of terminology (e.g., "principal") to ensure 104 consistency with other ABFAB docs. 106 o Understand Alan DeK's preferences with respect to choreography of 107 SAML messages and the RADIUS exchange(s). 109 o Request a new RADIUS attribute 111 o Check that binding/profiles identification URNs are reasonable 113 2. Introduction 115 The SAML RADIUS attribute, binding and profiles are motivated by the 116 requirements of the ABFAB architecture [I-D.ietf-abfab-arch]. In 117 this architecture, it is often desirable to convey Security Assertion 118 Mark-up Language (SAML) protocol messages between a SAML requester 119 and SAML responder. This can be used, for example, to allow a 120 Relying Party to request a SAML assertion from an Identity Provider 121 that describes a particular principal. This attribute and binding 122 are also likely to be useful for other purposes besides ABFAB; for 123 example, SAML-based authorization for network access. The attribute 124 and binding are therefore defined generically to facilitate general 125 applicability. 127 SAML defines a number of SAML protocol messages 128 [OASIS.saml-core-2.0-os], derived from common request and response 129 abstract types. These request and response protocol messages can be 130 exchanged using different modes of transport, such as HTTP; in the 131 SAML architecture, these are known as 'bindings'. SAML already 132 defines a number of HTTP-based bindings [OASIS.saml-bindings-2.0-os]; 133 and these are primarily intended for use with the SAML V2.0 Web 134 Browser Single Sign-On Profile [OASIS.saml-profiles-2.0-os] which 135 describes how the SAML protocol messages and HTTP-based bindings can 136 be used to effect Web-based Single Sign-On (SSO) by federating an 137 identity between an Identity Provider and a Service Provider 139 However the goal of ABFAB is to extend the applicability of federated 140 identity beyond the Web to other applications by building on the AAA 141 framework. Consequently there exists a requirement for an AAA-based 142 binding that is functionally equivalent to the existing bindings but 143 using AAA protocols, such as [RFC2865] and Diameter [RFC3588], rather 144 than HTTP. This document therefore defines a new RADIUS-based SAML 145 binding, building on a SAML RADIUS attribute also defined by this 146 document, to meet this need. 148 In addition to this attribute and binding, this document also 149 profiles their application in the context of two specific use cases: 150 authentication and assertion query/request. This is intended to 151 promote interoperability between implementations for these common use 152 cases. 154 A companion specification [I-D.jones-diameter-abfab] specifies 155 equivalent funtionality for Diameter. 157 In summary this document specifies: 159 o A SAML RADIUS attribute that defines how to encapsulate a SAML 160 protocol message within a RADIUS attribute. 162 o A SAML RADIUS binding that defines how SAML requesters and 163 responders can exchange SAML protocol messages. 165 o An Authentication Profile that defines how the SAML RADIUS binding 166 is used to effect SAML-based authentication and authorization. 168 o An Assertion Query/Request Profile that defines how the SAML 169 RADIUS binding is used to effect SAML-based assertion request. 171 The RADIUS SAML binding and profile specifications aspire to adhere 172 to the guidelines stipulated by [OASIS.saml-bindings-2.0-os] and 173 [OASIS.saml-profiles-2.0-os] for defining new SAML bindings and 174 profiles respectively. These new bindings and profiles are asked to 175 provide a 'Required Information' section that enumerates: 177 o A URI that uniquely identifies the protocol binding or profile 179 o Postal or electronic contact information for the author 181 o A reference to previously defined bindings or profiles that the 182 new binding updates or obsoletes 184 o In the case of a profile, any SAML confirmation method identifiers 185 defined and/or utilized by the profile 187 3. Conventions 189 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 190 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 191 document are to be interpreted as described in RFC 2119 [RFC2119]. 193 4. RADIUS SAML-Message Attribute 195 This attribute contains a SAML [OASIS.saml-core-2.0-os] protocol 196 message. Where multiple SAML-Message attributes are included in a 197 RADIUS message, the Message fields of these attributes are to be 198 concatenated to form a single SAML message. 200 A summary of the SAML-Message format is shown below. The fields are 201 transmitted from left to right. 203 0 1 2 3 204 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 206 | Type | Length | SAML Message... 207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 Figure 1 211 Type: TBD 213 Length: >=3 215 Message: The Message field is one or more octets containing a SAML 216 message. If larger than a single attribute, the SAML message data 217 MUST be split on 253-octet boundaries over as many attributes as 218 necessary. The SAML message is reconstructed by concatenating the 219 contents of all SAML-Message attributes. 221 5. SAML RADIUS Binding 223 The SAML RADIUS binding defines how RADIUS [RFC2865] can be used to 224 enable a RADIUS client and server to exchange SAML protocol messages. 226 5.1. Required Information 228 Identification: urn:ietf:params:xml:ns:abfab:bindings:radius 230 Contact information: iesg@ietf.org 232 Updates: None. 234 5.2. Operation 236 RADIUS can be used over multiple underlying transports; this binding 237 calls out the use of RADIUS over UDP as REQUIRED. It is RECOMMENDED 238 that the RADIUS exchange is protected using TLS encryption for RADIUS 239 [I-D.ietf-radext-radsec] to provide confidentiality and improve 240 integrity protection. Implementations of this profile MUST support 241 RADIUS packet fragmentation [I-D.perez-radext-radius-fragmentation] 242 to permit transport of large SAML messages. 244 The system model used for SAML conversations over RADIUS is a simple 245 request-response model, using the RADIUS SAML-Message attribute 246 defined in Section 4 to encapsulate the SAML protocol messages. 248 1. The RADIUS client, acting as a SAML requester, MAY transmit a 249 SAML request element within a RADIUS Access-Request message. 250 This message MUST include a single instance of the RADIUS User- 251 Name attribute whose value MUST conform to the Network Access 252 Identifier [RFC4282] scheme. The SAML requester MUST NOT include 253 more than one SAML request element. 255 2. The RADIUS server, acting as a SAML responder, MAY return a SAML 256 protocol message within a RADIUS Access-Accept or Access-Reject 257 message. These messages necessarily conclude a RADIUS exchange 258 and therefore this is the only opportunity for the SAML responder 259 to send a response in the context of this exchange. The SAML 260 responder MUST NOT include more than one SAML response. A SAML 261 responder that refuses to perform a message exchange with the 262 SAML requester MUST silently discard the SAML request. 264 A SAML responder MAY also return an unsolicited response (a SAML 265 response generated and emitted in the absence of a request from a 266 SAML requester). 268 This binding is intended to be composed with other uses of RADIUS, 269 such as network access. Therefore, other arbitrary RADIUS attributes 270 MAY be used in either the request or response. 272 In the case of a SAML processing error and successful authentication, 273 the RADIUS server SHOULD include a SAML-specified 274 element in the SAML response that is transported within the Access- 275 Accept packet sent by the RADIUS server. 277 In the case of a SAML processing error and failed authentication, the 278 RADIUS server MAY include a SAML-specified element in 279 the SAML response that is transported within the Access-Reject packet 280 sent by the RADIUS server. 282 5.2.1. Use of XML Signatures 284 This bindings calls for the use of SAML elements that support XML 285 signatures. To promote interoperability implementations of this 286 binding MUST NOT require the use of XML signatures. Implementations 287 MAY choose to use XML signatures, but this usage is outside of the 288 scope of this binding. 290 5.2.2. Metadata Considerations 292 There are no metadata considerations particular to this binding. 294 6. ABFAB Authentication Profile 296 In the scenario supported by the ABFAB Authentication Profile, a 297 Principal controlling a User Agent requests access to a Relying 298 Party. The User Agent and Relying Party use the GSS EAP mechanism to 299 authenticate the Principal. The Relying Party, acting as an EAP 300 pass-through authenticator, acts as a conduit for the EAP frames 301 emitted by the User Agent and an EAP server which acts as the 302 Principal's Identity Provider. If the Identity Provider successfully 303 authenticates the Principal, it produces an authentication assertion 304 which is consumed by the Relying Party. During this process, a name 305 identifier might also be established between the Relying Party and 306 the Identity Provider. 308 6.1. Required Information 310 Identification: urn:ietf:params:xml:ns:abfab:profiles:authentication 312 Contact information: iesg@ietf.org 314 SAML Confirmation Method Identifiers: The SAML V2.0 "sender vouches" 315 confirmation method identifier, 316 urn:oasis:names:tc:SAML:2.0:cm:sender-vouches, is used by this 317 profile. 319 Updates: None. 321 6.2. Profile Overview 323 To implement this scenario, a profile of the SAML Authentication 324 Request protocol is used in conjuction with the SAML RADIUS binding 325 defined in Section 5 and the GSS EAP mechanism 326 [I-D.ietf-abfab-gss-eap]. 328 This profile is based on the SAML V2.0 Web Browser Single Sign-On 329 Profile [OASIS.saml-profiles-2.0-os]. There are some important 330 differences, specifically: 332 Authentication: This profile requires the use of a particular 333 authentication framework (namely the GSS EAP mechanism), although 334 not a particular EAP authentication method. This allows the 335 profile to build on the EAP, AAA and GSS frameworks that comprise 336 the core of the ABFAB architecture. 338 Bindings: This profile does not require the use of HTTP-based 339 bindings. Instead all SAML protocol messages are transported 340 using the SAML RADIUS binding defined in Section 5. This is 341 intended to reduce the number of bindings that implementations 342 must support to be interoperable. 344 Requests: The profile does not permit the Relying Party to name the 345 of the . This is intended to 346 simplify implementation and interoperability. 348 Responses: The profile only permits the Identity Provider to return 349 a single assertion that must contain exactly one authentication 350 statement. Other statements may be included within this assertion 351 at the discretion of the Identity Provider. This is intended to 352 simplify implementation and interoperability. 354 Figure 1 below illustrates the flow of messages within this profile. 356 User Agent Relying Party Identity Provider 357 | | | 358 | (1) | | 359 | - - - - - - - - - > | | 360 | | | 361 | | (2) | 362 | | - - - - - - - - - - - - > | 363 | | | 364 | (3) | | 365 | < - - - - - - - - - |- - - - - - - - - - - - -> | 366 | | | 367 | | (4) | 368 | | < - - - - - - - - - - - - | 369 | | | 370 | (5) | | 371 | < - - - - - - - - - | | 372 | | | 373 V V V 375 The following steps are described by the profile. Within an 376 individual step, there may be one or more actual message exchanges. 378 Figure 1 380 1. User Agent Request to Relying Party (Section 6.3.1): In step 1, 381 the Principal, via a User Agent, makes a request for a secured 382 resource at the Relying Party. The Relying Party determines that 383 no security context for the User Agent exists and initiates GSS 384 EAP authentication of the Principal. 386 2. Relying Party Issues to Identity Provider 387 (Section 6.3.2). In step 2, the Relying Party may optionally 388 issue a message to be delivered to the 389 Identity Provider using the SAML RADIUS binding. 391 3. Identity Provider Identifies Principal (Section 6.3.3). In step 392 3, the Principal is identified by the Identity Provider using EAP 393 authentication, while honoring any requirements imposed by the 394 Relying Party in the message if provided. 396 4. Identity Provider Issues to Relying Party 397 (Section 6.3.4). In step 4, the Identity Provider issues a 398 message to the Relying Party using the SAML 399 RADIUS binding. The response either indicates an error or 400 includes an authentication statement in exactly one assertion. 402 5. Relying Party Grants or Denies Access to Principal 403 (Section 6.3.5). In step 5, having received the response from 404 the Identity Provider, the Relying Party can respond to the 405 Principal's User Agent with its own error, or can establish its 406 own security context for the Principal and return the requested 407 resource. 409 6.3. Profile Description 411 The ABFAB Authentication Profile is a profile of the SAML V2.0 412 Authentication Request Protocol [OASIS.saml-core-2.0-os]. Where this 413 specification conflicts with Core, the former takes precedence. 415 6.3.1. User Agent Request to Relying Party 417 The profile is initiated by an arbitrary User Agent request to the 418 Relying Party. There are no restrictions on the form of the request. 419 The Relying Party is free to use any means it wishes to associate the 420 subsequent interactions with the original request. The Relying 421 Party, acting as a GSS acceptor, MUST invoke the GSS EAP mechanism 422 (either spontaneously or as the result of a mechanism negotiation) 423 and send an EAP-Identity/Request message to the User Agent, acting as 424 a GSS initiator. 426 6.3.2. Relying Party Issues to Identity Provider 428 The Relying Party, on receiving the EAP-Identity/Response message 429 from the User Agent, MUST send it towards the Identity Provider using 430 RADIUS as described in [RFC3579]. The Relying Party MAY include a 431 within this RADIUS Access-Request message using 432 the SAML RADIUS binding. The next hop destination MAY be the 433 Identity Provider or alternatively an intermediate RADIUS proxy. 435 Profile-specific rules for the contents of the 436 element are given in Section 6.4.1. 438 6.3.3. Identity Provider Identifies Principal 440 The Identity Provider MUST establish the identity of the Principal 441 using EAP authentication, or else it will return an error. If the 442 ForceAuthn attribute on the element (if sent by 443 the requester) is present and true, the Identity Provider MUST 444 freshly establish this identity rather than relying on any existing 445 session state it may have with the Principal (for example, TLS state 446 that may be used for session resumption). Otherwise, and in all 447 other respects, the Identity Provider may use any EAP method to 448 authenticate the Principal, subject to the requirements of Section 449 5.8 of [I-D.ietf-abfab-gss-eap] and any others called out in the 450 message. 452 6.3.4. Identity Provider Issues to Relying Party 454 The Identity Provider MUST conclude the EAP authentication in a 455 manner consistent with the EAP authentication result, and MAY issue a 456 message to the Relying Party consisent with the 457 authentication result and as described in [OASIS.saml-core-2.0-os] 458 and delivered to the Relying Party using the SAML RADIUS binding. 460 Profile-specific rules regarding the contents of the 461 element are given in Section 6.4.2. 463 6.3.5. Relying Party Grants or Denies Access to Principal 465 If issued by the Identity Provider, the Relying Party MUST process 466 the message and any enclosed 467 elements as described in [OASIS.saml-core-2.0-os]. Any subsequent 468 use of the elements is at the discretion of the 469 Relying Party, subject to any restrictions on use contained within 470 the assertions themselves or previously established out-of-band 471 policy governing interactions between the Identity Provider and the 472 Relying Party. 474 To complete the profile, the Relying Party creates a GSS security 475 context for the User Agent. 477 6.4. Use of Authentication Request Protocol 479 This profile is based on the Authentication Request Protocol defined 480 in [OASIS.saml-core-2.0-os]. In the nomenclature of actors 481 enumerated in section 3.4, the Relying Party is the requester, the 482 User Agent is the attesting entity and the Principal is the Requested 483 Subject. 485 6.4.1. Usage 487 A Relying Party MAY include any message content described in 488 [OASIS.saml-core-2.0-os], section 3.4.1. All processing rules are as 489 defined in [OASIS.saml-core-2.0-os]. 491 If the Identity Provider cannot or will not satisfy the request, it 492 MAY respond with a message containing an appropriate 493 error status code or codes. 495 If the Relying Party wishes to permit the Identity Provider to 496 establish a new identifier for the principal if none exists, it MUST 497 include a element with the AllowCreate attribute 498 set to "true". Otherwise, only a principal for whom the Identity 499 Provider has previously established an identifier usable by the 500 Relying Party can be authenticated successfully. 502 The Relying Party MUST NOT include a element in the 503 request. The authenticated EAP Identity names the Principal of the 504 requested to the Identity Provider. 506 The message MAY be signed. Authentication and 507 integrity are also provided by the RADIUS SAML binding. 509 6.4.2. Usage 511 If the Identity Provider wishes to return an error, it MUST NOT 512 include any assertions in the . Otherwise, 513 if the request is successful (or if the response is not associated 514 with a request), the element MUST conform to the 515 following: 517 o It MAY be signed. 519 o It MUST contain exactly one . The 520 element of this assertion MUST refer to the authenticated 521 Principal. 523 o The assertion MUST contain a . This MUST 524 contain a element with at least one element containing a Method of 526 urn:oasis:names:tc:SAML:2.0:cm:sender-vouches that reflects the 527 authentication of the Principal to the Identity Provider. If the 528 containing message is in response to an , then 529 the InResponseTo attribute MUST match the request's ID. 531 o Other conditions MAY be included as requested by the Relying Party 532 or at the discretion of the Identity Provider. The Identity 533 Provider is NOT obligated to honor the requested set of conditions 534 in the , if any. 536 6.4.3. samlp:Response Message Processing Rules 538 The Relying Party MUST do the following: 540 o Verify that the InResponseTo attribute in the sender-vouches 541 equals the ID of its original 542 message, unless the response is unsolicited, 543 in which case the attribute MUST NOT be present. 545 o If a used to establish a security context 546 for the Principal contains a SessionNotOnOrAfter attribute, the 547 security context SHOULD be discarded once this time is reached, 548 unless the service provider reestablishes the Principal's identity 549 by repeating the use of this profile. 551 o Verify that any assertions relied upon are valid according to 552 processing rules in [OASIS.saml-core-2.0-os]. 554 o Any assertion which is not valid, or whose subject confirmation 555 requirements cannot be met MUST be discarded and MUST NOT be used 556 to establish a security context for the Principal. 558 6.4.4. Unsolicited Responses 560 An Identity Provider MAY initiate this profile by delivering an 561 unsolicited message to a Relying Party. 563 An unsolicited MUST NOT contain an InResponseTo 564 attribute, nor should any sender-vouches elements contain one. 567 6.4.5. Use of the SAML RADIUS Binding 569 It is RECOMMENDED that the RADIUS exchange is protected using TLS 570 encryption for RADIUS [I-D.ietf-radext-radsec] to provide 571 confidentiality and improve integrity protection. 573 6.4.6. Use of XML Signatures 575 This profile calls for the use of SAML elements that support XML 576 signatures. To promote interoperability implementations of this 577 profile MUST NOT require the use of XML signatures. Implementations 578 MAY choose to use XML signatures, but this usage is outside of the 579 scope of this profile. 581 6.4.7. Metadata Considerations 583 There are no metadata considerations particular to this binding. 585 7. ABFAB Assertion Query/Request Profile 587 This profile builds on the SAML V2.0 Assertion Query/Request Profile 588 defined by [OASIS.saml-profiles-2.0-os]. That profile describes the 589 use of the Assertion Query and Request Protocol defined by section 590 3.3 of [OASIS.saml-core-2.0-os] with synchronous bindings, such as 591 the SOAP binding defined in [OASIS.saml-bindings-2.0-os] or the SAML 592 RADIUS binding defined elsewhere in this document. 594 While the SAML V2.0 Assertion Query/Request Profile is independent of 595 the underlying binding, it is nonetheless useful to describe the use 596 of this profile with the SAML RADIUS binding in the interests of 597 promoting interoperable implementations, particularly as the SAML 598 V2.0 Assertion Query/Request Profile is most frequently discussed and 599 implemented in the context of the SOAP binding. 601 7.1. Required Information 603 Identification: urn:ietf:params:xml:ns:abfab:profiles:query 605 Contact information: iesg@ietf.org 607 Description: Given below. 609 Updates: None. 611 7.2. Profile Overview 613 As with the SAML V2.0 Assertion Query/Request Profile defined by 614 [OASIS.saml-profiles-2.0-os] the message exchange and basic 615 processing rules that govern this profile are largely defined by 616 Section 3.3 of [OASIS.saml-core-2.0-os] that defines the messages to 617 be exchanged, in combination with the binding used to exchange the 618 messages. The SAML RADIUS binding described in this document defines 619 the binding of the message exchange to RADIUS. Unless specifically 620 noted here, all requirements defined in those specifications apply. 622 Figure 2 below illustrates the basic template for the query/request 623 profile. 625 SAML Requester SAML Authority 626 | | 627 | (1) | 628 | - - - - - - - - - - - - - - - - - - - - - - - > | 629 | | 630 | (2) | 631 | < - - - - - - - - - - - - - - - - - - - - - - - | 632 | | 633 | | 634 V V 636 The following steps are described by the profile. 638 Figure 2 640 1. Query/Request issued by SAML Requester: In step 1, a SAML 641 requester initiates the profile by sending an 642 , , , 643 , or message to a SAML 644 authority. 646 2. issued by SAML Authority: In step 2, the responding 647 SAML authority (after processing the query or request) issues a 648 message to the SAML requester. 650 7.3. Profile Description 652 7.3.1. Differences from the SAML V2.0 Assertion Query/Request Profile 654 This profile is identical to the SAML V2.0 Assertion Query/Request 655 Profile, with the following exceptions: 657 o In respect to section 6.3.1 and 6.5, this profile does not 658 consider the use of metadata (as in [OASIS.saml-metadata-2.0-os]); 659 see Section 7.3.4. 661 o In respect to sections 6.3.2, 6.4.1 and 6.4.2, this profile 662 additionally stipulates that implementations of this profile MUST 663 NOT require the use of XML signatures; see . 665 7.3.2. Use of the SAML RADIUS Binding 667 It is RECOMMENDED that the RADIUS exchange is protected using TLS 668 encryption for RADIUS [I-D.ietf-radext-radsec] to provide 669 confidentiality and improve integrity protection. 671 7.3.3. Use of XML Signatures 673 This profile calls for the use of SAML elements that support XML 674 signatures. To promote interoperability implementations of this 675 profile MUST NOT require the use of XML signatures. Implementations 676 MAY choose to use XML signatures, but this usage is outside of the 677 scope of this profile. 679 7.3.4. Metadata Considerations 681 There are no metadata considerations particular to this binding. 683 8. Acknowledgements 685 TODO: Where should these go? Need to acknowledge OASIS SSTC, 686 UoMurcia, Scott and Steven. 688 9. Security Considerations 690 TODO 692 10. IANA Considerations 694 Assignments of additional enumerated values for the RADIUS attributes 695 defined in this document are to be processed as described in 696 [RFC3575], subject to the additional requirements of a published 697 specification. 699 11. References 701 11.1. Normative References 703 [RFC2119] Bradner, S., "Key words for 704 use in RFCs to Indicate 705 Requirement Levels", BCP 14, 706 RFC 2119, March 1997. 708 [I-D.ietf-radext-radsec] Winter, S., McCauley, M., 709 Venaas, S., and K. Wierenga, 710 "TLS encryption for RADIUS", 711 draft-ietf-radext-radsec-09 712 (work in progress), 713 July 2011. 715 [I-D.ietf-abfab-gss-eap] Howlett, J. and S. Hartman, 716 "A GSS-API Mechanism for the 717 Extensible Authentication 718 Protocol", 719 (work in progress), 720 October 2011. 722 [I-D.perez-radext-radius-fragmentation] Perez-Mendez, A., Lopez, R., 723 Pereniguez-Garcia, F., 724 Lopez-Millan, G., Lopez, D., 725 and A. DeKok, "Support of 726 fragmentation of RADIUS 727 packets", draft-perez- 728 radext-radius-fragmentation- 729 01 (work in progress), 730 February 2012. 732 11.2. Informative References 734 [RFC2865] Rigney, C., Willens, S., 735 Rubens, A., and W. Simpson, 736 "Remote Authentication Dial 737 In User Service (RADIUS)", 738 RFC 2865, June 2000. 740 [RFC3575] Aboba, B., "IANA 741 Considerations for RADIUS 742 (Remote Authentication Dial 743 In User Service)", RFC 3575, 744 July 2003. 746 [RFC3579] Aboba, B. and P. Calhoun, 747 "RADIUS (Remote 748 Authentication Dial In User 749 Service) Support For 750 Extensible Authentication 751 Protocol (EAP)", RFC 3579, 752 September 2003. 754 [RFC3588] Calhoun, P., Loughney, J., 755 Guttman, E., Zorn, G., and 756 J. Arkko, "Diameter Base 757 Protocol", RFC 3588, 758 September 2003. 760 [RFC4282] Aboba, B., Beadles, M., 761 Arkko, J., and P. Eronen, 762 "The Network Access 763 Identifier", RFC 4282, 764 December 2005. 766 [I-D.jones-diameter-abfab] Jones, M. and H. Tschofenig, 767 "The Diameter 'Application 768 Bridging for Federated 769 Access Beyond Web (ABFAB)' 770 Application", draft-jones- 771 diameter-abfab-00 (work in 772 progress), March 2011. 774 [I-D.ietf-abfab-arch] Howlett, J., Hartman, S., 775 Tschofenig, H., Lear, E., 776 and J. Schaad, "Application 777 Bridging for Federated 778 Access Beyond Web (ABFAB) 779 Architecture", 780 draft-ietf-abfab-arch-03 781 (work in progress), 782 July 2012. 784 [OASIS.saml-bindings-2.0-os] Cantor, S., Hirsch, F., 785 Kemp, J., Philpott, R., and 786 E. Maler, "Bindings for the 787 OASIS Security Assertion 788 Markup Language (SAML) 789 V2.0", OASIS Standard saml- 790 bindings-2.0-os, March 2005. 792 [OASIS.saml-core-2.0-os] Cantor, S., Kemp, J., 793 Philpott, R., and E. Maler, 794 "Assertions and Protocol for 795 the OASIS Security Assertion 796 Markup Language (SAML) 797 V2.0", OASIS Standard saml- 798 core-2.0-os, March 2005. 800 [OASIS.saml-profiles-2.0-os] Hughes, J., Cantor, S., 801 Hodges, J., Hirsch, F., 802 Mishra, P., Philpott, R., 803 and E. Maler, "Profiles for 804 the OASIS Security Assertion 805 Markup Language (SAML) 806 V2.0", OASIS Standard OASIS. 807 saml-profiles-2.0-os, 808 March 2005. 810 [OASIS.saml-metadata-2.0-os] Cantor, S., Moreh, J., 811 Philpott, R., and E. Maler, 812 "Metadata for the Security 813 Assertion Markup Language 814 (SAML) V2.0", OASIS Standard 815 saml-metadata-2.0-os, 816 March 2005. 818 Authors' Addresses 820 Josh Howlett 821 Janet 822 Lumen House, Library Avenue, Harwell 823 Oxford OX11 0SG 824 UK 826 Phone: +44 1235 822363 827 EMail: Josh.Howlett@ja.net 829 Sam Hartman 830 Painless Security 832 Phone: 833 EMail: hartmans-ietf@mit.edu