idnits 2.17.1 draft-ietf-abfab-aaa-saml-11.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 7, 2015) is 3184 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 3588 (Obsoleted by RFC 6733) -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) == Outdated reference: A later version (-07) exists of draft-ietf-radext-bigger-packets-03 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ABFAB J. Howlett 3 Internet-Draft Janet 4 Intended status: Informational S. Hartman 5 Expires: February 8, 2016 Painless Security 6 A. Perez-Mendez, Ed. 7 University of Murcia 8 August 7, 2015 10 A RADIUS Attribute, Binding, Profiles, Name Identifier Format, and 11 Confirmation Methods for SAML 12 draft-ietf-abfab-aaa-saml-11 14 Abstract 16 This document describes the use of the Security Assertion Mark-up 17 Language (SAML) with RADIUS in the context of the ABFAB architecture. 18 It defines two RADIUS attributes, a SAML binding, a SAML name 19 identifier format, two SAML profiles, and two SAML confirmation 20 methods. The RADIUS attributes permit encapsulation of SAML 21 assertions and protocol messages within RADIUS, allowing SAML 22 entities to communicate using the binding. The two profiles describe 23 the application of this binding for ABFAB authentication and 24 assertion query/request, enabling a Relying Party to request 25 authentication of, or assertions for, users or machines (Clients). 26 These Clients may be named using a NAI name identifier format. 27 Finally, the subject confirmation methods allow requests and queries 28 to be issued for a previously authenticated user or machine without 29 needing to explicitly identify them as the subject. These artifacts 30 have been defined to permit application in AAA scenarios other than 31 ABFAB, such as network access. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at http://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on February 8, 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-Message attribute . . . . . . . . . . . . . . . . . 6 73 4. SAML RADIUS Binding . . . . . . . . . . . . . . . . . . . . . 7 74 4.1. Required Information . . . . . . . . . . . . . . . . . . 7 75 4.2. Operation . . . . . . . . . . . . . . . . . . . . . . . . 7 76 4.3. Processing of names . . . . . . . . . . . . . . . . . . . 9 77 4.3.1. AAA names . . . . . . . . . . . . . . . . . . . . . . 9 78 4.3.2. SAML names . . . . . . . . . . . . . . . . . . . . . 9 79 4.3.3. Mapping of AAA names in SAML metadata . . . . . . . . 10 80 4.3.4. Example of SAML metadata including AAA names . . . . 12 81 4.4. Use of XML Signatures . . . . . . . . . . . . . . . . . . 13 82 4.5. Metadata Considerations . . . . . . . . . . . . . . . . . 13 83 5. Network Access Identifier Name Identifier Format . . . . . . 13 84 6. RADIUS State Confirmation Method Identifiers . . . . . . . . 13 85 7. ABFAB Authentication Profile . . . . . . . . . . . . . . . . 14 86 7.1. Required Information . . . . . . . . . . . . . . . . . . 14 87 7.2. Profile Overview . . . . . . . . . . . . . . . . . . . . 14 88 7.3. Profile Description . . . . . . . . . . . . . . . . . . . 16 89 7.3.1. Client Request to Relying Party . . . . . . . . . . . 16 90 7.3.2. Relying Party Issues to Identity 91 Provider . . . . . . . . . . . . . . . . . . . . . . 16 92 7.3.3. Identity Provider Identifies Client . . . . . . . . . 17 93 7.3.4. Identity Provider Issues to Relying 94 Party . . . . . . . . . . . . . . . . . . . . . . . . 17 95 7.3.5. Relying Party Grants or Denies Access to Client . . . 17 96 7.4. Use of Authentication Request Protocol . . . . . . . . . 17 97 7.4.1. Usage . . . . . . . . . . . . . 18 98 7.4.2. Message Usage . . . . . . . . . . . 18 99 7.4.3. Message Processing Rules . . . . . . 19 100 7.4.4. Unsolicited Responses . . . . . . . . . . . . . . . . 19 101 7.4.5. Use of the SAML RADIUS Binding . . . . . . . . . . . 19 102 7.4.6. Use of XML Signatures . . . . . . . . . . . . . . . . 20 103 7.4.7. Metadata Considerations . . . . . . . . . . . . . . . 20 104 8. ABFAB Assertion Query/Request Profile . . . . . . . . . . . . 20 105 8.1. Required Information . . . . . . . . . . . . . . . . . . 20 106 8.2. Profile Overview . . . . . . . . . . . . . . . . . . . . 20 107 8.3. Profile Description . . . . . . . . . . . . . . . . . . . 21 108 8.3.1. Differences from the SAML V2.0 Assertion 109 Query/Request Profile . . . . . . . . . . . . . . . . 21 110 8.3.2. Use of the SAML RADIUS Binding . . . . . . . . . . . 22 111 8.3.3. Use of XML Signatures . . . . . . . . . . . . . . . . 22 112 8.3.4. Metadata Considerations . . . . . . . . . . . . . . . 22 113 9. Privacy considerations . . . . . . . . . . . . . . . . . . . 22 114 10. Security Considerations . . . . . . . . . . . . . . . . . . . 23 115 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 116 11.1. RADIUS Attributes . . . . . . . . . . . . . . . . . . . 24 117 11.2. ABFAB Parameters . . . . . . . . . . . . . . . . . . . . 24 118 11.3. Registration of the ABFAB URN Namespace . . . . . . . . 25 119 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25 120 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 121 13.1. Normative References . . . . . . . . . . . . . . . . . . 25 122 13.2. Informative References . . . . . . . . . . . . . . . . . 27 123 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 125 1. Introduction 127 Within the ABFAB architecture [I-D.ietf-abfab-arch] it is often 128 desirable to convey Security Assertion Mark-up Language (SAML) 129 assertions and protocol messages. 131 SAML typically only considers the use of HTTP-based transports, known 132 as bindings [OASIS.saml-bindings-2.0-os], which are primarily 133 intended for use with the SAML V2.0 Web Browser Single Sign-On 134 Profile [OASIS.saml-profiles-2.0-os]. However the goal of ABFAB is 135 to extend the applicability of federated identity beyond the Web to 136 other applications by building on the AAA framework. Consequently 137 there exists a requirement for SAML to integrate with the AAA 138 framework and protocols such as RADIUS [RFC2865] and Diameter 139 [RFC3588], in addition to HTTP. 141 In summary this document specifies: 143 o Two RADIUS attributes to encapsulate SAML assertions and protocol 144 messages respectively. 146 o A SAML RADIUS binding that defines how SAML assertions and 147 protocol messages can be transported by RADIUS within a SAML 148 exchange. 150 o A SAML name identifier format in the form of a Network Access 151 Identifier. 153 o A profile of the SAML Authentication Request Protocol that uses 154 the SAML RADIUS binding to effect SAML-based authentication and 155 authorization. 157 o A profile of the SAML Assertion Query And Request Protocol that 158 uses the SAML RADIUS binding to effect the query and request of 159 SAML assertions. 161 o Two SAML Subject Confirmation Methods for indicating that a user 162 or machine client is the subject of an assertion. 164 This document adheres to the guidelines stipulated by 165 [OASIS.saml-bindings-2.0-os] and [OASIS.saml-profiles-2.0-os] for 166 defining new SAML bindings and profiles respectively, and other 167 conventions applied formally or otherwise within SAML. In particular 168 where this document provides a 'Required Information' section for the 169 binding and profiles that enumerate: 171 o A URI that uniquely identifies the protocol binding or profile. 173 o Postal or electronic contact information for the author. 175 o A reference to previously defined bindings or profiles that the 176 new binding updates or obsoletes. 178 o In the case of a profile, any SAML confirmation method identifiers 179 defined and/or utilized by the profile. 181 1.1. Terminology 183 This document uses terminology from a number of related standards, 184 which tend to addopt different terms for similar or identical 185 concepts. In general the document uses, when possible, the ABFAB 186 term for the entity, as described in [I-D.ietf-abfab-arch]. For 187 reference we include this table which maps the different terms into a 188 single view. 190 +----------+-----------+------------------+-------------------+ 191 | Protocol | Client | Relying Party | Identity Provider | 192 +----------+-----------+------------------+-------------------+ 193 | ABFAB | Client | Relying Party | Identity Provider | 194 | | | | | 195 | SAML | Subject | Service Provider | Identity Provider | 196 | | Principal | Requester | Responder | 197 | | | Consumer | Issuer | 198 | | | | | 199 | RADIUS | User | NAS | AS | 200 | | | RADIUS client | RADIUS server | 201 +----------+-----------+------------------+-------------------+ 203 Table 1. Terminology 205 2. Conventions 207 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 208 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 209 document are to be interpreted as described in RFC 2119 [RFC2119]. 211 3. RADIUS SAML Attributes 213 The RADIUS SAML binding defined in Section 4 of this document uses 214 two attributes to convey SAML assertions and protocol messages 215 respectively [OASIS.saml-core-2.0-os]. Owing to the typical size of 216 these structures, these attributes use the Long Extended Type format 217 [RFC6929] to encapsulate their data. 219 3.1. SAML-Assertion attribute 221 This attribute is used to encode a SAML assertion. The following 222 figure represents the format of this attribute. 224 1 2 3 225 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 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 | Type | Length | Extended-Type |M| Reserved | 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 229 | Value... 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 Figure 1: SAML-Assertion format 234 Type 236 245 (To be confirmed by IANA) 238 Length 240 >= 5 242 Extended-Type 244 TBD1 246 M (More) 248 As described in [RFC6929]. 250 Reserved 252 As described in [RFC6929]. 254 Value 256 One or more octets encoding a SAML assertion. 258 3.2. SAML-Message attribute 260 This attribute is used to encode a SAML protocol message. The 261 following figure represents the format of this attribute. 263 1 2 3 264 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 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 | Type | Length | Extended-Type |M| Reserved | 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 | Value... 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271 Figure 2: SAML-Message format 273 Type 275 245 (To be confirmed by IANA) 277 Length 279 >= 5 281 Extended-Type 283 TBD2 285 M (More) 286 As described in [RFC6929]. 288 Reserved 290 As described in [RFC6929]. 292 Value 294 One or more octets encoding a SAML protocol message. 296 4. SAML RADIUS Binding 298 The SAML RADIUS binding defines how RADIUS [RFC2865] can be used to 299 enable a RADIUS client and server to exchange SAML assertions and 300 protocol messages. 302 4.1. Required Information 304 Identification: urn:ietf:params:abfab:bindings:radius 306 Contact information: iesg@ietf.org 308 Updates: None. 310 4.2. Operation 312 RADIUS can be used over multiple underlying transports. It is 313 REQUIRED that the RADIUS exchange is protected using TLS encryption 314 for RADIUS [RFC6614] to provide confidentiality and improve integrity 315 protection, unless alternative methods are used to ensure 316 confidentiality, such as IPSEC tunnels or a sufficiently secure 317 internal network. 319 Implementations of this profile can take advantage of mechanisms to 320 permit the transport of longer SAML messages over RADIUS transports, 321 such as the Support of fragmentation of RADIUS packets [RFC7499] or 322 Larger Packets for RADIUS over TCP [I-D.ietf-radext-bigger-packets]. 324 There are two system models for the use of SAML over RADIUS. The 325 first is a request-response model, using the RADIUS SAML-Message 326 attribute defined in Section 3 to encapsulate the SAML protocol 327 messages. 329 1. The RADIUS client, acting as a Relying Party (RP), transmits a 330 SAML request element within a RADIUS Access-Request message. 331 This message MUST include a single instance of the RADIUS User- 332 Name attribute whose value MUST conform to the Network Access 333 Identifier [RFC7542] scheme. The Relying Party MUST NOT include 334 more than one SAML request element. 336 2. The RADIUS server, acting as an Identity Provider (IdP), returns 337 a SAML protocol message within a RADIUS Access-Accept or Access- 338 Reject message. These messages necessarily conclude a RADIUS 339 exchange and therefore this is the only opportunity for the 340 Identity Provider to send a response in the context of this 341 exchange. The Identity Provider MUST NOT include more than one 342 SAML response. An IdP that refuses to perform a message exchange 343 with the Relying Party can silently discard the SAML request 344 (this could subsequently be followed by a RADIUS Access-Reject, 345 as the same conditions that cause the IdP to discard the SAML 346 request may also cause the RADIUS server to fail to 347 authenticate). 349 The second system model permits a RADIUS server acting as an Identity 350 Provider to use the RADIUS SAML-Assertion attribute defined in 351 Section 3 to encapsulate an unsolicited SAML assertion. This 352 attribute MUST be included in a RADIUS Access-Accept message. When 353 included, the attribute MUST contain a single SAML assertion. 355 RADIUS servers MUST NOT include both the SAML-Message and the SAML- 356 Assertion attribute in the same RADIUS message. If an IdP is 357 producing a response to a SAML request, then the first system model 358 is used. An IdP MAY ignore a SAML request and send an unsolicited 359 assertion using the second system model using the RADIUS SAML- 360 Assertion attribute. 362 In either system model, Identity Providers SHOULD return a RADIUS 363 state attribute as part of the Access-Accept message so that future 364 SAML queries or requests can be run against the same context of an 365 authentication exchange. 367 This binding is intended to be composed with other uses of RADIUS, 368 such as network access. Therefore, other arbitrary RADIUS attributes 369 will be used in either the request or response. 371 In the case of a SAML processing error and successful authentication, 372 the RADIUS server SHOULD include a SAML-specified 373 element in the SAML response that is transported within the Access- 374 Accept packet sent by the RADIUS server. 376 In the case of a SAML processing error and failed authentication, the 377 RADIUS server MAY include a SAML-specified element in 378 the SAML response that is transported within the Access-Reject packet 379 sent by the RADIUS server. 381 4.3. Processing of names 383 SAML entities using profiles of this binding will typically possess 384 both the SAML and AAA names of their correspondents. Frequently 385 these entities will need to apply policies using these names; for 386 example, when deciding to release attributes. Often these policies 387 will be security-sensitive, and so it is important that policy is 388 applied on these names consistently. 390 4.3.1. AAA names 392 These rules relate to the processing of AAA names by SAML entities 393 using profiles of this binding. 395 o Identity Providers SHOULD apply policy based on the Relying 396 Party's identity associated with the RADIUS Access-Request. 398 o Relying Parties SHOULD apply policy based on the NAI realm 399 associated with the RADIUS Access-Accept. 401 4.3.2. SAML names 403 These rules relate to the processing of SAML names by SAML entities 404 using profiles of this binding. 406 Identity Providers MAY apply policy based on the Relying Party's SAML 407 . In such cases, at least one of the following methods is 408 required in order to establish a relation between the SAML name and 409 the AAA name of the Relying Party: 411 o RADIUS client identity in trusted digitally signed SAML request. 413 o RADIUS client identity in trusted SAML federation metadata (as in 414 [OASIS.saml-metadata-2.0-os]). 416 A digitally signed SAML request without the RADIUS client identity is 417 not sufficient, since a malicious RADIUS entity can observe a SAML 418 message and include it in a different RADIUS message without the 419 consent of the issuer of that SAML message. If an Identity Provider 420 were to process the SAML message without confirming that it applied 421 to the RADIUS message, inappropriate policy would be used. 423 Relying Parties MAY apply policy based on the SAML issuer's 424 . In such cases, at least one of the following methods is 425 required in order to establish a relation between the SAML name and 426 the AAA name of the Identity Provider: 428 o RADIUS realm in trusted digitally signed SAML response or 429 assertion. 431 o RADIUS realm in trusted SAML federation metadata. 433 A digitally signed SAML response alone is not sufficient for the same 434 reasons described above for SAML requests. 436 4.3.3. Mapping of AAA names in SAML metadata 438 This section defines the extensions to the SAML metadata 439 specification [OASIS.saml-metadata-2.0-os] that are required in order 440 to represent AAA names associated to a particular 441 element. 443 In SAML metadata, each single entity may act in many different roles 444 in the support of multiple profiles. This document defines two new 445 roles: RADIUS IDP and RADIUS RP, requiring the declaration of two new 446 subtypes of RoleDescriptorType: RADIUSIDPDescriptor and 447 RADIUSRPDescriptor. These subtypes define the additional elements 448 required to represent AAA names for IDP and RP entities respectively. 450 4.3.3.1. 452 The element extends RoleDescriptorType with 453 elements common to IdPs that support RADIUS. Its 454 RADIUSIDPDescriptorType complex type contains the following 455 additional elements: 457 [Zero or More] Zero or more elements of type 458 EndpointType that describe RADIUS endpoints that are associated to 459 this Entity. 461 [Zero or More] Zero or more elements of type xs:string 462 that represent the acceptable values of the RADIUS realm 463 associated to this Entity, obtained from the realm part of RADIUS 464 User-Name attribute. 466 The following schema fragment defines the 467 element and its RADIUSIDPDescriptorType complex type: 469 471 472 473 474 475 477 479 480 481 482 483 484 486 Figure 3: RADIUSIDPDescriptor schema 488 4.3.3.2. 490 The element extends RoleDescriptorType with 491 elements common to RPs that support RADIUS. Its 492 RADIUSRPDescriptorType complex type contains the following additional 493 elements: 495 [Zero or More] Zero or more elements of type 496 EndpointType that describe RADIUS endpoints that are associated to 497 this Entity. 499 [Zero or More] Zero or more elements of type 500 xs:string that represent the acceptable values of the RADIUS NAS- 501 IP-Address attribute associated to this Entity. 503 [Zero or More] Zero or more elements of type 504 xs:string that represent the acceptable values of the RADIUS NAS- 505 Identifier attribute associated to this Entity. 507 [Zero or More] Zero or more elements of type 508 xs:string that represent the acceptable values of the GSS-EAP 509 acceptor name associated to this Entity. The format for this name 510 is described in section 3.1 of [RFC7055], while section 3.4 511 describes how that name is decomposed and transported using RADIUS 512 attributes. 514 The following schema fragment defines the 515 element and its RADIUSRPDescriptorType complex type: 517 519 520 521 522 523 525 527 529 531 532 533 534 535 536 537 538 540 Figure 4: RADIUSRPDescriptor schema 542 4.3.4. Example of SAML metadata including AAA names 544 The following figures illustrate an example of metadata including AAA 545 names for and IDP and a RP respectively. The IDP's SAML name is 546 "https://IdentityProvider.com/", whereas its RADIUS realm is 547 "idp.com". The RP's SAML name is "https://RelyingParty.com/SAML", 548 being its GSS-EAP acceptor name "nfs/fileserver.rp.com@RP.COM". 550 552 554 555 idp.com 556 557 558 560 Figure 5: Metadata for the IDP 562 564 566 567 nfs/fileserver.rp.com@RP.COM 568 569 570 572 Figure 6: Metadata for the RP 574 4.4. Use of XML Signatures 576 This binding calls for the use of SAML elements that support XML 577 signatures. To promote interoperability, implementations of this 578 binding MUST support a default configuration that does not require 579 the use of XML signatures. Implementations MAY choose to use XML 580 signatures. 582 4.5. Metadata Considerations 584 There are no metadata considerations particular to this binding, 585 because this binding and profiles of this binding are mostly intended 586 to be used without metadata. In this usage, RADIUS infrastructure is 587 used to provide integrity and naming of the SAML messages and 588 assertions. RADIUS configuration is used to provide policy, 589 including which attributes are accepted from a Relying Party and 590 which attributes are sent by an Identity Provider. 592 Nevertheless, implementations MAY support other configurations 593 including the use of metadata. 595 5. Network Access Identifier Name Identifier Format 597 URI: urn:ietf:params:abfab:nameid-format:nai 599 Indicates that the content of the element is in the form of a Network 600 Access Identifier (NAI) using the syntax described by [RFC7542]. 602 6. RADIUS State Confirmation Method Identifiers 604 URI: urn:ietf:params:abfab:cm:user 606 URI: urn:ietf:params:abfab:cm:machine 608 Indicates that the Subject is the system entity (either the user or 609 machine) authenticated by a previously transmitted RADIUS Access- 610 Accept message, as identified by the value of that RADIUS message's 611 State attribute. 613 7. ABFAB Authentication Profile 615 In the scenario supported by the ABFAB Authentication Profile, a 616 Client controlling a User Agent requests access to a Relying Party. 617 The Relying Party uses RADIUS to authenticate the Client. In 618 particular, the Relying Party, acting as a RADIUS client, attempts to 619 validate the Client's credentials against a RADIUS server acting as 620 the Client's Identity Provider. If the Identity Provider 621 successfully authenticates the Client, it produces an authentication 622 assertion which is consumed by the Relying Party. This assertion MAY 623 include a name identifier that can be used between the Relying Party 624 and the Identity Provider to refer to the Client. 626 7.1. Required Information 628 Identification: urn:ietf:params:abfab:profiles:authentication 630 Contact information: iesg@ietf.org 632 SAML Confirmation Method Identifiers: The SAML V2.0 "RADIUS State" 633 confirmation method identifiers, either urn:ietf:params:abfab:cm:user 634 or urn:ietf:params:abfab:cm:machine, are used by this profile. 636 Updates: None. 638 7.2. Profile Overview 640 To implement this scenario, a profile of the SAML Authentication 641 Request protocol is used in conjunction with the SAML RADIUS binding 642 defined in Section 4. 644 This profile is based on the SAML V2.0 Web Browser Single Sign-On 645 Profile [OASIS.saml-profiles-2.0-os]. There are some important 646 differences, specifically: 648 Authentication: This profile does not require the use of any 649 particular authentication method. The ABFAB architecture does 650 require the use of EAP [RFC3579], but this specification may be 651 used in other non-ABFAB scenarios. 653 Bindings: This profile does not use HTTP-based bindings. Instead 654 all SAML protocol messages are transported using the SAML RADIUS 655 binding defined in Section 4. This is intended to reduce the 656 number of bindings that implementations must support to be 657 interoperable. 659 Requests: The profile does not permit the Relying Party to name the 660 of the . This is intended to 661 simplify implementation and interoperability. 663 Responses: The profile only permits the Identity Provider to return 664 a single SAML message or assertion that MUST contain exactly one 665 authentication statement. Other statements may be included within 666 this assertion at the discretion of the Identity Provider. This 667 is intended to simplify implementation and interoperability. 669 Figure 7 below illustrates the flow of messages within this profile. 671 Client Relying Party Identity Provider 672 | | | 673 | (1) | | 674 | - - - - - - - - - > | | 675 | | | 676 | | (2) | 677 | | - - - - - - - - - - - - > | 678 | | | 679 | (3) | | 680 | < - - - - - - - - - |- - - - - - - - - - - - - >| 681 | | | 682 | | (4) | 683 | | < - - - - - - - - - - - - | 684 | | | 685 | (5) | | 686 | < - - - - - - - - - | | 687 | | | 688 V V V 690 The following steps are described by the profile. Within an 691 individual step, there may be one or more actual message exchanges. 693 Figure 7 695 1. Client request to Relying Party (Section 7.3.1): In step 1, the 696 Client, via a User Agent, makes a request for a secured resource 697 at the Relying Party. The Relying Party determines that no 698 security context for the Client exists and initiates the 699 authentication process. 701 2. Relying Party issues to Identity Provider 702 (Section 7.3.2). In step 2, the Relying Party may optionally 703 issue a message to be delivered to the 704 Identity Provider using the SAML-Message RADIUS attribute. 706 3. Identity Provider identifies Client (Section 7.3.3). In step 3, 707 the Client is authenticated and identified by the Identity 708 Provider, while honoring any requirements imposed by the Relying 709 Party in the message if provided. 711 4. Identity Provider issues to Relying Party 712 (Section 7.3.4). In step 4, the Identity Provider issues a 713 message to the Relying Party using the SAML 714 RADIUS binding. The response either indicates an error or 715 includes a SAML Authentication Statement in exactly one SAML 716 Assertion. 718 5. Relying Party grants or denies access to Client (Section 7.3.5). 719 In step 5, having received the response from the Identity 720 Provider, the Relying Party can respond to the Client with its 721 own error, or can establish its own security context for the 722 Client and return the requested resource. 724 7.3. Profile Description 726 The ABFAB Authentication Profile is a profile of the SAML V2.0 727 Authentication Request Protocol [OASIS.saml-core-2.0-os]. Where this 728 specification conflicts with it, the former takes precedence. 730 7.3.1. Client Request to Relying Party 732 The profile is initiated by an arbitrary Client request to the 733 Relying Party. There are no restrictions on the form of the request. 734 The Relying Party is free to use any means it wishes to associate the 735 subsequent interactions with the original request. The Relying 736 Party, acting as a RADIUS client, attempts to authenticate the 737 Client. 739 7.3.2. Relying Party Issues to Identity Provider 741 The Relying Party uses RADIUS to communicate with the Client's 742 Identity Provider. The Relying Party MAY include a 743 within this RADIUS Access-Request message using 744 the SAML-Message RADIUS attribute. The next hop destination MAY be 745 the Identity Provider or alternatively an intermediate RADIUS proxy. 747 Profile-specific rules for the contents of the 748 element are given in Section 7.4.1. 750 7.3.3. Identity Provider Identifies Client 752 The Identity Provider MUST establish the identity of the Client using 753 a RADIUS authentication method, or else it will return an error. If 754 the ForceAuthn attribute on the element (if sent 755 by the Relying Party) is present and true, the Identity Provider MUST 756 freshly establish this identity rather than relying on any existing 757 session state it may have with the Client (for example, TLS state 758 that may be used for session resumption). Otherwise, and in all 759 other respects, the Identity Provider may use any method to 760 authenticate the Client, subject to the constraints called out in the 761 message. 763 7.3.4. Identity Provider Issues to Relying Party 765 The Identity Provider MUST conclude the authentication in a manner 766 consistent with the RADIUS authentication result. The IdP MAY issue 767 a message to the Relying Party that is consistent 768 with the authentication result, as described in 769 [OASIS.saml-core-2.0-os]. This SAML response is delivered to the 770 Relying Party using the SAML RADIUS binding described in Section 4. 772 Profile-specific rules regarding the contents of the 773 element are given in Section 7.4.2. 775 7.3.5. Relying Party Grants or Denies Access to Client 777 If issued by the Identity Provider, the Relying Party MUST process 778 the message and any enclosed 779 elements as described in [OASIS.saml-core-2.0-os]. Any subsequent 780 use of the elements is at the discretion of the 781 Relying Party, subject to any restrictions contained within the 782 assertions themselves or from any previously established out-of-band 783 policy that governs the interaction between the Identity Provider and 784 the Relying Party. 786 7.4. Use of Authentication Request Protocol 788 This profile is based on the Authentication Request Protocol defined 789 in [OASIS.saml-core-2.0-os]. In the nomenclature of actors 790 enumerated in section 3.4 of that document, the Relying Party is the 791 requester, the User Agent is the attesting entity and the Client is 792 the Requested Subject. 794 7.4.1. Usage 796 The Relying Party MUST NOT include a element in the 797 request. The authenticated RADIUS identity identifies the Client to 798 the Identity Provider. 800 A Relying Party MAY include any message content described in 801 [OASIS.saml-core-2.0-os], section 3.4.1. All processing rules are as 802 defined in [OASIS.saml-core-2.0-os]. 804 If the Relying Party wishes to permit the Identity Provider to 805 establish a new identifier for the Client if none exists, it MUST 806 include a element with the AllowCreate attribute 807 set to "true". Otherwise, only a Client for whom the Identity 808 Provider has previously established an identifier usable by the 809 Relying Party can be authenticated successfully. 811 The message MAY be signed. Authentication and 812 integrity are also provided by the SAML RADIUS binding. 814 7.4.2. Message Usage 816 If the Identity Provider cannot or will not satisfy the request, it 817 MUST either respond with a message containing an 818 appropriate error status code or codes and/or respond with a RADIUS 819 Access-Reject message. 821 If the Identity Provider wishes to return an error, it MUST NOT 822 include any assertions in the . Otherwise, 823 if the request is successful (or if the response is not associated 824 with a request), the element is subject conform to 825 the following: 827 o It MAY be signed. 829 o It MUST contain exactly one . The 830 element of this assertion MUST refer to the authenticated RADIUS 831 user. 833 o The assertion MUST contain a . Besides, the 834 assertion MUST contain a element with at least one 835 element containing a Method of 836 urn:ietf:params:abfab:cm:user or urn:ietf:params:abfab:cm:machine 837 that reflects the authentication of the Client to the Identity 838 Provider. Since the containing message is in response to an 839 , the InResponseTo attribute MUST match the 840 request's ID. The element MAY use the NAI Name 841 Identifier Format described in Section 5 to establish an 842 identifier between the Relying Party and the IdP. 844 o Other conditions MAY be included as requested by the Relying Party 845 or at the discretion of the Identity Provider. The Identity 846 Provider is NOT obligated to honor the requested set of conditions 847 in the , if any. 849 7.4.3. Message Processing Rules 851 The Relying Party MUST do the following: 853 o Assume that the Client's identifier implied by a SAML 854 element, if present, takes precedence over an identifier implied 855 by the RADIUS User-Name attribute. 857 o Verify that the InResponseTo attribute in the "RADIUS State" 858 equals the ID of its original 859 message, unless the response is unsolicited, 860 in which case the attribute MUST NOT be present. 862 o If a used to establish a security context 863 for the Client contains a SessionNotOnOrAfter attribute, the 864 security context SHOULD be discarded once this time is reached, 865 unless the Relying Party reestablishes the Client's identity by 866 repeating the use of this profile. 868 o Verify that any assertions relied upon are valid according to 869 processing rules in [OASIS.saml-core-2.0-os]. 871 o Any assertion which is not valid, or whose subject confirmation 872 requirements cannot be met MUST be discarded and MUST NOT be used 873 to establish a security context for the Client. 875 7.4.4. Unsolicited Responses 877 An Identity Provider MAY initiate this profile by delivering an 878 unsolicited to a Relying Party. This MUST NOT 879 contain any elements containing an 880 InResponseTo attribute. 882 7.4.5. Use of the SAML RADIUS Binding 884 It is RECOMMENDED that the RADIUS exchange is protected using TLS 885 encryption for RADIUS [RFC6614] to provide confidentiality and 886 improve integrity protection. 888 7.4.6. Use of XML Signatures 890 This profile calls for the use of SAML elements that support XML 891 signatures. To promote interoperability implementations of this 892 profile MUST NOT require the use of XML signatures. Implementations 893 MAY choose to use XML signatures. 895 7.4.7. Metadata Considerations 897 There are no metadata considerations particular to this binding. 899 8. ABFAB Assertion Query/Request Profile 901 This profile builds on the SAML V2.0 Assertion Query/Request Profile 902 defined by [OASIS.saml-profiles-2.0-os]. That profile describes the 903 use of the Assertion Query and Request Protocol defined by section 904 3.3 of [OASIS.saml-core-2.0-os] with synchronous bindings, such as 905 the SOAP binding defined in [OASIS.saml-bindings-2.0-os]. 907 While the SAML V2.0 Assertion Query/Request Profile is independent of 908 the underlying binding, it is nonetheless useful to describe the use 909 of the SAML RADIUS binding defined in Section 4 of this document, in 910 the interests of promoting interoperable implementations, 911 particularly as the SAML V2.0 Assertion Query/Request Profile is most 912 frequently discussed and implemented in the context of the SOAP 913 binding. 915 8.1. Required Information 917 Identification: urn:ietf:params:abfab:profiles:query 919 Contact information: iesg@ietf.org 921 Description: Given below. 923 Updates: None. 925 8.2. Profile Overview 927 As with the SAML V2.0 Assertion Query/Request Profile defined by 928 [OASIS.saml-profiles-2.0-os] the message exchange and basic 929 processing rules that govern this profile are largely defined by 930 Section 3.3 of [OASIS.saml-core-2.0-os] that defines the messages to 931 be exchanged, in combination with the binding used to exchange the 932 messages. The SAML RADIUS binding described in this document defines 933 the binding of the message exchange to RADIUS. Unless specifically 934 noted here, all requirements defined in those specifications apply. 936 Figure 8 below illustrates the basic template for the query/request 937 profile. 939 Relying Party Identity Provider 940 (SAML requester) (SAML responder) 941 | | 942 | (1) | 943 | - - - - - - - - - - - - - - - - - - - - - - - > | 944 | | 945 | (2) | 946 | < - - - - - - - - - - - - - - - - - - - - - - - | 947 | | 948 V V 950 The following steps are described by the profile. 952 Figure 8 954 1. Query/Request issued by Relying Party: In step 1, a Relying Party 955 initiates the profile by sending an , 956 , , , or 957 message to a SAML authority. 959 2. issued by SAML Authority: In step 2, the responding 960 SAML authority (after processing the query or request) issues a 961 message to the Relying Party. 963 8.3. Profile Description 965 8.3.1. Differences from the SAML V2.0 Assertion Query/Request Profile 967 This profile is identical to the SAML V2.0 Assertion Query/Request 968 Profile, with the following exceptions: 970 o When processing the SAML request, the IdP MUST give precedence to 971 the Client's identifier implied by RADIUS State attribute, if 972 present, over the identifier implied by the SAML request's 973 , if any. 975 o In respect to sections 6.3.1 and 6.5 of 976 [OASIS.saml-profiles-2.0-os], this profile does not consider the 977 use of metadata (as in [OASIS.saml-metadata-2.0-os]). See 978 Section 8.3.4. 980 o In respect to sections 6.3.2, 6.4.1, and 6.4.2 of 981 [OASIS.saml-profiles-2.0-os], this profile additionally stipulates 982 that implementations of this profile MUST NOT require the use of 983 XML signatures. See Section 8.3.3. 985 8.3.2. Use of the SAML RADIUS Binding 987 The RADIUS Access-Request sent by the Relying Party: 989 o MUST include an instance of the RADIUS Service-Type attribute, 990 having a value of Authorize-Only. 992 o SHOULD include the RADIUS State attribute, where this Query/ 993 Request pertains to previously authenticated Client. 995 When processing the SAML request, the IdP MUST give precedence to the 996 Client's identifier implied by RADIUS State attribute over the 997 identifier implied by the SAML request's , if any. 999 It is RECOMMENDED that the RADIUS exchange is protected using TLS 1000 encryption for RADIUS [RFC6614] to provide confidentiality and 1001 improve integrity protection. 1003 8.3.3. Use of XML Signatures 1005 This profile calls for the use of SAML elements that support XML 1006 signatures. To promote interoperability implementations of this 1007 profile MUST NOT require the use of XML signatures. Implementations 1008 MAY choose to use XML signatures. 1010 8.3.4. Metadata Considerations 1012 There are no metadata considerations particular to this binding. 1014 9. Privacy considerations 1016 The profiles defined in this document allow a Relying Party to 1017 request specific information about the Client, and allow an IdP to 1018 disclose information about that Client. In this sense, Identity 1019 Providers MUST apply policy to decide what information is released to 1020 a particular Relying Party. Moreover, the identity of the Client is 1021 typically hidden from the Relying Party unless informed by the 1022 Identity Provider. Conversely, the Relying Party does typically know 1023 the realm of the IdP, as it is required to being able to route the 1024 RADIUS packets to the right destination. 1026 The kind of information that is released by the IdP MAY include 1027 generic attributes such as affiliation shared by many Clients. But 1028 even these generic attributes can help to identify a specific Client. 1029 Other kind of attributes MAY also provide a Relying Party with the 1030 ability to link the same Client between different sessions. Finally, 1031 other kind of attributes MAY provide a group of Relying Parties with 1032 the ability to link the Client between them or with personally 1033 identifiable information about the Client. 1035 These profiles do not directly provide a Client with a mechanism to 1036 express preferences about what information is released. That 1037 information can be expressed out-of-band, for example as part of the 1038 enrollment process. 1040 The Relying Party MAY disclose privacy-sensitive information about 1041 itself as part of the request, although this is unlikely in typical 1042 deployments. 1044 If RADIUS proxies are used and encryption is not used, the attributes 1045 disclosed by the IdP are visible to the proxies. This is a 1046 significant privacy exposure in some deployments. Ongoing work is 1047 exploring mechanisms for creating TLS connections directly between 1048 the RADIUS client and the RADIUS server to reduce this exposure. If 1049 proxies are used, the impact of exposing SAML assertions to the 1050 proxies needs to be carefully considered. 1052 The use of TLS to provide confidentiality for the RADIUS exchange is 1053 strongly encouraged. Without this, passive eavesdroppers can observe 1054 the assertions. 1056 10. Security Considerations 1058 In this specification, the Relying Party MUST trust any statement in 1059 the SAML messages from the IdP in the same way that it trusts 1060 information contained in RADIUS attributes. These entities MUST 1061 trust the RADIUS infrastructure to provide integrity of the SAML 1062 messages. 1064 Furthermore, the Relying Party MUST apply policy and filter the 1065 information based on what information the IdP is permitted to assert 1066 and on what trust is reasonable to place in proxies between them. 1068 XML signatures and encryption are provided as an OPTIONAL mechanism 1069 for end-to-end security. These mechanism can protect SAML messages 1070 from being modified by proxies in the RADIUS infrastructure. These 1071 mechanisms are not mandatory-to-implement. It is believed that 1072 ongoing work to provide direct TLS connections between a RADIUS 1073 client and RADIUS server will provide similar assurances but better 1074 deployability. XML security is appropriate for deployments where 1075 end-to-end security is required but proxies cannot be removed or 1076 where SAML messages need to be verified at a later time or by parties 1077 not involved in the authentication exchange. 1079 11. IANA Considerations 1081 11.1. RADIUS Attributes 1083 The authors request that Attribute Types and Attribute Values defined 1084 in this document be registered by the Internet Assigned Numbers 1085 Authority (IANA) from the RADIUS namespaces as described in the "IANA 1086 Considerations" section of [RFC3575], in accordance with BCP 26 1087 [RFC5226]. For RADIUS packets, attributes and registries created by 1088 this document IANA is requested to place them at 1089 http://www.iana.org/assignments/radius-types. 1091 In particular, this document defines two new RADIUS attributes, 1092 entitled "SAML-Assertion" and "SAML-Message" (see Section 3), with 1093 assigned values of 245.TBD1 and 245.TBD2 from the Long Extended Space 1094 of [RFC6929]: 1096 Type Ext. Type Name Length Meaning 1097 ---- --------- -------------- ------ ------------------------ 1098 245 TBD1 SAML-Assertion >=5 Encodes a SAML assertion 1099 245 TBD2 SAML-Message >=5 Encodes a SAML protocol 1100 message 1102 11.2. ABFAB Parameters 1104 A new top-level registry is created titled "ABFAB Parameters". 1106 In this top-level registry, a sub-registry titled "ABFAB URN 1107 Parameters" is created. Registration in this registry is by the IETF 1108 review or expert review procedures [RFC5226]. 1110 This paragraph gives guidance to designated experts. Registrations 1111 in this registry are generally only expected as part of protocols 1112 published as RFCs on the IETF stream; other URIs are expected to be 1113 better choices for non-IETF work. Expert review is permitted mainly 1114 to allow early registration related to specifications under 1115 development when the community believes they have reached sufficient 1116 maturity. The expert SHOULD evaluate the maturity and stability of 1117 such an IETF-stream specification. Experts SHOULD review anything 1118 not from the IETF stream for consistency and consensus with current 1119 practice. Today such requests would not typically be approved. 1121 If a parameter named "paramname" is to be registered in this 1122 registry, then its URN will be "urn:ietf:params:abfab:paramname". 1123 The initial registrations are as follows: 1125 +-------------------------+-----------+ 1126 | Parameter | Reference | 1127 +-------------------------+-----------+ 1128 | bindings:radius | Section 4 | 1129 | nameid-format:nai | Section 5 | 1130 | profiles:authentication | Section 7 | 1131 | profiles:query | Section 8 | 1132 | cm:user | Section 6 | 1133 | cm:machine | Section 6 | 1134 +-------------------------+-----------+ 1136 ABFAB Parameters 1138 11.3. Registration of the ABFAB URN Namespace 1140 IANA is requested to register the "abfab" URN sub-namespace in the 1141 IETF URN sub-namespace for protocol parameters defined in [RFC3553]. 1143 Registry Name: abfab 1145 Specification: draft-ietf-abfab-aaa-saml 1147 Repository: ABFAB URN Parameters (Section Section 11.2) 1149 Index Value: Sub-parameters MUST be specified in UTF-8 using standard 1150 URI encoding where necessary. 1152 12. Acknowledgements 1154 The authors would like to acknowledge the OASIS Security Services 1155 (SAML) Technical Committee, and Scott Cantor in particular, for their 1156 help with the SAML-related material. 1158 The authors would also like to acknowledge the collaboration of Jim 1159 Schaad, Leif Johansson, Klaas Wierenga, Stephen Farell, Gabriel 1160 Lopez, and Rafael Marin, who have provided valuable comments on this 1161 document. 1163 13. References 1165 13.1. Normative References 1167 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1168 Requirement Levels", BCP 14, RFC 2119, 1169 DOI 10.17487/RFC2119, March 1997, 1170 . 1172 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 1173 "Remote Authentication Dial In User Service (RADIUS)", 1174 RFC 2865, DOI 10.17487/RFC2865, June 2000, 1175 . 1177 [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication 1178 Dial In User Service) Support For Extensible 1179 Authentication Protocol (EAP)", RFC 3579, 1180 DOI 10.17487/RFC3579, September 2003, 1181 . 1183 [RFC6614] Winter, S., McCauley, M., Venaas, S., and K. Wierenga, 1184 "Transport Layer Security (TLS) Encryption for RADIUS", 1185 RFC 6614, DOI 10.17487/RFC6614, May 2012, 1186 . 1188 [RFC6929] DeKok, A. and A. Lior, "Remote Authentication Dial In User 1189 Service (RADIUS) Protocol Extensions", RFC 6929, 1190 DOI 10.17487/RFC6929, April 2013, 1191 . 1193 [RFC3575] Aboba, B., "IANA Considerations for RADIUS (Remote 1194 Authentication Dial In User Service)", RFC 3575, 1195 DOI 10.17487/RFC3575, July 2003, 1196 . 1198 [RFC7542] DeKok, A., "The Network Access Identifier", RFC 7542, 1199 DOI 10.17487/RFC7542, May 2015, 1200 . 1202 [OASIS.saml-bindings-2.0-os] 1203 Cantor, S., Hirsch, F., Kemp, J., Philpott, R., and E. 1204 Maler, "Bindings for the OASIS Security Assertion Markup 1205 Language (SAML) V2.0", OASIS Standard saml-bindings- 1206 2.0-os, March 2005. 1208 [OASIS.saml-core-2.0-os] 1209 Cantor, S., Kemp, J., Philpott, R., and E. Maler, 1210 "Assertions and Protocol for the OASIS Security Assertion 1211 Markup Language (SAML) V2.0", OASIS Standard saml-core- 1212 2.0-os, March 2005. 1214 [OASIS.saml-profiles-2.0-os] 1215 Hughes, J., Cantor, S., Hodges, J., Hirsch, F., Mishra, 1216 P., Philpott, R., and E. Maler, "Profiles for the OASIS 1217 Security Assertion Markup Language (SAML) V2.0", OASIS 1218 Standard OASIS.saml-profiles-2.0-os, March 2005. 1220 [OASIS.saml-metadata-2.0-os] 1221 Cantor, S., Moreh, J., Philpott, R., and E. Maler, 1222 "Metadata for the Security Assertion Markup Language 1223 (SAML) V2.0", OASIS Standard saml-metadata-2.0-os, March 1224 2005. 1226 13.2. Informative References 1228 [RFC3553] Mealling, M., Masinter, L., Hardie, T., and G. Klyne, "An 1229 IETF URN Sub-namespace for Registered Protocol 1230 Parameters", BCP 73, RFC 3553, DOI 10.17487/RFC3553, June 1231 2003, . 1233 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 1234 Arkko, "Diameter Base Protocol", RFC 3588, 1235 DOI 10.17487/RFC3588, September 2003, 1236 . 1238 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1239 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1240 DOI 10.17487/RFC5226, May 2008, 1241 . 1243 [RFC7055] Hartman, S., Ed. and J. Howlett, "A GSS-API Mechanism for 1244 the Extensible Authentication Protocol", RFC 7055, 1245 DOI 10.17487/RFC7055, December 2013, 1246 . 1248 [RFC7499] Perez-Mendez, A., Ed., Marin-Lopez, R., Pereniguez-Garcia, 1249 F., Lopez-Millan, G., Lopez, D., and A. DeKok, "Support of 1250 Fragmentation of RADIUS Packets", RFC 7499, 1251 DOI 10.17487/RFC7499, April 2015, 1252 . 1254 [I-D.ietf-abfab-arch] 1255 Howlett, J., Hartman, S., Tschofenig, H., Lear, E., and J. 1256 Schaad, "Application Bridging for Federated Access Beyond 1257 Web (ABFAB) Architecture", draft-ietf-abfab-arch-13 (work 1258 in progress), July 2014. 1260 [I-D.ietf-radext-bigger-packets] 1261 Hartman, S., "Larger Packets for RADIUS over TCP", draft- 1262 ietf-radext-bigger-packets-03 (work in progress), March 1263 2015. 1265 Authors' Addresses 1267 Josh Howlett 1268 Janet 1269 Lumen House, Library Avenue, Harwell 1270 Oxford OX11 0SG 1271 UK 1273 Phone: +44 1235 822363 1274 EMail: Josh.Howlett@ja.net 1276 Sam Hartman 1277 Painless Security 1279 EMail: hartmans-ietf@mit.edu 1281 Alejandro Perez-Mendez (editor) 1282 University of Murcia 1283 Campus de Espinardo S/N, Faculty of Computer Science 1284 Murcia 30100 1285 Spain 1287 Phone: +34 868 88 46 44 1288 EMail: alex@um.es