idnits 2.17.1 draft-ietf-abfab-aaa-saml-14.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 (January 11, 2016) is 3029 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: July 14, 2016 Painless Security 6 A. Perez-Mendez, Ed. 7 University of Murcia 8 January 11, 2016 10 A RADIUS Attribute, Binding, Profiles, Name Identifier Format, and 11 Confirmation Methods for SAML 12 draft-ietf-abfab-aaa-saml-14 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 July 14, 2016. 50 Copyright Notice 52 Copyright (c) 2016 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 . . . . . . . . . . . . . 18 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 . . . . . . . . . . . . . . . . 20 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 [OASIS.saml-core-2.0-os]. Owing to the typical size of these 219 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 a message is issued by the Identity Provider, the 775 Relying Party MUST process that message and any enclosed assertion 776 elements as described in [OASIS.saml-core-2.0-os]. Any subsequent 777 use of the assertion elements is at the discretion of the Relying 778 Party, subject to any restrictions contained within the assertions 779 themselves or from any previously established out-of-band policy that 780 governs the interaction between the Identity Provider and the Relying 781 Party. 783 7.4. Use of Authentication Request Protocol 785 This profile is based on the Authentication Request Protocol defined 786 in [OASIS.saml-core-2.0-os]. In the nomenclature of actors 787 enumerated in section 3.4 of that document, the Relying Party is the 788 requester, the User Agent is the attesting entity and the Client is 789 the Requested Subject. 791 7.4.1. Usage 793 The Relying Party MUST NOT include a element in the 794 request. The authenticated RADIUS identity identifies the Client to 795 the Identity Provider. 797 A Relying Party MAY include any message content described in 798 [OASIS.saml-core-2.0-os], section 3.4.1. All processing rules are as 799 defined in [OASIS.saml-core-2.0-os]. 801 If the Relying Party wishes to permit the Identity Provider to 802 establish a new identifier for the Client if none exists, it MUST 803 include a element with the AllowCreate attribute 804 set to "true". Otherwise, only a Client for whom the Identity 805 Provider has previously established an identifier usable by the 806 Relying Party can be authenticated successfully. 808 The message MAY be signed. Authentication and 809 integrity are also provided by the SAML RADIUS binding. 811 7.4.2. Message Usage 813 If the Identity Provider cannot or will not satisfy the request, it 814 MUST either respond with a message containing an 815 appropriate error status code or codes and/or respond with a RADIUS 816 Access-Reject message. 818 If the Identity Provider wishes to return an error, it MUST NOT 819 include any assertions in the message. Otherwise, 820 if the request is successful (or if the response is not associated 821 with a request), the element is subject to the 822 following constraints: 824 o It MAY be signed. 826 o It MUST contain exactly one assertion. The element 827 of this assertion MUST refer to the authenticated RADIUS user. 829 o The assertion MUST contain a . Besides, the 830 assertion MUST contain a element with at least one 831 element containing a Method of 832 urn:ietf:params:abfab:cm:user or urn:ietf:params:abfab:cm:machine 833 that reflects the authentication of the Client to the Identity 834 Provider. Since the containing message is in response to an 835 , the InResponseTo attribute (both in the 836 and in the 837 elements) MUST match the request's ID. The element 838 MAY use the NAI Name Identifier Format described in Section 5 to 839 establish an identifier between the Relying Party and the IdP. 841 o Other conditions MAY be included as requested by the Relying Party 842 or at the discretion of the Identity Provider. The Identity 843 Provider is NOT obligated to honor the requested set of conditions 844 in the , if any. 846 7.4.3. Message Processing Rules 848 The Relying Party MUST do the following: 850 o Assume that the Client's identifier implied by a SAML 851 element, if present, takes precedence over an identifier implied 852 by the RADIUS User-Name attribute. 854 o Verify that the InResponseTo attribute in the "RADIUS State" 855 equals the ID of its original 856 message, unless the response is unsolicited, 857 in which case the attribute MUST NOT be present. 859 o If a used to establish a security context 860 for the Client contains a SessionNotOnOrAfter attribute, the 861 security context SHOULD be discarded once this time is reached, 862 unless the Relying Party reestablishes the Client's identity by 863 repeating the use of this profile. 865 o Verify that any assertions relied upon are valid according to 866 processing rules in [OASIS.saml-core-2.0-os]. 868 o Any assertion which is not valid, or whose subject confirmation 869 requirements cannot be met MUST be discarded and MUST NOT be used 870 to establish a security context for the Client. 872 7.4.4. Unsolicited Responses 874 An Identity Provider MAY initiate this profile by delivering an 875 unsolicited assertion to a Relying Party. This MUST NOT contain any 876 elements containing an InResponseTo 877 attribute. 879 7.4.5. Use of the SAML RADIUS Binding 881 It is RECOMMENDED that the RADIUS exchange is protected using TLS 882 encryption for RADIUS [RFC6614] to provide confidentiality and 883 integrity protection. 885 7.4.6. Use of XML Signatures 887 This profile calls for the use of SAML elements that support XML 888 signatures. To promote interoperability implementations of this 889 profile MUST NOT require the use of XML signatures. Implementations 890 MAY choose to use XML signatures. 892 7.4.7. Metadata Considerations 894 There are no metadata considerations particular to this profile, 895 aside from those applying to the use of the RADIUS binding. 897 8. ABFAB Assertion Query/Request Profile 899 This profile builds on the SAML V2.0 Assertion Query/Request Profile 900 defined by [OASIS.saml-profiles-2.0-os]. That profile describes the 901 use of the Assertion Query and Request Protocol defined by section 902 3.3 of [OASIS.saml-core-2.0-os] with synchronous bindings, such as 903 the SOAP binding defined in [OASIS.saml-bindings-2.0-os]. 905 While the SAML V2.0 Assertion Query/Request Profile is independent of 906 the underlying binding, it is nonetheless useful to describe the use 907 of the SAML RADIUS binding defined in Section 4 of this document, in 908 the interests of promoting interoperable implementations, 909 particularly as the SAML V2.0 Assertion Query/Request Profile is most 910 frequently discussed and implemented in the context of the SOAP 911 binding. 913 8.1. Required Information 915 Identification: urn:ietf:params:abfab:profiles:query 917 Contact information: iesg@ietf.org 919 Description: Given below. 921 Updates: None. 923 8.2. Profile Overview 925 As with the SAML V2.0 Assertion Query/Request Profile defined by 926 [OASIS.saml-profiles-2.0-os] the message exchange and basic 927 processing rules that govern this profile are largely defined by 928 Section 3.3 of [OASIS.saml-core-2.0-os] that defines the messages to 929 be exchanged, in combination with the binding used to exchange the 930 messages. The SAML RADIUS binding described in this document defines 931 the binding of the message exchange to RADIUS. Unless specifically 932 noted here, all requirements defined in those specifications apply. 934 Figure 8 below illustrates the basic template for the query/request 935 profile. 937 Relying Party Identity Provider 938 (SAML requester) (SAML responder) 939 | | 940 | (1) | 941 | - - - - - - - - - - - - - - - - - - - - - - - > | 942 | | 943 | (2) | 944 | < - - - - - - - - - - - - - - - - - - - - - - - | 945 | | 946 V V 948 The following steps are described by the profile. 950 Figure 8 952 1. Query/Request issued by Relying Party: In step 1, a Relying Party 953 initiates the profile by sending an , 954 , , , or 955 message to a SAML authority. 957 2. issued by SAML Authority: In step 2, the responding 958 SAML authority (after processing the query or request) issues a 959 message to the Relying Party. 961 8.3. Profile Description 963 8.3.1. Differences from the SAML V2.0 Assertion Query/Request Profile 965 This profile is identical to the SAML V2.0 Assertion Query/Request 966 Profile, with the following exceptions: 968 o When processing the SAML request, the IdP MUST give precedence to 969 the Client's identifier implied by RADIUS State attribute, if 970 present, over the identifier implied by the SAML request's 971 , if any. 973 o In respect to sections 6.3.1 and 6.5 of 974 [OASIS.saml-profiles-2.0-os], this profile does not consider the 975 use of metadata (as in [OASIS.saml-metadata-2.0-os]). See 976 Section 8.3.4. 978 o In respect to sections 6.3.2, 6.4.1, and 6.4.2 of 979 [OASIS.saml-profiles-2.0-os], this profile additionally stipulates 980 that implementations of this profile MUST NOT require the use of 981 XML signatures. See Section 8.3.3. 983 8.3.2. Use of the SAML RADIUS Binding 985 The RADIUS Access-Request sent by the Relying Party: 987 o MUST include an instance of the RADIUS Service-Type attribute, 988 having a value of Authorize-Only. 990 o SHOULD include the RADIUS State attribute, where this Query/ 991 Request pertains to previously authenticated Client. 993 When processing the SAML request, the IdP MUST give precedence to the 994 Client's identifier implied by RADIUS State attribute over the 995 identifier implied by the SAML request's , if any. 997 It is RECOMMENDED that the RADIUS exchange is protected using TLS 998 encryption for RADIUS [RFC6614] to provide confidentiality and 999 integrity protection. 1001 8.3.3. Use of XML Signatures 1003 This profile calls for the use of SAML elements that support XML 1004 signatures. To promote interoperability implementations of this 1005 profile MUST NOT require the use of XML signatures. Implementations 1006 MAY choose to use XML signatures. 1008 8.3.4. Metadata Considerations 1010 There are no metadata considerations particular to this profile, 1011 aside from those applying to the use of the RADIUS binding. 1013 9. Privacy considerations 1015 The profiles defined in this document allow a Relying Party to 1016 request specific information about the Client, and allow an IdP to 1017 disclose information about that Client. In this sense, Identity 1018 Providers MUST apply policy to decide what information is released to 1019 a particular Relying Party. Moreover, the identity of the Client is 1020 typically hidden from the Relying Party unless informed by the 1021 Identity Provider. Conversely, the Relying Party does typically know 1022 the realm of the IdP, as it is required to route the RADIUS packets 1023 to the right destination. 1025 The kind of information that is released by the IdP can include 1026 generic attributes such as affiliation shared by many Clients. But 1027 even these generic attributes can help to identify a specific Client. 1028 Other kinds of attributes may also provide a Relying Party with the 1029 ability to link the same Client between different sessions. Finally, 1030 other kind of attributes might provide a group of Relying Parties 1031 with the ability to link the Client between them or with personally 1032 identifiable information about the Client. 1034 These profiles do not directly provide a Client with a mechanism to 1035 express preferences about what information is released. That 1036 information can be expressed out-of-band, for example as part of the 1037 enrollment process. 1039 The Relying Party may disclose privacy-sensitive information about 1040 itself as part of the request, although this is unlikely in typical 1041 deployments. 1043 If RADIUS proxies are used and encryption is not used, the attributes 1044 disclosed by the IdP are visible to the proxies. This is a 1045 significant privacy exposure in some deployments. Ongoing work is 1046 exploring mechanisms for creating TLS connections directly between 1047 the RADIUS client and the RADIUS server to reduce this exposure. If 1048 proxies are used, the impact of exposing SAML assertions to the 1049 proxies needs to be carefully considered. 1051 The use of TLS to provide confidentiality for the RADIUS exchange is 1052 strongly encouraged. Without this, passive eavesdroppers can observe 1053 the assertions. 1055 10. Security Considerations 1057 In this specification, the Relying Party MUST trust any statement in 1058 the SAML messages from the IdP in the same way that it trusts 1059 information contained in RADIUS attributes. These entities MUST 1060 trust the RADIUS infrastructure to provide integrity of the SAML 1061 messages. 1063 Furthermore, the Relying Party MUST apply policy and filter the 1064 information based on what information the IdP is permitted to assert 1065 and on what trust is reasonable to place in proxies between them. 1067 XML signatures and encryption are provided as an OPTIONAL mechanism 1068 for end-to-end security. These mechanism can protect SAML messages 1069 from being modified by proxies in the RADIUS infrastructure. These 1070 mechanisms are not mandatory-to-implement. It is believed that 1071 ongoing work to provide direct TLS connections between a RADIUS 1072 client and RADIUS server will provide similar assurances but better 1073 deployability. XML security is appropriate for deployments where 1074 end-to-end security is required but proxies cannot be removed or 1075 where SAML messages need to be verified at a later time or by parties 1076 not involved in the authentication exchange. 1078 11. IANA Considerations 1080 11.1. RADIUS Attributes 1082 The authors request that Attribute Types and Attribute Values defined 1083 in this document be registered by the Internet Assigned Numbers 1084 Authority (IANA) from the RADIUS namespaces as described in the "IANA 1085 Considerations" section of [RFC3575], in accordance with BCP 26 1086 [RFC5226]. For RADIUS packets, attributes and registries created by 1087 this document IANA is requested to place them at 1088 http://www.iana.org/assignments/radius-types. 1090 In particular, this document defines two new RADIUS attributes, 1091 entitled "SAML-Assertion" and "SAML-Protocol" (see Section 3), with 1092 assigned values of 245.TBD1 and 245.TBD2 from the Long Extended Space 1093 of [RFC6929]: 1095 Type Ext. Type Name Length Meaning 1096 ---- --------- -------------- ------ ------------------------ 1097 245 TBD1 SAML-Assertion >=5 Encodes a SAML assertion 1098 245 TBD2 SAML-Protocol >=5 Encodes a SAML protocol 1099 message 1101 11.2. ABFAB Parameters 1103 A new top-level registry is created titled "ABFAB Parameters". 1105 In this top-level registry, a sub-registry titled "ABFAB URN 1106 Parameters" is created. Registration in this registry is by the IETF 1107 review or expert review procedures [RFC5226]. 1109 This paragraph gives guidance to designated experts. Registrations 1110 in this registry are generally only expected as part of protocols 1111 published as RFCs on the IETF stream; other URIs are expected to be 1112 better choices for non-IETF work. Expert review is permitted mainly 1113 to allow early registration related to specifications under 1114 development when the community believes they have reached sufficient 1115 maturity. The expert SHOULD evaluate the maturity and stability of 1116 such an IETF-stream specification. Experts SHOULD review anything 1117 not from the IETF stream for consistency and consensus with current 1118 practice. Today such requests would not typically be approved. 1120 If a parameter named "paramname" is to be registered in this 1121 registry, then its URN will be "urn:ietf:params:abfab:paramname". 1122 The initial registrations are as follows: 1124 +-------------------------+-----------+ 1125 | Parameter | Reference | 1126 +-------------------------+-----------+ 1127 | bindings:radius | Section 4 | 1128 | nameid-format:nai | Section 5 | 1129 | profiles:authentication | Section 7 | 1130 | profiles:query | Section 8 | 1131 | cm:user | Section 6 | 1132 | cm:machine | Section 6 | 1133 +-------------------------+-----------+ 1135 ABFAB Parameters 1137 11.3. Registration of the ABFAB URN Namespace 1139 IANA is requested to register the "abfab" URN sub-namespace in the 1140 IETF URN sub-namespace for protocol parameters defined in [RFC3553]. 1142 Registry Name: abfab 1144 Specification: draft-ietf-abfab-aaa-saml 1146 Repository: ABFAB URN Parameters (Section Section 11.2) 1148 Index Value: Sub-parameters MUST be specified in UTF-8 using standard 1149 URI encoding where necessary. 1151 12. Acknowledgements 1153 The authors would like to acknowledge the OASIS Security Services 1154 (SAML) Technical Committee, and Scott Cantor in particular, for their 1155 help with the SAML-related material. 1157 The authors would also like to acknowledge the collaboration of Jim 1158 Schaad, Leif Johansson, Klaas Wierenga, Stephen Farell, Gabriel 1159 Lopez, and Rafael Marin, who have provided valuable comments on this 1160 document. 1162 13. References 1164 13.1. Normative References 1166 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1167 Requirement Levels", BCP 14, RFC 2119, 1168 DOI 10.17487/RFC2119, March 1997, 1169 . 1171 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 1172 "Remote Authentication Dial In User Service (RADIUS)", 1173 RFC 2865, DOI 10.17487/RFC2865, June 2000, 1174 . 1176 [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication 1177 Dial In User Service) Support For Extensible 1178 Authentication Protocol (EAP)", RFC 3579, 1179 DOI 10.17487/RFC3579, September 2003, 1180 . 1182 [RFC6614] Winter, S., McCauley, M., Venaas, S., and K. Wierenga, 1183 "Transport Layer Security (TLS) Encryption for RADIUS", 1184 RFC 6614, DOI 10.17487/RFC6614, May 2012, 1185 . 1187 [RFC6929] DeKok, A. and A. Lior, "Remote Authentication Dial In User 1188 Service (RADIUS) Protocol Extensions", RFC 6929, 1189 DOI 10.17487/RFC6929, April 2013, 1190 . 1192 [RFC3575] Aboba, B., "IANA Considerations for RADIUS (Remote 1193 Authentication Dial In User Service)", RFC 3575, 1194 DOI 10.17487/RFC3575, July 2003, 1195 . 1197 [RFC7542] DeKok, A., "The Network Access Identifier", RFC 7542, 1198 DOI 10.17487/RFC7542, May 2015, 1199 . 1201 [OASIS.saml-bindings-2.0-os] 1202 Cantor, S., Hirsch, F., Kemp, J., Philpott, R., and E. 1203 Maler, "Bindings for the OASIS Security Assertion Markup 1204 Language (SAML) V2.0", OASIS Standard saml-bindings- 1205 2.0-os, March 2005. 1207 [OASIS.saml-core-2.0-os] 1208 Cantor, S., Kemp, J., Philpott, R., and E. Maler, 1209 "Assertions and Protocol for the OASIS Security Assertion 1210 Markup Language (SAML) V2.0", OASIS Standard saml-core- 1211 2.0-os, March 2005. 1213 [OASIS.saml-profiles-2.0-os] 1214 Hughes, J., Cantor, S., Hodges, J., Hirsch, F., Mishra, 1215 P., Philpott, R., and E. Maler, "Profiles for the OASIS 1216 Security Assertion Markup Language (SAML) V2.0", OASIS 1217 Standard OASIS.saml-profiles-2.0-os, March 2005. 1219 [OASIS.saml-metadata-2.0-os] 1220 Cantor, S., Moreh, J., Philpott, R., and E. Maler, 1221 "Metadata for the Security Assertion Markup Language 1222 (SAML) V2.0", OASIS Standard saml-metadata-2.0-os, March 1223 2005. 1225 13.2. Informative References 1227 [RFC3553] Mealling, M., Masinter, L., Hardie, T., and G. Klyne, "An 1228 IETF URN Sub-namespace for Registered Protocol 1229 Parameters", BCP 73, RFC 3553, DOI 10.17487/RFC3553, June 1230 2003, . 1232 [RFC6733] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn, 1233 Ed., "Diameter Base Protocol", RFC 6733, 1234 DOI 10.17487/RFC6733, October 2012, 1235 . 1237 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1238 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1239 DOI 10.17487/RFC5226, May 2008, 1240 . 1242 [RFC7055] Hartman, S., Ed. and J. Howlett, "A GSS-API Mechanism for 1243 the Extensible Authentication Protocol", RFC 7055, 1244 DOI 10.17487/RFC7055, December 2013, 1245 . 1247 [RFC7499] Perez-Mendez, A., Ed., Marin-Lopez, R., Pereniguez-Garcia, 1248 F., Lopez-Millan, G., Lopez, D., and A. DeKok, "Support of 1249 Fragmentation of RADIUS Packets", RFC 7499, 1250 DOI 10.17487/RFC7499, April 2015, 1251 . 1253 [I-D.ietf-abfab-arch] 1254 Howlett, J., Hartman, S., Tschofenig, H., Lear, E., and J. 1255 Schaad, "Application Bridging for Federated Access Beyond 1256 Web (ABFAB) Architecture", draft-ietf-abfab-arch-13 (work 1257 in progress), July 2014. 1259 [I-D.ietf-radext-bigger-packets] 1260 Hartman, S., "Larger Packets for RADIUS over TCP", draft- 1261 ietf-radext-bigger-packets-05 (work in progress), December 1262 2015. 1264 [W3C.REC-xmlschema-1] 1265 Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn, 1266 "XML Schema Part 1: Structures", W3C REC-xmlschema-1, May 1267 2001, . 1269 Appendix A. XML Schema 1271 The following schema formally defines the 1272 "urn:ietf:params:xml:ns:abfab" namespace used in this document, in 1273 conformance with [W3C.REC-xmlschema-1] While XML validation is 1274 optional, the schema that follows is the normative definition of the 1275 constructs it defines. Where the schema differs from any prose in 1276 this specification, the schema takes precedence. 1278 1288 1290 1291 1292 1293 1294 1295 1296 1297 1298 1299 1300 1301 1303 1304 1305 1306 1307 1308 1309 1310 1311 1312 1313 1314 1315 1316 1317 1318 1320 1322 Authors' Addresses 1324 Josh Howlett 1325 Janet 1326 Lumen House, Library Avenue, Harwell 1327 Oxford OX11 0SG 1328 UK 1330 Phone: +44 1235 822363 1331 EMail: Josh.Howlett@ja.net 1333 Sam Hartman 1334 Painless Security 1336 EMail: hartmans-ietf@mit.edu 1338 Alejandro Perez-Mendez (editor) 1339 University of Murcia 1340 Campus de Espinardo S/N, Faculty of Computer Science 1341 Murcia 30100 1342 Spain 1344 Phone: +34 868 88 46 44 1345 EMail: alex@um.es