GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc7833

Internet Engineering Task Force (IETF) J. Howlett Request for Comments: 7833 Jisc Category: Standards Track S. Hartman ISSN: 2070-1721 Painless Security

                                                  A. Perez-Mendez, Ed.
                                                  University of Murcia
                                                              May 2016
 A RADIUS Attribute, Binding, Profiles, Name Identifier Format, and

Confirmation Methods for the Security Assertion Markup Language (SAML)

Abstract

 This document describes the use of the Security Assertion Markup
 Language (SAML) with RADIUS in the context of the Application
 Bridging for Federated Access Beyond web (ABFAB) architecture.  It
 defines two RADIUS attributes, a SAML binding, a SAML name identifier
 format, two SAML profiles, and two SAML confirmation methods.  The
 RADIUS attributes permit encapsulation of SAML Assertions and
 protocol messages within RADIUS, allowing SAML entities to
 communicate using the binding.  The two profiles describe the
 application of this binding for ABFAB authentication and assertion
 Query/Request, enabling a Relying Party to request authentication of,
 or assertions for, users or machines (clients).  These clients may be
 named using a Network Access Identifier (NAI) name identifier format.
 Finally, the subject confirmation methods allow requests and queries
 to be issued for a previously authenticated user or machine without
 needing to explicitly identify them as the subject.  The use of the
 artifacts defined in this document is not exclusive to ABFAB.  They
 can be applied in any Authentication, Authorization, and Accounting
 (AAA) scenario, such as network access control.

Status of This Memo

 This is an Internet Standards Track document.
 This document is a product of the Internet Engineering Task Force
 (IETF).  It represents the consensus of the IETF community.  It has
 received public review and has been approved for publication by the
 Internet Engineering Steering Group (IESG).  Further information on
 Internet Standards is available in Section 2 of RFC 5741.
 Information about the current status of this document, any errata,
 and how to provide feedback on it may be obtained at
 http://www.rfc-editor.org/info/rfc7833.

Howlett, et al. Standards Track [Page 1] RFC 7833 SAML RADIUS May 2016

Copyright Notice

 Copyright (c) 2016 IETF Trust and the persons identified as the
 document authors.  All rights reserved.
 This document is subject to BCP 78 and the IETF Trust's Legal
 Provisions Relating to IETF Documents
 (http://trustee.ietf.org/license-info) in effect on the date of
 publication of this document.  Please review these documents
 carefully, as they describe your rights and restrictions with respect
 to this document.  Code Components extracted from this document must
 include Simplified BSD License text as described in Section 4.e of
 the Trust Legal Provisions and are provided without warranty as
 described in the Simplified BSD License.

Table of Contents

 1. Introduction ....................................................3
    1.1. Terminology ................................................5
 2. Conventions .....................................................5
 3. RADIUS SAML Attributes ..........................................5
    3.1. SAML-Assertion Attribute ...................................6
    3.2. SAML-Protocol Attribute ....................................7
 4. SAML RADIUS Binding .............................................8
    4.1. Required Information .......................................8
    4.2. Operation ..................................................8
    4.3. Processing of Names ........................................9
         4.3.1. AAA Names ..........................................10
         4.3.2. SAML Names .........................................10
         4.3.3. Mapping of AAA Names in SAML Metadata ..............11
         4.3.4. Example of SAML Metadata That Includes AAA Names ...13
    4.4. Use of XML Signatures .....................................14
    4.5. Metadata Considerations ...................................14
 5. Network Access Identifier Name Identifier Format ...............14
 6. RADIUS State Confirmation Method Identifiers ...................15
 7. ABFAB Authentication Profile ...................................15
    7.1. Required Information ......................................15
    7.2. Profile Overview ..........................................16
    7.3. Profile Description .......................................18
         7.3.1. Client Request to Relying Party ....................18
         7.3.2. Relying Party Issues <samlp:AuthnRequest>
                to Identity Provider ...............................18
         7.3.3. Identity Provider Identifies Client ................18
         7.3.4. Identity Provider Issues <samlp:Response>
                to Relying Party ...................................19
         7.3.5. Relying Party Grants or Denies Access to Client ....19

Howlett, et al. Standards Track [Page 2] RFC 7833 SAML RADIUS May 2016

    7.4. Use of Authentication Request Protocol ....................19
         7.4.1. <samlp:AuthnRequest> Usage .........................19
         7.4.2. <samlp:Response> Message Usage .....................20
         7.4.3. <samlp:Response> Message Processing Rules ..........20
         7.4.4. Unsolicited Responses ..............................21
         7.4.5. Use of the SAML RADIUS Binding .....................21
         7.4.6. Use of XML Signatures ..............................21
         7.4.7. Metadata Considerations ............................21
 8. ABFAB Assertion Query/Request Profile ..........................21
    8.1. Required Information ......................................22
    8.2. Profile Overview ..........................................22
    8.3. Profile Description .......................................23
         8.3.1. Differences from the SAML V2.0 Assertion
                Query/Request Profile ..............................23
         8.3.2. Use of the SAML RADIUS Binding .....................23
         8.3.3. Use of XML Signatures ..............................24
         8.3.4. Metadata Considerations ............................24
 9. Privacy Considerations .........................................24
 10. Security Considerations .......................................25
 11. IANA Considerations ...........................................25
    11.1. RADIUS Attributes ........................................25
    11.2. ABFAB Parameters .........................................26
    11.3. Registration of the ABFAB URN Namespace ..................27
 12. References ....................................................27
    12.1. Normative References .....................................27
    12.2. Informative References ...................................29
 Appendix A. XML Schema ............................................30
 Acknowledgments ...................................................32
 Authors' Addresses ................................................32

1. Introduction

 Within the ABFAB (Application Bridging for Federated Access Beyond
 web) architecture [RFC7831], it is often desirable to convey Security
 Assertion Markup Language (SAML) Assertions and protocol messages.
 SAML typically only considers the use of HTTP-based transports, known
 as bindings [OASIS.saml-bindings-2.0-os], which are primarily
 intended for use with the SAML V2.0 web browser single sign-on
 profile [OASIS.saml-profiles-2.0-os].  However, the goal of ABFAB is
 to extend the applicability of federated identity beyond the web to
 other applications by building on the Authentication, Authorization,
 and Accounting (AAA) framework.  Consequently, there exists a
 requirement for SAML to integrate with the AAA framework and with
 protocols such as RADIUS [RFC2865] and Diameter [RFC6733], in
 addition to HTTP.

Howlett, et al. Standards Track [Page 3] RFC 7833 SAML RADIUS May 2016

 In summary, this document specifies:
 o  Two RADIUS attributes to encapsulate SAML Assertions and protocol
    messages, respectively.
 o  A SAML RADIUS binding that defines how SAML Assertions and
    protocol messages can be transported by RADIUS within a SAML
    exchange.
 o  A SAML name identifier format in the form of a Network Access
    Identifier.
 o  A profile of the SAML Authentication Request Protocol that uses
    the SAML RADIUS binding to effect SAML-based authentication and
    authorization.
 o  A profile of the SAML Assertion Query and Request Protocol that
    uses the SAML RADIUS binding to effect the query and request of
    SAML Assertions.
 o  Two SAML subject confirmation methods for indicating that a user
    or machine client is the subject of an assertion.
 This document adheres to the guidelines stipulated by
 [OASIS.saml-bindings-2.0-os] and [OASIS.saml-profiles-2.0-os] for
 defining new SAML bindings and profiles, respectively, and other
 conventions applied formally or otherwise within SAML.  In
 particular, this document provides a "Required Information" section
 for the binding (Section 4.1) and profiles (Sections 7.1 and 8.1)
 that enumerate:
 o  A URI that uniquely identifies the protocol binding or profile.
 o  Postal or electronic contact information for the author.
 o  A reference to previously defined bindings or profiles that the
    new binding updates or obsoletes.
 o  In the case of a profile, any SAML confirmation method identifiers
    defined and/or utilized by the profile.

Howlett, et al. Standards Track [Page 4] RFC 7833 SAML RADIUS May 2016

1.1. Terminology

 This document uses terminology from a number of related standards
 that tend to adopt different terms for similar or identical concepts.
 In general, this document uses, when possible, the ABFAB term for the
 entity, as described in [RFC7831].  For reference, we include the
 following table, which maps the different terms into a single view.
 (In this document, "NAS" refers to a network access server, and "AS"
 refers to an authentication server.)
    +----------+-----------+------------------+-------------------+
    | Protocol | Client    | Relying Party    | Identity Provider |
    +----------+-----------+------------------+-------------------+
    | ABFAB    | Client    | Relying Party    | Identity Provider |
    |          |           |                  |                   |
    | SAML     | Subject   | Service Provider | Identity Provider |
    |          | Principal | Requester        | Responder         |
    |          |           | Consumer         | Issuer            |
    |          |           |                  |                   |
    | RADIUS   | User      | NAS              | AS                |
    |          |           | RADIUS client    | RADIUS server     |
    +----------+-----------+------------------+-------------------+
                         Table 1: Terminology

2. Conventions

 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
 document are to be interpreted as described in RFC 2119 [RFC2119].

3. RADIUS SAML Attributes

 The SAML RADIUS binding defined in Section 4 of this document uses
 two attributes to convey SAML Assertions and protocol messages
 [OASIS.saml-core-2.0-os].  Owing to the typical size of these
 structures, these attributes use the "Long Extended Type" format
 [RFC6929] to encapsulate their data.  RADIUS entities MUST NOT
 include both attributes in the same RADIUS message, as they represent
 exclusive alternatives to convey SAML information.

Howlett, et al. Standards Track [Page 5] RFC 7833 SAML RADIUS May 2016

3.1. SAML-Assertion Attribute

 This attribute is used to encode a SAML Assertion.  Figure 1
 represents the format of this attribute.
                        1                   2                   3
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Type        |    Length     | Extended-Type |M|  Reserved   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Value...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                    Figure 1: SAML-Assertion Format
 Type
    245
 Length
    >= 5
 Extended-Type
    1
 M (More)
    As described in [RFC6929].
 Reserved
    As described in [RFC6929].
 Value
    One or more octets encoding a SAML Assertion.

Howlett, et al. Standards Track [Page 6] RFC 7833 SAML RADIUS May 2016

3.2. SAML-Protocol Attribute

 This attribute is used to encode a SAML protocol message.  Figure 2
 represents the format of this attribute.
                        1                   2                   3
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Type        |    Length     | Extended-Type |M|  Reserved   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Value...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                    Figure 2: SAML-Protocol Format
 Type
    245
 Length
    >= 5
 Extended-Type
    2
 M (More)
    As described in [RFC6929].
 Reserved
    As described in [RFC6929].
 Value
    One or more octets encoding a SAML protocol message.

Howlett, et al. Standards Track [Page 7] RFC 7833 SAML RADIUS May 2016

4. SAML RADIUS Binding

 The SAML RADIUS binding defines how RADIUS [RFC2865] can be used to
 enable a RADIUS client and server to exchange SAML Assertions and
 protocol messages.

4.1. Required Information

 Identification: urn:ietf:params:abfab:bindings:radius
 Contact information: iesg@ietf.org
 Updates: None.

4.2. Operation

 In this specification, the Relying Party (RP) MUST trust any
 statement in the SAML messages from the Identity Provider (IdP) in
 the same way that it trusts information contained in RADIUS
 attributes.  These entities MUST trust the RADIUS infrastructure to
 provide integrity of the SAML messages.
 Hence, it is REQUIRED that the RADIUS exchange be protected using
 Transport Layer Security (TLS) encryption for RADIUS [RFC6614] to
 provide confidentiality and integrity protection, unless alternative
 methods to ensure them are used, such as IPsec tunnels or a
 sufficiently secure internal network.
 Implementations of this profile can take advantage of mechanisms to
 permit the transport of longer SAML messages over RADIUS transports,
 such as the support of fragmentation of RADIUS packets [RFC7499] or
 larger packets for RADIUS over TCP [RADIUS-Large-Pkts].
 There are two system models for the use of SAML over RADIUS.  The
 first is a request-response model, using the RADIUS SAML-Protocol
 attribute defined in Section 3 to encapsulate the SAML protocol
 messages.
 1.  The RADIUS client, acting as an RP, transmits a SAML request
     element within a RADIUS Access-Request message.  This message
     MUST include a single instance of the RADIUS User-Name attribute
     whose value MUST conform to the Network Access Identifier
     [RFC7542] scheme.  The RP MUST NOT include more than one SAML
     request element.

Howlett, et al. Standards Track [Page 8] RFC 7833 SAML RADIUS May 2016

 2.  The RADIUS server, acting as an IdP, returns a SAML protocol
     message within a RADIUS Access-Accept or Access-Reject message.
     These messages necessarily conclude a RADIUS exchange, and
     therefore this is the only opportunity for the IdP to send a
     response in the context of this exchange.  The IdP MUST NOT
     include more than one SAML response.  An IdP that refuses to
     perform a message exchange with the RP can silently discard the
     SAML request (this could subsequently be followed by a RADIUS
     Access-Reject, as the same conditions that cause the IdP to
     discard the SAML request may also cause the RADIUS server to fail
     to authenticate).
 The second system model permits a RADIUS server acting as an IdP to
 use the RADIUS SAML-Assertion attribute defined in Section 3 to
 encapsulate an unsolicited SAML Assertion.  This attribute MUST be
 included in a RADIUS Access-Accept message.  When included, the
 attribute MUST contain a single SAML Assertion.
 RADIUS servers MUST NOT include both the SAML-Protocol and the
 SAML-Assertion attribute in the same RADIUS message.  If an IdP is
 producing a response to a SAML request, then the first system model
 is used.  An IdP MAY ignore a SAML request and send an unsolicited
 assertion using the second system model (that is, using the RADIUS
 SAML-Assertion attribute).
 In either system model, IdPs SHOULD return a RADIUS State attribute
 as part of the Access-Accept message so that future SAML queries or
 requests can be run against the same context of an authentication
 exchange.
 This binding is intended to be composed with other uses of RADIUS,
 such as network access.  Therefore, other arbitrary RADIUS attributes
 MAY be used in either the request or response.
 In the case of a SAML processing error, the RADIUS server MAY include
 a SAML response message with an appropriate value for the
 <samlp:Status> element within the Access-Accept or Access-Reject
 packet to notify the client.  Alternatively, the RADIUS server can
 respond without a SAML-Protocol attribute.

4.3. Processing of Names

 SAML entities using profiles making use of this binding will
 typically possess both the SAML and AAA names of their
 correspondents.  Frequently, these entities will need to apply
 policies using these names -- for example, when deciding to release
 attributes.  Often, these policies will be security-sensitive, and so
 it is important that policy is applied on these names consistently.

Howlett, et al. Standards Track [Page 9] RFC 7833 SAML RADIUS May 2016

4.3.1. AAA Names

 These rules relate to the processing of AAA names by SAML entities
 using profiles making use of this binding.
 o  IdPs SHOULD apply policy based on the RP's identity associated
    with the RADIUS Access-Request.
 o  RPs SHOULD apply policy based on the NAI realm associated with the
    RADIUS Access-Accept.

4.3.2. SAML Names

 These rules relate to the processing of SAML names by SAML entities
 using profiles making use of this binding.
 IdPs MAY apply policy based on the RP's SAML entityID.  In such
 cases, at least one of the following methods is required in order to
 establish a relationship between the SAML name and the AAA name of
 the RP:
 o  RADIUS client identity in trusted SAML metadata (as described in
    Section 4.3.3).
 o  RADIUS client identity in trusted digitally signed SAML request.
 A digitally signed SAML request without the RADIUS client identity is
 not sufficient, since a malicious RADIUS entity can observe a SAML
 message and include it in a different RADIUS message without the
 consent of the issuer of that SAML message.  If an IdP were to
 process the SAML message without confirming that it applied to the
 RADIUS message, inappropriate policy would be used.
 RPs MAY apply policy based on the SAML issuer's entityID.  In such
 cases, at least one of the following methods is required in order to
 establish a relationship between the SAML name and the AAA name of
 the IdP:
 o  RADIUS realm in trusted SAML metadata (as described in
    Section 4.3.3).
 o  RADIUS realm in trusted digitally signed SAML response or
    assertion.
 A digitally signed SAML response alone is not sufficient, for the
 same reasons as those described above for SAML requests.

Howlett, et al. Standards Track [Page 10] RFC 7833 SAML RADIUS May 2016

4.3.3. Mapping of AAA Names in SAML Metadata

 This section defines extensions to the SAML metadata schema
 [OASIS.saml-metadata-2.0-os] that are required in order to represent
 AAA names associated with a particular <EntityDescriptor> element.
 In SAML metadata, a single entity may act in many different roles in
 the support of multiple profiles.  This document defines two new
 roles: RADIUS IdP and RADIUS RP, requiring the declaration of two new
 subtypes of RoleDescriptorType: RADIUSIDPDescriptorType and
 RADIUSRPDescriptorType.  These subtypes contain the additional
 elements required to represent AAA names for IdP and RP entities,
 respectively.

4.3.3.1. RADIUSIDPDescriptorType

 The RADIUSIDPDescriptorType complex type extends RoleDescriptorType
 with elements common to IdPs that support RADIUS.  It contains the
 following additional elements:
 <RADIUSIDPService> [Zero or More]  Zero or more elements of type
    EndpointType that describe RADIUS endpoints that are associated
    with the entity.
 <RADIUSRealm> [Zero or More]  Zero or more elements of type string
    that represent the acceptable values of the RADIUS realm
    associated with the entity, obtained from the realm part of the
    RADIUS User-Name attribute.

Howlett, et al. Standards Track [Page 11] RFC 7833 SAML RADIUS May 2016

 The following schema fragment defines the RADIUSIDPDescriptorType
 complex type:
         <complexType name="RADIUSIDPDescriptorType">
           <complexContent>
             <extension base="md:RoleDescriptorType">
               <sequence>
                 <element ref="abfab:RADIUSIDPService"
                               minOccurs="0" maxOccurs="unbounded"/>
                 <element ref="abfab:RADIUSRealm"
                               minOccurs="0" maxOccurs="unbounded"/>
               </sequence>
             </extension>
           </complexContent>
         </complexType>
         <element name="RADIUSIDPService" type="md:EndpointType"/>
         <element name="RADIUSRealm" type="string"/>
               Figure 3: RADIUSIDPDescriptorType Schema

4.3.3.2. RADIUSRPDescriptorType

 The RADIUSRPDescriptorType complex type extends RoleDescriptorType
 with elements common to RPs that support RADIUS.  It contains the
 following additional elements:
 <RADIUSRPService> [Zero or More]  Zero or more elements of type
    EndpointType that describe RADIUS endpoints that are associated
    with the entity.
 <RADIUSNasIpAddress> [Zero or More]  Zero or more elements of type
    string that represent the acceptable values of the RADIUS
    NAS-IP-Address or NAS-IPv6-Address attributes associated with the
    entity.
 <RADIUSNasIdentifier> [Zero or More]  Zero or more elements of type
    string that represent the acceptable values of the RADIUS
    NAS-Identifier attribute associated with the entity.
 <RADIUSGssEapName> [Zero or More]  Zero or more elements of type
    string that represent the acceptable values of the GSS-API
    Mechanism for the Extensible Authentication Protocol (GSS-EAP)
    acceptor name associated with the entity.  The format for this
    name is described in Section 3.1 of [RFC7055], while Section 3.4
    of [RFC7055] describes how that name is decomposed and transported
    using RADIUS attributes.

Howlett, et al. Standards Track [Page 12] RFC 7833 SAML RADIUS May 2016

 The following schema fragment defines the RADIUSRPDescriptorType
 complex type:
     <complexType name="RADIUSRPDescriptorType">
       <complexContent>
         <extension base="md:RoleDescriptorType">
           <sequence>
             <element ref="md:RADIUSRPService"
                           minOccurs="0" maxOccurs="unbounded"/>
             <element ref="md:RADIUSNasIpAddress"
                           minOccurs="0" maxOccurs="unbounded"/>
             <element ref="md:RADIUSNasIdentifier"
                           minOccurs="0" maxOccurs="unbounded"/>
             <element ref="md:RADIUSGssEapName"
                           minOccurs="0" maxOccurs="unbounded"/>
           </sequence>
         </extension>
       </complexContent>
     </complexType>
     <element name="RADIUSRPService" type="md:EndpointType"/>
     <element name="RADIUSNasIpAddress" type="string"/>
     <element name="RADIUSNasIdentifier" type="string"/>
     <element name="RADIUSGssEapName" type="string"/>
                Figure 4: RADIUSRPDescriptorType Schema

4.3.4. Example of SAML Metadata That Includes AAA Names

 Figures 5 and 6 illustrate examples of metadata that includes AAA
 names for an IdP and an RP, respectively.  The IdP's SAML name is
 "https://IdentityProvider.com/", whereas its RADIUS realm is
 "idp.com".  The RP's SAML name is "https://RelyingParty.com/SAML",
 being its GSS-EAP acceptor name "nfs/fileserver.rp.com@RP.COM".

<EntityDescriptor

 xmlns="urn:oasis:names:tc:SAML:2.0:metadata"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xmlns:abfab="urn:ietf:params:xml:ns:abfab"
 entityID="https://IdentityProvider.com/SAML">
 <RoleDescriptor
    xsi:type="abfab:RADIUSIDPDescriptorType"
    protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
     <RADIUSRealm>idp.com</RADIUSRealm>
 </RoleDescriptor>

</EntityDescriptor>

                    Figure 5: Metadata for the IdP

Howlett, et al. Standards Track [Page 13] RFC 7833 SAML RADIUS May 2016

<EntityDescriptor

 xmlns="urn:oasis:names:tc:SAML:2.0:metadata"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xmlns:abfab="urn:ietf:params:xml:ns:abfab"
 entityID="https://RelyingParty.com/SAML">
 <RoleDescriptor
    xsi:type="abfab:RADIUSRPDescriptorType"
    protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
     <RADIUSGssEapName>nfs/fileserver.rp.com@RP.COM</RADIUSGssEapName>
 </RoleDescriptor>

</EntityDescriptor>

                     Figure 6: Metadata for the RP

4.4. Use of XML Signatures

 This binding calls for the use of SAML elements that support XML
 signatures.  To promote interoperability, implementations of this
 binding MUST support a default configuration that does not require
 the use of XML signatures.  Implementations MAY choose to use XML
 signatures.

4.5. Metadata Considerations

 This binding, and the profiles, are mostly intended to be used
 without metadata.  In this usage, RADIUS infrastructure is used to
 provide integrity and naming of the SAML messages and assertions.
 RADIUS configuration is used to provide policy, including which
 attributes are accepted from an RP and which attributes are sent by
 an IdP.
 Nevertheless, if metadata is used, the roles described in
 Section 4.3.3 MUST be present.

5. Network Access Identifier Name Identifier Format

 URI: urn:ietf:params:abfab:nameid-format:nai
 Indicates that the content of the element is in the form of a Network
 Access Identifier (NAI) using the syntax described by [RFC7542].

Howlett, et al. Standards Track [Page 14] RFC 7833 SAML RADIUS May 2016

6. RADIUS State Confirmation Method Identifiers

 URI: urn:ietf:params:abfab:cm:user
 URI: urn:ietf:params:abfab:cm:machine
 Indicates that the subject is the system entity (either the user or
 machine) authenticated by a previously transmitted RADIUS
 Access-Accept message, as identified by the value of that RADIUS
 message's State attribute.

7. ABFAB Authentication Profile

 In the scenario supported by the ABFAB Authentication Profile, a
 client controlling a User Agent requests access to an RP.  The RP
 uses RADIUS to authenticate the client.  In particular, the RP,
 acting as a RADIUS client, attempts to validate the client's
 credentials against a RADIUS server acting as the client's IdP.  If
 the IdP successfully authenticates the client, it produces an
 authentication assertion that is consumed by the RP.  This assertion
 MAY include a name identifier that can be used between the RP and the
 IdP to refer to the client.

7.1. Required Information

 Identification: urn:ietf:params:abfab:profiles:authentication
 Contact information: iesg@ietf.org
 SAML confirmation method identifiers: The SAML V2.0 "RADIUS State"
 confirmation method identifiers -- either
 urn:ietf:params:abfab:cm:user or urn:ietf:params:abfab:cm:machine --
 are used by this profile.
 Updates: None.

Howlett, et al. Standards Track [Page 15] RFC 7833 SAML RADIUS May 2016

7.2. Profile Overview

 To implement this scenario, this profile of the SAML Authentication
 Request Protocol MUST be used in conjunction with the SAML RADIUS
 binding defined in Section 4.
 This profile is based on the SAML V2.0 web browser single sign-on
 profile [OASIS.saml-profiles-2.0-os].  There are some important
 differences; specifically:
 Authentication:  This profile does not require the use of any
    particular authentication method.  The ABFAB architecture does
    require the use of the Extensible Authentication Protocol (EAP)
    [RFC3579], but this specification may be used in other non-ABFAB
    scenarios.
 Bindings:  This profile does not use HTTP-based bindings.  Instead,
    all SAML protocol messages are transported using the SAML RADIUS
    binding defined in Section 4.  This is intended to reduce the
    number of bindings that implementations must support to be
    interoperable.
 Requests:  The profile does not permit the RP to name the
    <saml:Subject> of the <samlp:AuthnRequest>.  This is intended to
    simplify implementation and interoperability.
 Responses:  The profile only permits the IdP to return a single SAML
    message or assertion that MUST contain exactly one authentication
    statement.  Other statements may be included within this assertion
    at the discretion of the IdP.  This is intended to simplify
    implementation and interoperability.

Howlett, et al. Standards Track [Page 16] RFC 7833 SAML RADIUS May 2016

 Figure 7 below illustrates the flow of messages within this profile.
     Client            Relying Party             Identity Provider
       |                     |                           |
       |         (1)         |                           |
       | - - - - - - - - - > |                           |
       |                     |                           |
       |                     |            (2)            |
       |                     | - - - - - - - - - - - - > |
       |                     |                           |
       |              (3)    |                           |
       | < - - - - - - - - - |- - - - - - - - - - - - - >|
       |                     |                           |
       |                     |            (4)            |
       |                     | < - - - - - - - - - - - - |
       |                     |                           |
       |         (5)         |                           |
       | < - - - - - - - - - |                           |
       |                     |                           |
       V                     V                           V
                      Figure 7: Flow of Messages
 The following steps are described by the profile.  Within an
 individual step, there may be one or more actual message exchanges.
 1.  Client request to RP (Section 7.3.1): In step 1, the client, via
     a User Agent, makes a request for a secured resource at the RP.
     The RP determines that no security context for the client exists
     and initiates the authentication process.
 2.  RP issues <samlp:AuthnRequest> to IdP (Section 7.3.2).  In step
     2, the RP may optionally issue a <samlp:AuthnRequest> message to
     be delivered to the IdP using the SAML-Protocol RADIUS attribute.
 3.  IdP identifies client (Section 7.3.3).  In step 3, the client is
     authenticated and identified by the IdP, while honoring any
     requirements imposed by the RP in the <samlp:AuthnRequest>
     message if provided.
 4.  IdP issues <samlp:Response> to RP (Section 7.3.4).  In step 4,
     the IdP issues a <samlp:Response> message to the RP using the
     SAML RADIUS binding.  The response either indicates an error or
     includes a SAML authentication statement in exactly one SAML
     Assertion.  If the RP did not send a <samlp:AuthnRequest>, the
     IdP issues an unsolicited <samlp:Assertion>, as described in
     Section 7.4.4.

Howlett, et al. Standards Track [Page 17] RFC 7833 SAML RADIUS May 2016

 5.  RP grants or denies access to client (Section 7.3.5).  In step 5,
     having received the response from the IdP, the RP can respond to
     the client with its own error, or can establish its own security
     context for the client and return the requested resource.

7.3. Profile Description

 The ABFAB Authentication Profile is a profile of the SAML V2.0
 Authentication Request Protocol [OASIS.saml-core-2.0-os].  Where both
 specifications conflict, the ABFAB Authentication Profile takes
 precedence.

7.3.1. Client Request to Relying Party

 The profile is initiated by an arbitrary client request to the RP.
 There are no restrictions on the form of the request.  The RP is free
 to use any means it wishes to associate the subsequent interactions
 with the original request.  The RP, acting as a RADIUS client,
 attempts to authenticate the client.

7.3.2. Relying Party Issues <samlp:AuthnRequest> to Identity Provider

 The RP uses RADIUS to communicate with the client's IdP.  The RP MAY
 include a <samlp:AuthnRequest> within this RADIUS Access-Request
 message using the SAML-Protocol RADIUS attribute.  The "next hop"
 destination MAY be the IdP or, alternatively, an intermediate RADIUS
 proxy.
 Profile-specific rules for the contents of the <samlp:AuthnRequest>
 element are given in Section 7.4.1.

7.3.3. Identity Provider Identifies Client

 The IdP MUST establish the identity of the client using a RADIUS
 authentication method, or else it will return an error.  If the
 ForceAuthn attribute in the <samlp:AuthnRequest> element (if sent by
 the RP) is present and true, the IdP MUST freshly establish this
 identity rather than relying on any existing session state it may
 have with the client (for example, TLS state that may be used for
 session resumption).  Otherwise, and in all other respects, the IdP
 may use any method to authenticate the client, subject to the
 constraints called out in the <samlp:AuthnRequest> message.

Howlett, et al. Standards Track [Page 18] RFC 7833 SAML RADIUS May 2016

7.3.4. Identity Provider Issues <samlp:Response> to Relying Party

 The IdP MUST conclude the authentication in a manner consistent with
 the RADIUS authentication result.  The IdP MAY issue a
 <samlp:Response> message to the RP that is consistent with the
 authentication result, as described in [OASIS.saml-core-2.0-os].
 This SAML response is delivered to the RP using the SAML RADIUS
 binding described in Section 4.
 Profile-specific rules regarding the contents of the <samlp:Response>
 element are given in Section 7.4.2.

7.3.5. Relying Party Grants or Denies Access to Client

 If a <samlp:Response> message is issued by the IdP, the RP MUST
 process that message and any enclosed assertion elements as described
 in [OASIS.saml-core-2.0-os].  Any subsequent use of the assertion
 elements is at the discretion of the RP, subject to any restrictions
 contained within the assertions themselves or from any previously
 established out-of-band policy that governs the interaction between
 the IdP and the RP.

7.4. Use of Authentication Request Protocol

 This profile is based on the Authentication Request Protocol defined
 in [OASIS.saml-core-2.0-os].  In the nomenclature of actors
 enumerated in Section 3.4 of that document, the RP is the requester,
 the User Agent is the attesting entity, and the client is the
 subject.

7.4.1. <samlp:AuthnRequest> Usage

 The RP MUST NOT include a <saml:Subject> element in the request.  The
 authenticated RADIUS identity identifies the client to the IdP.
 An RP MAY include any message content described in Section 3.4.1 of
 [OASIS.saml-core-2.0-os].  All processing rules are as defined in
 [OASIS.saml-core-2.0-os].
 If the RP wishes to permit the IdP to establish a new identifier for
 the client if none exists, it MUST include a <saml:NameIDPolicy>
 element with the AllowCreate attribute set to "true".  Otherwise,
 only a client for whom the IdP has previously established an
 identifier usable by the RP can be authenticated successfully.
 The <samlp:AuthnRequest> message MAY be signed.  Authentication and
 integrity are also provided by the SAML RADIUS binding.

Howlett, et al. Standards Track [Page 19] RFC 7833 SAML RADIUS May 2016

7.4.2. <samlp:Response> Message Usage

 If the IdP cannot or will not satisfy the request, it MUST respond
 with a <samlp:Response> message containing an appropriate error
 status code or codes and/or respond with a RADIUS Access-Reject
 message.
 If the IdP wishes to return an error, it MUST NOT include any
 assertions in the <samlp:Response> message.  Otherwise, if the
 request is successful (or if the response is not associated with a
 request), the <samlp:Response> element is subject to the following
 constraints:
 o  It MAY be signed.
 o  It MUST contain exactly one assertion.  The <saml:Subject> element
    of this assertion MUST refer to the authenticated RADIUS user.
 o  The assertion MUST contain a <saml:AuthnStatement>.  Also, the
    assertion MUST contain a <saml:Subject> element with at least one
    <saml:SubjectConfirmation> element containing a
    <saml:ConfirmationMethod> element of urn:ietf:params:abfab:cm:user
    or urn:ietf:params:abfab:cm:machine that reflects the
    authentication of the client to the IdP.  Since the
    <samlp:Response> message is in response to a <samlp:AuthnRequest>,
    the InResponseTo attribute (in both the
    <saml:SubjectConfirmationData> and <saml:Response> elements) MUST
    match the request's ID.  The <saml:Subject> element MAY use the
    NAI name identifier format described in Section 5 to establish an
    identifier between the RP and the IdP.
 o  Other conditions MAY be included as requested by the RP or at the
    discretion of the IdP.  The IdP is NOT obligated to honor the
    requested set of conditions in the <samlp:AuthnRequest>, if any.

7.4.3. <samlp:Response> Message Processing Rules

 The RP MUST do the following:
 o  Assume that the client's identifier implied by a SAML <Subject>
    element, if present, takes precedence over an identifier implied
    by the RADIUS User-Name attribute.
 o  Verify that the InResponseTo attribute in the "RADIUS State"
    <saml:SubjectConfirmationData> equals the ID of its original
    <samlp:AuthnRequest> message, unless the response is unsolicited,
    in which case the attribute MUST NOT be present.

Howlett, et al. Standards Track [Page 20] RFC 7833 SAML RADIUS May 2016

 o  If a <saml:AuthnStatement> used to establish a security context
    for the client contains a SessionNotOnOrAfter attribute, the
    security context SHOULD be discarded once this time is reached,
    unless the RP reestablishes the client's identity by repeating the
    use of this profile.
 o  Verify that any assertions relied upon are valid according to
    processing rules specified in [OASIS.saml-core-2.0-os].
 o  Any assertion that is not valid or whose subject confirmation
    requirements cannot be met MUST be discarded and MUST NOT be used
    to establish a security context for the client.

7.4.4. Unsolicited Responses

 An IdP MAY initiate this profile by delivering an unsolicited
 assertion to an RP.  This MUST NOT contain any
 <saml:SubjectConfirmationData> elements containing an InResponseTo
 attribute.

7.4.5. Use of the SAML RADIUS Binding

 It is RECOMMENDED that the RADIUS exchange be protected using TLS
 encryption for RADIUS [RFC6614] to provide confidentiality and
 integrity protection.

7.4.6. Use of XML Signatures

 This profile calls for the use of SAML elements that support XML
 signatures.  To promote interoperability, implementations of this
 profile MUST NOT require the use of XML signatures.  Implementations
 MAY choose to use XML signatures.

7.4.7. Metadata Considerations

 There are no metadata considerations particular to this profile,
 aside from those applying to the use of the RADIUS binding.

8. ABFAB Assertion Query/Request Profile

 This profile builds on the SAML V2.0 Assertion Query/Request Profile
 defined by [OASIS.saml-profiles-2.0-os].  That profile describes the
 use of the Assertion Query and Request Protocol defined by
 Section 3.3 of [OASIS.saml-core-2.0-os] with synchronous bindings,
 such as the SOAP binding defined in [OASIS.saml-bindings-2.0-os].

Howlett, et al. Standards Track [Page 21] RFC 7833 SAML RADIUS May 2016

 Although the SAML V2.0 Assertion Query/Request Profile is independent
 of the underlying binding, it is nonetheless useful to describe the
 use of the SAML RADIUS binding defined in Section 4 of this document,
 in the interest of promoting interoperable implementations,
 particularly as the SAML V2.0 Assertion Query/Request Profile is most
 frequently discussed and implemented in the context of the SOAP
 binding.

8.1. Required Information

 Identification: urn:ietf:params:abfab:profiles:query
 Contact information: iesg@ietf.org
 Description: Given below.
 Updates: None.

8.2. Profile Overview

 As with the SAML V2.0 Assertion Query/Request Profile defined by
 [OASIS.saml-profiles-2.0-os], the message exchange and basic
 processing rules that govern this profile are largely defined by
 Section 3.3 of [OASIS.saml-core-2.0-os], which defines the messages
 to be exchanged, in combination with the binding used to exchange the
 messages.  The SAML RADIUS binding described in this document defines
 the binding of the message exchange to RADIUS.  Unless specifically
 noted here, all requirements defined in those specifications apply.
 Figure 8 below illustrates the basic template for the Query/Request
 Profile.
   Relying Party                                   Identity Provider
  (SAML requester)                                 (SAML responder)
        |                                                 |
        |                       (1)                       |
        | - - - - - - - - - - - - - - - - - - - - - - - > |
        |                                                 |
        |                       (2)                       |
        | < - - - - - - - - - - - - - - - - - - - - - - - |
        |                                                 |
        V                                                 V
          Figure 8: Basic Template for Query/Request Profile

Howlett, et al. Standards Track [Page 22] RFC 7833 SAML RADIUS May 2016

 The following steps are described by the profile:
 1.  Query/Request issued by RP: In step 1, an RP initiates the
     profile by sending an <AssertionIDRequest>, <SubjectQuery>,
     <AuthnQuery>, <AttributeQuery>, or <AuthzDecisionQuery> message
     to a SAML authority.
 2.  <Response> issued by SAML authority: In step 2, the responding
     SAML authority (after processing the query or request) issues a
     <Response> message to the RP.

8.3. Profile Description

8.3.1. Differences from the SAML V2.0 Assertion Query/Request Profile

 This profile is identical to the SAML V2.0 Assertion Query/Request
 Profile, with the following exceptions:
 o  When processing the SAML request, the IdP MUST give precedence to
    the client's identifier implied by the RADIUS State attribute, if
    present, over the identifier implied by the SAML request's
    <Subject>, if any.
 o  In respect to Sections 6.3.1 and 6.5 of
    [OASIS.saml-profiles-2.0-os], this profile does not consider the
    use of metadata (as in [OASIS.saml-metadata-2.0-os]).  See
    Section 8.3.4.
 o  In respect to Sections 6.3.2, 6.4.1, and 6.4.2 of
    [OASIS.saml-profiles-2.0-os], this profile additionally stipulates
    that implementations of this profile MUST NOT require the use of
    XML signatures.  See Section 8.3.3.

8.3.2. Use of the SAML RADIUS Binding

 The RADIUS Access-Request sent by the RP:
 o  MUST include an instance of the RADIUS Service-Type attribute,
    having a value of Authorize-Only.
 o  SHOULD include the RADIUS State attribute, where this
    Query/Request pertains to a previously authenticated client.
 When processing the SAML request, the IdP MUST give precedence to the
 client's identifier implied by the RADIUS State attribute over the
 identifier implied by the SAML request's <Subject>, if any.

Howlett, et al. Standards Track [Page 23] RFC 7833 SAML RADIUS May 2016

 It is RECOMMENDED that the RADIUS exchange be protected using TLS
 encryption for RADIUS [RFC6614] to provide confidentiality and
 integrity protection.

8.3.3. Use of XML Signatures

 This profile calls for the use of SAML elements that support XML
 signatures.  To promote interoperability, implementations of this
 profile MUST NOT require the use of XML signatures.  Implementations
 MAY choose to use XML signatures.

8.3.4. Metadata Considerations

 There are no metadata considerations particular to this profile,
 aside from those applying to the use of the RADIUS binding.

9. Privacy Considerations

 The profiles defined in this document allow an RP to request specific
 information about the client and allow an IdP to disclose information
 about that client.  In this sense, IdPs MUST apply policy to decide
 what information is released to a particular RP.  Moreover, the
 identity of the client is typically hidden from the RP unless
 provided by the IdP.  Conversely, the RP does typically know the
 realm of the IdP, as it is required to route the RADIUS packets to
 the right destination.
 The kind of information that is released by the IdP can include
 generic attributes such as affiliation shared by many clients.  But
 even these generic attributes can help to identify a specific client.
 Other kinds of attributes may also provide an RP with the ability to
 link the same client between different sessions.  Finally, other
 kinds of attributes might provide a group of RPs with the ability to
 link the client between them or with personally identifiable
 information about the client.
 These profiles do not directly provide a client with a mechanism to
 express preferences about what information is released.  That
 information can be expressed out of band, for example, as part of the
 enrollment process.
 The RP may disclose privacy-sensitive information about itself as
 part of the request, although this is unlikely in typical
 deployments.

Howlett, et al. Standards Track [Page 24] RFC 7833 SAML RADIUS May 2016

 If RADIUS proxies are used and encryption is not used, the attributes
 disclosed by the IdP are visible to the proxies.  This is a
 significant privacy exposure in some deployments.  Ongoing work is
 exploring mechanisms for creating TLS connections directly between
 the RADIUS client and the RADIUS server to reduce this exposure.  If
 proxies are used, the impact of exposing SAML Assertions to the
 proxies needs to be carefully considered.
 The use of TLS to provide confidentiality for the RADIUS exchange is
 strongly encouraged.  Without this, passive eavesdroppers can observe
 the assertions.

10. Security Considerations

 In this specification, the RP MUST trust any statement in the SAML
 messages from the IdP in the same way that it trusts information
 contained in RADIUS attributes.  These entities MUST trust the RADIUS
 infrastructure to provide integrity of the SAML messages.
 Furthermore, the RP MUST apply policy and filter the information
 based on what information the IdP is permitted to assert and on what
 trust is reasonable to place in proxies between them.
 XML signatures and encryption are provided as an OPTIONAL mechanism
 for end-to-end security.  These mechanisms can protect SAML messages
 from being modified by proxies in the RADIUS infrastructure.  These
 mechanisms are not mandatory to implement.  It is believed that
 ongoing work to provide direct TLS connections between a RADIUS
 client and RADIUS server will provide similar assurances but better
 deployability.  XML security is appropriate for deployments where
 end-to-end security is required but proxies cannot be removed or
 where SAML messages need to be verified at a later time or by parties
 not involved in the authentication exchange.

11. IANA Considerations

11.1. RADIUS Attributes

 The Attribute Types and Attribute Values defined in this document
 have been registered by the Internet Assigned Numbers Authority
 (IANA) from the RADIUS namespaces as described in the "IANA
 Considerations" section of [RFC3575], in accordance with BCP 26
 [RFC5226].  For RADIUS packets, attributes, and registries created by
 this document, IANA has placed them at
 <http://www.iana.org/assignments/radius-types>.

Howlett, et al. Standards Track [Page 25] RFC 7833 SAML RADIUS May 2016

 In particular, this document defines two new RADIUS attributes,
 entitled "SAML-Assertion" and "SAML-Protocol" (see Section 3), with
 assigned values of 245.1 and 245.2 from the long extended space
 [RFC6929]:
   Type  Ext. Type  Name            Length  Meaning
   ----  ---------  --------------  ------  ------------------------
   245   1          SAML-Assertion  >=5     Encodes a SAML Assertion
   245   2          SAML-Protocol   >=5     Encodes a SAML protocol
                                              message

11.2. ABFAB Parameters

 A new top-level registry has been created, entitled "Application
 Bridging for Federated Access Beyond Web (ABFAB) Parameters".
 In this top-level registry, a sub-registry entitled "ABFAB URN
 Parameters" has been created.  Registration in this registry is via
 IETF Review or Expert Review procedures [RFC5226].
 This paragraph gives guidance to designated experts.  Registrations
 in this registry are generally only expected as part of protocols
 published as RFCs on the IETF stream; other URIs are expected to be
 better choices for non-IETF work.  Expert review is permitted mainly
 to allow early registration related to specifications under
 development when the community believes they have reached sufficient
 maturity.  The expert SHOULD evaluate the maturity and stability of
 such an IETF-stream specification.  Experts SHOULD review anything
 not from the IETF stream for consistency and consensus with current
 practice.  Today, such requests would not typically be approved.
 If a parameter named "paramname" is registered in this registry, then
 its URN will be "urn:ietf:params:abfab:paramname".  The initial
 registrations are as follows:
                +-------------------------+-----------+
                | Parameter               | Reference |
                +-------------------------+-----------+
                | bindings:radius         | Section 4 |
                | nameid-format:nai       | Section 5 |
                | profiles:authentication | Section 7 |
                | profiles:query          | Section 8 |
                | cm:user                 | Section 6 |
                | cm:machine              | Section 6 |
                +-------------------------+-----------+
                           ABFAB Parameters

Howlett, et al. Standards Track [Page 26] RFC 7833 SAML RADIUS May 2016

11.3. Registration of the ABFAB URN Namespace

 IANA has registered the "abfab" URN sub-namespace in the IETF URN
 sub-namespace for protocol parameters defined in [RFC3553].
 Registry Name: abfab
 Specification: RFC 7833 (this document)
 Repository: ABFAB URN Parameters (Section 11.2)
 Index Value: Sub-parameters MUST be specified in UTF-8, using
 standard URI encoding where necessary.

12. References

12.1. Normative References

 [OASIS.saml-bindings-2.0-os]
            Cantor, S., Hirsch, F., Kemp, J., Philpott, R., and E.
            Maler, "Bindings for the OASIS Security Assertion
            Markup Language (SAML) V2.0", OASIS
            Standard saml-bindings-2.0-os, March 2005,
            <http://docs.oasis-open.org/security/saml/v2.0/
            saml-bindings-2.0-os.pdf>.
 [OASIS.saml-core-2.0-os]
            Cantor, S., Kemp, J., Philpott, R., and E. Maler,
            "Assertions and Protocols for the OASIS Security Assertion
            Markup Language (SAML) V2.0", OASIS
            Standard saml-core-2.0-os, March 2005,
            <http://docs.oasis-open.org/security/saml/v2.0/
            saml-core-2.0-os.pdf>.
 [OASIS.saml-metadata-2.0-os]
            Cantor, S., Moreh, J., Philpott, R., and E. Maler,
            "Metadata for the OASIS Security Assertion Markup Language
            (SAML) V2.0", OASIS Standard saml-metadata-2.0-os,
            March 2005, <http://docs.oasis-open.org/security/
            saml/v2.0/saml-metadata-2.0-os.pdf>.
 [OASIS.saml-profiles-2.0-os]
            Hughes, J., Cantor, S., Hodges, J., Hirsch, F., Mishra,
            P., Philpott, R., and E. Maler, "Profiles for the OASIS
            Security Assertion Markup Language (SAML) V2.0", OASIS
            Standard OASIS.saml-profiles-2.0-os, March 2005,
            <http://docs.oasis-open.org/security/saml/v2.0/
            saml-profiles-2.0-os.pdf>.

Howlett, et al. Standards Track [Page 27] RFC 7833 SAML RADIUS May 2016

 [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
            Requirement Levels", BCP 14, RFC 2119,
            DOI 10.17487/RFC2119, March 1997,
            <http://www.rfc-editor.org/info/rfc2119>.
 [RFC2865]  Rigney, C., Willens, S., Rubens, A., and W. Simpson,
            "Remote Authentication Dial In User Service (RADIUS)",
            RFC 2865, DOI 10.17487/RFC2865, June 2000,
            <http://www.rfc-editor.org/info/rfc2865>.
 [RFC3575]  Aboba, B., "IANA Considerations for RADIUS (Remote
            Authentication Dial In User Service)", RFC 3575,
            DOI 10.17487/RFC3575, July 2003,
            <http://www.rfc-editor.org/info/rfc3575>.
 [RFC3579]  Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication
            Dial In User Service) Support For Extensible
            Authentication Protocol (EAP)", RFC 3579,
            DOI 10.17487/RFC3579, September 2003,
            <http://www.rfc-editor.org/info/rfc3579>.
 [RFC6614]  Winter, S., McCauley, M., Venaas, S., and K. Wierenga,
            "Transport Layer Security (TLS) Encryption for RADIUS",
            RFC 6614, DOI 10.17487/RFC6614, May 2012,
            <http://www.rfc-editor.org/info/rfc6614>.
 [RFC6929]  DeKok, A. and A. Lior, "Remote Authentication Dial In User
            Service (RADIUS) Protocol Extensions", RFC 6929,
            DOI 10.17487/RFC6929, April 2013,
            <http://www.rfc-editor.org/info/rfc6929>.
 [RFC7542]  DeKok, A., "The Network Access Identifier", RFC 7542,
            DOI 10.17487/RFC7542, May 2015,
            <http://www.rfc-editor.org/info/rfc7542>.

Howlett, et al. Standards Track [Page 28] RFC 7833 SAML RADIUS May 2016

12.2. Informative References

 [RADIUS-Large-Pkts]
            Hartman, S., "Larger Packets for RADIUS over TCP", Work in
            Progress, draft-ietf-radext-bigger-packets-07, April 2016.
 [RFC3553]  Mealling, M., Masinter, L., Hardie, T., and G. Klyne, "An
            IETF URN Sub-namespace for Registered Protocol
            Parameters", BCP 73, RFC 3553, DOI 10.17487/RFC3553,
            June 2003, <http://www.rfc-editor.org/info/rfc3553>.
 [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
            IANA Considerations Section in RFCs", BCP 26, RFC 5226,
            DOI 10.17487/RFC5226, May 2008,
            <http://www.rfc-editor.org/info/rfc5226>.
 [RFC6733]  Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn,
            Ed., "Diameter Base Protocol", RFC 6733,
            DOI 10.17487/RFC6733, October 2012,
            <http://www.rfc-editor.org/info/rfc6733>.
 [RFC7055]  Hartman, S., Ed., and J. Howlett, "A GSS-API Mechanism for
            the Extensible Authentication Protocol", RFC 7055,
            DOI 10.17487/RFC7055, December 2013,
            <http://www.rfc-editor.org/info/rfc7055>.
 [RFC7499]  Perez-Mendez, A., Ed., Marin-Lopez, R., Pereniguez-Garcia,
            F., Lopez-Millan, G., Lopez, D., and A. DeKok, "Support of
            Fragmentation of RADIUS Packets", RFC 7499,
            DOI 10.17487/RFC7499, April 2015,
            <http://www.rfc-editor.org/info/rfc7499>.
 [RFC7831]  Howlett, J., Hartman, S., Tschofenig, H., and J. Schaad,
            "Application Bridging for Federated Access Beyond Web
            (ABFAB) Architecture", RFC 7831, DOI 10.17487/RFC7831,
            May 2016, <http://www.rfc-editor.org/info/rfc7831>.
 [W3C.REC-xmlschema-1]
            Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn,
            "XML Schema Part 1: Structures Second Edition",
            W3C REC-xmlschema-1, October 2004,
            <http://www.w3.org/TR/xmlschema-1/>.

Howlett, et al. Standards Track [Page 29] RFC 7833 SAML RADIUS May 2016

Appendix A. XML Schema

 The following schema formally defines the
 "urn:ietf:params:xml:ns:abfab" namespace used in this document, in
 conformance with [W3C.REC-xmlschema-1].  Although XML validation is
 optional, the schema that follows is the normative definition of the
 constructs it defines.  Where the schema differs from any prose in
 this specification, the schema takes precedence.
         <schema
           targetNamespace="urn:ietf:params:xml:ns:abfab"
           xmlns="http://www.w3.org/2001/XMLSchema"
           xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata"
           xmlns:abfab="urn:ietf:params:xml:ns:abfab"
           elementFormDefault="unqualified"
           attributeFormDefault="unqualified"
           blockDefault="substitution"
           version="1.0">
           <import namespace="urn:oasis:names:tc:SAML:2.0:metadata"/>
           <complexType name="RADIUSIDPDescriptorType">
             <complexContent>
               <extension base="md:RoleDescriptorType">
                 <sequence>
                   <element ref="abfab:RADIUSIDPService"
                                 minOccurs="0" maxOccurs="unbounded"/>
                   <element ref="abfab:RADIUSRealm"
                                 minOccurs="0" maxOccurs="unbounded"/>
                 </sequence>
               </extension>
             </complexContent>
           </complexType>
           <element name="RADIUSIDPService" type="md:EndpointType"/>
           <element name="RADIUSRealm" type="string"/>

Howlett, et al. Standards Track [Page 30] RFC 7833 SAML RADIUS May 2016

           <complexType name="RADIUSRPDescriptorType">
             <complexContent>
               <extension base="md:RoleDescriptorType">
                 <sequence>
                   <element ref="md:RADIUSRPService"
                                 minOccurs="0" maxOccurs="unbounded"/>
                   <element ref="md:RADIUSNasIpAddress"
                                 minOccurs="0" maxOccurs="unbounded"/>
                   <element ref="md:RADIUSNasIdentifier"
                                 minOccurs="0" maxOccurs="unbounded"/>
                   <element ref="md:RADIUSGssEapName"
                                 minOccurs="0" maxOccurs="unbounded"/>
                 </sequence>
               </extension>
             </complexContent>
           </complexType>
           <element name="RADIUSRPService" type="md:EndpointType"/>
           <element name="RADIUSNasIpAddress" type="string"/>
           <element name="RADIUSNasIdentifier" type="string"/>
           <element name="RADIUSGssEapName" type="string"/>
         </schema>

Howlett, et al. Standards Track [Page 31] RFC 7833 SAML RADIUS May 2016

Acknowledgments

 The authors would like to acknowledge the OASIS Security Services
 (SAML) Technical Committee, and Scott Cantor in particular, for their
 help with the SAML-related material.
 The authors would also like to acknowledge the collaboration of Jim
 Schaad, Leif Johansson, Klaas Wierenga, Stephen Farrell, Gabriel
 Lopez-Millan, and Rafa Marin-Lopez, who have provided valuable
 comments on this document.

Authors' Addresses

 Josh Howlett
 Jisc
 Lumen House, Library Avenue, Harwell
 Oxford  OX11 0SG
 United Kingdom
 Phone: +44 1235 822363
 Email: Josh.Howlett@ja.net
 Sam Hartman
 Painless Security
 Email: hartmans-ietf@mit.edu
 Alejandro Perez-Mendez (editor)
 University of Murcia
 Campus de Espinardo S/N, Faculty of Computer Science
 Murcia  30100
 Spain
 Phone: +34 868 88 46 44
 Email: alex@um.es

Howlett, et al. Standards Track [Page 32]

/data/webs/external/dokuwiki/data/pages/rfc/rfc7833.txt · Last modified: 2016/05/11 22:52 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki