idnits 2.17.1 draft-ietf-abfab-aaa-saml-09.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 14, 2014) is 3696 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC3575' is defined on line 1004, but no explicit reference was found in the text == Outdated reference: A later version (-15) exists of draft-ietf-radext-nai-03 -- Obsolete informational reference (is this intentional?): RFC 3588 (Obsoleted by RFC 6733) -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) -- No information found for draft-perez-radext-radius-fragmentation - is the name correct? == 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 == Outdated reference: A later version (-13) exists of draft-ietf-radext-dtls-05 == Outdated reference: A later version (-10) exists of draft-ietf-emu-eap-tunnel-method-06 Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 4 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 18, 2014 Painless Security 6 February 14, 2014 8 A RADIUS Attribute, Binding, Profiles, Name Identifier Format, and 9 Confirmation Methods for SAML 10 draft-ietf-abfab-aaa-saml-09 12 Abstract 14 This document describes the use of the Security Assertion Mark-up 15 Language (SAML) with RADIUS in the context of the ABFAB architecture. 16 It defines two RADIUS attributes, a SAML binding, a SAML name 17 identifier format, two SAML profiles, and two SAML confirmation 18 methods. The RADIUS attributes permit encapsulation of SAML 19 assertions and protocol messages within RADIUS, allowing SAML 20 entities to communicate using the binding. The two profiles describe 21 the application of this binding for ABFAB authentication and 22 assertion query/request, enabling a Relying Party to request 23 authentication of, or assertions for, user or machine principals. 24 These principals may be named using an NAI name identifier format. 25 Finally, the subject confirmation methods allow requests and queries 26 to be issued for a previously authenticated user or machine without 27 needing to explicitly identify them as the subject. These artifacts 28 have been defined to permit application in AAA scenarios other than 29 ABFAB, such as network access. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on August 18, 2014. 48 Copyright Notice 49 Copyright (c) 2014 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. TODO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 3. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 5 67 4. RADIUS SAML Attributes . . . . . . . . . . . . . . . . . . . . 5 68 5. SAML RADIUS Binding . . . . . . . . . . . . . . . . . . . . . 6 69 5.1. Required Information . . . . . . . . . . . . . . . . . . . 6 70 5.2. Operation . . . . . . . . . . . . . . . . . . . . . . . . 6 71 5.3. Processing of names . . . . . . . . . . . . . . . . . . . 7 72 5.3.1. AAA names . . . . . . . . . . . . . . . . . . . . . . 8 73 5.3.2. SAML names . . . . . . . . . . . . . . . . . . . . . . 8 74 5.3.3. Use of XML Signatures . . . . . . . . . . . . . . . . 8 75 5.3.4. Metadata Considerations . . . . . . . . . . . . . . . 9 76 6. Network Access Identifier Name Identifier Format . . . . . . . 9 77 7. ABFAB Authentication Profile . . . . . . . . . . . . . . . . . 9 78 7.1. Required Information . . . . . . . . . . . . . . . . . . . 9 79 7.2. Profile Overview . . . . . . . . . . . . . . . . . . . . . 10 80 7.3. Profile Description . . . . . . . . . . . . . . . . . . . 12 81 7.3.1. User Agent Request to Relying Party . . . . . . . . . 12 82 7.3.2. Relying Party Issues to 83 Identity Provider . . . . . . . . . . . . . . . . . . 12 84 7.3.3. Identity Provider Identifies Principal . . . . . . . . 12 85 7.3.4. Identity Provider Issues to 86 Relying Party . . . . . . . . . . . . . . . . . . . . 13 87 7.3.5. Relying Party Grants or Denies Access to Principal . . 13 88 7.4. Use of Authentication Request Protocol . . . . . . . . . . 13 89 7.4.1. Usage . . . . . . . . . . . . . . 13 90 7.4.2. Usage . . . . . . . . . . . . 14 91 7.4.3. Processing Rules . . . . . . 14 92 7.4.4. Unsolicited Responses . . . . . . . . . . . . . . . . 15 93 7.4.5. Use of the SAML RADIUS Binding . . . . . . . . . . . . 15 94 7.4.6. Use of XML Signatures . . . . . . . . . . . . . . . . 15 95 7.4.7. Metadata Considerations . . . . . . . . . . . . . . . 15 96 8. ABFAB Assertion Query/Request Profile . . . . . . . . . . . . 15 97 8.1. Required Information . . . . . . . . . . . . . . . . . . . 16 98 8.2. Profile Overview . . . . . . . . . . . . . . . . . . . . . 16 99 8.3. Profile Description . . . . . . . . . . . . . . . . . . . 17 100 8.3.1. Differences from the SAML V2.0 Assertion 101 Query/Request Profile . . . . . . . . . . . . . . . . 17 102 8.3.2. Use of the SAML RADIUS Binding . . . . . . . . . . . . 17 103 8.3.3. Use of XML Signatures . . . . . . . . . . . . . . . . 18 104 8.3.4. Metadata Considerations . . . . . . . . . . . . . . . 18 105 9. RADIUS State Confirmation Methods . . . . . . . . . . . . . . 18 106 10. Privacy considerations . . . . . . . . . . . . . . . . . . . . 18 107 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 108 12. Security Considerations . . . . . . . . . . . . . . . . . . . 19 109 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 110 13.1. RADIUS Attributes . . . . . . . . . . . . . . . . . . . . 20 111 13.2. ABFAB Parameters . . . . . . . . . . . . . . . . . . . . . 20 112 13.3. Registration of the ABFAB URN Namespace . . . . . . . . . 21 113 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 114 14.1. Normative References . . . . . . . . . . . . . . . . . . . 21 115 14.2. Informative References . . . . . . . . . . . . . . . . . . 22 117 1. TODO 119 o Clean up use of terminology (e.g., "principal") to ensure 120 consistency with other ABFAB docs. 122 o Complete the Acknowledgements and Security and Privacy 123 Considerations sections. 125 2. Introduction 127 Within the ABFAB architecture [I-D.ietf-abfab-arch] it is often 128 desirable to convey Security Assertion Mark-up Language (SAML) 129 asertions and protocol messages. 131 SAML typically only considers the use of HTTP-based transports, known 132 as bindings [OASIS.saml-bindings-2.0-os], which are primarily 133 intended for use with the SAML V2.0 Web Browser Single Sign-On 134 Profile [OASIS.saml-profiles-2.0-os]. However the goal of ABFAB is 135 to extend the applicability of federated identity beyond the Web to 136 other applications by building on the AAA framework. Consequently 137 there exists a requirement for SAML to integrate with the AAA 138 framework and protocols such as RADIUS [RFC2865] and Diameter 139 [RFC3588], in addition to HTTP. 141 A companion specification [I-D.jones-diameter-abfab] specifies 142 equivalent funtionality for Diameter. 144 In summary this document specifies: 146 o Two RADIUS attributes to encapsulate SAML assertions and protocol 147 messages respectively. 149 o A SAML RADIUS binding that defines how SAML assertions and 150 protocol messages can be transported by RADIUS within a SAML 151 exchange. 153 o A profile of the SAML Authentication Request Protocol that uses 154 the SAML RADIUS binding to effect SAML-based authentication and 155 authorization. 157 o A profile of the SAML Assertion Query And Request Protocol that 158 uses the SAML RADIUS binding to effect the query and request of 159 SAML assertions. 161 o Two SAML Subject Confirmation Methods for indicating that a user 162 or machine principal is the subject of an assertion. 164 This document aspires to the guidelines stipulated by 166 [OASIS.saml-bindings-2.0-os] and [OASIS.saml-profiles-2.0-os] for 167 defining new SAML bindings and profiles respectively, and other 168 conventions applied formally or otherwise within SAML. In particular 169 where this document provides a 'Required Information' section for the 170 binding and profiles that enumerate: 172 o A URI that uniquely identifies the protocol binding or profile 174 o Postal or electronic contact information for the author 176 o A reference to previously defined bindings or profiles that the 177 new binding updates or obsoletes 179 o In the case of a profile, any SAML confirmation method identifiers 180 defined and/or utilized by the profile 182 3. Conventions 184 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 185 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 186 document are to be interpreted as described in RFC 2119 [RFC2119]. 188 4. RADIUS SAML Attributes 190 The RADIUS SAML binding defined by this binding Section 5 uses two 191 attributes to convey SAML assertions and protocol messages 192 respectively [OASIS.saml-core-2.0-os] . Owing to the typical size of 193 these structures, these attributes use the Long Extended Type format 194 [RFC6929] to encapsulate their data. The table below defines these 195 attributes. The Length of both of these attributes is >=5. The More 196 and Reserved fields are handled as described in [RFC6929] and are not 197 depicted in this table for simplicity. 199 +----------------+------+---------------+---------------------------+ 200 | Name | Type | Extended-Type | Value | 201 +----------------+------+---------------+---------------------------+ 202 | SAML-Assertion | TBD | TBD | One or more octets | 203 | | | | encoding a SAML assertion | 204 | SAML-Message | TBD | TBD | One or more octets | 205 | | | | encoding a SAML protocol | 206 | | | | message | 207 +----------------+------+---------------+---------------------------+ 209 Table 1: RADIUS SAML attribute definitions 211 5. SAML RADIUS Binding 213 The SAML RADIUS binding defines how RADIUS [RFC2865] can be used to 214 enable a RADIUS client and server to exchange SAML assertions and 215 protocol messages. 217 5.1. Required Information 219 Identification: urn:ietf:params:abfab:bindings:radius 221 Contact information: iesg@ietf.org 223 Updates: None. 225 5.2. Operation 227 RADIUS can be used over multiple underlying transports; this binding 228 calls out for the use of Transport Layer Security (TLS) Encryption 229 for RADIUS [RFC6614] as REQUIRED to provide interoperability, 230 confidentiality, improve integrity protection and support the use of 231 longer SAML messages. 233 Implementations of this profile can take advantage of other 234 mechanisms such as RADIUS packet fragmentation 235 [I-D.perez-radext-radius-fragmentation] to permit transport of longer 236 SAML messages over UDP-based RADIUS transports, such as those 237 described in [RFC2865] and [I-D.ietf-radext-dtls]. Support for 238 fragmentation over UDP is not mandatory. 240 There are two system models for the use of SAML over RADIUS. The 241 first is a request-response model, using the RADIUS SAML-Message 242 attribute defined in Section 4 to encapsulate the SAML protocol 243 messages. 245 1. The RADIUS client, acting as a SAML requester, transmits a SAML 246 request element within a RADIUS Access-Request message. This 247 message MUST include a single instance of the RADIUS User-Name 248 attribute whose value MUST conform to the Network Access 249 Identifier [I-D.ietf-radext-nai] scheme. The SAML requester MUST 250 NOT include more than one SAML request element. 252 2. The RADIUS server, acting as a SAML responder, returns a SAML 253 protocol message within a RADIUS Access-Accept or Access-Reject 254 message. These messages necessarily conclude a RADIUS exchange 255 and therefore this is the only opportunity for the SAML responder 256 to send a response in the context of this exchange. The SAML 257 responder MUST NOT include more than one SAML response. A SAML 258 responder that refuses to perform a message exchange with the 259 SAML requester can silently discard the SAML request (this could 260 subsequently be followed by a RADIUS Access-Reject, as the same 261 conditions that cause the SAML responder to discard the SAML 262 request may also cause the RADIUS server to fail to 263 authenticate). 265 The second system model permits a RADIUS server acting as a SAML 266 responder to use the RADIUS SAML-Assertion attribute defined in 267 Section 4 to encapsulate an unsolicited, unencrypted SAML assertion. 268 This attribute MAY be included in a RADIUS Access-Accept message. 269 When included, the attribute MUST contain a single SAML assertion. 271 RADIUS servers MUST NOT include both the SAML-Message and the SAML- 272 Assertion attribute in the same RADIUS message. If a SAML responder 273 is producing a response to a SAML request, then the first system 274 model is used. A SAML responder MAY ignore a SAML request and send 275 an unsolicited assertion using the second system model using the 276 RADIUS SAML-Assertion attribute. 278 In either system model, SAML responders SHOULD return a RADIUS state 279 attribute as part of the Access-Accept message so that future SAML 280 queries or requests can be run against the same context of an 281 authentication exchange. 283 This binding is intended to be composed with other uses of RADIUS, 284 such as network access. Therefore, other arbitrary RADIUS attributes 285 MAY be used in either the request or response. 287 In the case of a SAML processing error and successful authentication, 288 the RADIUS server SHOULD include a SAML-specified 289 element in the SAML response that is transported within the Access- 290 Accept packet sent by the RADIUS server. 292 In the case of a SAML processing error and failed authentication, the 293 RADIUS server MAY include a SAML-specified element in 294 the SAML response that is transported within the Access-Reject packet 295 sent by the RADIUS server. 297 5.3. Processing of names 299 SAML entities using profiles of this binding will typically possess 300 both the SAML and AAA names of their correspondents. Frequently 301 these entities will need to apply policy using these names; for 302 example, when deciding to release attributes. Often these policies 303 will be security-sensitive, and so it is important that policy is 304 applied on these names consistently. 306 5.3.1. AAA names 308 These rules relate to the processing of AAA names by SAML entities 309 using profiles of this binding. 311 o SAML responders SHOULD apply policy based on the NAS identity 312 associated with the RADIUS Access-Request. 314 o SAML requesters SHOULD apply policy based on the NAI realm 315 associated with the RADIUS Access-Accept. 317 5.3.2. SAML names 319 These rules relate to the processing of SAML names by SAML entities 320 using profiles of this binding. 322 SAML issuers MAY apply policy based on the requester's 323 after validating that the request comes from the NAS. The following 324 methods are sufficient: 326 o NAS identity in trusted digitally signed request. 328 o NAS identity in trusted SAML federation metadata. 330 A digitally signed request alone is not sufficient. A RADIUS entity 331 can observe a SAML message and include it in a RADIUS message without 332 the consent of the issuer of that SAML message. If a SAML consumer 333 were to process the SAML message without confirming that it applied 334 to the RADIUS message, inappropriate policy would be used. 336 SAML consumers MAY apply policy based on the SAML issuer's 337 after validating that the response comes from the RADIUS server. The 338 following methods are sufficient: 340 o RADIUS realm in trusted digitally signed request. 342 o RADIUS realm in trusted SAML federation metadata. 344 A digitally signed request alone is not sufficient. 346 5.3.3. Use of XML Signatures 348 This bindings calls for the use of SAML elements that support XML 349 signatures. To promote interoperability implementations of this 350 binding MUST support a default configuration that does not require 351 the use of XML signatures. Implementations MAY choose to use XML 352 signatures, but this usage is outside of the scope of this binding. 354 5.3.4. Metadata Considerations 356 There are no metadata considerations particular to this binding, 357 because this binding and profiles of this binding are intended to be 358 used without metadata. In this usage, RADIUS infrastructure is used 359 to provide integrity and naming. RADIUS configuration is used to 360 provide policy including which attributes are accepted from a SAML 361 responder and which attributes are sent by a SAML responder. 363 Implementations MAY support other configurations including the use of 364 metadata. 366 6. Network Access Identifier Name Identifier Format 368 URI: urn:ietf:params:abfab:nameid-format:nai 370 Indicates that the content of the element is in the form of a Network 371 Access Identifier (NAI) using the syntax described by 372 [I-D.ietf-radext-nai]. 374 7. ABFAB Authentication Profile 376 In the scenario supported by the ABFAB Authentication Profile, a 377 Principal controlling a User Agent requests access to a Relying 378 Party. The User Agent and Relying Party uses RADIUS to authenticate 379 the Principal. The Relying Party, acting as a NAS, attempts to 380 validate the Principal's credentials against a RADIUS server acting 381 the Principal's Identity Provider. If the Identity Provider 382 successfully authenticates the Principal, it produces an 383 authentication assertion which is consumed by the Relying Party. 384 During this process, a name identifier might also be established 385 between the Relying Party and the Identity Provider. 387 7.1. Required Information 389 Identification: urn:ietf:params:abfab:profiles:authentication 391 Contact information: iesg@ietf.org 393 SAML Confirmation Method Identifiers: The SAML V2.0 "sender vouches" 394 confirmation method identifier, 395 urn:oasis:names:tc:SAML:2.0:cm:sender-vouches, is used by this 396 profile. 398 Updates: None. 400 7.2. Profile Overview 402 To implement this scenario a profile of the SAML Authentication 403 Request protocol is used in conjuction with the SAML RADIUS binding 404 defined in Section 5. 406 This profile is based on the SAML V2.0 Web Browser Single Sign-On 407 Profile [OASIS.saml-profiles-2.0-os]. There are some important 408 differences, specifically: 410 Authentication: This profile does not require the use of any 411 particular authentication method. The ABFAB architecture does 412 require the use of EAP [RFC3579], but this specification may be 413 used in other non-ABFAB scenarios. 415 Bindings: This profile does not require the use of HTTP-based 416 bindings. Instead all SAML protocol messages are transported 417 using the SAML RADIUS binding defined in Section 5. This is 418 intended to reduce the number of bindings that implementations 419 must support to be interoperable. 421 Requests: The profile does not permit the Relying Party to name the 422 of the . This is intended to 423 simplify implementation and interoperability. 425 Responses: The profile only permits the Identity Provider to return 426 a single assertion that must contain exactly one authentication 427 statement. Other statements may be included within this assertion 428 at the discretion of the Identity Provider. This is intended to 429 simplify implementation and interoperability. 431 Figure 1 below illustrates the flow of messages within this profile. 433 User Agent Relying Party Identity Provider 434 | | | 435 | (1) | | 436 | - - - - - - - - - > | | 437 | | | 438 | | (2) | 439 | | - - - - - - - - - - - - > | 440 | | | 441 | (3) | | 442 | < - - - - - - - - - |- - - - - - - - - - - - -> | 443 | | | 444 | | (4) | 445 | | < - - - - - - - - - - - - | 446 | | | 447 | (5) | | 448 | < - - - - - - - - - | | 449 | | | 450 V V V 452 The following steps are described by the profile. Within an 453 individual step, there may be one or more actual message exchanges. 455 Figure 1 457 1. User Agent Request to Relying Party (Section 7.3.1): In step 1, 458 the Principal, via a User Agent, makes a request for a secured 459 resource at the Relying Party. The Relying Party determines that 460 no security context for the User Agent exists and initiates 461 authentication of the Principal. 463 2. Relying Party Issues to Identity Provider 464 (Section 7.3.2). In step 2, the Relying Party may optionally 465 issue a message to be delivered to the 466 Identity Provider using the SAML RADIUS binding. 468 3. Identity Provider Identifies Principal (Section 7.3.3). In step 469 3, the Principal is authenticated and identified by the Identity 470 Provider, while honoring any requirements imposed by the Relying 471 Party in the message if provided. 473 4. Identity Provider Issues to Relying Party 474 (Section 7.3.4). In step 4, the Identity Provider issues a 475 message to the Relying Party using the SAML 476 RADIUS binding. The response either indicates an error or 477 includes an authentication statement in exactly one assertion. 479 5. Relying Party Grants or Denies Access to Principal 480 (Section 7.3.5). In step 5, having received the response from 481 the Identity Provider, the Relying Party can respond to the 482 Principal's User Agent with its own error, or can establish its 483 own security context for the Principal and return the requested 484 resource. 486 7.3. Profile Description 488 The ABFAB Authentication Profile is a profile of the SAML V2.0 489 Authentication Request Protocol [OASIS.saml-core-2.0-os]. Where this 490 specification conflicts with Core, the former takes precedence. 492 7.3.1. User Agent Request to Relying Party 494 The profile is initiated by an arbitrary User Agent request to the 495 Relying Party. There are no restrictions on the form of the request. 496 The Relying Party is free to use any means it wishes to associate the 497 subsequent interactions with the original request. The Relying 498 Party, acting as a NAS, attempts to authenticate the User Agent. 500 7.3.2. Relying Party Issues to Identity Provider 502 The Relying Party uses RADIUS to communicate with the Principal's 503 Identity Provider. The Relying Party MAY include a within this RADIUS Access-Request message using the 505 SAML RADIUS binding. The next hop destination MAY be the Identity 506 Provider or alternatively an intermediate RADIUS proxy. 508 Profile-specific rules for the contents of the 509 element are given in Section 7.4.1. 511 7.3.3. Identity Provider Identifies Principal 513 The Identity Provider MUST establish the identity of the Principal 514 using RADIUS authentication, or else it will return an error. If the 515 ForceAuthn attribute on the element (if sent by 516 the requester) is present and true, the Identity Provider MUST 517 freshly establish this identity rather than relying on any existing 518 session state it may have with the Principal (for example, TLS state 519 that may be used for session resumption). Otherwise, and in all 520 other respects, the Identity Provider may use any method to 521 authenticate the Principal, subject to the constraints called out in 522 the message. 524 7.3.4. Identity Provider Issues to Relying Party 526 The Identity Provider MUST conclude the authentication in a manner 527 consistent with the RADIUS authentication result, and MAY issue a 528 message to the Relying Party consisent with the 529 authentication result and as described in [OASIS.saml-core-2.0-os] 530 and delivered to the Relying Party using the SAML RADIUS binding. 532 Profile-specific rules regarding the contents of the 533 element are given in Section 7.4.2. 535 7.3.5. Relying Party Grants or Denies Access to Principal 537 If issued by the Identity Provider, the Relying Party MUST process 538 the message and any enclosed 539 elements as described in [OASIS.saml-core-2.0-os]. Any subsequent 540 use of the elements is at the discretion of the 541 Relying Party, subject to any restrictions on use contained within 542 the assertions themselves or previously established out-of-band 543 policy governing interactions between the Identity Provider and the 544 Relying Party. 546 7.4. Use of Authentication Request Protocol 548 This profile is based on the Authentication Request Protocol defined 549 in [OASIS.saml-core-2.0-os]. In the nomenclature of actors 550 enumerated in section 3.4, the Relying Party is the requester, the 551 User Agent is the attesting entity and the Principal is the Requested 552 Subject. 554 7.4.1. Usage 556 The Relying Party MUST NOT include a element in the 557 request. The authenticated RADIUS user identifies the principal to 558 the Identity Provider. 560 A Relying Party MAY include any message content described in 561 [OASIS.saml-core-2.0-os], section 3.4.1. All processing rules are as 562 defined in [OASIS.saml-core-2.0-os]. 564 If the Relying Party wishes to permit the Identity Provider to 565 establish a new identifier for the principal if none exists, it MUST 566 include a element with the AllowCreate attribute 567 set to "true". Otherwise, only a principal for whom the Identity 568 Provider has previously established an identifier usable by the 569 Relying Party can be authenticated successfully. 571 The message MAY be signed. Authentication and 572 integrity are also provided by the RADIUS SAML binding. 574 7.4.2. Usage 576 If the Identity Provider cannot or will not satisfy the request, it 577 MAY respond with a message containing an appropriate 578 error status code or codes. 580 If the Identity Provider wishes to return an error, it MUST NOT 581 include any assertions in the . Otherwise, 582 if the request is successful (or if the response is not associated 583 with a request), the element MUST conform to the 584 following: 586 o It MAY be signed. 588 o It MUST contain exactly one . The 589 element of this assertion MUST refer to the authenticated RADIUS 590 user. 592 o The assertion MUST contain a . This MUST 593 contain a element with at least one element containing a Method of 595 urn:oasis:names:tc:SAML:2.0:cm:sender-vouches that reflects the 596 authentication of the Principal to the Identity Provider. If the 597 containing message is in response to an , then 598 the InResponseTo attribute MUST match the request's ID. 600 o Other conditions MAY be included as requested by the Relying Party 601 or at the discretion of the Identity Provider. The Identity 602 Provider is NOT obligated to honor the requested set of conditions 603 in the , if any. 605 7.4.3. Processing Rules 607 The Relying Party MUST do the following: 609 o Assume that the principal implied by a SAML element, if 610 present, takes precedence over a principal implied by the RADIUS 611 User-Name attribute. 613 o Verify that the InResponseTo attribute in the sender-vouches 614 equals the ID of its original 615 message, unless the response is unsolicited, 616 in which case the attribute MUST NOT be present. 618 o If a used to establish a security context 619 for the Principal contains a SessionNotOnOrAfter attribute, the 620 security context SHOULD be discarded once this time is reached, 621 unless the service provider reestablishes the Principal's identity 622 by repeating the use of this profile. 624 o Verify that any assertions relied upon are valid according to 625 processing rules in [OASIS.saml-core-2.0-os]. 627 o Any assertion which is not valid, or whose subject confirmation 628 requirements cannot be met MUST be discarded and MUST NOT be used 629 to establish a security context for the Principal. 631 7.4.4. Unsolicited Responses 633 An Identity Provider MAY initiate this profile by delivering an 634 unsolicited to a Relying Party. This MUST NOT 635 contain any sender-vouches elements 636 containing an InResponseTo attribute. 638 7.4.5. Use of the SAML RADIUS Binding 640 It is RECOMMENDED that the RADIUS exchange is protected using TLS 641 encryption for RADIUS [RFC6614] to provide confidentiality and 642 improve integrity protection. 644 7.4.6. Use of XML Signatures 646 This profile calls for the use of SAML elements that support XML 647 signatures. To promote interoperability implementations of this 648 profile MUST NOT require the use of XML signatures. Implementations 649 MAY choose to use XML signatures, but this usage is outside of the 650 scope of this profile. 652 7.4.7. Metadata Considerations 654 There are no metadata considerations particular to this binding. 656 8. ABFAB Assertion Query/Request Profile 658 This profile builds on the SAML V2.0 Assertion Query/Request Profile 659 defined by [OASIS.saml-profiles-2.0-os]. That profile describes the 660 use of the Assertion Query and Request Protocol defined by section 661 3.3 of [OASIS.saml-core-2.0-os] with synchronous bindings, such as 662 the SOAP binding defined in [OASIS.saml-bindings-2.0-os] or the SAML 663 RADIUS binding defined elsewhere in this document. 665 While the SAML V2.0 Assertion Query/Request Profile is independent of 666 the underlying binding, it is nonetheless useful to describe the use 667 of this profile with the SAML RADIUS binding in the interests of 668 promoting interoperable implementations, particularly as the SAML 669 V2.0 Assertion Query/Request Profile is most frequently discussed and 670 implemented in the context of the SOAP binding. 672 8.1. Required Information 674 Identification: urn:ietf:params:abfab:profiles:query 676 Contact information: iesg@ietf.org 678 Description: Given below. 680 Updates: None. 682 8.2. Profile Overview 684 As with the SAML V2.0 Assertion Query/Request Profile defined by 685 [OASIS.saml-profiles-2.0-os] the message exchange and basic 686 processing rules that govern this profile are largely defined by 687 Section 3.3 of [OASIS.saml-core-2.0-os] that defines the messages to 688 be exchanged, in combination with the binding used to exchange the 689 messages. The SAML RADIUS binding described in this document defines 690 the binding of the message exchange to RADIUS. Unless specifically 691 noted here, all requirements defined in those specifications apply. 693 Figure 2 below illustrates the basic template for the query/request 694 profile. 696 SAML Requester SAML Authority 697 | | 698 | (1) | 699 | - - - - - - - - - - - - - - - - - - - - - - - > | 700 | | 701 | (2) | 702 | < - - - - - - - - - - - - - - - - - - - - - - - | 703 | | 704 | | 705 V V 707 The following steps are described by the profile. 709 Figure 2 711 1. Query/Request issued by SAML Requester: In step 1, a SAML 712 requester initiates the profile by sending an 713 , , , 714 , or message to a SAML 715 authority. 717 2. issued by SAML Authority: In step 2, the responding 718 SAML authority (after processing the query or request) issues a 719 message to the SAML requester. 721 8.3. Profile Description 723 8.3.1. Differences from the SAML V2.0 Assertion Query/Request Profile 725 This profile is identical to the SAML V2.0 Assertion Query/Request 726 Profile, with the following exceptions: 728 o When processing the SAML request, the SAML responder MUST give 729 precedence to the principal implied by RADIUS State attribute, if 730 present, over the principal implied by the SAML request's 731 , if any. 733 o In respect to section 6.3.1 and 6.5, this profile does not 734 consider the use of metadata (as in [OASIS.saml-metadata-2.0-os]); 735 see Section 8.3.4. 737 o In respect to sections 6.3.2, 6.4.1 and 6.4.2, this profile 738 additionally stipulates that implementations of this profile MUST 739 NOT require the use of XML signatures; see Section 8.3.3. 741 8.3.2. Use of the SAML RADIUS Binding 743 The RADIUS Access-Request sent by the SAML requester: 745 o MUST use a RADIUS User-Name attribute whose value is "@REALM", 746 where REALM is the destination NAI realm. 748 o MUST include an instance of the RADIUS Service-Type attribute, 749 having a value of Authorize-Only. 751 o SHOULD include the RADIUS State attribute, where this Query/ 752 Request pertains to previously authenticated principal. 754 When processing the SAML request, the SAML responder MUST give 755 precedence to the principal implied by RADIUS State attribute over 756 the principal implied by the SAML request's , if any. 758 It is RECOMMENDED that the RADIUS exchange is protected using TLS 759 encryption for RADIUS [RFC6614] to provide confidentiality and 760 improve integrity protection. 762 8.3.3. Use of XML Signatures 764 This profile calls for the use of SAML elements that support XML 765 signatures. To promote interoperability implementations of this 766 profile MUST NOT require the use of XML signatures. Implementations 767 MAY choose to use XML signatures, but this usage is outside of the 768 scope of this profile. 770 8.3.4. Metadata Considerations 772 There are no metadata considerations particular to this binding. 774 9. RADIUS State Confirmation Methods 776 URI: urn:ietf:params:abfab:cm:user 778 URI: urn:ietf:params:abfab:cm:machine 780 The RADIUS State Confirmation Methods indicate that the Subject is 781 the system entity (either the user or machine) authenticated by a 782 previously transmitted RADIUS Access-Accept message, as identified by 783 the value of that RADIUS message's State attribute, in the sense of 784 [I-D.ietf-emu-eap-tunnel-method]. 786 10. Privacy considerations 788 The profiles defined in this document allow a SAML requester to 789 request specific information about the principal and allow a SAML 790 responder to disclose information about a requester. Responders MUST 791 apply policy to decide what information is released. The SAML 792 requester does not typically know the identity of the principal 793 unless informed by the SAML responder or RADIUS server. The SAML 794 requester does typically know the realm of the IDP. Information that 795 is released MAY include generic attributes such as affiliation shared 796 by many principals. Even these generic attributes can help to 797 identify a specific principal. Other attributes MAY provide a SAML 798 requester with the ability to link the same principals between 799 sessions with the same SAML requester. Other attributes MAY provide 800 the requester with the ability to link the principal between 801 requesters or with personally identifyable information about the 802 principal. 804 These profiles do not directly provide a principal with a mechanism 805 to express preferences about what information is released. That 806 information can be expressed out-of-band, for example as part of 807 enrollment. 809 The SAML requester MAY disclose privacy-sensitive information about 810 itself as part of the request. This is unlikely in typical 811 deployments. 813 If RADIUS proxies are used, then attributes disclode by the SAML 814 responder are visible to the proxies. This is a significant privacy 815 exposure in some deployments. Ongoing work is exploring mechanisms 816 for creating TLS connections directly between the NAS and the RADIUS 817 server to reduce this exposure. If proxies are used, the impact of 818 exposing SAML assertions to the proxies needs to be carefully 819 considered. 821 The use of TLS to provide confidentiality for the RADIUS exchange is 822 strongly encouraged. Without this, passive observers can observe the 823 assertions. 825 11. Acknowledgements 827 TODO: Need to acknowledge OASIS SSTC, UoMurcia, Scott, Jim, and 828 Steven. 830 12. Security Considerations 832 TODO: Elaborate on the following 834 The RADIUS server vouches for its SAML messages. The NAS trusts any 835 statement in the SAML messages from the RADIUS server in the same way 836 that it trusts information contained in RADIUS attributes. The NAS 837 MUST apply policy and filter the information based on what 838 information the RADIUS server is permitted to assert and on what 839 trust is reasonable to place in proxies between the NAS and RADIUS 840 server. 842 SAML entities' level of trust in the SAML messages that they recieve 843 from other entities should be consistent with the trust it holds in 844 the RADIUS infrastructure. That is SAML entities SHOULD trust RADIUS 845 to authenticate the principal and to reach the right IDP. SAML 846 entities trust the RADIUS infrastructure to provide integrity of the 847 SAML messages. However policy MUST be applied to limit what 848 statements are permitted. 850 XML signatures and encryption are provided as an OPTIONAL mechanism 851 for end-to-end security. These mechanism can protect SAML messages 852 from being modified by proxies in the RADIUS infrastructure. These 853 mechanisms are not mandatory-to-implement. It is believed that 854 ongoing work to provide direct TLS connections between a NAS and 855 RADIUS server will provide similar assurances but better 856 deployability. XML security is appropriate for deployments where 857 end-to-end security is required but proxies cannot be removed or 858 where SAML messages need to be verified at a later time ro by parties 859 not involved in the authentication exchange. 861 13. IANA Considerations 863 13.1. RADIUS Attributes 865 Assignments of additional enumerated values for the RADIUS attribute 866 defined in this document are to be processed as described in 867 [RFC6929], subject to the additional requirements of a published 868 specification. 870 13.2. ABFAB Parameters 872 A new top-level registry is created titled "ABFAB Parameters". 874 In this top-level registry, a sub-registry titled "ABFAB URN 875 Parameters" is created. Registration in this registry is by the IETF 876 review or expert review procedures [RFC5226]. 878 This paragraph gives guidance to designated experts. Registrations 879 in this registry are generally only expected as part of protocols 880 published as RFCs on the IETF stream; other URIs are expected to be 881 better choices for non-IETF work. Expert review is permitted mainly 882 to permit early registration related to specifications under 883 development when the community believes they have reach sufficient 884 maturity. The expert SHOULD evaluate the maturity and stability of 885 such an IETF-stream specification. Experts SHOULD review anything 886 not from the IETF stream for consistency and consensus with current 887 practice. Today such requests would not typically be approved. 889 If the "paramname" parameter is registered in this registry then its 890 URN will be "urn:ietf:params:abfab:paramname". The initial 891 registrations are as follows: 893 +-------------------------+-----------+ 894 | Parameter | Reference | 895 +-------------------------+-----------+ 896 | bindings:radius | Section 5 | 897 | nameid-format:nai | Section 6 | 898 | profiles:authentication | Section 7 | 899 | profiles:query | Section 8 | 900 | cm:user | Section 9 | 901 | cm:machine | Section 9 | 902 +-------------------------+-----------+ 904 ABFAB Parameters 906 13.3. Registration of the ABFAB URN Namespace 908 IANA is requested to register the "abfab" URN sub-namespace in the 909 IETF URN sub-namespace for protocol parameters defined in [RFC3553]. 911 Registry Name: abfab 913 Specification: draft-ietf-abfab-aaa-saml 915 Repository: ABFAB URN Parameters (Section Section 13.2) 917 Index Value: Sub-parameters MUST be specified in UTF-8 using standard 918 URI encoding where necessary. 920 14. References 922 14.1. Normative References 924 [RFC2119] Bradner, S., "Key words for 925 use in RFCs to Indicate 926 Requirement Levels", BCP 14, 927 RFC 2119, March 1997. 929 [RFC2865] Rigney, C., Willens, S., 930 Rubens, A., and W. Simpson, 931 "Remote Authentication Dial 932 In User Service (RADIUS)", 933 RFC 2865, June 2000. 935 [RFC3579] Aboba, B. and P. Calhoun, 936 "RADIUS (Remote 937 Authentication Dial In User 938 Service) Support For 939 Extensible Authentication 940 Protocol (EAP)", RFC 3579, 941 September 2003. 943 [RFC6614] Winter, S., McCauley, M., 944 Venaas, S., and K. Wierenga, 945 "Transport Layer Security 946 (TLS) Encryption for 947 RADIUS", RFC 6614, May 2012. 949 [RFC6929] DeKok, A. and A. Lior, 950 "Remote Authentication Dial 951 In User Service (RADIUS) 952 Protocol Extensions", 953 RFC 6929, April 2013. 955 [I-D.ietf-radext-nai] DeKok, A., "The Network 956 Access Identifier", 957 draft-ietf-radext-nai-03 958 (work in progress), 959 May 2013. 961 [OASIS.saml-bindings-2.0-os] Cantor, S., Hirsch, F., 962 Kemp, J., Philpott, R., and 963 E. Maler, "Bindings for the 964 OASIS Security Assertion 965 Markup Language (SAML) 966 V2.0", OASIS Standard saml- 967 bindings-2.0-os, March 2005. 969 [OASIS.saml-core-2.0-os] Cantor, S., Kemp, J., 970 Philpott, R., and E. Maler, 971 "Assertions and Protocol for 972 the OASIS Security Assertion 973 Markup Language (SAML) 974 V2.0", OASIS Standard saml- 975 core-2.0-os, March 2005. 977 [OASIS.saml-profiles-2.0-os] Hughes, J., Cantor, S., 978 Hodges, J., Hirsch, F., 979 Mishra, P., Philpott, R., 980 and E. Maler, "Profiles for 981 the OASIS Security Assertion 982 Markup Language (SAML) 983 V2.0", OASIS Standard OASIS. 984 saml-profiles-2.0-os, 985 March 2005. 987 [OASIS.saml-metadata-2.0-os] Cantor, S., Moreh, J., 988 Philpott, R., and E. Maler, 989 "Metadata for the Security 990 Assertion Markup Language 991 (SAML) V2.0", OASIS Standard 992 saml-metadata-2.0-os, 993 March 2005. 995 14.2. Informative References 997 [RFC3553] Mealling, M., Masinter, L., 998 Hardie, T., and G. Klyne, 999 "An IETF URN Sub-namespace 1000 for Registered Protocol 1001 Parameters", BCP 73, 1002 RFC 3553, June 2003. 1004 [RFC3575] Aboba, B., "IANA 1005 Considerations for RADIUS 1006 (Remote Authentication Dial 1007 In User Service)", RFC 3575, 1008 July 2003. 1010 [RFC3588] Calhoun, P., Loughney, J., 1011 Guttman, E., Zorn, G., and 1012 J. Arkko, "Diameter Base 1013 Protocol", RFC 3588, 1014 September 2003. 1016 [RFC5226] Narten, T. and H. 1017 Alvestrand, "Guidelines for 1018 Writing an IANA 1019 Considerations Section in 1020 RFCs", BCP 26, RFC 5226, 1021 May 2008. 1023 [I-D.perez-radext-radius-fragmentation] Perez-Mendez, A., Lopez, R., 1024 Pereniguez-Garcia, F., 1025 Lopez-Millan, G., Lopez, D., 1026 and A. DeKok, "Support of 1027 fragmentation of RADIUS 1028 packets", draft-perez- 1029 radext-radius-fragmentation- 1030 01 (work in progress), 1031 February 2012. 1033 [I-D.jones-diameter-abfab] Jones, M. and H. Tschofenig, 1034 "The Diameter 'Application 1035 Bridging for Federated 1036 Access Beyond Web (ABFAB)' 1037 Application", draft-jones- 1038 diameter-abfab-00 (work in 1039 progress), March 2011. 1041 [I-D.ietf-abfab-arch] Howlett, J., Hartman, S., 1042 Tschofenig, H., Lear, E., 1043 and J. Schaad, "Application 1044 Bridging for Federated 1045 Access Beyond Web (ABFAB) 1046 Architecture", 1047 draft-ietf-abfab-arch-03 1048 (work in progress), 1049 July 2012. 1051 [I-D.ietf-radext-dtls] DeKok, A., "DTLS as a 1052 Transport Layer for RADIUS", 1053 draft-ietf-radext-dtls-05 1054 (work in progress), 1055 April 2013. 1057 [I-D.ietf-emu-eap-tunnel-method] Zhou, H., Cam-Winget, N., 1058 Salowey, J., and S. Hanna, 1059 "Tunnel EAP Method (TEAP) 1060 Version 1", draft-ietf-emu- 1061 eap-tunnel-method-06 (work 1062 in progress), March 2013. 1064 Authors' Addresses 1066 Josh Howlett 1067 Janet 1068 Lumen House, Library Avenue, Harwell 1069 Oxford OX11 0SG 1070 UK 1072 Phone: +44 1235 822363 1073 EMail: Josh.Howlett@ja.net 1075 Sam Hartman 1076 Painless Security 1078 Phone: 1079 EMail: hartmans-ietf@mit.edu