idnits 2.17.1 draft-ietf-abfab-aaa-saml-12.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 : ---------------------------------------------------------------------------- ** There are 17 instances of too long lines in the document, the longest one being 21 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 19, 2015) is 3111 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-03 Summary: 1 error (**), 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: April 21, 2016 Painless Security 6 A. Perez-Mendez, Ed. 7 University of Murcia 8 October 19, 2015 10 A RADIUS Attribute, Binding, Profiles, Name Identifier Format, and 11 Confirmation Methods for SAML 12 draft-ietf-abfab-aaa-saml-12 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 April 21, 2016. 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 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 69 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 5 70 3. RADIUS SAML Attributes . . . . . . . . . . . . . . . . . . . 5 71 3.1. SAML-Assertion attribute . . . . . . . . . . . . . . . . 5 72 3.2. SAML-Protocol attribute . . . . . . . . . . . . . . . . . 6 73 4. SAML RADIUS Binding . . . . . . . . . . . . . . . . . . . . . 7 74 4.1. Required Information . . . . . . . . . . . . . . . . . . 7 75 4.2. Operation . . . . . . . . . . . . . . . . . . . . . . . . 7 76 4.3. Processing of names . . . . . . . . . . . . . . . . . . . 9 77 4.3.1. AAA names . . . . . . . . . . . . . . . . . . . . . . 9 78 4.3.2. SAML names . . . . . . . . . . . . . . . . . . . . . 9 79 4.3.3. Mapping of AAA names in SAML metadata . . . . . . . . 10 80 4.3.4. Example of SAML metadata including AAA names . . . . 12 81 4.4. Use of XML Signatures . . . . . . . . . . . . . . . . . . 13 82 4.5. Metadata Considerations . . . . . . . . . . . . . . . . . 13 83 5. Network Access Identifier Name Identifier Format . . . . . . 13 84 6. RADIUS State Confirmation Method Identifiers . . . . . . . . 13 85 7. ABFAB Authentication Profile . . . . . . . . . . . . . . . . 14 86 7.1. Required Information . . . . . . . . . . . . . . . . . . 14 87 7.2. Profile Overview . . . . . . . . . . . . . . . . . . . . 14 88 7.3. Profile Description . . . . . . . . . . . . . . . . . . . 16 89 7.3.1. Client Request to Relying Party . . . . . . . . . . . 16 90 7.3.2. Relying Party Issues to Identity 91 Provider . . . . . . . . . . . . . . . . . . . . . . 16 92 7.3.3. Identity Provider Identifies Client . . . . . . . . . 17 93 7.3.4. Identity Provider Issues to Relying 94 Party . . . . . . . . . . . . . . . . . . . . . . . . 17 95 7.3.5. Relying Party Grants or Denies Access to Client . . . 17 96 7.4. Use of Authentication Request Protocol . . . . . . . . . 17 97 7.4.1. Usage . . . . . . . . . . . . . 17 98 7.4.2. Message Usage . . . . . . . . . . . 18 99 7.4.3. Message Processing Rules . . . . . . 19 100 7.4.4. Unsolicited Responses . . . . . . . . . . . . . . . . 19 101 7.4.5. Use of the SAML RADIUS Binding . . . . . . . . . . . 19 102 7.4.6. Use of XML Signatures . . . . . . . . . . . . . . . . 19 103 7.4.7. Metadata Considerations . . . . . . . . . . . . . . . 20 104 8. ABFAB Assertion Query/Request Profile . . . . . . . . . . . . 20 105 8.1. Required Information . . . . . . . . . . . . . . . . . . 20 106 8.2. Profile Overview . . . . . . . . . . . . . . . . . . . . 20 107 8.3. Profile Description . . . . . . . . . . . . . . . . . . . 21 108 8.3.1. Differences from the SAML V2.0 Assertion 109 Query/Request Profile . . . . . . . . . . . . . . . . 21 110 8.3.2. Use of the SAML RADIUS Binding . . . . . . . . . . . 22 111 8.3.3. Use of XML Signatures . . . . . . . . . . . . . . . . 22 112 8.3.4. Metadata Considerations . . . . . . . . . . . . . . . 22 113 9. Privacy considerations . . . . . . . . . . . . . . . . . . . 22 114 10. Security Considerations . . . . . . . . . . . . . . . . . . . 23 115 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 116 11.1. RADIUS Attributes . . . . . . . . . . . . . . . . . . . 24 117 11.2. ABFAB Parameters . . . . . . . . . . . . . . . . . . . . 24 118 11.3. Registration of the ABFAB URN Namespace . . . . . . . . 25 119 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25 120 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 121 13.1. Normative References . . . . . . . . . . . . . . . . . . 25 122 13.2. Informative References . . . . . . . . . . . . . . . . . 27 123 Appendix A. XML Schema . . . . . . . . . . . . . . . . . . . . . 29 124 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 126 1. Introduction 128 Within the ABFAB architecture [I-D.ietf-abfab-arch] it is often 129 desirable to convey Security Assertion Mark-up Language (SAML) 130 assertions and protocol messages. 132 SAML typically only considers the use of HTTP-based transports, known 133 as bindings [OASIS.saml-bindings-2.0-os], which are primarily 134 intended for use with the SAML V2.0 Web Browser Single Sign-On 135 Profile [OASIS.saml-profiles-2.0-os]. However the goal of ABFAB is 136 to extend the applicability of federated identity beyond the Web to 137 other applications by building on the AAA framework. Consequently 138 there exists a requirement for SAML to integrate with the AAA 139 framework and protocols such as RADIUS [RFC2865] and Diameter 140 [RFC3588], in addition to HTTP. 142 In summary this document specifies: 144 o Two RADIUS attributes to encapsulate SAML assertions and protocol 145 messages respectively. 147 o A SAML RADIUS binding that defines how SAML assertions and 148 protocol messages can be transported by RADIUS within a SAML 149 exchange. 151 o A SAML name identifier format in the form of a Network Access 152 Identifier. 154 o A profile of the SAML Authentication Request Protocol that uses 155 the SAML RADIUS binding to effect SAML-based authentication and 156 authorization. 158 o A profile of the SAML Assertion Query And Request Protocol that 159 uses the SAML RADIUS binding to effect the query and request of 160 SAML assertions. 162 o Two SAML Subject Confirmation Methods for indicating that a user 163 or machine client is the subject of an assertion. 165 This document adheres 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 169 particular, this document provides a 'Required Information' section 170 for the 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 1.1. Terminology 184 This document uses terminology from a number of related standards, 185 which tend to addopt different terms for similar or identical 186 concepts. In general the document uses, when possible, the ABFAB 187 term for the entity, as described in [I-D.ietf-abfab-arch]. For 188 reference we include this table which maps the different terms into a 189 single view. 191 +----------+-----------+------------------+-------------------+ 192 | Protocol | Client | Relying Party | Identity Provider | 193 +----------+-----------+------------------+-------------------+ 194 | ABFAB | Client | Relying Party | Identity Provider | 195 | | | | | 196 | SAML | Subject | Service Provider | Identity Provider | 197 | | Principal | Requester | Responder | 198 | | | Consumer | Issuer | 199 | | | | | 200 | RADIUS | User | NAS | AS | 201 | | | RADIUS client | RADIUS server | 202 +----------+-----------+------------------+-------------------+ 204 Table 1. Terminology 206 2. Conventions 208 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 209 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 210 document are to be interpreted as described in RFC 2119 [RFC2119]. 212 3. RADIUS SAML Attributes 214 The RADIUS SAML binding defined in Section 4 of this document uses 215 two attributes to convey SAML assertions and protocol messages 216 respectively [OASIS.saml-core-2.0-os]. Owing to the typical size of 217 these structures, these attributes use the Long Extended Type format 218 [RFC6929] to encapsulate their data. RADIUS entities MUST NOT 219 include both attributes in the same RADIUS message, as they represent 220 exclusive alternatives to convey SAML information. 222 3.1. SAML-Assertion attribute 224 This attribute is used to encode a SAML assertion. The following 225 figure represents the format of this attribute. 227 1 2 3 228 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 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 | Type | Length | Extended-Type |M| Reserved | 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 | Value... 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 Figure 1: SAML-Assertion format 237 Type 238 245 (To be confirmed by IANA) 240 Length 242 >= 5 244 Extended-Type 246 TBD1 248 M (More) 250 As described in [RFC6929]. 252 Reserved 254 As described in [RFC6929]. 256 Value 258 One or more octets encoding a SAML assertion. 260 3.2. SAML-Protocol attribute 262 This attribute is used to encode a SAML protocol message. The 263 following figure represents the format of this attribute. 265 1 2 3 266 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 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 | Type | Length | Extended-Type |M| Reserved | 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 | Value... 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 Figure 2: SAML-Protocol format 275 Type 277 245 (To be confirmed by IANA) 279 Length 281 >= 5 283 Extended-Type 285 TBD2 287 M (More) 289 As described in [RFC6929]. 291 Reserved 293 As described in [RFC6929]. 295 Value 297 One or more octets encoding a SAML protocol message. 299 4. SAML RADIUS Binding 301 The SAML RADIUS binding defines how RADIUS [RFC2865] can be used to 302 enable a RADIUS client and server to exchange SAML assertions and 303 protocol messages. 305 4.1. Required Information 307 Identification: urn:ietf:params:abfab:bindings:radius 309 Contact information: iesg@ietf.org 311 Updates: None. 313 4.2. Operation 315 RADIUS can be used over multiple underlying transports. It is 316 REQUIRED that the RADIUS exchange is protected using TLS encryption 317 for RADIUS [RFC6614] to provide confidentiality and integrity 318 protection, unless alternative methods are used to ensure 319 confidentiality, such as IPSEC tunnels or a sufficiently secure 320 internal network. 322 Implementations of this profile can take advantage of mechanisms to 323 permit the transport of longer SAML messages over RADIUS transports, 324 such as the Support of fragmentation of RADIUS packets [RFC7499] or 325 Larger Packets for RADIUS over TCP [I-D.ietf-radext-bigger-packets]. 327 There are two system models for the use of SAML over RADIUS. The 328 first is a request-response model, using the RADIUS SAML-Protocol 329 attribute defined in Section 3 to encapsulate the SAML protocol 330 messages. 332 1. The RADIUS client, acting as a Relying Party (RP), transmits a 333 SAML request element within a RADIUS Access-Request message. 334 This message MUST include a single instance of the RADIUS User- 335 Name attribute whose value MUST conform to the Network Access 336 Identifier [RFC7542] scheme. The Relying Party MUST NOT include 337 more than one SAML request element. 339 2. The RADIUS server, acting as an Identity Provider (IdP), returns 340 a SAML protocol message within a RADIUS Access-Accept or Access- 341 Reject message. These messages necessarily conclude a RADIUS 342 exchange and therefore this is the only opportunity for the 343 Identity Provider to send a response in the context of this 344 exchange. The Identity Provider MUST NOT include more than one 345 SAML response. An IdP that refuses to perform a message exchange 346 with the Relying Party can silently discard the SAML request 347 (this could subsequently be followed by a RADIUS Access-Reject, 348 as the same conditions that cause the IdP to discard the SAML 349 request may also cause the RADIUS server to fail to 350 authenticate). 352 The second system model permits a RADIUS server acting as an Identity 353 Provider to use the RADIUS SAML-Assertion attribute defined in 354 Section 3 to encapsulate an unsolicited SAML assertion. This 355 attribute MUST be included in a RADIUS Access-Accept message. When 356 included, the attribute MUST contain a single SAML assertion. 358 RADIUS servers MUST NOT include both the SAML-Protocol and the SAML- 359 Assertion attribute in the same RADIUS message. If an IdP is 360 producing a response to a SAML request, then the first system model 361 is used. An IdP MAY ignore a SAML request and send an unsolicited 362 assertion using the second system model using the RADIUS SAML- 363 Assertion attribute. 365 In either system model, Identity Providers SHOULD return a RADIUS 366 state attribute as part of the Access-Accept message so that future 367 SAML queries or requests can be run against the same context of an 368 authentication exchange. 370 This binding is intended to be composed with other uses of RADIUS, 371 such as network access. Therefore, other arbitrary RADIUS attributes 372 MAY be used in either the request or response. 374 In the case of a SAML processing error, the RADIUS server MAY include 375 a SAML response message with an appropriate value for the 376 element within the Access-Accept or Access-Reject 377 packet to notify the client. Alternatively, the RADIUS server can 378 respond without a SAML-Protocol attribute. 380 4.3. Processing of names 382 SAML entities using profiles making use of this binding will 383 typically possess both the SAML and AAA names of their 384 correspondents. Frequently these entities will need to apply 385 policies using these names; for example, when deciding to release 386 attributes. Often these policies will be security-sensitive, and so 387 it is important that policy is applied on these names consistently. 389 4.3.1. AAA names 391 These rules relate to the processing of AAA names by SAML entities 392 using profiles making use of this binding. 394 o Identity Providers SHOULD apply policy based on the Relying 395 Party's identity associated with the RADIUS Access-Request. 397 o Relying Parties SHOULD apply policy based on the NAI realm 398 associated with the RADIUS Access-Accept. 400 4.3.2. SAML names 402 These rules relate to the processing of SAML names by SAML entities 403 using profiles making use of this binding. 405 Identity Providers MAY apply policy based on the Relying Party's SAML 406 entityId. In such cases, at least one of the following methods is 407 required in order to establish a relation between the SAML name and 408 the AAA name of the Relying Party: 410 o RADIUS client identity in trusted SAML metadata (as described in 411 section Section 4.3.3). 413 o RADIUS client identity in trusted digitally signed SAML request. 415 A digitally signed SAML request without the RADIUS client identity is 416 not sufficient, since a malicious RADIUS entity can observe a SAML 417 message and include it in a different RADIUS message without the 418 consent of the issuer of that SAML message. If an Identity Provider 419 were to process the SAML message without confirming that it applied 420 to the RADIUS message, inappropriate policy would be used. 422 Relying Parties MAY apply policy based on the SAML issuer's 423 . In such cases, at least one of the following methods is 424 required in order to establish a relationship between the SAML name 425 and the AAA name of the Identity Provider: 427 o RADIUS realm in trusted SAML metadata (as described in section 428 Section 4.3.3). 430 o RADIUS realm in trusted digitally signed SAML response or 431 assertion. 433 A digitally signed SAML response alone is not sufficient for the same 434 reasons described above for SAML requests. 436 4.3.3. Mapping of AAA names in SAML metadata 438 This section defines extensions to the SAML metadata schema 439 [OASIS.saml-metadata-2.0-os] that are required in order to represent 440 AAA names associated with a particular element. 442 In SAML metadata, a single entity may act in many different roles in 443 the support of multiple profiles. This document defines two new 444 roles: RADIUS IDP and RADIUS RP, requiring the declaration of two new 445 subtypes of RoleDescriptorType: RADIUSIDPDescriptorType and 446 RADIUSRPDescriptorType. These subtypes contain the additional 447 elements required to represent AAA names for IDP and RP entities 448 respectively. 450 4.3.3.1. RADIUSIDPDescriptorType 452 The RADIUSIDPDescriptorType complex type extends RoleDescriptorType 453 with elements common to IdPs that support RADIUS. It contains the 454 following additional elements: 456 [Zero or More] Zero or more elements of type 457 EndpointType that describe RADIUS endpoints that are associated 458 with the entity. 460 [Zero or More] Zero or more elements of type string 461 that represent the acceptable values of the RADIUS realm 462 associated with the entity, obtained from the realm part of RADIUS 463 User-Name attribute. 465 The following schema fragment defines the RADIUSIDPDescriptorType 466 complex type: 468 469 470 471 472 473 474 475 476 477 478 479 481 Figure 3: RADIUSIDPDescriptorType schema 483 4.3.3.2. RADIUSRPDescriptorType 485 The RADIUSRPDescriptorType complex type extends RoleDescriptorType 486 with elements common to RPs that support RADIUS. It contains the 487 following additional elements: 489 [Zero or More] Zero or more elements of type 490 EndpointType that describe RADIUS endpoints that are associated 491 with the entity. 493 [Zero or More] Zero or more elements of type 494 string that represent the acceptable values of the RADIUS NAS-IP- 495 Address or NAS-IPv6-Address attributes associated with the entity. 497 [Zero or More] Zero or more elements of type 498 string that represent the acceptable values of the RADIUS NAS- 499 Identifier attribute associated with the entity. 501 [Zero or More] Zero or more elements of type 502 string that represent the acceptable values of the GSS-EAP 503 acceptor name associated with the entity. The format for this 504 name is described in section 3.1 of [RFC7055], while section 3.4 505 describes how that name is decomposed and transported using RADIUS 506 attributes. 508 The following schema fragment defines the RADIUSRPDescriptorType 509 complex type: 511 512 513 514 515 516 517 518 519 520 521 522 523 524 525 526 528 Figure 4: RADIUSRPDescriptorType schema 530 4.3.4. Example of SAML metadata including AAA names 532 The following figures illustrate an example of metadata including AAA 533 names for and IDP and a RP respectively. The IDP's SAML name is 534 "https://IdentityProvider.com/", whereas its RADIUS realm is 535 "idp.com". The RP's SAML name is "https://RelyingParty.com/SAML", 536 being its GSS-EAP acceptor name "nfs/fileserver.rp.com@RP.COM". 538 542 544 idp.com 545 546 548 Figure 5: Metadata for the IDP 550 554 556 nfs/fileserver.rp.com@RP.COM 557 558 560 Figure 6: Metadata for the RP 562 4.4. Use of XML Signatures 564 This binding calls for the use of SAML elements that support XML 565 signatures. To promote interoperability, implementations of this 566 binding MUST support a default configuration that does not require 567 the use of XML signatures. Implementations MAY choose to use XML 568 signatures. 570 4.5. Metadata Considerations 572 These binding and profiles are mostly intended to be used without 573 metadata. In this usage, RADIUS infrastructure is used to provide 574 integrity and naming of the SAML messages and assertions. RADIUS 575 configuration is used to provide policy, including which attributes 576 are accepted from a Relying Party and which attributes are sent by an 577 Identity Provider. 579 Nevertheless, if metadata is used, the roles describe in section 580 Section 4.3.3 MUST be present. 582 5. Network Access Identifier Name Identifier Format 584 URI: urn:ietf:params:abfab:nameid-format:nai 586 Indicates that the content of the element is in the form of a Network 587 Access Identifier (NAI) using the syntax described by [RFC7542]. 589 6. RADIUS State Confirmation Method Identifiers 591 URI: urn:ietf:params:abfab:cm:user 593 URI: urn:ietf:params:abfab:cm:machine 595 Indicates that the Subject is the system entity (either the user or 596 machine) authenticated by a previously transmitted RADIUS Access- 597 Accept message, as identified by the value of that RADIUS message's 598 State attribute. 600 7. ABFAB Authentication Profile 602 In the scenario supported by the ABFAB Authentication Profile, a 603 Client controlling a User Agent requests access to a Relying Party. 604 The Relying Party uses RADIUS to authenticate the Client. In 605 particular, the Relying Party, acting as a RADIUS client, attempts to 606 validate the Client's credentials against a RADIUS server acting as 607 the Client's Identity Provider. If the Identity Provider 608 successfully authenticates the Client, it produces an authentication 609 assertion which is consumed by the Relying Party. This assertion MAY 610 include a name identifier that can be used between the Relying Party 611 and the Identity Provider to refer to the Client. 613 7.1. Required Information 615 Identification: urn:ietf:params:abfab:profiles:authentication 617 Contact information: iesg@ietf.org 619 SAML Confirmation Method Identifiers: The SAML V2.0 "RADIUS State" 620 confirmation method identifiers, either urn:ietf:params:abfab:cm:user 621 or urn:ietf:params:abfab:cm:machine, are used by this profile. 623 Updates: None. 625 7.2. Profile Overview 627 To implement this scenario, a profile of the SAML Authentication 628 Request protocol is used in conjunction with the SAML RADIUS binding 629 defined in Section 4. 631 This profile is based on the SAML V2.0 Web Browser Single Sign-On 632 Profile [OASIS.saml-profiles-2.0-os]. There are some important 633 differences, specifically: 635 Authentication: This profile does not require the use of any 636 particular authentication method. The ABFAB architecture does 637 require the use of EAP [RFC3579], but this specification may be 638 used in other non-ABFAB scenarios. 640 Bindings: This profile does not use HTTP-based bindings. Instead 641 all SAML protocol messages are transported using the SAML RADIUS 642 binding defined in Section 4. This is intended to reduce the 643 number of bindings that implementations must support to be 644 interoperable. 646 Requests: The profile does not permit the Relying Party to name the 647 of the . This is intended to 648 simplify implementation and interoperability. 650 Responses: The profile only permits the Identity Provider to return 651 a single SAML message or assertion that MUST contain exactly one 652 authentication statement. Other statements may be included within 653 this assertion at the discretion of the Identity Provider. This 654 is intended to simplify implementation and interoperability. 656 Figure 7 below illustrates the flow of messages within this profile. 658 Client Relying Party Identity Provider 659 | | | 660 | (1) | | 661 | - - - - - - - - - > | | 662 | | | 663 | | (2) | 664 | | - - - - - - - - - - - - > | 665 | | | 666 | (3) | | 667 | < - - - - - - - - - |- - - - - - - - - - - - - >| 668 | | | 669 | | (4) | 670 | | < - - - - - - - - - - - - | 671 | | | 672 | (5) | | 673 | < - - - - - - - - - | | 674 | | | 675 V V V 677 The following steps are described by the profile. Within an 678 individual step, there may be one or more actual message exchanges. 680 Figure 7 682 1. Client request to Relying Party (Section 7.3.1): In step 1, the 683 Client, via a User Agent, makes a request for a secured resource 684 at the Relying Party. The Relying Party determines that no 685 security context for the Client exists and initiates the 686 authentication process. 688 2. Relying Party issues to Identity Provider 689 (Section 7.3.2). In step 2, the Relying Party may optionally 690 issue a message to be delivered to the 691 Identity Provider using the SAML-Protocol RADIUS attribute. 693 3. Identity Provider identifies Client (Section 7.3.3). In step 3, 694 the Client is authenticated and identified by the Identity 695 Provider, while honoring any requirements imposed by the Relying 696 Party in the message if provided. 698 4. Identity Provider issues to Relying Party 699 (Section 7.3.4). In step 4, the Identity Provider issues a 700 message to the Relying Party using the SAML 701 RADIUS binding. The response either indicates an error or 702 includes a SAML Authentication Statement in exactly one SAML 703 Assertion. 705 5. Relying Party grants or denies access to Client (Section 7.3.5). 706 In step 5, having received the response from the Identity 707 Provider, the Relying Party can respond to the Client with its 708 own error, or can establish its own security context for the 709 Client and return the requested resource. 711 7.3. Profile Description 713 The ABFAB Authentication Profile is a profile of the SAML V2.0 714 Authentication Request Protocol [OASIS.saml-core-2.0-os]. Where both 715 specifications conflict, the ABFAB Authentication Profile takes 716 precedence. 718 7.3.1. Client Request to Relying Party 720 The profile is initiated by an arbitrary Client request to the 721 Relying Party. There are no restrictions on the form of the request. 722 The Relying Party is free to use any means it wishes to associate the 723 subsequent interactions with the original request. The Relying 724 Party, acting as a RADIUS client, attempts to authenticate the 725 Client. 727 7.3.2. Relying Party Issues to Identity Provider 729 The Relying Party uses RADIUS to communicate with the Client's 730 Identity Provider. The Relying Party MAY include a 731 within this RADIUS Access-Request message using 732 the SAML-Protocol RADIUS attribute. The next hop destination MAY be 733 the Identity Provider or alternatively an intermediate RADIUS proxy. 735 Profile-specific rules for the contents of the 736 element are given in Section 7.4.1. 738 7.3.3. Identity Provider Identifies Client 740 The Identity Provider MUST establish the identity of the Client using 741 a RADIUS authentication method, or else it will return an error. If 742 the ForceAuthn attribute on the element (if sent 743 by the Relying Party) is present and true, the Identity Provider MUST 744 freshly establish this identity rather than relying on any existing 745 session state it may have with the Client (for example, TLS state 746 that may be used for session resumption). Otherwise, and in all 747 other respects, the Identity Provider may use any method to 748 authenticate the Client, subject to the constraints called out in the 749 message. 751 7.3.4. Identity Provider Issues to Relying Party 753 The Identity Provider MUST conclude the authentication in a manner 754 consistent with the RADIUS authentication result. The IdP MAY issue 755 a message to the Relying Party that is consistent 756 with the authentication result, as described in 757 [OASIS.saml-core-2.0-os]. This SAML response is delivered to the 758 Relying Party using the SAML RADIUS binding described in Section 4. 760 Profile-specific rules regarding the contents of the 761 element are given in Section 7.4.2. 763 7.3.5. Relying Party Grants or Denies Access to Client 765 If issued by the Identity Provider, the Relying Party MUST process 766 the message and any enclosed assertion elements as 767 described in [OASIS.saml-core-2.0-os]. Any subsequent use of the 768 assertion elements is at the discretion of the Relying Party, subject 769 to any restrictions contained within the assertions themselves or 770 from any previously established out-of-band policy that governs the 771 interaction between the Identity Provider and the Relying Party. 773 7.4. Use of Authentication Request Protocol 775 This profile is based on the Authentication Request Protocol defined 776 in [OASIS.saml-core-2.0-os]. In the nomenclature of actors 777 enumerated in section 3.4 of that document, the Relying Party is the 778 requester, the User Agent is the attesting entity and the Client is 779 the Requested Subject. 781 7.4.1. Usage 783 The Relying Party MUST NOT include a element in the 784 request. The authenticated RADIUS identity identifies the Client to 785 the Identity Provider. 787 A Relying Party MAY include any message content described in 788 [OASIS.saml-core-2.0-os], section 3.4.1. All processing rules are as 789 defined in [OASIS.saml-core-2.0-os]. 791 If the Relying Party wishes to permit the Identity Provider to 792 establish a new identifier for the Client if none exists, it MUST 793 include a element with the AllowCreate attribute 794 set to "true". Otherwise, only a Client for whom the Identity 795 Provider has previously established an identifier usable by the 796 Relying Party can be authenticated successfully. 798 The message MAY be signed. Authentication and 799 integrity are also provided by the SAML RADIUS binding. 801 7.4.2. Message Usage 803 If the Identity Provider cannot or will not satisfy the request, it 804 MUST either respond with a message containing an 805 appropriate error status code or codes and/or respond with a RADIUS 806 Access-Reject message. 808 If the Identity Provider wishes to return an error, it MUST NOT 809 include any assertions in the message. Otherwise, 810 if the request is successful (or if the response is not associated 811 with a request), the element is subject to the 812 following constraints: 814 o It MAY be signed. 816 o It MUST contain exactly one assertion. The element 817 of this assertion MUST refer to the authenticated RADIUS user. 819 o The assertion MUST contain a . Besides, the 820 assertion MUST contain a element with at least one 821 element containing a Method of 822 urn:ietf:params:abfab:cm:user or urn:ietf:params:abfab:cm:machine 823 that reflects the authentication of the Client to the Identity 824 Provider. Since the containing message is in response to an 825 , the InResponseTo attribute (both in the 826 and in the 827 elements) MUST match the request's ID. The element 828 MAY use the NAI Name Identifier Format described in Section 5 to 829 establish an identifier between the Relying Party and the IdP. 831 o Other conditions MAY be included as requested by the Relying Party 832 or at the discretion of the Identity Provider. The Identity 833 Provider is NOT obligated to honor the requested set of conditions 834 in the , if any. 836 7.4.3. Message Processing Rules 838 The Relying Party MUST do the following: 840 o Assume that the Client's identifier implied by a SAML 841 element, if present, takes precedence over an identifier implied 842 by the RADIUS User-Name attribute. 844 o Verify that the InResponseTo attribute in the "RADIUS State" 845 equals the ID of its original 846 message, unless the response is unsolicited, 847 in which case the attribute MUST NOT be present. 849 o If a used to establish a security context 850 for the Client contains a SessionNotOnOrAfter attribute, the 851 security context SHOULD be discarded once this time is reached, 852 unless the Relying Party reestablishes the Client's identity by 853 repeating the use of this profile. 855 o Verify that any assertions relied upon are valid according to 856 processing rules in [OASIS.saml-core-2.0-os]. 858 o Any assertion which is not valid, or whose subject confirmation 859 requirements cannot be met MUST be discarded and MUST NOT be used 860 to establish a security context for the Client. 862 7.4.4. Unsolicited Responses 864 An Identity Provider MAY initiate this profile by delivering an 865 unsolicited assertion to a Relying Party. This MUST NOT contain any 866 elements containing an InResponseTo 867 attribute. 869 7.4.5. Use of the SAML RADIUS Binding 871 It is RECOMMENDED that the RADIUS exchange is protected using TLS 872 encryption for RADIUS [RFC6614] to provide confidentiality and 873 integrity protection. 875 7.4.6. Use of XML Signatures 877 This profile calls for the use of SAML elements that support XML 878 signatures. To promote interoperability implementations of this 879 profile MUST NOT require the use of XML signatures. Implementations 880 MAY choose to use XML signatures. 882 7.4.7. Metadata Considerations 884 There are no metadata considerations particular to this profile, 885 aside from those applying to the use of the RADIUS binding. 887 8. ABFAB Assertion Query/Request Profile 889 This profile builds on the SAML V2.0 Assertion Query/Request Profile 890 defined by [OASIS.saml-profiles-2.0-os]. That profile describes the 891 use of the Assertion Query and Request Protocol defined by section 892 3.3 of [OASIS.saml-core-2.0-os] with synchronous bindings, such as 893 the SOAP binding defined in [OASIS.saml-bindings-2.0-os]. 895 While the SAML V2.0 Assertion Query/Request Profile is independent of 896 the underlying binding, it is nonetheless useful to describe the use 897 of the SAML RADIUS binding defined in Section 4 of this document, in 898 the interests of promoting interoperable implementations, 899 particularly as the SAML V2.0 Assertion Query/Request Profile is most 900 frequently discussed and implemented in the context of the SOAP 901 binding. 903 8.1. Required Information 905 Identification: urn:ietf:params:abfab:profiles:query 907 Contact information: iesg@ietf.org 909 Description: Given below. 911 Updates: None. 913 8.2. Profile Overview 915 As with the SAML V2.0 Assertion Query/Request Profile defined by 916 [OASIS.saml-profiles-2.0-os] the message exchange and basic 917 processing rules that govern this profile are largely defined by 918 Section 3.3 of [OASIS.saml-core-2.0-os] that defines the messages to 919 be exchanged, in combination with the binding used to exchange the 920 messages. The SAML RADIUS binding described in this document defines 921 the binding of the message exchange to RADIUS. Unless specifically 922 noted here, all requirements defined in those specifications apply. 924 Figure 8 below illustrates the basic template for the query/request 925 profile. 927 Relying Party Identity Provider 928 (SAML requester) (SAML responder) 929 | | 930 | (1) | 931 | - - - - - - - - - - - - - - - - - - - - - - - > | 932 | | 933 | (2) | 934 | < - - - - - - - - - - - - - - - - - - - - - - - | 935 | | 936 V V 938 The following steps are described by the profile. 940 Figure 8 942 1. Query/Request issued by Relying Party: In step 1, a Relying Party 943 initiates the profile by sending an , 944 , , , or 945 message to a SAML authority. 947 2. issued by SAML Authority: In step 2, the responding 948 SAML authority (after processing the query or request) issues a 949 message to the Relying Party. 951 8.3. Profile Description 953 8.3.1. Differences from the SAML V2.0 Assertion Query/Request Profile 955 This profile is identical to the SAML V2.0 Assertion Query/Request 956 Profile, with the following exceptions: 958 o When processing the SAML request, the IdP MUST give precedence to 959 the Client's identifier implied by RADIUS State attribute, if 960 present, over the identifier implied by the SAML request's 961 , if any. 963 o In respect to sections 6.3.1 and 6.5 of 964 [OASIS.saml-profiles-2.0-os], this profile does not consider the 965 use of metadata (as in [OASIS.saml-metadata-2.0-os]). See 966 Section 8.3.4. 968 o In respect to sections 6.3.2, 6.4.1, and 6.4.2 of 969 [OASIS.saml-profiles-2.0-os], this profile additionally stipulates 970 that implementations of this profile MUST NOT require the use of 971 XML signatures. See Section 8.3.3. 973 8.3.2. Use of the SAML RADIUS Binding 975 The RADIUS Access-Request sent by the Relying Party: 977 o MUST include an instance of the RADIUS Service-Type attribute, 978 having a value of Authorize-Only. 980 o SHOULD include the RADIUS State attribute, where this Query/ 981 Request pertains to previously authenticated Client. 983 When processing the SAML request, the IdP MUST give precedence to the 984 Client's identifier implied by RADIUS State attribute over the 985 identifier implied by the SAML request's , if any. 987 It is RECOMMENDED that the RADIUS exchange is protected using TLS 988 encryption for RADIUS [RFC6614] to provide confidentiality and 989 integrity protection. 991 8.3.3. Use of XML Signatures 993 This profile calls for the use of SAML elements that support XML 994 signatures. To promote interoperability implementations of this 995 profile MUST NOT require the use of XML signatures. Implementations 996 MAY choose to use XML signatures. 998 8.3.4. Metadata Considerations 1000 There are no metadata considerations particular to this profile, 1001 aside from those applying to the use of the RADIUS binding. 1003 9. Privacy considerations 1005 The profiles defined in this document allow a Relying Party to 1006 request specific information about the Client, and allow an IdP to 1007 disclose information about that Client. In this sense, Identity 1008 Providers MUST apply policy to decide what information is released to 1009 a particular Relying Party. Moreover, the identity of the Client is 1010 typically hidden from the Relying Party unless informed by the 1011 Identity Provider. Conversely, the Relying Party does typically know 1012 the realm of the IdP, as it is required to route the RADIUS packets 1013 to the right destination. 1015 The kind of information that is released by the IdP MAY include 1016 generic attributes such as affiliation shared by many Clients. But 1017 even these generic attributes can help to identify a specific Client. 1018 Other kinds of attributes MAY also provide a Relying Party with the 1019 ability to link the same Client between different sessions. Finally, 1020 other kind of attributes MAY provide a group of Relying Parties with 1021 the ability to link the Client between them or with personally 1022 identifiable information about the Client. 1024 These profiles do not directly provide a Client with a mechanism to 1025 express preferences about what information is released. That 1026 information can be expressed out-of-band, for example as part of the 1027 enrollment process. 1029 The Relying Party MAY disclose privacy-sensitive information about 1030 itself as part of the request, although this is unlikely in typical 1031 deployments. 1033 If RADIUS proxies are used and encryption is not used, the attributes 1034 disclosed by the IdP are visible to the proxies. This is a 1035 significant privacy exposure in some deployments. Ongoing work is 1036 exploring mechanisms for creating TLS connections directly between 1037 the RADIUS client and the RADIUS server to reduce this exposure. If 1038 proxies are used, the impact of exposing SAML assertions to the 1039 proxies needs to be carefully considered. 1041 The use of TLS to provide confidentiality for the RADIUS exchange is 1042 strongly encouraged. Without this, passive eavesdroppers can observe 1043 the assertions. 1045 10. Security Considerations 1047 In this specification, the Relying Party MUST trust any statement in 1048 the SAML messages from the IdP in the same way that it trusts 1049 information contained in RADIUS attributes. These entities MUST 1050 trust the RADIUS infrastructure to provide integrity of the SAML 1051 messages. 1053 Furthermore, the Relying Party MUST apply policy and filter the 1054 information based on what information the IdP is permitted to assert 1055 and on what trust is reasonable to place in proxies between them. 1057 XML signatures and encryption are provided as an OPTIONAL mechanism 1058 for end-to-end security. These mechanism can protect SAML messages 1059 from being modified by proxies in the RADIUS infrastructure. These 1060 mechanisms are not mandatory-to-implement. It is believed that 1061 ongoing work to provide direct TLS connections between a RADIUS 1062 client and RADIUS server will provide similar assurances but better 1063 deployability. XML security is appropriate for deployments where 1064 end-to-end security is required but proxies cannot be removed or 1065 where SAML messages need to be verified at a later time or by parties 1066 not involved in the authentication exchange. 1068 11. IANA Considerations 1070 11.1. RADIUS Attributes 1072 The authors request that Attribute Types and Attribute Values defined 1073 in this document be registered by the Internet Assigned Numbers 1074 Authority (IANA) from the RADIUS namespaces as described in the "IANA 1075 Considerations" section of [RFC3575], in accordance with BCP 26 1076 [RFC5226]. For RADIUS packets, attributes and registries created by 1077 this document IANA is requested to place them at 1078 http://www.iana.org/assignments/radius-types. 1080 In particular, this document defines two new RADIUS attributes, 1081 entitled "SAML-Assertion" and "SAML-Protocol" (see Section 3), with 1082 assigned values of 245.TBD1 and 245.TBD2 from the Long Extended Space 1083 of [RFC6929]: 1085 Type Ext. Type Name Length Meaning 1086 ---- --------- -------------- ------ ------------------------ 1087 245 TBD1 SAML-Assertion >=5 Encodes a SAML assertion 1088 245 TBD2 SAML-Protocol >=5 Encodes a SAML protocol 1089 message 1091 11.2. ABFAB Parameters 1093 A new top-level registry is created titled "ABFAB Parameters". 1095 In this top-level registry, a sub-registry titled "ABFAB URN 1096 Parameters" is created. Registration in this registry is by the IETF 1097 review or expert review procedures [RFC5226]. 1099 This paragraph gives guidance to designated experts. Registrations 1100 in this registry are generally only expected as part of protocols 1101 published as RFCs on the IETF stream; other URIs are expected to be 1102 better choices for non-IETF work. Expert review is permitted mainly 1103 to allow early registration related to specifications under 1104 development when the community believes they have reached sufficient 1105 maturity. The expert SHOULD evaluate the maturity and stability of 1106 such an IETF-stream specification. Experts SHOULD review anything 1107 not from the IETF stream for consistency and consensus with current 1108 practice. Today such requests would not typically be approved. 1110 If a parameter named "paramname" is to be registered in this 1111 registry, then its URN will be "urn:ietf:params:abfab:paramname". 1112 The initial registrations are as follows: 1114 +-------------------------+-----------+ 1115 | Parameter | Reference | 1116 +-------------------------+-----------+ 1117 | bindings:radius | Section 4 | 1118 | nameid-format:nai | Section 5 | 1119 | profiles:authentication | Section 7 | 1120 | profiles:query | Section 8 | 1121 | cm:user | Section 6 | 1122 | cm:machine | Section 6 | 1123 +-------------------------+-----------+ 1125 ABFAB Parameters 1127 11.3. Registration of the ABFAB URN Namespace 1129 IANA is requested to register the "abfab" URN sub-namespace in the 1130 IETF URN sub-namespace for protocol parameters defined in [RFC3553]. 1132 Registry Name: abfab 1134 Specification: draft-ietf-abfab-aaa-saml 1136 Repository: ABFAB URN Parameters (Section Section 11.2) 1138 Index Value: Sub-parameters MUST be specified in UTF-8 using standard 1139 URI encoding where necessary. 1141 12. Acknowledgements 1143 The authors would like to acknowledge the OASIS Security Services 1144 (SAML) Technical Committee, and Scott Cantor in particular, for their 1145 help with the SAML-related material. 1147 The authors would also like to acknowledge the collaboration of Jim 1148 Schaad, Leif Johansson, Klaas Wierenga, Stephen Farell, Gabriel 1149 Lopez, and Rafael Marin, who have provided valuable comments on this 1150 document. 1152 13. References 1154 13.1. Normative References 1156 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1157 Requirement Levels", BCP 14, RFC 2119, 1158 DOI 10.17487/RFC2119, March 1997, 1159 . 1161 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 1162 "Remote Authentication Dial In User Service (RADIUS)", 1163 RFC 2865, DOI 10.17487/RFC2865, June 2000, 1164 . 1166 [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication 1167 Dial In User Service) Support For Extensible 1168 Authentication Protocol (EAP)", RFC 3579, 1169 DOI 10.17487/RFC3579, September 2003, 1170 . 1172 [RFC6614] Winter, S., McCauley, M., Venaas, S., and K. Wierenga, 1173 "Transport Layer Security (TLS) Encryption for RADIUS", 1174 RFC 6614, DOI 10.17487/RFC6614, May 2012, 1175 . 1177 [RFC6929] DeKok, A. and A. Lior, "Remote Authentication Dial In User 1178 Service (RADIUS) Protocol Extensions", RFC 6929, 1179 DOI 10.17487/RFC6929, April 2013, 1180 . 1182 [RFC3575] Aboba, B., "IANA Considerations for RADIUS (Remote 1183 Authentication Dial In User Service)", RFC 3575, 1184 DOI 10.17487/RFC3575, July 2003, 1185 . 1187 [RFC7542] DeKok, A., "The Network Access Identifier", RFC 7542, 1188 DOI 10.17487/RFC7542, May 2015, 1189 . 1191 [OASIS.saml-bindings-2.0-os] 1192 Cantor, S., Hirsch, F., Kemp, J., Philpott, R., and E. 1193 Maler, "Bindings for the OASIS Security Assertion Markup 1194 Language (SAML) V2.0", OASIS Standard saml-bindings- 1195 2.0-os, March 2005. 1197 [OASIS.saml-core-2.0-os] 1198 Cantor, S., Kemp, J., Philpott, R., and E. Maler, 1199 "Assertions and Protocol for the OASIS Security Assertion 1200 Markup Language (SAML) V2.0", OASIS Standard saml-core- 1201 2.0-os, March 2005. 1203 [OASIS.saml-profiles-2.0-os] 1204 Hughes, J., Cantor, S., Hodges, J., Hirsch, F., Mishra, 1205 P., Philpott, R., and E. Maler, "Profiles for the OASIS 1206 Security Assertion Markup Language (SAML) V2.0", OASIS 1207 Standard OASIS.saml-profiles-2.0-os, March 2005. 1209 [OASIS.saml-metadata-2.0-os] 1210 Cantor, S., Moreh, J., Philpott, R., and E. Maler, 1211 "Metadata for the Security Assertion Markup Language 1212 (SAML) V2.0", OASIS Standard saml-metadata-2.0-os, March 1213 2005. 1215 13.2. Informative References 1217 [RFC3553] Mealling, M., Masinter, L., Hardie, T., and G. Klyne, "An 1218 IETF URN Sub-namespace for Registered Protocol 1219 Parameters", BCP 73, RFC 3553, DOI 10.17487/RFC3553, June 1220 2003, . 1222 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 1223 Arkko, "Diameter Base Protocol", RFC 3588, 1224 DOI 10.17487/RFC3588, September 2003, 1225 . 1227 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1228 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1229 DOI 10.17487/RFC5226, May 2008, 1230 . 1232 [RFC7055] Hartman, S., Ed. and J. Howlett, "A GSS-API Mechanism for 1233 the Extensible Authentication Protocol", RFC 7055, 1234 DOI 10.17487/RFC7055, December 2013, 1235 . 1237 [RFC7499] Perez-Mendez, A., Ed., Marin-Lopez, R., Pereniguez-Garcia, 1238 F., Lopez-Millan, G., Lopez, D., and A. DeKok, "Support of 1239 Fragmentation of RADIUS Packets", RFC 7499, 1240 DOI 10.17487/RFC7499, April 2015, 1241 . 1243 [I-D.ietf-abfab-arch] 1244 Howlett, J., Hartman, S., Tschofenig, H., Lear, E., and J. 1245 Schaad, "Application Bridging for Federated Access Beyond 1246 Web (ABFAB) Architecture", draft-ietf-abfab-arch-13 (work 1247 in progress), July 2014. 1249 [I-D.ietf-radext-bigger-packets] 1250 Hartman, S., "Larger Packets for RADIUS over TCP", draft- 1251 ietf-radext-bigger-packets-03 (work in progress), March 1252 2015. 1254 [W3C.REC-xmlschema-1] 1255 Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn, 1256 "XML Schema Part 1: Structures", W3C REC-xmlschema-1, May 1257 2001, . 1259 Appendix A. XML Schema 1261 The following schema formally defines the 1262 "urn:ietf:params:xml:ns:abfab" namespace used in this document, in 1263 conformance with [W3C.REC-xmlschema-1] While XML validation is 1264 optional, the schema that follows is the normative definition of the 1265 constructs it defines. Where the schema differs from any prose in 1266 this specification, the schema takes precedence. 1268 1278 1280 1281 1282 1283 1284 1285 1286 1287 1288 1289 1290 1291 1293 1294 1295 1296 1297 1298 1299 1300 1301 1302 1303 1304 1305 1306 1307 1308 1310 1312 Authors' Addresses 1314 Josh Howlett 1315 Janet 1316 Lumen House, Library Avenue, Harwell 1317 Oxford OX11 0SG 1318 UK 1320 Phone: +44 1235 822363 1321 EMail: Josh.Howlett@ja.net 1323 Sam Hartman 1324 Painless Security 1326 EMail: hartmans-ietf@mit.edu 1328 Alejandro Perez-Mendez (editor) 1329 University of Murcia 1330 Campus de Espinardo S/N, Faculty of Computer Science 1331 Murcia 30100 1332 Spain 1334 Phone: +34 868 88 46 44 1335 EMail: alex@um.es