idnits 2.17.1 draft-ietf-abfab-aaa-saml-13.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 (December 14, 2015) is 3056 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Informational RFC: RFC 3579 ** Downref: Normative reference to an Experimental RFC: RFC 6614 -- 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-05 Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 2 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: Standards Track S. Hartman 5 Expires: June 16, 2016 Painless Security 6 A. Perez-Mendez, Ed. 7 University of Murcia 8 December 14, 2015 10 A RADIUS Attribute, Binding, Profiles, Name Identifier Format, and 11 Confirmation Methods for SAML 12 draft-ietf-abfab-aaa-saml-13 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. The use of the 30 artifacts defined in this document is not exclusive to ABFAB. They 31 can be applied in any AAA scenario, such as the network access 32 control. 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at http://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on June 16, 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 97 7.4. Use of Authentication Request Protocol . . . . . . . . . 17 98 7.4.1. Usage . . . . . . . . . . . . . 17 99 7.4.2. Message Usage . . . . . . . . . . . 18 100 7.4.3. Message Processing Rules . . . . . . 19 101 7.4.4. Unsolicited Responses . . . . . . . . . . . . . . . . 19 102 7.4.5. Use of the SAML RADIUS Binding . . . . . . . . . . . 19 103 7.4.6. Use of XML Signatures . . . . . . . . . . . . . . . . 19 104 7.4.7. Metadata Considerations . . . . . . . . . . . . . . . 20 105 8. ABFAB Assertion Query/Request Profile . . . . . . . . . . . . 20 106 8.1. Required Information . . . . . . . . . . . . . . . . . . 20 107 8.2. Profile Overview . . . . . . . . . . . . . . . . . . . . 20 108 8.3. Profile Description . . . . . . . . . . . . . . . . . . . 21 109 8.3.1. Differences from the SAML V2.0 Assertion 110 Query/Request Profile . . . . . . . . . . . . . . . . 21 111 8.3.2. Use of the SAML RADIUS Binding . . . . . . . . . . . 22 112 8.3.3. Use of XML Signatures . . . . . . . . . . . . . . . . 22 113 8.3.4. Metadata Considerations . . . . . . . . . . . . . . . 22 114 9. Privacy considerations . . . . . . . . . . . . . . . . . . . 22 115 10. Security Considerations . . . . . . . . . . . . . . . . . . . 23 116 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 117 11.1. RADIUS Attributes . . . . . . . . . . . . . . . . . . . 24 118 11.2. ABFAB Parameters . . . . . . . . . . . . . . . . . . . . 24 119 11.3. Registration of the ABFAB URN Namespace . . . . . . . . 25 120 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25 121 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 122 13.1. Normative References . . . . . . . . . . . . . . . . . . 25 123 13.2. Informative References . . . . . . . . . . . . . . . . . 27 124 Appendix A. XML Schema . . . . . . . . . . . . . . . . . . . . . 29 125 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 127 1. Introduction 129 Within the ABFAB (Application Bridging for Federated Access Beyond 130 web) architecture [I-D.ietf-abfab-arch] it is often desirable to 131 convey Security Assertion Mark-up Language (SAML) assertions and 132 protocol messages. 134 SAML typically only considers the use of HTTP-based transports, known 135 as bindings [OASIS.saml-bindings-2.0-os], which are primarily 136 intended for use with the SAML V2.0 Web Browser Single Sign-On 137 Profile [OASIS.saml-profiles-2.0-os]. However the goal of ABFAB is 138 to extend the applicability of federated identity beyond the Web to 139 other applications by building on the AAA framework. Consequently 140 there exists a requirement for SAML to integrate with the AAA 141 framework and protocols such as RADIUS [RFC2865] and Diameter 142 [RFC6733], in addition to HTTP. 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 SAML name identifier format in the form of a Network Access 154 Identifier. 156 o A profile of the SAML Authentication Request Protocol that uses 157 the SAML RADIUS binding to effect SAML-based authentication and 158 authorization. 160 o A profile of the SAML Assertion Query And Request Protocol that 161 uses the SAML RADIUS binding to effect the query and request of 162 SAML assertions. 164 o Two SAML Subject Confirmation Methods for indicating that a user 165 or machine client is the subject of an assertion. 167 This document adheres to the guidelines stipulated by 168 [OASIS.saml-bindings-2.0-os] and [OASIS.saml-profiles-2.0-os] for 169 defining new SAML bindings and profiles respectively, and other 170 conventions applied formally or otherwise within SAML. In 171 particular, this document provides a 'Required Information' section 172 for the binding and profiles that enumerate: 174 o A URI that uniquely identifies the protocol binding or profile. 176 o Postal or electronic contact information for the author. 178 o A reference to previously defined bindings or profiles that the 179 new binding updates or obsoletes. 181 o In the case of a profile, any SAML confirmation method identifiers 182 defined and/or utilized by the profile. 184 1.1. Terminology 186 This document uses terminology from a number of related standards, 187 which tend to adopt different terms for similar or identical 188 concepts. In general the document uses, when possible, the ABFAB 189 term for the entity, as described in [I-D.ietf-abfab-arch]. For 190 reference we include this table which maps the different terms into a 191 single view. 193 +----------+-----------+------------------+-------------------+ 194 | Protocol | Client | Relying Party | Identity Provider | 195 +----------+-----------+------------------+-------------------+ 196 | ABFAB | Client | Relying Party | Identity Provider | 197 | | | | | 198 | SAML | Subject | Service Provider | Identity Provider | 199 | | Principal | Requester | Responder | 200 | | | Consumer | Issuer | 201 | | | | | 202 | RADIUS | User | NAS | AS | 203 | | | RADIUS client | RADIUS server | 204 +----------+-----------+------------------+-------------------+ 206 Table 1. Terminology 208 2. Conventions 210 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 211 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 212 document are to be interpreted as described in RFC 2119 [RFC2119]. 214 3. RADIUS SAML Attributes 216 The RADIUS SAML binding defined in Section 4 of this document uses 217 two attributes to convey SAML assertions and protocol messages 218 respectively [OASIS.saml-core-2.0-os]. Owing to the typical size of 219 these structures, these attributes use the Long Extended Type format 220 [RFC6929] to encapsulate their data. RADIUS entities MUST NOT 221 include both attributes in the same RADIUS message, as they represent 222 exclusive alternatives to convey SAML information. 224 3.1. SAML-Assertion attribute 226 This attribute is used to encode a SAML assertion. The following 227 figure represents the format of this attribute. 229 1 2 3 230 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 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 | Type | Length | Extended-Type |M| Reserved | 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 | Value... 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 Figure 1: SAML-Assertion format 239 Type 240 245 (To be confirmed by IANA) 242 Length 244 >= 5 246 Extended-Type 248 TBD1 250 M (More) 252 As described in [RFC6929]. 254 Reserved 256 As described in [RFC6929]. 258 Value 260 One or more octets encoding a SAML assertion. 262 3.2. SAML-Protocol attribute 264 This attribute is used to encode a SAML protocol message. The 265 following figure represents the format of this attribute. 267 1 2 3 268 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 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 | Type | Length | Extended-Type |M| Reserved | 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 | Value... 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 275 Figure 2: SAML-Protocol format 277 Type 279 245 (To be confirmed by IANA) 281 Length 283 >= 5 285 Extended-Type 287 TBD2 289 M (More) 291 As described in [RFC6929]. 293 Reserved 295 As described in [RFC6929]. 297 Value 299 One or more octets encoding a SAML protocol message. 301 4. SAML RADIUS Binding 303 The SAML RADIUS binding defines how RADIUS [RFC2865] can be used to 304 enable a RADIUS client and server to exchange SAML assertions and 305 protocol messages. 307 4.1. Required Information 309 Identification: urn:ietf:params:abfab:bindings:radius 311 Contact information: iesg@ietf.org 313 Updates: None. 315 4.2. Operation 317 In this specification, the Relying Party MUST trust any statement in 318 the SAML messages from the IdP in the same way that it trusts 319 information contained in RADIUS attributes. These entities MUST 320 trust the RADIUS infrastructure to provide integrity of the SAML 321 messages. 323 Hence, it is REQUIRED that the RADIUS exchange is protected using TLS 324 encryption for RADIUS [RFC6614] to provide confidentiality and 325 integrity protection, unless alternative methods to ensure them are 326 used, such as IPSEC tunnels or a sufficiently secure internal 327 network. 329 Implementations of this profile can take advantage of mechanisms to 330 permit the transport of longer SAML messages over RADIUS transports, 331 such as the Support of fragmentation of RADIUS packets [RFC7499] or 332 Larger Packets for RADIUS over TCP [I-D.ietf-radext-bigger-packets]. 334 There are two system models for the use of SAML over RADIUS. The 335 first is a request-response model, using the RADIUS SAML-Protocol 336 attribute defined in Section 3 to encapsulate the SAML protocol 337 messages. 339 1. The RADIUS client, acting as a Relying Party (RP), transmits a 340 SAML request element within a RADIUS Access-Request message. 341 This message MUST include a single instance of the RADIUS User- 342 Name attribute whose value MUST conform to the Network Access 343 Identifier [RFC7542] scheme. The Relying Party MUST NOT include 344 more than one SAML request element. 346 2. The RADIUS server, acting as an Identity Provider (IdP), returns 347 a SAML protocol message within a RADIUS Access-Accept or Access- 348 Reject message. These messages necessarily conclude a RADIUS 349 exchange and therefore this is the only opportunity for the 350 Identity Provider to send a response in the context of this 351 exchange. The Identity Provider MUST NOT include more than one 352 SAML response. An IdP that refuses to perform a message exchange 353 with the Relying Party can silently discard the SAML request 354 (this could subsequently be followed by a RADIUS Access-Reject, 355 as the same conditions that cause the IdP to discard the SAML 356 request may also cause the RADIUS server to fail to 357 authenticate). 359 The second system model permits a RADIUS server acting as an Identity 360 Provider to use the RADIUS SAML-Assertion attribute defined in 361 Section 3 to encapsulate an unsolicited SAML assertion. This 362 attribute MUST be included in a RADIUS Access-Accept message. When 363 included, the attribute MUST contain a single SAML assertion. 365 RADIUS servers MUST NOT include both the SAML-Protocol and the SAML- 366 Assertion attribute in the same RADIUS message. If an IdP is 367 producing a response to a SAML request, then the first system model 368 is used. An IdP MAY ignore a SAML request and send an unsolicited 369 assertion using the second system model using the RADIUS SAML- 370 Assertion attribute. 372 In either system model, Identity Providers SHOULD return a RADIUS 373 state attribute as part of the Access-Accept message so that future 374 SAML queries or requests can be run against the same context of an 375 authentication exchange. 377 This binding is intended to be composed with other uses of RADIUS, 378 such as network access. Therefore, other arbitrary RADIUS attributes 379 MAY be used in either the request or response. 381 In the case of a SAML processing error, the RADIUS server MAY include 382 a SAML response message with an appropriate value for the 383 element within the Access-Accept or Access-Reject 384 packet to notify the client. Alternatively, the RADIUS server can 385 respond without a SAML-Protocol attribute. 387 4.3. Processing of names 389 SAML entities using profiles making use of this binding will 390 typically possess both the SAML and AAA names of their 391 correspondents. Frequently these entities will need to apply 392 policies using these names; for example, when deciding to release 393 attributes. Often these policies will be security-sensitive, and so 394 it is important that policy is applied on these names consistently. 396 4.3.1. AAA names 398 These rules relate to the processing of AAA names by SAML entities 399 using profiles making use of this binding. 401 o Identity Providers SHOULD apply policy based on the Relying 402 Party's identity associated with the RADIUS Access-Request. 404 o Relying Parties SHOULD apply policy based on the NAI realm 405 associated with the RADIUS Access-Accept. 407 4.3.2. SAML names 409 These rules relate to the processing of SAML names by SAML entities 410 using profiles making use of this binding. 412 Identity Providers MAY apply policy based on the Relying Party's SAML 413 entityId. In such cases, at least one of the following methods is 414 required in order to establish a relation between the SAML name and 415 the AAA name of the Relying Party: 417 o RADIUS client identity in trusted SAML metadata (as described in 418 section Section 4.3.3). 420 o RADIUS client identity in trusted digitally signed SAML request. 422 A digitally signed SAML request without the RADIUS client identity is 423 not sufficient, since a malicious RADIUS entity can observe a SAML 424 message and include it in a different RADIUS message without the 425 consent of the issuer of that SAML message. If an Identity Provider 426 were to process the SAML message without confirming that it applied 427 to the RADIUS message, inappropriate policy would be used. 429 Relying Parties MAY apply policy based on the SAML issuer's 430 . In such cases, at least one of the following methods is 431 required in order to establish a relationship between the SAML name 432 and the AAA name of the Identity Provider: 434 o RADIUS realm in trusted SAML metadata (as described in section 435 Section 4.3.3). 437 o RADIUS realm in trusted digitally signed SAML response or 438 assertion. 440 A digitally signed SAML response alone is not sufficient for the same 441 reasons described above for SAML requests. 443 4.3.3. Mapping of AAA names in SAML metadata 445 This section defines extensions to the SAML metadata schema 446 [OASIS.saml-metadata-2.0-os] that are required in order to represent 447 AAA names associated with a particular element. 449 In SAML metadata, a single entity may act in many different roles in 450 the support of multiple profiles. This document defines two new 451 roles: RADIUS IDP and RADIUS RP, requiring the declaration of two new 452 subtypes of RoleDescriptorType: RADIUSIDPDescriptorType and 453 RADIUSRPDescriptorType. These subtypes contain the additional 454 elements required to represent AAA names for IDP and RP entities 455 respectively. 457 4.3.3.1. RADIUSIDPDescriptorType 459 The RADIUSIDPDescriptorType complex type extends RoleDescriptorType 460 with elements common to IdPs that support RADIUS. It contains the 461 following additional elements: 463 [Zero or More] Zero or more elements of type 464 EndpointType that describe RADIUS endpoints that are associated 465 with the entity. 467 [Zero or More] Zero or more elements of type string 468 that represent the acceptable values of the RADIUS realm 469 associated with the entity, obtained from the realm part of RADIUS 470 User-Name attribute. 472 The following schema fragment defines the RADIUSIDPDescriptorType 473 complex type: 475 476 477 478 479 480 481 482 483 484 485 486 488 Figure 3: RADIUSIDPDescriptorType schema 490 4.3.3.2. RADIUSRPDescriptorType 492 The RADIUSRPDescriptorType complex type extends RoleDescriptorType 493 with elements common to RPs that support RADIUS. It contains the 494 following additional elements: 496 [Zero or More] Zero or more elements of type 497 EndpointType that describe RADIUS endpoints that are associated 498 with the entity. 500 [Zero or More] Zero or more elements of type 501 string that represent the acceptable values of the RADIUS NAS-IP- 502 Address or NAS-IPv6-Address attributes associated with the entity. 504 [Zero or More] Zero or more elements of type 505 string that represent the acceptable values of the RADIUS NAS- 506 Identifier attribute associated with the entity. 508 [Zero or More] Zero or more elements of type 509 string that represent the acceptable values of the GSS-EAP 510 acceptor name associated with the entity. The format for this 511 name is described in section 3.1 of [RFC7055], while section 3.4 512 describes how that name is decomposed and transported using RADIUS 513 attributes. 515 The following schema fragment defines the RADIUSRPDescriptorType 516 complex type: 518 519 520 521 522 523 524 525 526 527 528 529 530 531 532 533 535 Figure 4: RADIUSRPDescriptorType schema 537 4.3.4. Example of SAML metadata including AAA names 539 The following figures illustrate an example of metadata including AAA 540 names for and IDP and a RP respectively. The IDP's SAML name is 541 "https://IdentityProvider.com/", whereas its RADIUS realm is 542 "idp.com". The RP's SAML name is "https://RelyingParty.com/SAML", 543 being its GSS-EAP acceptor name "nfs/fileserver.rp.com@RP.COM". 545 549 551 idp.com 552 553 555 Figure 5: Metadata for the IDP 557 561 563 nfs/fileserver.rp.com@RP.COM 564 565 567 Figure 6: Metadata for the RP 569 4.4. Use of XML Signatures 571 This binding calls for the use of SAML elements that support XML 572 signatures. To promote interoperability, implementations of this 573 binding MUST support a default configuration that does not require 574 the use of XML signatures. Implementations MAY choose to use XML 575 signatures. 577 4.5. Metadata Considerations 579 These binding and profiles are mostly intended to be used without 580 metadata. In this usage, RADIUS infrastructure is used to provide 581 integrity and naming of the SAML messages and assertions. RADIUS 582 configuration is used to provide policy, including which attributes 583 are accepted from a Relying Party and which attributes are sent by an 584 Identity Provider. 586 Nevertheless, if metadata is used, the roles describe in section 587 Section 4.3.3 MUST be present. 589 5. Network Access Identifier Name Identifier Format 591 URI: urn:ietf:params:abfab:nameid-format:nai 593 Indicates that the content of the element is in the form of a Network 594 Access Identifier (NAI) using the syntax described by [RFC7542]. 596 6. RADIUS State Confirmation Method Identifiers 598 URI: urn:ietf:params:abfab:cm:user 600 URI: urn:ietf:params:abfab:cm:machine 602 Indicates that the Subject is the system entity (either the user or 603 machine) authenticated by a previously transmitted RADIUS Access- 604 Accept message, as identified by the value of that RADIUS message's 605 State attribute. 607 7. ABFAB Authentication Profile 609 In the scenario supported by the ABFAB Authentication Profile, a 610 Client controlling a User Agent requests access to a Relying Party. 611 The Relying Party uses RADIUS to authenticate the Client. In 612 particular, the Relying Party, acting as a RADIUS client, attempts to 613 validate the Client's credentials against a RADIUS server acting as 614 the Client's Identity Provider. If the Identity Provider 615 successfully authenticates the Client, it produces an authentication 616 assertion which is consumed by the Relying Party. This assertion MAY 617 include a name identifier that can be used between the Relying Party 618 and the Identity Provider to refer to the Client. 620 7.1. Required Information 622 Identification: urn:ietf:params:abfab:profiles:authentication 624 Contact information: iesg@ietf.org 626 SAML Confirmation Method Identifiers: The SAML V2.0 "RADIUS State" 627 confirmation method identifiers, either urn:ietf:params:abfab:cm:user 628 or urn:ietf:params:abfab:cm:machine, are used by this profile. 630 Updates: None. 632 7.2. Profile Overview 634 To implement this scenario, this profile of the SAML Authentication 635 Request protocol MUST be used in conjunction with the SAML RADIUS 636 binding defined in Section 4. 638 This profile is based on the SAML V2.0 Web Browser Single Sign-On 639 Profile [OASIS.saml-profiles-2.0-os]. There are some important 640 differences, specifically: 642 Authentication: This profile does not require the use of any 643 particular authentication method. The ABFAB architecture does 644 require the use of EAP [RFC3579], but this specification may be 645 used in other non-ABFAB scenarios. 647 Bindings: This profile does not use HTTP-based bindings. Instead 648 all SAML protocol messages are transported using the SAML RADIUS 649 binding defined in Section 4. This is intended to reduce the 650 number of bindings that implementations must support to be 651 interoperable. 653 Requests: The profile does not permit the Relying Party to name the 654 of the . This is intended to 655 simplify implementation and interoperability. 657 Responses: The profile only permits the Identity Provider to return 658 a single SAML message or assertion that MUST contain exactly one 659 authentication statement. Other statements may be included within 660 this assertion at the discretion of the Identity Provider. This 661 is intended to simplify implementation and interoperability. 663 Figure 7 below illustrates the flow of messages within this profile. 665 Client Relying Party Identity Provider 666 | | | 667 | (1) | | 668 | - - - - - - - - - > | | 669 | | | 670 | | (2) | 671 | | - - - - - - - - - - - - > | 672 | | | 673 | (3) | | 674 | < - - - - - - - - - |- - - - - - - - - - - - - >| 675 | | | 676 | | (4) | 677 | | < - - - - - - - - - - - - | 678 | | | 679 | (5) | | 680 | < - - - - - - - - - | | 681 | | | 682 V V V 684 The following steps are described by the profile. Within an 685 individual step, there may be one or more actual message exchanges. 687 Figure 7 689 1. Client request to Relying Party (Section 7.3.1): In step 1, the 690 Client, via a User Agent, makes a request for a secured resource 691 at the Relying Party. The Relying Party determines that no 692 security context for the Client exists and initiates the 693 authentication process. 695 2. Relying Party issues to Identity Provider 696 (Section 7.3.2). In step 2, the Relying Party may optionally 697 issue a message to be delivered to the 698 Identity Provider using the SAML-Protocol RADIUS attribute. 700 3. Identity Provider identifies Client (Section 7.3.3). In step 3, 701 the Client is authenticated and identified by the Identity 702 Provider, while honoring any requirements imposed by the Relying 703 Party in the message if provided. 705 4. Identity Provider issues to Relying Party 706 (Section 7.3.4). In step 4, the Identity Provider issues a 707 message to the Relying Party using the SAML 708 RADIUS binding. The response either indicates an error or 709 includes a SAML Authentication Statement in exactly one SAML 710 Assertion. If the RP did not send an , the 711 IdP issues an unsolicited , as described in 712 Section 7.4.4. 714 5. Relying Party grants or denies access to Client (Section 7.3.5). 715 In step 5, having received the response from the Identity 716 Provider, the Relying Party can respond to the Client with its 717 own error, or can establish its own security context for the 718 Client and return the requested resource. 720 7.3. Profile Description 722 The ABFAB Authentication Profile is a profile of the SAML V2.0 723 Authentication Request Protocol [OASIS.saml-core-2.0-os]. Where both 724 specifications conflict, the ABFAB Authentication Profile takes 725 precedence. 727 7.3.1. Client Request to Relying Party 729 The profile is initiated by an arbitrary Client request to the 730 Relying Party. There are no restrictions on the form of the request. 731 The Relying Party is free to use any means it wishes to associate the 732 subsequent interactions with the original request. The Relying 733 Party, acting as a RADIUS client, attempts to authenticate the 734 Client. 736 7.3.2. Relying Party Issues to Identity Provider 738 The Relying Party uses RADIUS to communicate with the Client's 739 Identity Provider. The Relying Party MAY include a 740 within this RADIUS Access-Request message using 741 the SAML-Protocol RADIUS attribute. The next hop destination MAY be 742 the Identity Provider or alternatively an intermediate RADIUS proxy. 744 Profile-specific rules for the contents of the 745 element are given in Section 7.4.1. 747 7.3.3. Identity Provider Identifies Client 749 The Identity Provider MUST establish the identity of the Client using 750 a RADIUS authentication method, or else it will return an error. If 751 the ForceAuthn attribute on the element (if sent 752 by the Relying Party) is present and true, the Identity Provider MUST 753 freshly establish this identity rather than relying on any existing 754 session state it may have with the Client (for example, TLS state 755 that may be used for session resumption). Otherwise, and in all 756 other respects, the Identity Provider may use any method to 757 authenticate the Client, subject to the constraints called out in the 758 message. 760 7.3.4. Identity Provider Issues to Relying Party 762 The Identity Provider MUST conclude the authentication in a manner 763 consistent with the RADIUS authentication result. The IdP MAY issue 764 a message to the Relying Party that is consistent 765 with the authentication result, as described in 766 [OASIS.saml-core-2.0-os]. This SAML response is delivered to the 767 Relying Party using the SAML RADIUS binding described in Section 4. 769 Profile-specific rules regarding the contents of the 770 element are given in Section 7.4.2. 772 7.3.5. Relying Party Grants or Denies Access to Client 774 If issued by the Identity Provider, the Relying Party MUST process 775 the message and any enclosed assertion elements as 776 described in [OASIS.saml-core-2.0-os]. Any subsequent use of the 777 assertion elements is at the discretion of the Relying Party, subject 778 to any restrictions contained within the assertions themselves or 779 from any previously established out-of-band policy that governs the 780 interaction between the Identity Provider and the Relying Party. 782 7.4. Use of Authentication Request Protocol 784 This profile is based on the Authentication Request Protocol defined 785 in [OASIS.saml-core-2.0-os]. In the nomenclature of actors 786 enumerated in section 3.4 of that document, the Relying Party is the 787 requester, the User Agent is the attesting entity and the Client is 788 the Requested Subject. 790 7.4.1. Usage 792 The Relying Party MUST NOT include a element in the 793 request. The authenticated RADIUS identity identifies the Client to 794 the Identity Provider. 796 A Relying Party MAY include any message content described in 797 [OASIS.saml-core-2.0-os], section 3.4.1. All processing rules are as 798 defined in [OASIS.saml-core-2.0-os]. 800 If the Relying Party wishes to permit the Identity Provider to 801 establish a new identifier for the Client if none exists, it MUST 802 include a element with the AllowCreate attribute 803 set to "true". Otherwise, only a Client for whom the Identity 804 Provider has previously established an identifier usable by the 805 Relying Party can be authenticated successfully. 807 The message MAY be signed. Authentication and 808 integrity are also provided by the SAML RADIUS binding. 810 7.4.2. Message Usage 812 If the Identity Provider cannot or will not satisfy the request, it 813 MUST either respond with a message containing an 814 appropriate error status code or codes and/or respond with a RADIUS 815 Access-Reject message. 817 If the Identity Provider wishes to return an error, it MUST NOT 818 include any assertions in the message. Otherwise, 819 if the request is successful (or if the response is not associated 820 with a request), the element is subject to the 821 following constraints: 823 o It MAY be signed. 825 o It MUST contain exactly one assertion. The element 826 of this assertion MUST refer to the authenticated RADIUS user. 828 o The assertion MUST contain a . Besides, the 829 assertion MUST contain a element with at least one 830 element containing a Method of 831 urn:ietf:params:abfab:cm:user or urn:ietf:params:abfab:cm:machine 832 that reflects the authentication of the Client to the Identity 833 Provider. Since the containing message is in response to an 834 , the InResponseTo attribute (both in the 835 and in the 836 elements) MUST match the request's ID. The element 837 MAY use the NAI Name Identifier Format described in Section 5 to 838 establish an identifier between the Relying Party and the IdP. 840 o Other conditions MAY be included as requested by the Relying Party 841 or at the discretion of the Identity Provider. The Identity 842 Provider is NOT obligated to honor the requested set of conditions 843 in the , if any. 845 7.4.3. Message Processing Rules 847 The Relying Party MUST do the following: 849 o Assume that the Client's identifier implied by a SAML 850 element, if present, takes precedence over an identifier implied 851 by the RADIUS User-Name attribute. 853 o Verify that the InResponseTo attribute in the "RADIUS State" 854 equals the ID of its original 855 message, unless the response is unsolicited, 856 in which case the attribute MUST NOT be present. 858 o If a used to establish a security context 859 for the Client contains a SessionNotOnOrAfter attribute, the 860 security context SHOULD be discarded once this time is reached, 861 unless the Relying Party reestablishes the Client's identity by 862 repeating the use of this profile. 864 o Verify that any assertions relied upon are valid according to 865 processing rules in [OASIS.saml-core-2.0-os]. 867 o Any assertion which is not valid, or whose subject confirmation 868 requirements cannot be met MUST be discarded and MUST NOT be used 869 to establish a security context for the Client. 871 7.4.4. Unsolicited Responses 873 An Identity Provider MAY initiate this profile by delivering an 874 unsolicited assertion to a Relying Party. This MUST NOT contain any 875 elements containing an InResponseTo 876 attribute. 878 7.4.5. Use of the SAML RADIUS Binding 880 It is RECOMMENDED that the RADIUS exchange is protected using TLS 881 encryption for RADIUS [RFC6614] to provide confidentiality and 882 integrity protection. 884 7.4.6. Use of XML Signatures 886 This profile calls for the use of SAML elements that support XML 887 signatures. To promote interoperability implementations of this 888 profile MUST NOT require the use of XML signatures. Implementations 889 MAY choose to use XML signatures. 891 7.4.7. Metadata Considerations 893 There are no metadata considerations particular to this profile, 894 aside from those applying to the use of the RADIUS binding. 896 8. ABFAB Assertion Query/Request Profile 898 This profile builds on the SAML V2.0 Assertion Query/Request Profile 899 defined by [OASIS.saml-profiles-2.0-os]. That profile describes the 900 use of the Assertion Query and Request Protocol defined by section 901 3.3 of [OASIS.saml-core-2.0-os] with synchronous bindings, such as 902 the SOAP binding defined in [OASIS.saml-bindings-2.0-os]. 904 While the SAML V2.0 Assertion Query/Request Profile is independent of 905 the underlying binding, it is nonetheless useful to describe the use 906 of the SAML RADIUS binding defined in Section 4 of this document, in 907 the interests of promoting interoperable implementations, 908 particularly as the SAML V2.0 Assertion Query/Request Profile is most 909 frequently discussed and implemented in the context of the SOAP 910 binding. 912 8.1. Required Information 914 Identification: urn:ietf:params:abfab:profiles:query 916 Contact information: iesg@ietf.org 918 Description: Given below. 920 Updates: None. 922 8.2. Profile Overview 924 As with the SAML V2.0 Assertion Query/Request Profile defined by 925 [OASIS.saml-profiles-2.0-os] the message exchange and basic 926 processing rules that govern this profile are largely defined by 927 Section 3.3 of [OASIS.saml-core-2.0-os] that defines the messages to 928 be exchanged, in combination with the binding used to exchange the 929 messages. The SAML RADIUS binding described in this document defines 930 the binding of the message exchange to RADIUS. Unless specifically 931 noted here, all requirements defined in those specifications apply. 933 Figure 8 below illustrates the basic template for the query/request 934 profile. 936 Relying Party Identity Provider 937 (SAML requester) (SAML responder) 938 | | 939 | (1) | 940 | - - - - - - - - - - - - - - - - - - - - - - - > | 941 | | 942 | (2) | 943 | < - - - - - - - - - - - - - - - - - - - - - - - | 944 | | 945 V V 947 The following steps are described by the profile. 949 Figure 8 951 1. Query/Request issued by Relying Party: In step 1, a Relying Party 952 initiates the profile by sending an , 953 , , , or 954 message to a SAML authority. 956 2. issued by SAML Authority: In step 2, the responding 957 SAML authority (after processing the query or request) issues a 958 message to the Relying Party. 960 8.3. Profile Description 962 8.3.1. Differences from the SAML V2.0 Assertion Query/Request Profile 964 This profile is identical to the SAML V2.0 Assertion Query/Request 965 Profile, with the following exceptions: 967 o When processing the SAML request, the IdP MUST give precedence to 968 the Client's identifier implied by RADIUS State attribute, if 969 present, over the identifier implied by the SAML request's 970 , if any. 972 o In respect to sections 6.3.1 and 6.5 of 973 [OASIS.saml-profiles-2.0-os], this profile does not consider the 974 use of metadata (as in [OASIS.saml-metadata-2.0-os]). See 975 Section 8.3.4. 977 o In respect to sections 6.3.2, 6.4.1, and 6.4.2 of 978 [OASIS.saml-profiles-2.0-os], this profile additionally stipulates 979 that implementations of this profile MUST NOT require the use of 980 XML signatures. See Section 8.3.3. 982 8.3.2. Use of the SAML RADIUS Binding 984 The RADIUS Access-Request sent by the Relying Party: 986 o MUST include an instance of the RADIUS Service-Type attribute, 987 having a value of Authorize-Only. 989 o SHOULD include the RADIUS State attribute, where this Query/ 990 Request pertains to previously authenticated Client. 992 When processing the SAML request, the IdP MUST give precedence to the 993 Client's identifier implied by RADIUS State attribute over the 994 identifier implied by the SAML request's , if any. 996 It is RECOMMENDED that the RADIUS exchange is protected using TLS 997 encryption for RADIUS [RFC6614] to provide confidentiality and 998 integrity protection. 1000 8.3.3. Use of XML Signatures 1002 This profile calls for the use of SAML elements that support XML 1003 signatures. To promote interoperability implementations of this 1004 profile MUST NOT require the use of XML signatures. Implementations 1005 MAY choose to use XML signatures. 1007 8.3.4. Metadata Considerations 1009 There are no metadata considerations particular to this profile, 1010 aside from those applying to the use of the RADIUS binding. 1012 9. Privacy considerations 1014 The profiles defined in this document allow a Relying Party to 1015 request specific information about the Client, and allow an IdP to 1016 disclose information about that Client. In this sense, Identity 1017 Providers MUST apply policy to decide what information is released to 1018 a particular Relying Party. Moreover, the identity of the Client is 1019 typically hidden from the Relying Party unless informed by the 1020 Identity Provider. Conversely, the Relying Party does typically know 1021 the realm of the IdP, as it is required to route the RADIUS packets 1022 to the right destination. 1024 The kind of information that is released by the IdP MAY include 1025 generic attributes such as affiliation shared by many Clients. But 1026 even these generic attributes can help to identify a specific Client. 1027 Other kinds of attributes MAY also provide a Relying Party with the 1028 ability to link the same Client between different sessions. Finally, 1029 other kind of attributes MAY provide a group of Relying Parties with 1030 the ability to link the Client between them or with personally 1031 identifiable information about the Client. 1033 These profiles do not directly provide a Client with a mechanism to 1034 express preferences about what information is released. That 1035 information can be expressed out-of-band, for example as part of the 1036 enrollment process. 1038 The Relying Party MAY disclose privacy-sensitive information about 1039 itself as part of the request, although this is unlikely in typical 1040 deployments. 1042 If RADIUS proxies are used and encryption is not used, the attributes 1043 disclosed by the IdP are visible to the proxies. This is a 1044 significant privacy exposure in some deployments. Ongoing work is 1045 exploring mechanisms for creating TLS connections directly between 1046 the RADIUS client and the RADIUS server to reduce this exposure. If 1047 proxies are used, the impact of exposing SAML assertions to the 1048 proxies needs to be carefully considered. 1050 The use of TLS to provide confidentiality for the RADIUS exchange is 1051 strongly encouraged. Without this, passive eavesdroppers can observe 1052 the assertions. 1054 10. Security Considerations 1056 In this specification, the Relying Party MUST trust any statement in 1057 the SAML messages from the IdP in the same way that it trusts 1058 information contained in RADIUS attributes. These entities MUST 1059 trust the RADIUS infrastructure to provide integrity of the SAML 1060 messages. 1062 Furthermore, the Relying Party MUST apply policy and filter the 1063 information based on what information the IdP is permitted to assert 1064 and on what trust is reasonable to place in proxies between them. 1066 XML signatures and encryption are provided as an OPTIONAL mechanism 1067 for end-to-end security. These mechanism can protect SAML messages 1068 from being modified by proxies in the RADIUS infrastructure. These 1069 mechanisms are not mandatory-to-implement. It is believed that 1070 ongoing work to provide direct TLS connections between a RADIUS 1071 client and RADIUS server will provide similar assurances but better 1072 deployability. XML security is appropriate for deployments where 1073 end-to-end security is required but proxies cannot be removed or 1074 where SAML messages need to be verified at a later time or by parties 1075 not involved in the authentication exchange. 1077 11. IANA Considerations 1079 11.1. RADIUS Attributes 1081 The authors request that Attribute Types and Attribute Values defined 1082 in this document be registered by the Internet Assigned Numbers 1083 Authority (IANA) from the RADIUS namespaces as described in the "IANA 1084 Considerations" section of [RFC3575], in accordance with BCP 26 1085 [RFC5226]. For RADIUS packets, attributes and registries created by 1086 this document IANA is requested to place them at 1087 http://www.iana.org/assignments/radius-types. 1089 In particular, this document defines two new RADIUS attributes, 1090 entitled "SAML-Assertion" and "SAML-Protocol" (see Section 3), with 1091 assigned values of 245.TBD1 and 245.TBD2 from the Long Extended Space 1092 of [RFC6929]: 1094 Type Ext. Type Name Length Meaning 1095 ---- --------- -------------- ------ ------------------------ 1096 245 TBD1 SAML-Assertion >=5 Encodes a SAML assertion 1097 245 TBD2 SAML-Protocol >=5 Encodes a SAML protocol 1098 message 1100 11.2. ABFAB Parameters 1102 A new top-level registry is created titled "ABFAB Parameters". 1104 In this top-level registry, a sub-registry titled "ABFAB URN 1105 Parameters" is created. Registration in this registry is by the IETF 1106 review or expert review procedures [RFC5226]. 1108 This paragraph gives guidance to designated experts. Registrations 1109 in this registry are generally only expected as part of protocols 1110 published as RFCs on the IETF stream; other URIs are expected to be 1111 better choices for non-IETF work. Expert review is permitted mainly 1112 to allow early registration related to specifications under 1113 development when the community believes they have reached sufficient 1114 maturity. The expert SHOULD evaluate the maturity and stability of 1115 such an IETF-stream specification. Experts SHOULD review anything 1116 not from the IETF stream for consistency and consensus with current 1117 practice. Today such requests would not typically be approved. 1119 If a parameter named "paramname" is to be registered in this 1120 registry, then its URN will be "urn:ietf:params:abfab:paramname". 1121 The initial registrations are as follows: 1123 +-------------------------+-----------+ 1124 | Parameter | Reference | 1125 +-------------------------+-----------+ 1126 | bindings:radius | Section 4 | 1127 | nameid-format:nai | Section 5 | 1128 | profiles:authentication | Section 7 | 1129 | profiles:query | Section 8 | 1130 | cm:user | Section 6 | 1131 | cm:machine | Section 6 | 1132 +-------------------------+-----------+ 1134 ABFAB Parameters 1136 11.3. Registration of the ABFAB URN Namespace 1138 IANA is requested to register the "abfab" URN sub-namespace in the 1139 IETF URN sub-namespace for protocol parameters defined in [RFC3553]. 1141 Registry Name: abfab 1143 Specification: draft-ietf-abfab-aaa-saml 1145 Repository: ABFAB URN Parameters (Section Section 11.2) 1147 Index Value: Sub-parameters MUST be specified in UTF-8 using standard 1148 URI encoding where necessary. 1150 12. Acknowledgements 1152 The authors would like to acknowledge the OASIS Security Services 1153 (SAML) Technical Committee, and Scott Cantor in particular, for their 1154 help with the SAML-related material. 1156 The authors would also like to acknowledge the collaboration of Jim 1157 Schaad, Leif Johansson, Klaas Wierenga, Stephen Farell, Gabriel 1158 Lopez, and Rafael Marin, who have provided valuable comments on this 1159 document. 1161 13. References 1163 13.1. Normative References 1165 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1166 Requirement Levels", BCP 14, RFC 2119, 1167 DOI 10.17487/RFC2119, March 1997, 1168 . 1170 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 1171 "Remote Authentication Dial In User Service (RADIUS)", 1172 RFC 2865, DOI 10.17487/RFC2865, June 2000, 1173 . 1175 [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication 1176 Dial In User Service) Support For Extensible 1177 Authentication Protocol (EAP)", RFC 3579, 1178 DOI 10.17487/RFC3579, September 2003, 1179 . 1181 [RFC6614] Winter, S., McCauley, M., Venaas, S., and K. Wierenga, 1182 "Transport Layer Security (TLS) Encryption for RADIUS", 1183 RFC 6614, DOI 10.17487/RFC6614, May 2012, 1184 . 1186 [RFC6929] DeKok, A. and A. Lior, "Remote Authentication Dial In User 1187 Service (RADIUS) Protocol Extensions", RFC 6929, 1188 DOI 10.17487/RFC6929, April 2013, 1189 . 1191 [RFC3575] Aboba, B., "IANA Considerations for RADIUS (Remote 1192 Authentication Dial In User Service)", RFC 3575, 1193 DOI 10.17487/RFC3575, July 2003, 1194 . 1196 [RFC7542] DeKok, A., "The Network Access Identifier", RFC 7542, 1197 DOI 10.17487/RFC7542, May 2015, 1198 . 1200 [OASIS.saml-bindings-2.0-os] 1201 Cantor, S., Hirsch, F., Kemp, J., Philpott, R., and E. 1202 Maler, "Bindings for the OASIS Security Assertion Markup 1203 Language (SAML) V2.0", OASIS Standard saml-bindings- 1204 2.0-os, March 2005. 1206 [OASIS.saml-core-2.0-os] 1207 Cantor, S., Kemp, J., Philpott, R., and E. Maler, 1208 "Assertions and Protocol for the OASIS Security Assertion 1209 Markup Language (SAML) V2.0", OASIS Standard saml-core- 1210 2.0-os, March 2005. 1212 [OASIS.saml-profiles-2.0-os] 1213 Hughes, J., Cantor, S., Hodges, J., Hirsch, F., Mishra, 1214 P., Philpott, R., and E. Maler, "Profiles for the OASIS 1215 Security Assertion Markup Language (SAML) V2.0", OASIS 1216 Standard OASIS.saml-profiles-2.0-os, March 2005. 1218 [OASIS.saml-metadata-2.0-os] 1219 Cantor, S., Moreh, J., Philpott, R., and E. Maler, 1220 "Metadata for the Security Assertion Markup Language 1221 (SAML) V2.0", OASIS Standard saml-metadata-2.0-os, March 1222 2005. 1224 13.2. Informative References 1226 [RFC3553] Mealling, M., Masinter, L., Hardie, T., and G. Klyne, "An 1227 IETF URN Sub-namespace for Registered Protocol 1228 Parameters", BCP 73, RFC 3553, DOI 10.17487/RFC3553, June 1229 2003, . 1231 [RFC6733] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn, 1232 Ed., "Diameter Base Protocol", RFC 6733, 1233 DOI 10.17487/RFC6733, October 2012, 1234 . 1236 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1237 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1238 DOI 10.17487/RFC5226, May 2008, 1239 . 1241 [RFC7055] Hartman, S., Ed. and J. Howlett, "A GSS-API Mechanism for 1242 the Extensible Authentication Protocol", RFC 7055, 1243 DOI 10.17487/RFC7055, December 2013, 1244 . 1246 [RFC7499] Perez-Mendez, A., Ed., Marin-Lopez, R., Pereniguez-Garcia, 1247 F., Lopez-Millan, G., Lopez, D., and A. DeKok, "Support of 1248 Fragmentation of RADIUS Packets", RFC 7499, 1249 DOI 10.17487/RFC7499, April 2015, 1250 . 1252 [I-D.ietf-abfab-arch] 1253 Howlett, J., Hartman, S., Tschofenig, H., Lear, E., and J. 1254 Schaad, "Application Bridging for Federated Access Beyond 1255 Web (ABFAB) Architecture", draft-ietf-abfab-arch-13 (work 1256 in progress), July 2014. 1258 [I-D.ietf-radext-bigger-packets] 1259 Hartman, S., "Larger Packets for RADIUS over TCP", draft- 1260 ietf-radext-bigger-packets-05 (work in progress), December 1261 2015. 1263 [W3C.REC-xmlschema-1] 1264 Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn, 1265 "XML Schema Part 1: Structures", W3C REC-xmlschema-1, May 1266 2001, . 1268 Appendix A. XML Schema 1270 The following schema formally defines the 1271 "urn:ietf:params:xml:ns:abfab" namespace used in this document, in 1272 conformance with [W3C.REC-xmlschema-1] While XML validation is 1273 optional, the schema that follows is the normative definition of the 1274 constructs it defines. Where the schema differs from any prose in 1275 this specification, the schema takes precedence. 1277 1287 1289 1290 1291 1292 1293 1294 1295 1296 1297 1298 1299 1300 1302 1303 1304 1305 1306 1307 1308 1309 1310 1311 1312 1313 1314 1315 1316 1317 1319 1321 Authors' Addresses 1323 Josh Howlett 1324 Janet 1325 Lumen House, Library Avenue, Harwell 1326 Oxford OX11 0SG 1327 UK 1329 Phone: +44 1235 822363 1330 EMail: Josh.Howlett@ja.net 1332 Sam Hartman 1333 Painless Security 1335 EMail: hartmans-ietf@mit.edu 1337 Alejandro Perez-Mendez (editor) 1338 University of Murcia 1339 Campus de Espinardo S/N, Faculty of Computer Science 1340 Murcia 30100 1341 Spain 1343 Phone: +34 868 88 46 44 1344 EMail: alex@um.es