idnits 2.17.1 draft-ietf-abfab-aaa-saml-10.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 (February 5, 2015) is 3368 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 3588 (Obsoleted by RFC 6733) -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) == Outdated reference: A later version (-07) exists of draft-ietf-radext-bigger-packets-01 Summary: 0 errors (**), 0 flaws (~~), 2 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: August 9, 2015 Painless Security 6 A. Perez-Mendez, Ed. 7 University of Murcia 8 February 5, 2015 10 A RADIUS Attribute, Binding, Profiles, Name Identifier Format, and 11 Confirmation Methods for SAML 12 draft-ietf-abfab-aaa-saml-10 14 Abstract 16 This document describes the use of the Security Assertion Mark-up 17 Language (SAML) with RADIUS in the context of the ABFAB architecture. 18 It defines two RADIUS attributes, a SAML binding, a SAML name 19 identifier format, two SAML profiles, and two SAML confirmation 20 methods. The RADIUS attributes permit encapsulation of SAML 21 assertions and protocol messages within RADIUS, allowing SAML 22 entities to communicate using the binding. The two profiles describe 23 the application of this binding for ABFAB authentication and 24 assertion query/request, enabling a Relying Party to request 25 authentication of, or assertions for, users or machines (Clients). 26 These Clients may be named using a NAI name identifier format. 27 Finally, the subject confirmation methods allow requests and queries 28 to be issued for a previously authenticated user or machine without 29 needing to explicitly identify them as the subject. These artifacts 30 have been defined to permit application in AAA scenarios other than 31 ABFAB, such as network access. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at http://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on August 9, 2015. 50 Copyright Notice 52 Copyright (c) 2015 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 3. RADIUS SAML Attributes . . . . . . . . . . . . . . . . . . . 4 70 3.1. SAML-Assertion attribute . . . . . . . . . . . . . . . . 5 71 3.2. SAML-Message attribute . . . . . . . . . . . . . . . . . 5 72 4. SAML RADIUS Binding . . . . . . . . . . . . . . . . . . . . . 6 73 4.1. Required Information . . . . . . . . . . . . . . . . . . 6 74 4.2. Operation . . . . . . . . . . . . . . . . . . . . . . . . 7 75 4.3. Processing of names . . . . . . . . . . . . . . . . . . . 8 76 4.3.1. AAA names . . . . . . . . . . . . . . . . . . . . . . 8 77 4.3.2. SAML names . . . . . . . . . . . . . . . . . . . . . 8 78 4.3.3. Use of XML Signatures . . . . . . . . . . . . . . . . 9 79 4.3.4. Metadata Considerations . . . . . . . . . . . . . . . 9 80 5. Network Access Identifier Name Identifier Format . . . . . . 10 81 6. ABFAB Authentication Profile . . . . . . . . . . . . . . . . 10 82 6.1. Required Information . . . . . . . . . . . . . . . . . . 10 83 6.2. Profile Overview . . . . . . . . . . . . . . . . . . . . 10 84 6.3. Profile Description . . . . . . . . . . . . . . . . . . . 12 85 6.3.1. Client Request to Relying Party . . . . . . . . . . . 12 86 6.3.2. Relying Party Issues to Identity 87 Provider . . . . . . . . . . . . . . . . . . . . . . 13 88 6.3.3. Identity Provider Identifies Client . . . . . . . . . 13 89 6.3.4. Identity Provider Issues to Relying 90 Party . . . . . . . . . . . . . . . . . . . . . . . . 13 91 6.3.5. Relying Party Grants or Denies Access to Client . . . 13 92 6.4. Use of Authentication Request Protocol . . . . . . . . . 14 93 6.4.1. Usage . . . . . . . . . . . . . 14 94 6.4.2. Message Usage . . . . . . . . . . . 14 95 6.4.3. Message Processing Rules . . . . . . 15 96 6.4.4. Unsolicited Responses . . . . . . . . . . . . . . . . 15 97 6.4.5. Use of the SAML RADIUS Binding . . . . . . . . . . . 16 98 6.4.6. Use of XML Signatures . . . . . . . . . . . . . . . . 16 99 6.4.7. Metadata Considerations . . . . . . . . . . . . . . . 16 100 7. ABFAB Assertion Query/Request Profile . . . . . . . . . . . . 16 101 7.1. Required Information . . . . . . . . . . . . . . . . . . 16 102 7.2. Profile Overview . . . . . . . . . . . . . . . . . . . . 17 103 7.3. Profile Description . . . . . . . . . . . . . . . . . . . 17 104 7.3.1. Differences from the SAML V2.0 Assertion 105 Query/Request Profile . . . . . . . . . . . . . . . . 17 106 7.3.2. Use of the SAML RADIUS Binding . . . . . . . . . . . 18 107 7.3.3. Use of XML Signatures . . . . . . . . . . . . . . . . 18 108 7.3.4. Metadata Considerations . . . . . . . . . . . . . . . 18 109 8. RADIUS State Confirmation Methods . . . . . . . . . . . . . . 18 110 9. Privacy considerations . . . . . . . . . . . . . . . . . . . 19 111 10. Security Considerations . . . . . . . . . . . . . . . . . . . 20 112 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 113 11.1. RADIUS Attributes . . . . . . . . . . . . . . . . . . . 20 114 11.2. ABFAB Parameters . . . . . . . . . . . . . . . . . . . . 21 115 11.3. Registration of the ABFAB URN Namespace . . . . . . . . 21 116 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 117 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 118 13.1. Normative References . . . . . . . . . . . . . . . . . . 22 119 13.2. Informative References . . . . . . . . . . . . . . . . . 23 121 1. Introduction 123 Within the ABFAB architecture [I-D.ietf-abfab-arch] it is often 124 desirable to convey Security Assertion Mark-up Language (SAML) 125 assertions and protocol messages. 127 SAML typically only considers the use of HTTP-based transports, known 128 as bindings [OASIS.saml-bindings-2.0-os], which are primarily 129 intended for use with the SAML V2.0 Web Browser Single Sign-On 130 Profile [OASIS.saml-profiles-2.0-os]. However the goal of ABFAB is 131 to extend the applicability of federated identity beyond the Web to 132 other applications by building on the AAA framework. Consequently 133 there exists a requirement for SAML to integrate with the AAA 134 framework and protocols such as RADIUS [RFC2865] and Diameter 135 [RFC3588], in addition to HTTP. 137 A companion specification [I-D.jones-diameter-abfab] specifies 138 equivalent functionality for Diameter. 140 In summary this document specifies: 142 o Two RADIUS attributes to encapsulate SAML assertions and protocol 143 messages respectively. 145 o A SAML RADIUS binding that defines how SAML assertions and 146 protocol messages can be transported by RADIUS within a SAML 147 exchange. 149 o A SAML name identifier format in the form of a Network Access 150 Identifier. 152 o A profile of the SAML Authentication Request Protocol that uses 153 the SAML RADIUS binding to effect SAML-based authentication and 154 authorization. 156 o A profile of the SAML Assertion Query And Request Protocol that 157 uses the SAML RADIUS binding to effect the query and request of 158 SAML assertions. 160 o Two SAML Subject Confirmation Methods for indicating that a user 161 or machine client is the subject of an assertion. 163 This document adheres to the guidelines stipulated by 164 [OASIS.saml-bindings-2.0-os] and [OASIS.saml-profiles-2.0-os] for 165 defining new SAML bindings and profiles respectively, and other 166 conventions applied formally or otherwise within SAML. In particular 167 where this document provides a 'Required Information' section for the 168 binding and profiles that enumerate: 170 o A URI that uniquely identifies the protocol binding or profile 172 o Postal or electronic contact information for the author 174 o A reference to previously defined bindings or profiles that the 175 new binding updates or obsoletes 177 o In the case of a profile, any SAML confirmation method identifiers 178 defined and/or utilized by the profile 180 2. Conventions 182 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 183 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 184 document are to be interpreted as described in RFC 2119 [RFC2119]. 186 3. RADIUS SAML Attributes 188 The RADIUS SAML binding defined in Section 4 of this document uses 189 two attributes to convey SAML assertions and protocol messages 190 respectively [OASIS.saml-core-2.0-os]. Owing to the typical size of 191 these structures, these attributes use the Long Extended Type format 192 [RFC6929] to encapsulate their data. 194 3.1. SAML-Assertion attribute 196 This attribute is used to encode a SAML assertion. The following 197 figure represents the format of this attribute. 199 1 2 3 200 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 201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 202 | Type | Length | Extended-Type |M| Reserved | 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 204 | Value... 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 Figure 1: SAML-Assertion format 209 Type 211 245 (To be confirmed by IANA) 213 Length 215 >= 5 217 Extended-Type 219 TBD1 221 M (More) 223 As described in [RFC6929]. 225 Reserved 227 As described in [RFC6929]. 229 Value 231 One or more octets encoding a SAML assertion. 233 3.2. SAML-Message attribute 235 This attribute is used to encode a SAML protocol message. The 236 following figure represents the format of this attribute. 238 1 2 3 239 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 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 | Type | Length | Extended-Type |M| Reserved | 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 243 | Value... 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 Figure 2: SAML-Message format 248 Type 250 245 (To be confirmed by IANA) 252 Length 254 >= 5 256 Extended-Type 258 TBD2 260 M (More) 262 As described in [RFC6929]. 264 Reserved 266 As described in [RFC6929]. 268 Value 270 One or more octets encoding a SAML protocol message. 272 4. SAML RADIUS Binding 274 The SAML RADIUS binding defines how RADIUS [RFC2865] can be used to 275 enable a RADIUS client and server to exchange SAML assertions and 276 protocol messages. 278 4.1. Required Information 280 Identification: urn:ietf:params:abfab:bindings:radius 282 Contact information: iesg@ietf.org 284 Updates: None. 286 4.2. Operation 288 RADIUS can be used over multiple underlying transports. It is 289 RECOMMENDED that the RADIUS exchange is protected using TLS 290 encryption for RADIUS [RFC6614] to provide confidentiality and 291 improve integrity protection. 293 Implementations of this profile MAY take advantage of mechanisms to 294 permit the transport of longer SAML messages over RADIUS transports, 295 such as the Support of fragmentation of RADIUS packets 296 [I-D.ietf-radext-radius-fragmentation] or Larger Packets for RADIUS 297 over TCP [I-D.ietf-radext-bigger-packets]. 299 There are two system models for the use of SAML over RADIUS. The 300 first is a request-response model, using the RADIUS SAML-Message 301 attribute defined in Section 3 to encapsulate the SAML protocol 302 messages. 304 1. The RADIUS client, acting as a Relying Party (RP), transmits a 305 SAML request element within a RADIUS Access-Request message. 306 This message MUST include a single instance of the RADIUS User- 307 Name attribute whose value MUST conform to the Network Access 308 Identifier [I-D.ietf-radext-nai] scheme. The Relying Party MUST 309 NOT include more than one SAML request element. 311 2. The RADIUS server, acting as an Identity Provider (IdP), returns 312 a SAML protocol message within a RADIUS Access-Accept or Access- 313 Reject message. These messages necessarily conclude a RADIUS 314 exchange and therefore this is the only opportunity for the 315 Identity Provider to send a response in the context of this 316 exchange. The Identity Provider MUST NOT include more than one 317 SAML response. An IdP that refuses to perform a message exchange 318 with the Relying Party can silently discard the SAML request 319 (this could subsequently be followed by a RADIUS Access-Reject, 320 as the same conditions that cause the IdP to discard the SAML 321 request may also cause the RADIUS server to fail to 322 authenticate). 324 The second system model permits a RADIUS server acting as an Identity 325 Provider to use the RADIUS SAML-Assertion attribute defined in 326 Section 3 to encapsulate an unsolicited SAML assertion. This 327 attribute MUST be included in a RADIUS Access-Accept message. When 328 included, the attribute MUST contain a single SAML assertion. 330 RADIUS servers MUST NOT include both the SAML-Message and the SAML- 331 Assertion attribute in the same RADIUS message. If an IdP is 332 producing a response to a SAML request, then the first system model 333 is used. An IdP MAY ignore a SAML request and send an unsolicited 334 assertion using the second system model using the RADIUS SAML- 335 Assertion attribute. 337 In either system model, Identity Providers SHOULD return a RADIUS 338 state attribute as part of the Access-Accept message so that future 339 SAML queries or requests can be run against the same context of an 340 authentication exchange. 342 This binding is intended to be composed with other uses of RADIUS, 343 such as network access. Therefore, other arbitrary RADIUS attributes 344 MAY be used in either the request or response. 346 In the case of a SAML processing error and successful authentication, 347 the RADIUS server SHOULD include a SAML-specified 348 element in the SAML response that is transported within the Access- 349 Accept packet sent by the RADIUS server. 351 In the case of a SAML processing error and failed authentication, the 352 RADIUS server MAY include a SAML-specified element in 353 the SAML response that is transported within the Access-Reject packet 354 sent by the RADIUS server. 356 4.3. Processing of names 358 SAML entities using profiles of this binding will typically possess 359 both the SAML and AAA names of their correspondents. Frequently 360 these entities will need to apply policies using these names; for 361 example, when deciding to release attributes. Often these policies 362 will be security-sensitive, and so it is important that policy is 363 applied on these names consistently. 365 4.3.1. AAA names 367 These rules relate to the processing of AAA names by SAML entities 368 using profiles of this binding. 370 o Identity Providers SHOULD apply policy based on the Relying 371 Party's identity associated with the RADIUS Access-Request. 373 o Relying Parties SHOULD apply policy based on the NAI realm 374 associated with the RADIUS Access-Accept. 376 4.3.2. SAML names 378 These rules relate to the processing of SAML names by SAML entities 379 using profiles of this binding. 381 Identity Providers MAY apply policy based on the Relying Party's SAML 382 In such cases, at least one of the following methods is 383 required in order to establish a relation between the SAML name and 384 the AAA name of the Relying Party: 386 o RADIUS client identity in trusted digitally signed SAML request. 388 o RADIUS client identity in trusted SAML federation metadata (as in 389 [OASIS.saml-metadata-2.0-os]). 391 A digitally signed SAML request without the RADIUS client identity is 392 not sufficient, since a malicious RADIUS entity can observe a SAML 393 message and include it in a different RADIUS message without the 394 consent of the issuer of that SAML message. If an Identity Provider 395 were to process the SAML message without confirming that it applied 396 to the RADIUS message, inappropriate policy would be used. 398 Relying Parties MAY apply policy based on the SAML issuer's 399 . In such cases, at least one of the following methods is 400 required in order to establish a relation between the SAML name and 401 the AAA name of the Identity Provider: 403 o RADIUS realm in trusted digitally signed SAML response or 404 assertion. 406 o RADIUS realm in trusted SAML federation metadata. 408 A digitally signed SAML response alone is not sufficient for the same 409 reasons described above for SAML requests. 411 4.3.3. Use of XML Signatures 413 This binding calls for the use of SAML elements that support XML 414 signatures. To promote interoperability, implementations of this 415 binding MUST support a default configuration that does not require 416 the use of XML signatures. Implementations MAY choose to use XML 417 signatures, but this usage is outside of the scope of this binding. 419 4.3.4. Metadata Considerations 421 There are no metadata considerations particular to this binding, 422 because this binding and profiles of this binding are mostly intended 423 to be used without metadata. In this usage, RADIUS infrastructure is 424 used to provide integrity and naming of the SAML messages and 425 assertions. RADIUS configuration is used to provide policy including 426 which attributes are accepted from a Relying Party and which 427 attributes are sent by an Identity Provider. 429 Nevertheless, implementations MAY support other configurations 430 including the use of metadata. 432 5. Network Access Identifier Name Identifier Format 434 URI: urn:ietf:params:abfab:nameid-format:nai 436 Indicates that the content of the element is in the form of a Network 437 Access Identifier (NAI) using the syntax described by 438 [I-D.ietf-radext-nai]. 440 6. ABFAB Authentication Profile 442 In the scenario supported by the ABFAB Authentication Profile, a 443 Client controlling a User Agent requests access to a Relying Party. 444 The Relying Party uses RADIUS to authenticate the Client. In 445 particular, the Relying Party, acting as a RADIUS client, attempts to 446 validate the Client's credentials against a RADIUS server acting as 447 the Client's Identity Provider. If the Identity Provider 448 successfully authenticates the Client, it produces an authentication 449 assertion which is consumed by the Relying Party. This assertion MAY 450 include a name identifier that can be used between the Relying Party 451 and the Identity Provider to refer to the Client. 453 6.1. Required Information 455 Identification: urn:ietf:params:abfab:profiles:authentication 457 Contact information: iesg@ietf.org 459 SAML Confirmation Method Identifiers: The SAML V2.0 "sender vouches" 460 confirmation method identifier, 461 urn:oasis:names:tc:SAML:2.0:cm:sender-vouches, is used by this 462 profile. 464 Updates: None. 466 6.2. Profile Overview 468 To implement this scenario a profile of the SAML Authentication 469 Request protocol is used in conjunction with the SAML RADIUS binding 470 defined in Section 4. 472 This profile is based on the SAML V2.0 Web Browser Single Sign-On 473 Profile [OASIS.saml-profiles-2.0-os]. There are some important 474 differences, specifically: 476 Authentication: This profile does not require the use of any 477 particular authentication method. The ABFAB architecture does 478 require the use of EAP [RFC3579], but this specification may be 479 used in other non-ABFAB scenarios. 481 Bindings: This profile does not require the use of HTTP-based 482 bindings. Instead all SAML protocol messages are transported 483 using the SAML RADIUS binding defined in Section 4. This is 484 intended to reduce the number of bindings that implementations 485 must support to be interoperable. 487 Requests: The profile does not permit the Relying Party to name the 488 of the . This is intended to 489 simplify implementation and interoperability. 491 Responses: The profile only permits the Identity Provider to return 492 a single SAML message or assertion that MUST contain exactly one 493 authentication statement. Other statements may be included within 494 this assertion at the discretion of the Identity Provider. This 495 is intended to simplify implementation and interoperability. 497 Figure 3 below illustrates the flow of messages within this profile. 499 Client Relying Party Identity Provider 500 | | | 501 | (1) | | 502 | - - - - - - - - - > | | 503 | | | 504 | | (2) | 505 | | - - - - - - - - - - - - > | 506 | | | 507 | (3) | | 508 | < - - - - - - - - - |- - - - - - - - - - - - - >| 509 | | | 510 | | (4) | 511 | | < - - - - - - - - - - - - | 512 | | | 513 | (5) | | 514 | < - - - - - - - - - | | 515 | | | 516 V V V 518 The following steps are described by the profile. Within an 519 individual step, there may be one or more actual message exchanges. 521 Figure 3 523 1. Client request to Relying Party (Section 6.3.1): In step 1, the 524 Client, via a User Agent, makes a request for a secured resource 525 at the Relying Party. The Relying Party determines that no 526 security context for the Client exists and initiates the 527 authentication process. 529 2. Relying Party issues to Identity Provider 530 (Section 6.3.2). In step 2, the Relying Party may optionally 531 issue a message to be delivered to the 532 Identity Provider using the SAML RADIUS binding. 534 3. Identity Provider identifies Client (Section 6.3.3). In step 3, 535 the Client is authenticated and identified by the Identity 536 Provider, while honoring any requirements imposed by the Relying 537 Party in the message if provided. 539 4. Identity Provider issues to Relying Party 540 (Section 6.3.4). In step 4, the Identity Provider issues a 541 message to the Relying Party using the SAML 542 RADIUS binding. The response either indicates an error or 543 includes a SAML Authentication Statement in exactly one SAML 544 Assertion. 546 5. Relying Party grants or denies access to Client (Section 6.3.5). 547 In step 5, having received the response from the Identity 548 Provider, the Relying Party can respond to the Client with its 549 own error, or can establish its own security context for the 550 Client and return the requested resource. 552 6.3. Profile Description 554 The ABFAB Authentication Profile is a profile of the SAML V2.0 555 Authentication Request Protocol [OASIS.saml-core-2.0-os]. Where this 556 specification conflicts with it, the former takes precedence. 558 6.3.1. Client Request to Relying Party 560 The profile is initiated by an arbitrary Client request to the 561 Relying Party. There are no restrictions on the form of the request. 562 The Relying Party is free to use any means it wishes to associate the 563 subsequent interactions with the original request. The Relying 564 Party, acting as a RADIUS client, attempts to authenticate the 565 Client. 567 6.3.2. Relying Party Issues to Identity Provider 569 The Relying Party uses RADIUS to communicate with the Client's 570 Identity Provider. The Relying Party MAY include a 571 within this RADIUS Access-Request message using 572 the SAML RADIUS binding. The next hop destination MAY be the 573 Identity Provider or alternatively an intermediate RADIUS proxy. 575 Profile-specific rules for the contents of the 576 element are given in Section 6.4.1. 578 6.3.3. Identity Provider Identifies Client 580 The Identity Provider MUST establish the identity of the Client using 581 RADIUS authentication, or else it will return an error. If the 582 ForceAuthn attribute on the element (if sent by 583 the Relying Party) is present and true, the Identity Provider MUST 584 freshly establish this identity rather than relying on any existing 585 session state it may have with the Client (for example, TLS state 586 that may be used for session resumption). Otherwise, and in all 587 other respects, the Identity Provider may use any method to 588 authenticate the Client, subject to the constraints called out in the 589 message. 591 6.3.4. Identity Provider Issues to Relying Party 593 The Identity Provider MUST conclude the authentication in a manner 594 consistent with the RADIUS authentication result. The IdP MAY issue 595 a message to the Relying Party that is consistent 596 with the authentication result, as described in 597 [OASIS.saml-core-2.0-os]. This SAML response is delivered to the 598 Relying Party using the SAML RADIUS binding described in Section 4. 600 Profile-specific rules regarding the contents of the 601 element are given in Section 6.4.2. 603 6.3.5. Relying Party Grants or Denies Access to Client 605 If issued by the Identity Provider, the Relying Party MUST process 606 the message and any enclosed 607 elements as described in [OASIS.saml-core-2.0-os]. Any subsequent 608 use of the elements is at the discretion of the 609 Relying Party, subject to any restrictions contained within the 610 assertions themselves or from any previously established out-of-band 611 policy that governs the interaction between the Identity Provider and 612 the Relying Party. 614 6.4. Use of Authentication Request Protocol 616 This profile is based on the Authentication Request Protocol defined 617 in [OASIS.saml-core-2.0-os]. In the nomenclature of actors 618 enumerated in section 3.4 of that document, the Relying Party is the 619 requester, the User Agent is the attesting entity and the Client is 620 the Requested Subject. 622 6.4.1. Usage 624 The Relying Party MUST NOT include a element in the 625 request. The authenticated RADIUS identity identifies the Client to 626 the Identity Provider. 628 A Relying Party MAY include any message content described in 629 [OASIS.saml-core-2.0-os], section 3.4.1. All processing rules are as 630 defined in [OASIS.saml-core-2.0-os]. 632 If the Relying Party wishes to permit the Identity Provider to 633 establish a new identifier for the Client if none exists, it MUST 634 include a element with the AllowCreate attribute 635 set to "true". Otherwise, only a Client for whom the Identity 636 Provider has previously established an identifier usable by the 637 Relying Party can be authenticated successfully. 639 The message MAY be signed. Authentication and 640 integrity are also provided by the SAML RADIUS binding. 642 6.4.2. Message Usage 644 If the Identity Provider cannot or will not satisfy the request, it 645 MAY respond with a message containing an appropriate 646 error status code or codes. 648 If the Identity Provider wishes to return an error, it MUST NOT 649 include any assertions in the . Otherwise, 650 if the request is successful (or if the response is not associated 651 with a request), the element is subject conform to 652 the following: 654 o It MAY be signed. 656 o It MUST contain exactly one . The 657 element of this assertion MUST refer to the authenticated RADIUS 658 user. 660 o The assertion MUST contain a . Besides, the 661 assertion MUST contain a element with at least one 662 element containing a Method of 663 urn:oasis:names:tc:SAML:2.0:cm:sender-vouches that reflects the 664 authentication of the Client to the Identity Provider. Since the 665 containing message is in response to an , the 666 InResponseTo attribute MUST match the request's ID. The 667 element MAY use the NAI Name Identifier Format 668 described in Section 5 to establish an identifier between the 669 Relying Party and the IdP. 671 o Other conditions MAY be included as requested by the Relying Party 672 or at the discretion of the Identity Provider. The Identity 673 Provider is NOT obligated to honor the requested set of conditions 674 in the , if any. 676 6.4.3. Message Processing Rules 678 The Relying Party MUST do the following: 680 o Assume that the Client's identifier implied by a SAML 681 element, if present, takes precedence over an identifier implied 682 by the RADIUS User-Name attribute. 684 o Verify that the InResponseTo attribute in the sender-vouches 685 equals the ID of its original 686 message, unless the response is unsolicited, 687 in which case the attribute MUST NOT be present. 689 o If a used to establish a security context 690 for the Client contains a SessionNotOnOrAfter attribute, the 691 security context SHOULD be discarded once this time is reached, 692 unless the Relying Party reestablishes the Client's identity by 693 repeating the use of this profile. 695 o Verify that any assertions relied upon are valid according to 696 processing rules in [OASIS.saml-core-2.0-os]. 698 o Any assertion which is not valid, or whose subject confirmation 699 requirements cannot be met MUST be discarded and MUST NOT be used 700 to establish a security context for the Client. 702 6.4.4. Unsolicited Responses 704 An Identity Provider MAY initiate this profile by delivering an 705 unsolicited to a Relying Party. This MUST NOT 706 contain any sender-vouches elements 707 containing an InResponseTo attribute. 709 6.4.5. Use of the SAML RADIUS Binding 711 It is RECOMMENDED that the RADIUS exchange is protected using TLS 712 encryption for RADIUS [RFC6614] to provide confidentiality and 713 improve integrity protection. 715 6.4.6. Use of XML Signatures 717 This profile calls for the use of SAML elements that support XML 718 signatures. To promote interoperability implementations of this 719 profile MUST NOT require the use of XML signatures. Implementations 720 MAY choose to use XML signatures, but this usage is outside of the 721 scope of this profile. 723 6.4.7. Metadata Considerations 725 There are no metadata considerations particular to this binding. 727 7. ABFAB Assertion Query/Request Profile 729 This profile builds on the SAML V2.0 Assertion Query/Request Profile 730 defined by [OASIS.saml-profiles-2.0-os]. That profile describes the 731 use of the Assertion Query and Request Protocol defined by section 732 3.3 of [OASIS.saml-core-2.0-os] with synchronous bindings, such as 733 the SOAP binding defined in [OASIS.saml-bindings-2.0-os]. 735 While the SAML V2.0 Assertion Query/Request Profile is independent of 736 the underlying binding, it is nonetheless useful to describe the use 737 of the SAML RADIUS binding defined in Section 4 of this document, in 738 the interests of promoting interoperable implementations, 739 particularly as the SAML V2.0 Assertion Query/Request Profile is most 740 frequently discussed and implemented in the context of the SOAP 741 binding. 743 7.1. Required Information 745 Identification: urn:ietf:params:abfab:profiles:query 747 Contact information: iesg@ietf.org 749 Description: Given below. 751 Updates: None. 753 7.2. Profile Overview 755 As with the SAML V2.0 Assertion Query/Request Profile defined by 756 [OASIS.saml-profiles-2.0-os] the message exchange and basic 757 processing rules that govern this profile are largely defined by 758 Section 3.3 of [OASIS.saml-core-2.0-os] that defines the messages to 759 be exchanged, in combination with the binding used to exchange the 760 messages. The SAML RADIUS binding described in this document defines 761 the binding of the message exchange to RADIUS. Unless specifically 762 noted here, all requirements defined in those specifications apply. 764 Figure 4 below illustrates the basic template for the query/request 765 profile. 767 Relying Party Identity Provider 768 (SAML requester) (SAML responder) 769 | | 770 | (1) | 771 | - - - - - - - - - - - - - - - - - - - - - - - > | 772 | | 773 | (2) | 774 | < - - - - - - - - - - - - - - - - - - - - - - - | 775 | | 776 V V 778 The following steps are described by the profile. 780 Figure 4 782 1. Query/Request issued by Relying Party: In step 1, a Relying Party 783 initiates the profile by sending an , 784 , , , or 785 message to a SAML authority. 787 2. issued by SAML Authority: In step 2, the responding 788 SAML authority (after processing the query or request) issues a 789 message to the Relying Party. 791 7.3. Profile Description 793 7.3.1. Differences from the SAML V2.0 Assertion Query/Request Profile 795 This profile is identical to the SAML V2.0 Assertion Query/Request 796 Profile, with the following exceptions: 798 o When processing the SAML request, the IdP MUST give precedence to 799 the Client's identifier implied by RADIUS State attribute, if 800 present, over the identifier implied by the SAML request's 801 , if any. 803 o In respect to sections 6.3.1 and 6.5 of 804 [OASIS.saml-profiles-2.0-os], this profile does not consider the 805 use of metadata (as in [OASIS.saml-metadata-2.0-os]). See 806 Section 7.3.4. 808 o In respect to sections 6.3.2, 6.4.1, and 6.4.2 of 809 [OASIS.saml-profiles-2.0-os], this profile additionally stipulates 810 that implementations of this profile MUST NOT require the use of 811 XML signatures. See Section 7.3.3. 813 7.3.2. Use of the SAML RADIUS Binding 815 The RADIUS Access-Request sent by the Relying Party: 817 o MUST include an instance of the RADIUS Service-Type attribute, 818 having a value of Authorize-Only. 820 o SHOULD include the RADIUS State attribute, where this Query/ 821 Request pertains to previously authenticated Client. 823 When processing the SAML request, the IdP MUST give precedence to the 824 Client's identifier implied by RADIUS State attribute over the 825 identifier implied by the SAML request's , if any. 827 It is RECOMMENDED that the RADIUS exchange is protected using TLS 828 encryption for RADIUS [RFC6614] to provide confidentiality and 829 improve integrity protection. 831 7.3.3. Use of XML Signatures 833 This profile calls for the use of SAML elements that support XML 834 signatures. To promote interoperability implementations of this 835 profile MUST NOT require the use of XML signatures. Implementations 836 MAY choose to use XML signatures, but this usage is outside of the 837 scope of this profile. 839 7.3.4. Metadata Considerations 841 There are no metadata considerations particular to this binding. 843 8. RADIUS State Confirmation Methods 845 URI: urn:ietf:params:abfab:cm:user 847 URI: urn:ietf:params:abfab:cm:machine 848 The RADIUS State Confirmation Methods indicate that the Subject is 849 the system entity (either the user or machine) authenticated by a 850 previously transmitted RADIUS Access-Accept message, as identified by 851 the value of that RADIUS message's State attribute. 853 9. Privacy considerations 855 The profiles defined in this document allow a Relaying Party to 856 request specific information about the Client, and allow an IdP to 857 disclose information about that Client. In this sense, Identity 858 Providers MUST apply policy to decide what information is released to 859 a particular Relying Party. Moreover, the identity of the Client is 860 typically hidden from the Relying Party unless informed by the 861 Identity Provider. Conversely, the Relying Party does typically know 862 the realm of the IdP, as it is required to being able to route the 863 RADIUS packets to the right destination. 865 The kind of information that is released by the IdP MAY include 866 generic attributes such as affiliation shared by many Clients. But 867 even these generic attributes can help to identify a specific Client. 868 Other kind of attributes MAY also provide a Relying Party with the 869 ability to link the same Client between different sessions. Finally, 870 other kind of attributes MAY provide a group of Relying Parties with 871 the ability to link the Client between them or with personally 872 identifiable information about the Client. 874 These profiles do not directly provide a Client with a mechanism to 875 express preferences about what information is released. That 876 information can be expressed out-of-band, for example as part of the 877 enrollment process. 879 The Relying Party MAY disclose privacy-sensitive information about 880 itself as part of the request, although this is unlikely in typical 881 deployments. 883 If RADIUS proxies are used and encryption is not used, the attributes 884 disclosed by the IdP are visible to the proxies. This is a 885 significant privacy exposure in some deployments. Ongoing work is 886 exploring mechanisms for creating TLS connections directly between 887 the RADIUS client and the RADIUS server to reduce this exposure. If 888 proxies are used, the impact of exposing SAML assertions to the 889 proxies needs to be carefully considered. 891 The use of TLS to provide confidentiality for the RADIUS exchange is 892 strongly encouraged. Without this, passive eavesdroppers can observe 893 the assertions. 895 10. Security Considerations 897 In this specification, the IdP vouches for its SAML messages. 898 Therefore, the Relying Party MUST trust any statement in the SAML 899 messages from the IdP in the same way that it trusts information 900 contained in RADIUS attributes. These entities MUST trust the RADIUS 901 infrastructure to provide integrity of the SAML messages. 903 Furthermore, the Relying Party MUST apply policy and filter the 904 information based on what information the IdP is permitted to assert 905 and on what trust is reasonable to place in proxies between them. 907 XML signatures and encryption are provided as an OPTIONAL mechanism 908 for end-to-end security. These mechanism can protect SAML messages 909 from being modified by proxies in the RADIUS infrastructure. These 910 mechanisms are not mandatory-to-implement. It is believed that 911 ongoing work to provide direct TLS connections between a RADIUS 912 client and RADIUS server will provide similar assurances but better 913 deployability. XML security is appropriate for deployments where 914 end-to-end security is required but proxies cannot be removed or 915 where SAML messages need to be verified at a later time or by parties 916 not involved in the authentication exchange. 918 11. IANA Considerations 920 11.1. RADIUS Attributes 922 The authors request that Attribute Types and Attribute Values defined 923 in this document be registered by the Internet Assigned Numbers 924 Authority (IANA) from the RADIUS namespaces as described in the "IANA 925 Considerations" section of [RFC3575], in accordance with BCP 26 926 [RFC5226]. For RADIUS packets, attributes and registries created by 927 this document IANA is requested to place them at 928 http://www.iana.org/assignments/radius-types. 930 In particular, this document defines two new RADIUS attributes, 931 entitled "SAML-Assertion" and "SAML-Message" (see Section 3), with 932 assigned values of 245.TBD1 and 245.TBD2 from the Long Extended Space 933 of [RFC6929]: 935 Type Name Length Meaning 936 -------- -------------- ------ ------------------------------- 937 245.TBD1 SAML-Assertion >=5 Encodes a SAML assertion 938 245.TBD2 SAML-Message >=5 Encodes a SAML protocol message 940 11.2. ABFAB Parameters 942 A new top-level registry is created titled "ABFAB Parameters". 944 In this top-level registry, a sub-registry titled "ABFAB URN 945 Parameters" is created. Registration in this registry is by the IETF 946 review or expert review procedures [RFC5226]. 948 This paragraph gives guidance to designated experts. Registrations 949 in this registry are generally only expected as part of protocols 950 published as RFCs on the IETF stream; other URIs are expected to be 951 better choices for non-IETF work. Expert review is permitted mainly 952 to allow early registration related to specifications under 953 development when the community believes they have reached sufficient 954 maturity. The expert SHOULD evaluate the maturity and stability of 955 such an IETF-stream specification. Experts SHOULD review anything 956 not from the IETF stream for consistency and consensus with current 957 practice. Today such requests would not typically be approved. 959 If a parameter named "paramname" is to be registered in this 960 registry, then its URN will be "urn:ietf:params:abfab:paramname". 961 The initial registrations are as follows: 963 +-------------------------+-----------+ 964 | Parameter | Reference | 965 +-------------------------+-----------+ 966 | bindings:radius | Section 4 | 967 | nameid-format:nai | Section 5 | 968 | profiles:authentication | Section 6 | 969 | profiles:query | Section 7 | 970 | cm:user | Section 8 | 971 | cm:machine | Section 8 | 972 +-------------------------+-----------+ 974 ABFAB Parameters 976 11.3. Registration of the ABFAB URN Namespace 978 IANA is requested to register the "abfab" URN sub-namespace in the 979 IETF URN sub-namespace for protocol parameters defined in [RFC3553]. 981 Registry Name: abfab 983 Specification: draft-ietf-abfab-aaa-saml 985 Repository: ABFAB URN Parameters (Section Section 11.2) 986 Index Value: Sub-parameters MUST be specified in UTF-8 using standard 987 URI encoding where necessary. 989 12. Acknowledgements 991 The authors would like to acknowledge the OASIS Security Services 992 (SAML) Technical Committee, and Scott Cantor in particular, for their 993 help with the SAML-related material. 995 The authors would also like to acknowledge the collaboration of Jim 996 Schaad, Leif Johansson, Klaas Wierenga, Stephen Farell, Gabriel 997 Lopez, and Rafael Marin, who have provided valuable comments on this 998 document. 1000 13. References 1002 13.1. Normative References 1004 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1005 Requirement Levels", BCP 14, RFC 2119, March 1997. 1007 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 1008 "Remote Authentication Dial In User Service (RADIUS)", RFC 1009 2865, June 2000. 1011 [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication 1012 Dial In User Service) Support For Extensible 1013 Authentication Protocol (EAP)", RFC 3579, September 2003. 1015 [RFC6614] Winter, S., McCauley, M., Venaas, S., and K. Wierenga, 1016 "Transport Layer Security (TLS) Encryption for RADIUS", 1017 RFC 6614, May 2012. 1019 [RFC6929] DeKok, A. and A. Lior, "Remote Authentication Dial In User 1020 Service (RADIUS) Protocol Extensions", RFC 6929, April 1021 2013. 1023 [RFC3575] Aboba, B., "IANA Considerations for RADIUS (Remote 1024 Authentication Dial In User Service)", RFC 3575, July 1025 2003. 1027 [I-D.ietf-radext-nai] 1028 DeKok, A., "The Network Access Identifier", draft-ietf- 1029 radext-nai-15 (work in progress), December 2014. 1031 [OASIS.saml-bindings-2.0-os] 1032 Cantor, S., Hirsch, F., Kemp, J., Philpott, R., and E. 1033 Maler, "Bindings for the OASIS Security Assertion Markup 1034 Language (SAML) V2.0", OASIS Standard saml-bindings- 1035 2.0-os, March 2005. 1037 [OASIS.saml-core-2.0-os] 1038 Cantor, S., Kemp, J., Philpott, R., and E. Maler, 1039 "Assertions and Protocol for the OASIS Security Assertion 1040 Markup Language (SAML) V2.0", OASIS Standard saml-core- 1041 2.0-os, March 2005. 1043 [OASIS.saml-profiles-2.0-os] 1044 Hughes, J., Cantor, S., Hodges, J., Hirsch, F., Mishra, 1045 P., Philpott, R., and E. Maler, "Profiles for the OASIS 1046 Security Assertion Markup Language (SAML) V2.0", OASIS 1047 Standard OASIS.saml-profiles-2.0-os, March 2005. 1049 [OASIS.saml-metadata-2.0-os] 1050 Cantor, S., Moreh, J., Philpott, R., and E. Maler, 1051 "Metadata for the Security Assertion Markup Language 1052 (SAML) V2.0", OASIS Standard saml-metadata-2.0-os, March 1053 2005. 1055 13.2. Informative References 1057 [RFC3553] Mealling, M., Masinter, L., Hardie, T., and G. Klyne, "An 1058 IETF URN Sub-namespace for Registered Protocol 1059 Parameters", BCP 73, RFC 3553, June 2003. 1061 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 1062 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 1064 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1065 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1066 May 2008. 1068 [I-D.ietf-radext-radius-fragmentation] 1069 Perez-Mendez, A., Lopez, R., Pereniguez-Garcia, F., Lopez- 1070 Millan, G., Lopez, D., and A. DeKok, "Support of 1071 fragmentation of RADIUS packets", draft-ietf-radext- 1072 radius-fragmentation-12 (work in progress), January 2015. 1074 [I-D.jones-diameter-abfab] 1075 Jones, M. and H. Tschofenig, "The Diameter 'Application 1076 Bridging for Federated Access Beyond Web (ABFAB)' 1077 Application", draft-jones-diameter-abfab-01 (work in 1078 progress), March 2012. 1080 [I-D.ietf-abfab-arch] 1081 Howlett, J., Hartman, S., Tschofenig, H., Lear, E., and J. 1082 Schaad, "Application Bridging for Federated Access Beyond 1083 Web (ABFAB) Architecture", draft-ietf-abfab-arch-13 (work 1084 in progress), July 2014. 1086 [I-D.ietf-radext-bigger-packets] 1087 Hartman, S., "Larger Packets for RADIUS over TCP", draft- 1088 ietf-radext-bigger-packets-01 (work in progress), July 1089 2014. 1091 Authors' Addresses 1093 Josh Howlett 1094 Janet 1095 Lumen House, Library Avenue, Harwell 1096 Oxford OX11 0SG 1097 UK 1099 Phone: +44 1235 822363 1100 EMail: Josh.Howlett@ja.net 1102 Sam Hartman 1103 Painless Security 1105 EMail: hartmans-ietf@mit.edu 1107 Alejandro Perez-Mendez (editor) 1108 University of Murcia 1109 Campus de Espinardo S/N, Faculty of Computer Science 1110 Murcia 30100 1111 Spain 1113 Phone: +34 868 88 46 44 1114 EMail: alex@um.es