< draft-ietf-abfab-aaa-saml-11.txt   draft-ietf-abfab-aaa-saml-12.txt >
ABFAB J. Howlett ABFAB J. Howlett
Internet-Draft Janet Internet-Draft Janet
Intended status: Informational S. Hartman Intended status: Informational S. Hartman
Expires: February 8, 2016 Painless Security Expires: April 21, 2016 Painless Security
A. Perez-Mendez, Ed. A. Perez-Mendez, Ed.
University of Murcia University of Murcia
August 7, 2015 October 19, 2015
A RADIUS Attribute, Binding, Profiles, Name Identifier Format, and A RADIUS Attribute, Binding, Profiles, Name Identifier Format, and
Confirmation Methods for SAML Confirmation Methods for SAML
draft-ietf-abfab-aaa-saml-11 draft-ietf-abfab-aaa-saml-12
Abstract Abstract
This document describes the use of the Security Assertion Mark-up This document describes the use of the Security Assertion Mark-up
Language (SAML) with RADIUS in the context of the ABFAB architecture. Language (SAML) with RADIUS in the context of the ABFAB architecture.
It defines two RADIUS attributes, a SAML binding, a SAML name It defines two RADIUS attributes, a SAML binding, a SAML name
identifier format, two SAML profiles, and two SAML confirmation identifier format, two SAML profiles, and two SAML confirmation
methods. The RADIUS attributes permit encapsulation of SAML methods. The RADIUS attributes permit encapsulation of SAML
assertions and protocol messages within RADIUS, allowing SAML assertions and protocol messages within RADIUS, allowing SAML
entities to communicate using the binding. The two profiles describe entities to communicate using the binding. The two profiles describe
skipping to change at page 1, line 49 skipping to change at page 1, line 49
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on February 8, 2016. This Internet-Draft will expire on April 21, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 27 skipping to change at page 2, line 27
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. RADIUS SAML Attributes . . . . . . . . . . . . . . . . . . . 5 3. RADIUS SAML Attributes . . . . . . . . . . . . . . . . . . . 5
3.1. SAML-Assertion attribute . . . . . . . . . . . . . . . . 5 3.1. SAML-Assertion attribute . . . . . . . . . . . . . . . . 5
3.2. SAML-Message attribute . . . . . . . . . . . . . . . . . 6 3.2. SAML-Protocol attribute . . . . . . . . . . . . . . . . . 6
4. SAML RADIUS Binding . . . . . . . . . . . . . . . . . . . . . 7 4. SAML RADIUS Binding . . . . . . . . . . . . . . . . . . . . . 7
4.1. Required Information . . . . . . . . . . . . . . . . . . 7 4.1. Required Information . . . . . . . . . . . . . . . . . . 7
4.2. Operation . . . . . . . . . . . . . . . . . . . . . . . . 7 4.2. Operation . . . . . . . . . . . . . . . . . . . . . . . . 7
4.3. Processing of names . . . . . . . . . . . . . . . . . . . 9 4.3. Processing of names . . . . . . . . . . . . . . . . . . . 9
4.3.1. AAA names . . . . . . . . . . . . . . . . . . . . . . 9 4.3.1. AAA names . . . . . . . . . . . . . . . . . . . . . . 9
4.3.2. SAML names . . . . . . . . . . . . . . . . . . . . . 9 4.3.2. SAML names . . . . . . . . . . . . . . . . . . . . . 9
4.3.3. Mapping of AAA names in SAML metadata . . . . . . . . 10 4.3.3. Mapping of AAA names in SAML metadata . . . . . . . . 10
4.3.4. Example of SAML metadata including AAA names . . . . 12 4.3.4. Example of SAML metadata including AAA names . . . . 12
4.4. Use of XML Signatures . . . . . . . . . . . . . . . . . . 13 4.4. Use of XML Signatures . . . . . . . . . . . . . . . . . . 13
4.5. Metadata Considerations . . . . . . . . . . . . . . . . . 13 4.5. Metadata Considerations . . . . . . . . . . . . . . . . . 13
skipping to change at page 2, line 52 skipping to change at page 2, line 52
7.2. Profile Overview . . . . . . . . . . . . . . . . . . . . 14 7.2. Profile Overview . . . . . . . . . . . . . . . . . . . . 14
7.3. Profile Description . . . . . . . . . . . . . . . . . . . 16 7.3. Profile Description . . . . . . . . . . . . . . . . . . . 16
7.3.1. Client Request to Relying Party . . . . . . . . . . . 16 7.3.1. Client Request to Relying Party . . . . . . . . . . . 16
7.3.2. Relying Party Issues <samlp:AuthnRequest> to Identity 7.3.2. Relying Party Issues <samlp:AuthnRequest> to Identity
Provider . . . . . . . . . . . . . . . . . . . . . . 16 Provider . . . . . . . . . . . . . . . . . . . . . . 16
7.3.3. Identity Provider Identifies Client . . . . . . . . . 17 7.3.3. Identity Provider Identifies Client . . . . . . . . . 17
7.3.4. Identity Provider Issues <samlp:Response> to Relying 7.3.4. Identity Provider Issues <samlp:Response> to Relying
Party . . . . . . . . . . . . . . . . . . . . . . . . 17 Party . . . . . . . . . . . . . . . . . . . . . . . . 17
7.3.5. Relying Party Grants or Denies Access to Client . . . 17 7.3.5. Relying Party Grants or Denies Access to Client . . . 17
7.4. Use of Authentication Request Protocol . . . . . . . . . 17 7.4. Use of Authentication Request Protocol . . . . . . . . . 17
7.4.1. <samlp:AuthnRequest> Usage . . . . . . . . . . . . . 18 7.4.1. <samlp:AuthnRequest> Usage . . . . . . . . . . . . . 17
7.4.2. <samlp:Response> Message Usage . . . . . . . . . . . 18 7.4.2. <samlp:Response> Message Usage . . . . . . . . . . . 18
7.4.3. <samlp:Response> Message Processing Rules . . . . . . 19 7.4.3. <samlp:Response> Message Processing Rules . . . . . . 19
7.4.4. Unsolicited Responses . . . . . . . . . . . . . . . . 19 7.4.4. Unsolicited Responses . . . . . . . . . . . . . . . . 19
7.4.5. Use of the SAML RADIUS Binding . . . . . . . . . . . 19 7.4.5. Use of the SAML RADIUS Binding . . . . . . . . . . . 19
7.4.6. Use of XML Signatures . . . . . . . . . . . . . . . . 20 7.4.6. Use of XML Signatures . . . . . . . . . . . . . . . . 19
7.4.7. Metadata Considerations . . . . . . . . . . . . . . . 20 7.4.7. Metadata Considerations . . . . . . . . . . . . . . . 20
8. ABFAB Assertion Query/Request Profile . . . . . . . . . . . . 20 8. ABFAB Assertion Query/Request Profile . . . . . . . . . . . . 20
8.1. Required Information . . . . . . . . . . . . . . . . . . 20 8.1. Required Information . . . . . . . . . . . . . . . . . . 20
8.2. Profile Overview . . . . . . . . . . . . . . . . . . . . 20 8.2. Profile Overview . . . . . . . . . . . . . . . . . . . . 20
8.3. Profile Description . . . . . . . . . . . . . . . . . . . 21 8.3. Profile Description . . . . . . . . . . . . . . . . . . . 21
8.3.1. Differences from the SAML V2.0 Assertion 8.3.1. Differences from the SAML V2.0 Assertion
Query/Request Profile . . . . . . . . . . . . . . . . 21 Query/Request Profile . . . . . . . . . . . . . . . . 21
8.3.2. Use of the SAML RADIUS Binding . . . . . . . . . . . 22 8.3.2. Use of the SAML RADIUS Binding . . . . . . . . . . . 22
8.3.3. Use of XML Signatures . . . . . . . . . . . . . . . . 22 8.3.3. Use of XML Signatures . . . . . . . . . . . . . . . . 22
8.3.4. Metadata Considerations . . . . . . . . . . . . . . . 22 8.3.4. Metadata Considerations . . . . . . . . . . . . . . . 22
9. Privacy considerations . . . . . . . . . . . . . . . . . . . 22 9. Privacy considerations . . . . . . . . . . . . . . . . . . . 22
10. Security Considerations . . . . . . . . . . . . . . . . . . . 23 10. Security Considerations . . . . . . . . . . . . . . . . . . . 23
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
11.1. RADIUS Attributes . . . . . . . . . . . . . . . . . . . 24 11.1. RADIUS Attributes . . . . . . . . . . . . . . . . . . . 24
11.2. ABFAB Parameters . . . . . . . . . . . . . . . . . . . . 24 11.2. ABFAB Parameters . . . . . . . . . . . . . . . . . . . . 24
11.3. Registration of the ABFAB URN Namespace . . . . . . . . 25 11.3. Registration of the ABFAB URN Namespace . . . . . . . . 25
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
13.1. Normative References . . . . . . . . . . . . . . . . . . 25 13.1. Normative References . . . . . . . . . . . . . . . . . . 25
13.2. Informative References . . . . . . . . . . . . . . . . . 27 13.2. Informative References . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 Appendix A. XML Schema . . . . . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31
1. Introduction 1. Introduction
Within the ABFAB architecture [I-D.ietf-abfab-arch] it is often Within the ABFAB architecture [I-D.ietf-abfab-arch] it is often
desirable to convey Security Assertion Mark-up Language (SAML) desirable to convey Security Assertion Mark-up Language (SAML)
assertions and protocol messages. assertions and protocol messages.
SAML typically only considers the use of HTTP-based transports, known SAML typically only considers the use of HTTP-based transports, known
as bindings [OASIS.saml-bindings-2.0-os], which are primarily as bindings [OASIS.saml-bindings-2.0-os], which are primarily
intended for use with the SAML V2.0 Web Browser Single Sign-On intended for use with the SAML V2.0 Web Browser Single Sign-On
skipping to change at page 4, line 26 skipping to change at page 4, line 26
o A profile of the SAML Assertion Query And Request Protocol that o A profile of the SAML Assertion Query And Request Protocol that
uses the SAML RADIUS binding to effect the query and request of uses the SAML RADIUS binding to effect the query and request of
SAML assertions. SAML assertions.
o Two SAML Subject Confirmation Methods for indicating that a user o Two SAML Subject Confirmation Methods for indicating that a user
or machine client is the subject of an assertion. or machine client is the subject of an assertion.
This document adheres to the guidelines stipulated by This document adheres to the guidelines stipulated by
[OASIS.saml-bindings-2.0-os] and [OASIS.saml-profiles-2.0-os] for [OASIS.saml-bindings-2.0-os] and [OASIS.saml-profiles-2.0-os] for
defining new SAML bindings and profiles respectively, and other defining new SAML bindings and profiles respectively, and other
conventions applied formally or otherwise within SAML. In particular conventions applied formally or otherwise within SAML. In
where this document provides a 'Required Information' section for the particular, this document provides a 'Required Information' section
binding and profiles that enumerate: for the binding and profiles that enumerate:
o A URI that uniquely identifies the protocol binding or profile. o A URI that uniquely identifies the protocol binding or profile.
o Postal or electronic contact information for the author. o Postal or electronic contact information for the author.
o A reference to previously defined bindings or profiles that the o A reference to previously defined bindings or profiles that the
new binding updates or obsoletes. new binding updates or obsoletes.
o In the case of a profile, any SAML confirmation method identifiers o In the case of a profile, any SAML confirmation method identifiers
defined and/or utilized by the profile. defined and/or utilized by the profile.
skipping to change at page 5, line 32 skipping to change at page 5, line 32
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
3. RADIUS SAML Attributes 3. RADIUS SAML Attributes
The RADIUS SAML binding defined in Section 4 of this document uses The RADIUS SAML binding defined in Section 4 of this document uses
two attributes to convey SAML assertions and protocol messages two attributes to convey SAML assertions and protocol messages
respectively [OASIS.saml-core-2.0-os]. Owing to the typical size of respectively [OASIS.saml-core-2.0-os]. Owing to the typical size of
these structures, these attributes use the Long Extended Type format these structures, these attributes use the Long Extended Type format
[RFC6929] to encapsulate their data. [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.
3.1. SAML-Assertion attribute 3.1. SAML-Assertion attribute
This attribute is used to encode a SAML assertion. The following This attribute is used to encode a SAML assertion. The following
figure represents the format of this attribute. figure represents the format of this attribute.
1 2 3 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 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 | | Type | Length | Extended-Type |M| Reserved |
skipping to change at page 6, line 25 skipping to change at page 6, line 26
As described in [RFC6929]. As described in [RFC6929].
Reserved Reserved
As described in [RFC6929]. As described in [RFC6929].
Value Value
One or more octets encoding a SAML assertion. One or more octets encoding a SAML assertion.
3.2. SAML-Message attribute 3.2. SAML-Protocol attribute
This attribute is used to encode a SAML protocol message. The This attribute is used to encode a SAML protocol message. The
following figure represents the format of this attribute. following figure represents the format of this attribute.
1 2 3 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 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 | | Type | Length | Extended-Type |M| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value... | Value...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: SAML-Message format Figure 2: SAML-Protocol format
Type Type
245 (To be confirmed by IANA) 245 (To be confirmed by IANA)
Length Length
>= 5 >= 5
Extended-Type Extended-Type
skipping to change at page 7, line 32 skipping to change at page 7, line 35
Identification: urn:ietf:params:abfab:bindings:radius Identification: urn:ietf:params:abfab:bindings:radius
Contact information: iesg@ietf.org Contact information: iesg@ietf.org
Updates: None. Updates: None.
4.2. Operation 4.2. Operation
RADIUS can be used over multiple underlying transports. It is RADIUS can be used over multiple underlying transports. It is
REQUIRED that the RADIUS exchange is protected using TLS encryption REQUIRED that the RADIUS exchange is protected using TLS encryption
for RADIUS [RFC6614] to provide confidentiality and improve integrity for RADIUS [RFC6614] to provide confidentiality and integrity
protection, unless alternative methods are used to ensure protection, unless alternative methods are used to ensure
confidentiality, such as IPSEC tunnels or a sufficiently secure confidentiality, such as IPSEC tunnels or a sufficiently secure
internal network. internal network.
Implementations of this profile can take advantage of mechanisms to Implementations of this profile can take advantage of mechanisms to
permit the transport of longer SAML messages over RADIUS transports, permit the transport of longer SAML messages over RADIUS transports,
such as the Support of fragmentation of RADIUS packets [RFC7499] or such as the Support of fragmentation of RADIUS packets [RFC7499] or
Larger Packets for RADIUS over TCP [I-D.ietf-radext-bigger-packets]. Larger Packets for RADIUS over TCP [I-D.ietf-radext-bigger-packets].
There are two system models for the use of SAML over RADIUS. The There are two system models for the use of SAML over RADIUS. The
first is a request-response model, using the RADIUS SAML-Message first is a request-response model, using the RADIUS SAML-Protocol
attribute defined in Section 3 to encapsulate the SAML protocol attribute defined in Section 3 to encapsulate the SAML protocol
messages. messages.
1. The RADIUS client, acting as a Relying Party (RP), transmits a 1. The RADIUS client, acting as a Relying Party (RP), transmits a
SAML request element within a RADIUS Access-Request message. SAML request element within a RADIUS Access-Request message.
This message MUST include a single instance of the RADIUS User- This message MUST include a single instance of the RADIUS User-
Name attribute whose value MUST conform to the Network Access Name attribute whose value MUST conform to the Network Access
Identifier [RFC7542] scheme. The Relying Party MUST NOT include Identifier [RFC7542] scheme. The Relying Party MUST NOT include
more than one SAML request element. more than one SAML request element.
skipping to change at page 8, line 26 skipping to change at page 8, line 27
as the same conditions that cause the IdP to discard the SAML as the same conditions that cause the IdP to discard the SAML
request may also cause the RADIUS server to fail to request may also cause the RADIUS server to fail to
authenticate). authenticate).
The second system model permits a RADIUS server acting as an Identity The second system model permits a RADIUS server acting as an Identity
Provider to use the RADIUS SAML-Assertion attribute defined in Provider to use the RADIUS SAML-Assertion attribute defined in
Section 3 to encapsulate an unsolicited SAML assertion. This Section 3 to encapsulate an unsolicited SAML assertion. This
attribute MUST be included in a RADIUS Access-Accept message. When attribute MUST be included in a RADIUS Access-Accept message. When
included, the attribute MUST contain a single SAML assertion. included, the attribute MUST contain a single SAML assertion.
RADIUS servers MUST NOT include both the SAML-Message and the SAML- RADIUS servers MUST NOT include both the SAML-Protocol and the SAML-
Assertion attribute in the same RADIUS message. If an IdP is Assertion attribute in the same RADIUS message. If an IdP is
producing a response to a SAML request, then the first system model 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 is used. An IdP MAY ignore a SAML request and send an unsolicited
assertion using the second system model using the RADIUS SAML- assertion using the second system model using the RADIUS SAML-
Assertion attribute. Assertion attribute.
In either system model, Identity Providers SHOULD return a RADIUS In either system model, Identity Providers SHOULD return a RADIUS
state attribute as part of the Access-Accept message so that future 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 SAML queries or requests can be run against the same context of an
authentication exchange. authentication exchange.
This binding is intended to be composed with other uses of RADIUS, This binding is intended to be composed with other uses of RADIUS,
such as network access. Therefore, other arbitrary RADIUS attributes such as network access. Therefore, other arbitrary RADIUS attributes
will be used in either the request or response. MAY be used in either the request or response.
In the case of a SAML processing error and successful authentication,
the RADIUS server SHOULD include a SAML-specified <samlp:Status>
element in the SAML response that is transported within the Access-
Accept packet sent by the RADIUS server.
In the case of a SAML processing error and failed authentication, the In the case of a SAML processing error, the RADIUS server MAY include
RADIUS server MAY include a SAML-specified <samlp:Status> element in a SAML response message with an appropriate value for the
the SAML response that is transported within the Access-Reject packet <samlp:Status> element within the Access-Accept or Access-Reject
sent by the RADIUS server. packet to notify the client. Alternatively, the RADIUS server can
respond without a SAML-Protocol attribute.
4.3. Processing of names 4.3. Processing of names
SAML entities using profiles of this binding will typically possess SAML entities using profiles making use of this binding will
both the SAML and AAA names of their correspondents. Frequently typically possess both the SAML and AAA names of their
these entities will need to apply policies using these names; for correspondents. Frequently these entities will need to apply
example, when deciding to release attributes. Often these policies policies using these names; for example, when deciding to release
will be security-sensitive, and so it is important that policy is attributes. Often these policies will be security-sensitive, and so
applied on these names consistently. it is important that policy is applied on these names consistently.
4.3.1. AAA names 4.3.1. AAA names
These rules relate to the processing of AAA names by SAML entities These rules relate to the processing of AAA names by SAML entities
using profiles of this binding. using profiles making use of this binding.
o Identity Providers SHOULD apply policy based on the Relying o Identity Providers SHOULD apply policy based on the Relying
Party's identity associated with the RADIUS Access-Request. Party's identity associated with the RADIUS Access-Request.
o Relying Parties SHOULD apply policy based on the NAI realm o Relying Parties SHOULD apply policy based on the NAI realm
associated with the RADIUS Access-Accept. associated with the RADIUS Access-Accept.
4.3.2. SAML names 4.3.2. SAML names
These rules relate to the processing of SAML names by SAML entities These rules relate to the processing of SAML names by SAML entities
using profiles of this binding. using profiles making use of this binding.
Identity Providers MAY apply policy based on the Relying Party's SAML Identity Providers MAY apply policy based on the Relying Party's SAML
<entityId>. In such cases, at least one of the following methods is entityId. In such cases, at least one of the following methods is
required in order to establish a relation between the SAML name and required in order to establish a relation between the SAML name and
the AAA name of the Relying Party: the AAA name of the Relying Party:
o RADIUS client identity in trusted digitally signed SAML request. o RADIUS client identity in trusted SAML metadata (as described in
section Section 4.3.3).
o RADIUS client identity in trusted SAML federation metadata (as in o RADIUS client identity in trusted digitally signed SAML request.
[OASIS.saml-metadata-2.0-os]).
A digitally signed SAML request without the RADIUS client identity is A digitally signed SAML request without the RADIUS client identity is
not sufficient, since a malicious RADIUS entity can observe a SAML not sufficient, since a malicious RADIUS entity can observe a SAML
message and include it in a different RADIUS message without the message and include it in a different RADIUS message without the
consent of the issuer of that SAML message. If an Identity Provider consent of the issuer of that SAML message. If an Identity Provider
were to process the SAML message without confirming that it applied were to process the SAML message without confirming that it applied
to the RADIUS message, inappropriate policy would be used. to the RADIUS message, inappropriate policy would be used.
Relying Parties MAY apply policy based on the SAML issuer's Relying Parties MAY apply policy based on the SAML issuer's
<entityId>. In such cases, at least one of the following methods is <entityId>. In such cases, at least one of the following methods is
required in order to establish a relation between the SAML name and required in order to establish a relationship between the SAML name
the AAA name of the Identity Provider: and the AAA name of the Identity Provider:
o RADIUS realm in trusted SAML metadata (as described in section
Section 4.3.3).
o RADIUS realm in trusted digitally signed SAML response or o RADIUS realm in trusted digitally signed SAML response or
assertion. assertion.
o RADIUS realm in trusted SAML federation metadata.
A digitally signed SAML response alone is not sufficient for the same A digitally signed SAML response alone is not sufficient for the same
reasons described above for SAML requests. reasons described above for SAML requests.
4.3.3. Mapping of AAA names in SAML metadata 4.3.3. Mapping of AAA names in SAML metadata
This section defines the extensions to the SAML metadata This section defines extensions to the SAML metadata schema
specification [OASIS.saml-metadata-2.0-os] that are required in order [OASIS.saml-metadata-2.0-os] that are required in order to represent
to represent AAA names associated to a particular <EntityDescriptor> AAA names associated with a particular <EntityDescriptor> element.
element.
In SAML metadata, each single entity may act in many different roles In SAML metadata, a single entity may act in many different roles in
in the support of multiple profiles. This document defines two new the support of multiple profiles. This document defines two new
roles: RADIUS IDP and RADIUS RP, requiring the declaration of two new roles: RADIUS IDP and RADIUS RP, requiring the declaration of two new
subtypes of RoleDescriptorType: RADIUSIDPDescriptor and subtypes of RoleDescriptorType: RADIUSIDPDescriptorType and
RADIUSRPDescriptor. These subtypes define the additional elements RADIUSRPDescriptorType. These subtypes contain the additional
required to represent AAA names for IDP and RP entities respectively. elements required to represent AAA names for IDP and RP entities
respectively.
4.3.3.1. <RADIUSIDPDescriptor> 4.3.3.1. RADIUSIDPDescriptorType
The <RADIUSIDPDescriptor> element extends RoleDescriptorType with The RADIUSIDPDescriptorType complex type extends RoleDescriptorType
elements common to IdPs that support RADIUS. Its with elements common to IdPs that support RADIUS. It contains the
RADIUSIDPDescriptorType complex type contains the following following additional elements:
additional elements:
<RADIUSIDPService> [Zero or More] Zero or more elements of type <RADIUSIDPService> [Zero or More] Zero or more elements of type
EndpointType that describe RADIUS endpoints that are associated to EndpointType that describe RADIUS endpoints that are associated
this Entity. with the entity.
<RADIUSRealm> [Zero or More] Zero or more elements of type xs:string <RADIUSRealm> [Zero or More] Zero or more elements of type string
that represent the acceptable values of the RADIUS realm that represent the acceptable values of the RADIUS realm
associated to this Entity, obtained from the realm part of RADIUS associated with the entity, obtained from the realm part of RADIUS
User-Name attribute. User-Name attribute.
The following schema fragment defines the <RADIUSIDPDescriptor> The following schema fragment defines the RADIUSIDPDescriptorType
element and its RADIUSIDPDescriptorType complex type: complex type:
<element name="RADIUSIDPDescriptor" <complexType name="RADIUSIDPDescriptorType">
type="md:RADIUSIDPDescriptorType"/> <complexContent>
<complexType name="RADIUSIDPDescriptorType"> <extension base="md:RoleDescriptorType">
<complexContent> <sequence>
<extension base="md:RoleDescriptorType"> <element ref="abfab:RADIUSIDPService" minOccurs="0" maxOccurs="unbounded"/>
<sequence> <element ref="abfab:RADIUSRealm" minOccurs="0" maxOccurs="unbounded"/>
<element ref="md:RADIUSIDPService" </sequence>
minOccurs="0" maxOccurs="unbounded"/> </extension>
<element ref="md:RADIUSRealm" </complexContent>
minOccurs="0" maxOccurs="unbounded"/> </complexType>
</sequence> <element name="RADIUSIDPService" type="md:EndpointType"/>
</extension> <element name="RADIUSRealm" type="string"/>
</complexContent>
</complexType>
<element name="RADIUSIDPService" type="md:EndpointType"/>
<element name="RADIUSRealm" type="xs:string"/>
Figure 3: RADIUSIDPDescriptor schema Figure 3: RADIUSIDPDescriptorType schema
4.3.3.2. <RADIUSRPDescriptor> 4.3.3.2. RADIUSRPDescriptorType
The <RADIUSRPDescriptor> element extends RoleDescriptorType with The RADIUSRPDescriptorType complex type extends RoleDescriptorType
elements common to RPs that support RADIUS. Its with elements common to RPs that support RADIUS. It contains the
RADIUSRPDescriptorType complex type contains the following additional following additional elements:
elements:
<RADIUSRPService> [Zero or More] Zero or more elements of type <RADIUSRPService> [Zero or More] Zero or more elements of type
EndpointType that describe RADIUS endpoints that are associated to EndpointType that describe RADIUS endpoints that are associated
this Entity. with the entity.
<RADIUSNasIpAddress> [Zero or More] Zero or more elements of type <RADIUSNasIpAddress> [Zero or More] Zero or more elements of type
xs:string that represent the acceptable values of the RADIUS NAS- string that represent the acceptable values of the RADIUS NAS-IP-
IP-Address attribute associated to this Entity. Address or NAS-IPv6-Address attributes associated with the entity.
<RADIUSNasIdentifier> [Zero or More] Zero or more elements of type <RADIUSNasIdentifier> [Zero or More] Zero or more elements of type
xs:string that represent the acceptable values of the RADIUS NAS- string that represent the acceptable values of the RADIUS NAS-
Identifier attribute associated to this Entity. Identifier attribute associated with the entity.
<RADIUSGssEapName> [Zero or More] Zero or more elements of type <RADIUSGssEapName> [Zero or More] Zero or more elements of type
xs:string that represent the acceptable values of the GSS-EAP string that represent the acceptable values of the GSS-EAP
acceptor name associated to this Entity. The format for this name acceptor name associated with the entity. The format for this
is described in section 3.1 of [RFC7055], while section 3.4 name is described in section 3.1 of [RFC7055], while section 3.4
describes how that name is decomposed and transported using RADIUS describes how that name is decomposed and transported using RADIUS
attributes. attributes.
The following schema fragment defines the <RADIUSRPDescriptor> The following schema fragment defines the RADIUSRPDescriptorType
element and its RADIUSRPDescriptorType complex type: complex type:
<element name="RADIUSRPDescriptor" <complexType name="RADIUSRPDescriptorType">
type="md:RADIUSRPDescriptorType"/> <complexContent>
<complexType name="RADIUSRPDescriptorType"> <extension base="md:RoleDescriptorType">
<complexContent> <sequence>
<extension base="md:RoleDescriptorType"> <element ref="md:RADIUSRPService" minOccurs="0" maxOccurs="unbounded"/>
<sequence> <element ref="md:RADIUSNasIpAddress" minOccurs="0" maxOccurs="unbounded"/>
<element ref="md:RADIUSRPService" <element ref="md:RADIUSNasIdentifier" minOccurs="0" maxOccurs="unbounded"/>
minOccurs="0" maxOccurs="unbounded"/> <element ref="md:RADIUSGssEapName" minOccurs="0" maxOccurs="unbounded"/>
<element ref="md:RADIUSNasIpAddress" </sequence>
minOccurs="0" maxOccurs="unbounded"/> </extension>
<element ref="md:RADIUSNasIdentifier" </complexContent>
minOccurs="0" maxOccurs="unbounded"/> </complexType>
<element ref="md:RADIUSGssEapName" <element name="RADIUSRPService" type="md:EndpointType"/>
minOccurs="0" maxOccurs="unbounded"/> <element name="RADIUSNasIpAddress" type="string"/>
</sequence> <element name="RADIUSNasIdentifier" type="string"/>
</extension> <element name="RADIUSGssEapName" type="string"/>
</complexContent>
</complexType>
<element name="RADIUSRPService" type="md:EndpointType"/>
<element name="RADIUSNasIpAddress" type="xs:string"/>
<element name="RADIUSNasIdentifier" type="xs:string"/>
<element name="RADIUSGssEapName" type="xs:string"/>
Figure 4: RADIUSRPDescriptor schema Figure 4: RADIUSRPDescriptorType schema
4.3.4. Example of SAML metadata including AAA names 4.3.4. Example of SAML metadata including AAA names
The following figures illustrate an example of metadata including AAA The following figures illustrate an example of metadata including AAA
names for and IDP and a RP respectively. The IDP's SAML name is names for and IDP and a RP respectively. The IDP's SAML name is
"https://IdentityProvider.com/", whereas its RADIUS realm is "https://IdentityProvider.com/", whereas its RADIUS realm is
"idp.com". The RP's SAML name is "https://RelyingParty.com/SAML", "idp.com". The RP's SAML name is "https://RelyingParty.com/SAML",
being its GSS-EAP acceptor name "nfs/fileserver.rp.com@RP.COM". being its GSS-EAP acceptor name "nfs/fileserver.rp.com@RP.COM".
<EntityDescriptor xmlns="urn:oasis:names:tc:SAML:2.0:metadata" <EntityDescriptor xmlns="urn:oasis:names:tc:SAML:2.0:metadata"
entityID="https://IdentityProvider.com/SAML"> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
<RADIUSIDPDescriptor protocolSupportEnumeration= xmlns:abfab="urn:ietf:params:xml:ns:abfab"
"urn:oasis:names:tc:SAML:2.0:protocol"> entityID="https://IdentityProvider.com/SAML">
<RADIUSRealm> <RoleDescriptor xsi:type="abfab:RADIUSIDPDescriptorType"
idp.com protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
</RADIUSRealm> <RADIUSRealm>idp.com</RADIUSRealm>
</RADIUSIDPDescriptor> </RoleDescriptor>
</EntityDescriptor> </EntityDescriptor>
Figure 5: Metadata for the IDP Figure 5: Metadata for the IDP
<EntityDescriptor xmlns="urn:oasis:names:tc:SAML:2.0:metadata" <EntityDescriptor xmlns="urn:oasis:names:tc:SAML:2.0:metadata"
entityID="https://RelyingParty.com/SAML"> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
<RADIUSRPDescriptor protocolSupportEnumeration= xmlns:abfab="urn:ietf:params:xml:ns:abfab"
"urn:oasis:names:tc:SAML:2.0:protocol"> entityID="https://RelyingParty.com/SAML">
<RADIUSGssEapName> <RoleDescriptor xsi:type="abfab:RADIUSRPDescriptorType"
nfs/fileserver.rp.com@RP.COM protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
</RADIUSGssEapName> <RADIUSGssEapName>nfs/fileserver.rp.com@RP.COM</RADIUSGssEapName>
</RADIUSRPDescriptor> </RoleDescriptor>
</EntityDescriptor> </EntityDescriptor>
Figure 6: Metadata for the RP Figure 6: Metadata for the RP
4.4. Use of XML Signatures 4.4. Use of XML Signatures
This binding calls for the use of SAML elements that support XML This binding calls for the use of SAML elements that support XML
signatures. To promote interoperability, implementations of this signatures. To promote interoperability, implementations of this
binding MUST support a default configuration that does not require binding MUST support a default configuration that does not require
the use of XML signatures. Implementations MAY choose to use XML the use of XML signatures. Implementations MAY choose to use XML
signatures. signatures.
4.5. Metadata Considerations 4.5. Metadata Considerations
There are no metadata considerations particular to this binding, These binding and profiles are mostly intended to be used without
because this binding and profiles of this binding are mostly intended metadata. In this usage, RADIUS infrastructure is used to provide
to be used without metadata. In this usage, RADIUS infrastructure is integrity and naming of the SAML messages and assertions. RADIUS
used to provide integrity and naming of the SAML messages and configuration is used to provide policy, including which attributes
assertions. RADIUS configuration is used to provide policy, are accepted from a Relying Party and which attributes are sent by an
including which attributes are accepted from a Relying Party and Identity Provider.
which attributes are sent by an Identity Provider.
Nevertheless, implementations MAY support other configurations Nevertheless, if metadata is used, the roles describe in section
including the use of metadata. Section 4.3.3 MUST be present.
5. Network Access Identifier Name Identifier Format 5. Network Access Identifier Name Identifier Format
URI: urn:ietf:params:abfab:nameid-format:nai URI: urn:ietf:params:abfab:nameid-format:nai
Indicates that the content of the element is in the form of a Network Indicates that the content of the element is in the form of a Network
Access Identifier (NAI) using the syntax described by [RFC7542]. Access Identifier (NAI) using the syntax described by [RFC7542].
6. RADIUS State Confirmation Method Identifiers 6. RADIUS State Confirmation Method Identifiers
skipping to change at page 15, line 50 skipping to change at page 15, line 50
1. Client request to Relying Party (Section 7.3.1): In step 1, the 1. Client request to Relying Party (Section 7.3.1): In step 1, the
Client, via a User Agent, makes a request for a secured resource Client, via a User Agent, makes a request for a secured resource
at the Relying Party. The Relying Party determines that no at the Relying Party. The Relying Party determines that no
security context for the Client exists and initiates the security context for the Client exists and initiates the
authentication process. authentication process.
2. Relying Party issues <samlp:AuthnRequest> to Identity Provider 2. Relying Party issues <samlp:AuthnRequest> to Identity Provider
(Section 7.3.2). In step 2, the Relying Party may optionally (Section 7.3.2). In step 2, the Relying Party may optionally
issue a <samlp:AuthnRequest> message to be delivered to the issue a <samlp:AuthnRequest> message to be delivered to the
Identity Provider using the SAML-Message RADIUS attribute. Identity Provider using the SAML-Protocol RADIUS attribute.
3. Identity Provider identifies Client (Section 7.3.3). In step 3, 3. Identity Provider identifies Client (Section 7.3.3). In step 3,
the Client is authenticated and identified by the Identity the Client is authenticated and identified by the Identity
Provider, while honoring any requirements imposed by the Relying Provider, while honoring any requirements imposed by the Relying
Party in the <samlp:AuthnRequest> message if provided. Party in the <samlp:AuthnRequest> message if provided.
4. Identity Provider issues <samlp:Response> to Relying Party 4. Identity Provider issues <samlp:Response> to Relying Party
(Section 7.3.4). In step 4, the Identity Provider issues a (Section 7.3.4). In step 4, the Identity Provider issues a
<samlp:Response> message to the Relying Party using the SAML <samlp:Response> message to the Relying Party using the SAML
RADIUS binding. The response either indicates an error or RADIUS binding. The response either indicates an error or
skipping to change at page 16, line 26 skipping to change at page 16, line 26
5. Relying Party grants or denies access to Client (Section 7.3.5). 5. Relying Party grants or denies access to Client (Section 7.3.5).
In step 5, having received the response from the Identity In step 5, having received the response from the Identity
Provider, the Relying Party can respond to the Client with its Provider, the Relying Party can respond to the Client with its
own error, or can establish its own security context for the own error, or can establish its own security context for the
Client and return the requested resource. Client and return the requested resource.
7.3. Profile Description 7.3. Profile Description
The ABFAB Authentication Profile is a profile of the SAML V2.0 The ABFAB Authentication Profile is a profile of the SAML V2.0
Authentication Request Protocol [OASIS.saml-core-2.0-os]. Where this Authentication Request Protocol [OASIS.saml-core-2.0-os]. Where both
specification conflicts with it, the former takes precedence. specifications conflict, the ABFAB Authentication Profile takes
precedence.
7.3.1. Client Request to Relying Party 7.3.1. Client Request to Relying Party
The profile is initiated by an arbitrary Client request to the The profile is initiated by an arbitrary Client request to the
Relying Party. There are no restrictions on the form of the request. Relying Party. There are no restrictions on the form of the request.
The Relying Party is free to use any means it wishes to associate the The Relying Party is free to use any means it wishes to associate the
subsequent interactions with the original request. The Relying subsequent interactions with the original request. The Relying
Party, acting as a RADIUS client, attempts to authenticate the Party, acting as a RADIUS client, attempts to authenticate the
Client. Client.
7.3.2. Relying Party Issues <samlp:AuthnRequest> to Identity Provider 7.3.2. Relying Party Issues <samlp:AuthnRequest> to Identity Provider
The Relying Party uses RADIUS to communicate with the Client's The Relying Party uses RADIUS to communicate with the Client's
Identity Provider. The Relying Party MAY include a Identity Provider. The Relying Party MAY include a
<samlp:AuthnRequest> within this RADIUS Access-Request message using <samlp:AuthnRequest> within this RADIUS Access-Request message using
the SAML-Message RADIUS attribute. The next hop destination MAY be the SAML-Protocol RADIUS attribute. The next hop destination MAY be
the Identity Provider or alternatively an intermediate RADIUS proxy. the Identity Provider or alternatively an intermediate RADIUS proxy.
Profile-specific rules for the contents of the <samlp:AuthnRequest> Profile-specific rules for the contents of the <samlp:AuthnRequest>
element are given in Section 7.4.1. element are given in Section 7.4.1.
7.3.3. Identity Provider Identifies Client 7.3.3. Identity Provider Identifies Client
The Identity Provider MUST establish the identity of the Client using The Identity Provider MUST establish the identity of the Client using
a RADIUS authentication method, or else it will return an error. If a RADIUS authentication method, or else it will return an error. If
the ForceAuthn attribute on the <samlp:AuthnRequest> element (if sent the ForceAuthn attribute on the <samlp:AuthnRequest> element (if sent
skipping to change at page 17, line 33 skipping to change at page 17, line 33
with the authentication result, as described in with the authentication result, as described in
[OASIS.saml-core-2.0-os]. This SAML response is delivered to the [OASIS.saml-core-2.0-os]. This SAML response is delivered to the
Relying Party using the SAML RADIUS binding described in Section 4. Relying Party using the SAML RADIUS binding described in Section 4.
Profile-specific rules regarding the contents of the <samlp:Response> Profile-specific rules regarding the contents of the <samlp:Response>
element are given in Section 7.4.2. element are given in Section 7.4.2.
7.3.5. Relying Party Grants or Denies Access to Client 7.3.5. Relying Party Grants or Denies Access to Client
If issued by the Identity Provider, the Relying Party MUST process If issued by the Identity Provider, the Relying Party MUST process
the <samlp:Response> message and any enclosed <saml:Assertion> the <samlp:Response> message and any enclosed assertion elements as
elements as described in [OASIS.saml-core-2.0-os]. Any subsequent described in [OASIS.saml-core-2.0-os]. Any subsequent use of the
use of the <saml:Assertion> elements is at the discretion of the assertion elements is at the discretion of the Relying Party, subject
Relying Party, subject to any restrictions contained within the to any restrictions contained within the assertions themselves or
assertions themselves or from any previously established out-of-band from any previously established out-of-band policy that governs the
policy that governs the interaction between the Identity Provider and interaction between the Identity Provider and the Relying Party.
the Relying Party.
7.4. Use of Authentication Request Protocol 7.4. Use of Authentication Request Protocol
This profile is based on the Authentication Request Protocol defined This profile is based on the Authentication Request Protocol defined
in [OASIS.saml-core-2.0-os]. In the nomenclature of actors in [OASIS.saml-core-2.0-os]. In the nomenclature of actors
enumerated in section 3.4 of that document, the Relying Party is the enumerated in section 3.4 of that document, the Relying Party is the
requester, the User Agent is the attesting entity and the Client is requester, the User Agent is the attesting entity and the Client is
the Requested Subject. the Requested Subject.
7.4.1. <samlp:AuthnRequest> Usage 7.4.1. <samlp:AuthnRequest> Usage
skipping to change at page 18, line 33 skipping to change at page 18, line 27
integrity are also provided by the SAML RADIUS binding. integrity are also provided by the SAML RADIUS binding.
7.4.2. <samlp:Response> Message Usage 7.4.2. <samlp:Response> Message Usage
If the Identity Provider cannot or will not satisfy the request, it If the Identity Provider cannot or will not satisfy the request, it
MUST either respond with a <samlp:Response> message containing an MUST either respond with a <samlp:Response> message containing an
appropriate error status code or codes and/or respond with a RADIUS appropriate error status code or codes and/or respond with a RADIUS
Access-Reject message. Access-Reject message.
If the Identity Provider wishes to return an error, it MUST NOT If the Identity Provider wishes to return an error, it MUST NOT
include any assertions in the <samlp:Response message>. Otherwise, include any assertions in the <samlp:Response> message. Otherwise,
if the request is successful (or if the response is not associated if the request is successful (or if the response is not associated
with a request), the <samlp:Response> element is subject conform to with a request), the <samlp:Response> element is subject to the
the following: following constraints:
o It MAY be signed. o It MAY be signed.
o It MUST contain exactly one <saml:Assertion>. The <saml:Subject> o It MUST contain exactly one assertion. The <saml:Subject> element
element of this assertion MUST refer to the authenticated RADIUS of this assertion MUST refer to the authenticated RADIUS user.
user.
o The assertion MUST contain a <saml:AuthnStatement>. Besides, the o The assertion MUST contain a <saml:AuthnStatement>. Besides, the
assertion MUST contain a <saml:Subject> element with at least one assertion MUST contain a <saml:Subject> element with at least one
<saml:SubjectConfirmation> element containing a Method of <saml:SubjectConfirmation> element containing a Method of
urn:ietf:params:abfab:cm:user or urn:ietf:params:abfab:cm:machine urn:ietf:params:abfab:cm:user or urn:ietf:params:abfab:cm:machine
that reflects the authentication of the Client to the Identity that reflects the authentication of the Client to the Identity
Provider. Since the containing message is in response to an Provider. Since the containing message is in response to an
<samlp:AuthnRequest>, the InResponseTo attribute MUST match the <samlp:AuthnRequest>, the InResponseTo attribute (both in the
request's ID. The <saml:Subject> element MAY use the NAI Name <saml:SubjectConfirmationData> and in the <saml:Response>
Identifier Format described in Section 5 to establish an elements) MUST match the request's ID. The <saml:Subject> element
identifier between the Relying Party and the IdP. MAY use the NAI Name Identifier Format described in Section 5 to
establish an identifier between the Relying Party and the IdP.
o Other conditions MAY be included as requested by the Relying Party o Other conditions MAY be included as requested by the Relying Party
or at the discretion of the Identity Provider. The Identity or at the discretion of the Identity Provider. The Identity
Provider is NOT obligated to honor the requested set of conditions Provider is NOT obligated to honor the requested set of conditions
in the <samlp:AuthnRequest>, if any. in the <samlp:AuthnRequest>, if any.
7.4.3. <samlp:Response> Message Processing Rules 7.4.3. <samlp:Response> Message Processing Rules
The Relying Party MUST do the following: The Relying Party MUST do the following:
skipping to change at page 19, line 41 skipping to change at page 19, line 34
o Verify that any assertions relied upon are valid according to o Verify that any assertions relied upon are valid according to
processing rules in [OASIS.saml-core-2.0-os]. processing rules in [OASIS.saml-core-2.0-os].
o Any assertion which is not valid, or whose subject confirmation o Any assertion which is not valid, or whose subject confirmation
requirements cannot be met MUST be discarded and MUST NOT be used requirements cannot be met MUST be discarded and MUST NOT be used
to establish a security context for the Client. to establish a security context for the Client.
7.4.4. Unsolicited Responses 7.4.4. Unsolicited Responses
An Identity Provider MAY initiate this profile by delivering an An Identity Provider MAY initiate this profile by delivering an
unsolicited <saml:Assertion> to a Relying Party. This MUST NOT unsolicited assertion to a Relying Party. This MUST NOT contain any
contain any <saml:SubjectConfirmationData> elements containing an <saml:SubjectConfirmationData> elements containing an InResponseTo
InResponseTo attribute. attribute.
7.4.5. Use of the SAML RADIUS Binding 7.4.5. Use of the SAML RADIUS Binding
It is RECOMMENDED that the RADIUS exchange is protected using TLS It is RECOMMENDED that the RADIUS exchange is protected using TLS
encryption for RADIUS [RFC6614] to provide confidentiality and encryption for RADIUS [RFC6614] to provide confidentiality and
improve integrity protection. integrity protection.
7.4.6. Use of XML Signatures 7.4.6. Use of XML Signatures
This profile calls for the use of SAML elements that support XML This profile calls for the use of SAML elements that support XML
signatures. To promote interoperability implementations of this signatures. To promote interoperability implementations of this
profile MUST NOT require the use of XML signatures. Implementations profile MUST NOT require the use of XML signatures. Implementations
MAY choose to use XML signatures. MAY choose to use XML signatures.
7.4.7. Metadata Considerations 7.4.7. Metadata Considerations
There are no metadata considerations particular to this binding. 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 8. ABFAB Assertion Query/Request Profile
This profile builds on the SAML V2.0 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 defined by [OASIS.saml-profiles-2.0-os]. That profile describes the
use of the Assertion Query and Request Protocol defined by section 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 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]. the SOAP binding defined in [OASIS.saml-bindings-2.0-os].
While the SAML V2.0 Assertion Query/Request Profile is independent of While the SAML V2.0 Assertion Query/Request Profile is independent of
skipping to change at page 22, line 21 skipping to change at page 22, line 21
o SHOULD include the RADIUS State attribute, where this Query/ o SHOULD include the RADIUS State attribute, where this Query/
Request pertains to previously authenticated Client. Request pertains to previously authenticated Client.
When processing the SAML request, the IdP MUST give precedence to the When processing the SAML request, the IdP MUST give precedence to the
Client's identifier implied by RADIUS State attribute over the Client's identifier implied by RADIUS State attribute over the
identifier implied by the SAML request's <Subject>, if any. identifier implied by the SAML request's <Subject>, if any.
It is RECOMMENDED that the RADIUS exchange is protected using TLS It is RECOMMENDED that the RADIUS exchange is protected using TLS
encryption for RADIUS [RFC6614] to provide confidentiality and encryption for RADIUS [RFC6614] to provide confidentiality and
improve integrity protection. integrity protection.
8.3.3. Use of XML Signatures 8.3.3. Use of XML Signatures
This profile calls for the use of SAML elements that support XML This profile calls for the use of SAML elements that support XML
signatures. To promote interoperability implementations of this signatures. To promote interoperability implementations of this
profile MUST NOT require the use of XML signatures. Implementations profile MUST NOT require the use of XML signatures. Implementations
MAY choose to use XML signatures. MAY choose to use XML signatures.
8.3.4. Metadata Considerations 8.3.4. Metadata Considerations
There are no metadata considerations particular to this binding. There are no metadata considerations particular to this profile,
aside from those applying to the use of the RADIUS binding.
9. Privacy considerations 9. Privacy considerations
The profiles defined in this document allow a Relying Party to The profiles defined in this document allow a Relying Party to
request specific information about the Client, and allow an IdP to request specific information about the Client, and allow an IdP to
disclose information about that Client. In this sense, Identity disclose information about that Client. In this sense, Identity
Providers MUST apply policy to decide what information is released to Providers MUST apply policy to decide what information is released to
a particular Relying Party. Moreover, the identity of the Client is a particular Relying Party. Moreover, the identity of the Client is
typically hidden from the Relying Party unless informed by the typically hidden from the Relying Party unless informed by the
Identity Provider. Conversely, the Relying Party does typically know Identity Provider. Conversely, the Relying Party does typically know
the realm of the IdP, as it is required to being able to route the the realm of the IdP, as it is required to route the RADIUS packets
RADIUS packets to the right destination. to the right destination.
The kind of information that is released by the IdP MAY include The kind of information that is released by the IdP MAY include
generic attributes such as affiliation shared by many Clients. But generic attributes such as affiliation shared by many Clients. But
even these generic attributes can help to identify a specific Client. even these generic attributes can help to identify a specific Client.
Other kind of attributes MAY also provide a Relying Party with the Other kinds of attributes MAY also provide a Relying Party with the
ability to link the same Client between different sessions. Finally, ability to link the same Client between different sessions. Finally,
other kind of attributes MAY provide a group of Relying Parties with other kind of attributes MAY provide a group of Relying Parties with
the ability to link the Client between them or with personally the ability to link the Client between them or with personally
identifiable information about the Client. identifiable information about the Client.
These profiles do not directly provide a Client with a mechanism to These profiles do not directly provide a Client with a mechanism to
express preferences about what information is released. That express preferences about what information is released. That
information can be expressed out-of-band, for example as part of the information can be expressed out-of-band, for example as part of the
enrollment process. enrollment process.
skipping to change at page 24, line 18 skipping to change at page 24, line 18
The authors request that Attribute Types and Attribute Values defined The authors request that Attribute Types and Attribute Values defined
in this document be registered by the Internet Assigned Numbers in this document be registered by the Internet Assigned Numbers
Authority (IANA) from the RADIUS namespaces as described in the "IANA Authority (IANA) from the RADIUS namespaces as described in the "IANA
Considerations" section of [RFC3575], in accordance with BCP 26 Considerations" section of [RFC3575], in accordance with BCP 26
[RFC5226]. For RADIUS packets, attributes and registries created by [RFC5226]. For RADIUS packets, attributes and registries created by
this document IANA is requested to place them at this document IANA is requested to place them at
http://www.iana.org/assignments/radius-types. http://www.iana.org/assignments/radius-types.
In particular, this document defines two new RADIUS attributes, In particular, this document defines two new RADIUS attributes,
entitled "SAML-Assertion" and "SAML-Message" (see Section 3), with entitled "SAML-Assertion" and "SAML-Protocol" (see Section 3), with
assigned values of 245.TBD1 and 245.TBD2 from the Long Extended Space assigned values of 245.TBD1 and 245.TBD2 from the Long Extended Space
of [RFC6929]: of [RFC6929]:
Type Ext. Type Name Length Meaning Type Ext. Type Name Length Meaning
---- --------- -------------- ------ ------------------------ ---- --------- -------------- ------ ------------------------
245 TBD1 SAML-Assertion >=5 Encodes a SAML assertion 245 TBD1 SAML-Assertion >=5 Encodes a SAML assertion
245 TBD2 SAML-Message >=5 Encodes a SAML protocol 245 TBD2 SAML-Protocol >=5 Encodes a SAML protocol
message message
11.2. ABFAB Parameters 11.2. ABFAB Parameters
A new top-level registry is created titled "ABFAB Parameters". A new top-level registry is created titled "ABFAB Parameters".
In this top-level registry, a sub-registry titled "ABFAB URN In this top-level registry, a sub-registry titled "ABFAB URN
Parameters" is created. Registration in this registry is by the IETF Parameters" is created. Registration in this registry is by the IETF
review or expert review procedures [RFC5226]. review or expert review procedures [RFC5226].
skipping to change at page 28, line 5 skipping to change at page 28, line 5
Howlett, J., Hartman, S., Tschofenig, H., Lear, E., and J. Howlett, J., Hartman, S., Tschofenig, H., Lear, E., and J.
Schaad, "Application Bridging for Federated Access Beyond Schaad, "Application Bridging for Federated Access Beyond
Web (ABFAB) Architecture", draft-ietf-abfab-arch-13 (work Web (ABFAB) Architecture", draft-ietf-abfab-arch-13 (work
in progress), July 2014. in progress), July 2014.
[I-D.ietf-radext-bigger-packets] [I-D.ietf-radext-bigger-packets]
Hartman, S., "Larger Packets for RADIUS over TCP", draft- Hartman, S., "Larger Packets for RADIUS over TCP", draft-
ietf-radext-bigger-packets-03 (work in progress), March ietf-radext-bigger-packets-03 (work in progress), March
2015. 2015.
[W3C.REC-xmlschema-1]
Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn,
"XML Schema Part 1: Structures", W3C REC-xmlschema-1, May
2001, <http://www.w3.org/TR/xmlschema-1/>.
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] While 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"/>
<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>
Authors' Addresses Authors' Addresses
Josh Howlett Josh Howlett
Janet Janet
Lumen House, Library Avenue, Harwell Lumen House, Library Avenue, Harwell
Oxford OX11 0SG Oxford OX11 0SG
UK UK
Phone: +44 1235 822363 Phone: +44 1235 822363
EMail: Josh.Howlett@ja.net EMail: Josh.Howlett@ja.net
 End of changes. 67 change blocks. 
179 lines changed or deleted 226 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/