One document matched: draft-ietf-abfab-aaa-saml-04.xml
<?xml version="1.0" encoding="US-ASCII"?>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc strict="no"?>
<?rfc rfcedstyle="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY rfc2865 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2865.xml">
<!ENTITY rfc3575 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3575.xml">
<!ENTITY rfc3579 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3579.xml">
<!ENTITY rfc3588 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3588.xml">
<!ENTITY rfc4282 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4282.xml">
<!ENTITY I-D.ietf-abfab-arch SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-abfab-arch-03.xml">
<!ENTITY I-D.ietf-abfab-gss-eap SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-abfab-gss-eap-04.xml">
<!ENTITY I-D.jones-diameter-abfab SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-jones-diameter-abfab-00.xml">
<!ENTITY I-D.draft-ietf-radext-radsec SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-radext-radsec-09.xml">
<!ENTITY I-D.draft-perez-radext-radius-fragmentation SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-perez-radext-radius-fragmentation-01.xml">
<!ENTITY SAML2Core SYSTEM "http://xml.resource.org/public/rfc/bibxml2/reference.OASIS.saml-core-2.0-os.xml">
<!ENTITY SAML2Profiles SYSTEM "http://xml.resource.org/public/rfc/bibxml2/reference.OASIS.saml-profiles-2.0-os.xml">
<!ENTITY SAML2Bindings SYSTEM "http://xml.resource.org/public/rfc/bibxml2/reference.OASIS.saml-bindings-2.0-os.xml">
<!ENTITY SAML2Metadata SYSTEM "http://xml.resource.org/public/rfc/bibxml2/reference.OASIS.saml-metadata-2.0-os.xml">
]>
<rfc category="info" docName="draft-ietf-abfab-aaa-saml-04" ipr="trust200902">
<front>
<title abbrev="SAML RADIUS">A RADIUS Attribute, Binding and Profiles for SAML</title>
<author initials="J." surname="Howlett" fullname="Josh Howlett">
<organization>Janet</organization>
<address>
<postal>
<street>Lumen House, Library Avenue, Harwell</street>
<city>Oxford</city>
<code>OX11 0SG</code>
<country>UK</country>
</postal>
<phone>+44 1235 822363</phone>
<email>Josh.Howlett@ja.net</email>
</address>
</author>
<author initials="S." surname="Hartman" fullname="Sam Hartman">
<organization>Painless Security</organization>
<address>
<postal>
<street> </street>
<city> </city>
<code> </code>
<country> </country>
</postal>
<phone> </phone>
<email>hartmans-ietf@mit.edu</email>
</address>
</author>
<date year="2012" />
<area>Security Area</area>
<workgroup>ABFAB</workgroup>
<keyword>ABFAB</keyword>
<keyword>AAA</keyword>
<keyword>EAP</keyword>
<keyword>GSS</keyword>
<keyword>RADIUS</keyword>
<keyword>SAML</keyword>
<abstract>
<t>
This document specifies a RADIUS attribute, a binding and two profiles for the
Security Assertion Mark-up Language (SAML). The attribute provides RADIUS
encapsulation of SAML protocol messages, and the binding describes the use of
this attribute, and the SAML protocol messages within, with RADIUS transport.
The two profiles describe the application of this binding for ABFAB
authentication and assertion query/request respectively. The SAML RADIUS
attribute and binding are defined generically to permit application in other
scenarios, such as network access.
</t>
</abstract>
</front>
<middle>
<section title="TODO">
<list style="symbols">
<t>
Clean up use of terminology (e.g., "principal") to ensure consistency with
other ABFAB docs.
</t>
<t>
Understand Alan DeK's preferences with respect to choreography of SAML
messages and the RADIUS exchange(s).
</t>
<t>
Request a new RADIUS attribute
</t>
<t>
Check that binding/profiles identification URNs are reasonable
</t>
</list>
</section>
<section title="Introduction">
<t>
The SAML RADIUS attribute, binding and profiles are motivated by the requirements
of the ABFAB architecture <xref target="I-D.ietf-abfab-arch" />. In this
architecture, it is often desirable to convey Security Assertion Mark-up Language
(SAML) protocol messages between a SAML requester and SAML responder. This can be
used, for example, to allow a Relying Party to request a SAML assertion from an
Identity Provider that describes a particular principal. This attribute and
binding are also likely to be useful for other purposes besides ABFAB; for
example, SAML-based authorization for network access. The attribute and binding
are therefore defined generically to facilitate general applicability.
</t>
<t>
SAML defines a number of SAML protocol messages
<xref target="OASIS.saml-core-2.0-os" />, derived from common request and
response abstract types. These request and response protocol messages can be
exchanged using different modes of transport, such as HTTP; in the SAML
architecture, these are known as 'bindings'. SAML already
defines a number of HTTP-based bindings <xref target="OASIS.saml-bindings-2.0-os" />;
and these are primarily intended for use with the SAML V2.0 Web Browser
Single Sign-On Profile <xref target="OASIS.saml-profiles-2.0-os" /> which
describes how the SAML protocol messages and HTTP-based bindings can be used
to effect Web-based Single Sign-On (SSO) by federating an identity between
an Identity Provider and a Service Provider
</t>
<t>
However the goal of ABFAB is to extend the applicability of federated identity
beyond the Web to other applications by building on the AAA framework.
Consequently there exists a requirement for an AAA-based binding that is
functionally equivalent to the existing bindings but using AAA protocols, such
as <xref target="RFC2865"/> and Diameter <xref target="RFC3588"/>, rather than
HTTP. This document therefore defines a new RADIUS-based SAML binding, building
on a SAML RADIUS attribute also defined by this document, to meet this need.
</t>
<t>
In addition to this attribute and binding, this document also profiles their
application in the context of two specific use cases: authentication and
assertion query/request. This is intended to promote interoperability between
implementations for these common use cases.
</t>
<t>
A companion specification <xref target="I-D.jones-diameter-abfab" /> specifies
equivalent funtionality for Diameter.
</t>
<t>
In summary this document specifies:
<list style="symbols">
<t>
A SAML RADIUS attribute that defines how to encapsulate a SAML protocol
message within a RADIUS attribute.
</t>
<t>
A SAML RADIUS binding that defines how SAML requesters and responders can
exchange SAML protocol messages.
</t>
<t>
An Authentication Profile that defines how the SAML RADIUS binding
is used to effect SAML-based authentication and authorization.
</t>
<t>
An Assertion Query/Request Profile that defines how the SAML RADIUS
binding is used to effect SAML-based assertion request.
</t>
</list>
</t>
<t>
The RADIUS SAML binding and profile specifications aspire to adhere to the
guidelines stipulated by <xref target="OASIS.saml-bindings-2.0-os" /> and
<xref target="OASIS.saml-profiles-2.0-os" /> for defining new SAML bindings
and profiles respectively. These new bindings and profiles are asked to
provide a 'Required Information' section that enumerates:
<list style="symbols">
<t>
A URI that uniquely identifies the protocol binding or profile
</t>
<t>
Postal or electronic contact information for the author
</t>
<t>
A reference to previously defined bindings or profiles that the new
binding updates or obsoletes
</t>
<t>
In the case of a profile, any SAML confirmation method identifiers
defined and/or utilized by the profile
</t>
</list>
</t>
</section>
<section title="Conventions">
<t>
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 <xref target="RFC2119" />.
</t>
</section>
<section title="RADIUS SAML-Message Attribute" anchor="SAML_RADIUS_Message_attribute">
<t>
This attribute contains a SAML <xref target="OASIS.saml-core-2.0-os" />
protocol message. Where multiple SAML-Message attributes are included in a
RADIUS message, the Message fields of these attributes are to be concatenated
to form a single SAML message.
</t>
<t>
A summary of the SAML-Message format is shown below. The fields are
transmitted from left to right.
</t>
<figure>
<artwork><![CDATA[
0 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 | SAML Message...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1
]]></artwork>
</figure>
<list style="hanging">
<t hangText="Type:">
TBD
</t>
<t hangText="Length:">
>=3
</t>
<t hangText="Message:">
The Message field is one or more octets containing a SAML message. If
larger than a single attribute, the SAML message data MUST be split on
253-octet boundaries over as many attributes as necessary. The SAML
message is reconstructed by concatenating the contents of all SAML-Message
attributes.
</t>
</list>
</section>
<section title="SAML RADIUS Binding" anchor="SAML_RADIUS_binding">
<t>
The SAML RADIUS binding defines how RADIUS <xref target="RFC2865"/> can be
used to enable a RADIUS client and server to exchange SAML protocol messages.
</t>
<section title="Required Information">
<t>
Identification: urn:ietf:params:xml:ns:abfab:bindings:radius
</t>
<t>
Contact information: iesg@ietf.org
</t>
<t>
Updates: None.
</t>
</section>
<section title="Operation">
<t>
RADIUS can be used over multiple underlying transports; this binding
calls out the use of RADIUS over UDP as REQUIRED. It is RECOMMENDED
that the RADIUS exchange is protected using TLS encryption for RADIUS
<xref target="I-D.ietf-radext-radsec" /> to provide confidentiality
and improve integrity protection. Implementations of this profile
MUST support RADIUS packet fragmentation
<xref target="I-D.perez-radext-radius-fragmentation" /> to permit
transport of large SAML messages.
</t>
<t>
The system model used for SAML conversations over RADIUS is a simple
request-response model, using the RADIUS SAML-Message attribute
defined in <xref target='SAML_RADIUS_Message_attribute' /> to
encapsulate the SAML protocol messages.
</t>
<list style="numbers">
<t>
The RADIUS client, acting as a SAML requester, MAY transmit 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
<xref target="RFC4282" /> scheme. The SAML requester MUST NOT
include more than one SAML request element.
</t>
<t>
The RADIUS server, acting as a SAML responder, MAY return 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 SAML responder
to send a response in the context of this exchange. The SAML
responder MUST NOT include more than one SAML response. A SAML
responder that refuses to perform a message exchange with the
SAML requester MUST silently discard the SAML request.
</t>
</list>
<t>
A SAML responder MAY also return an unsolicited response (a SAML response
generated and emitted in the absence of a request from a SAML requester).
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
In the case of a SAML processing error and failed authentication, the RADIUS
server MAY include a SAML-specified <samlp:Status> element in the SAML
response that is transported within the Access-Reject packet sent by the
RADIUS server.
</t>
<section title="Use of XML Signatures">
<t>
This bindings calls for the use of SAML elements that support XML
signatures. To promote interoperability implementations of this binding
MUST NOT require the use of XML signatures. Implementations MAY choose
to use XML signatures, but this usage is outside of the scope of this
binding.
</t>
</section>
<section title="Metadata Considerations">
<t>
There are no metadata considerations particular to this binding.
</t>
</section>
</section>
</section>
<section title="ABFAB Authentication Profile">
<t>
In the scenario supported by the ABFAB Authentication Profile, a Principal
controlling a User Agent requests access to a Relying Party. The User Agent
and Relying Party use the GSS EAP mechanism to authenticate the Principal.
The Relying Party, acting as an EAP pass-through authenticator, acts as a
conduit for the EAP frames emitted by the User Agent and an EAP server which
acts as the Principal's Identity Provider. If the Identity Provider successfully
authenticates the Principal, it produces an authentication assertion which is
consumed by the Relying Party. During this process, a name identifier might
also be established between the Relying Party and the Identity Provider.
</t>
<section title="Required Information">
<t>
Identification: urn:ietf:params:xml:ns:abfab:profiles:authentication
</t>
<t>
Contact information: iesg@ietf.org
</t>
<t>
SAML Confirmation Method Identifiers: The SAML V2.0 "sender vouches"
confirmation method identifier, urn:oasis:names:tc:SAML:2.0:cm:sender-vouches,
is used by this profile.
</t>
<t>
Updates: None.
</t>
</section>
<section title="Profile Overview">
<t>
To implement this scenario, a profile of the SAML Authentication Request
protocol is used in conjuction with the SAML RADIUS binding defined in
<xref target="SAML_RADIUS_binding" /> and the GSS EAP mechanism
<xref target="I-D.ietf-abfab-gss-eap" />.
</t>
<t>
This profile is based on the SAML V2.0 Web Browser Single Sign-On Profile
<xref target="OASIS.saml-profiles-2.0-os" />. There are some important
differences, specifically:
</t>
<list style="hanging">
<t hangText="Authentication:">
This profile requires the use of a particular authentication
framework (namely the GSS EAP mechanism), although not a particular EAP
authentication method. This allows the profile to build on the EAP, AAA
and GSS frameworks that comprise the core of the ABFAB architecture.
</t>
<t hangText="Bindings:">
This profile does not require the use of HTTP-based bindings. Instead all
SAML protocol messages are transported using the SAML RADIUS binding
defined in <xref target="SAML_RADIUS_binding" />. This is intended to
reduce the number of bindings that implementations must support to be
interoperable.
</t>
<t hangText="Requests:">
The profile does not permit the Relying Party to name the
<saml:Subject> of the <samlp:AuthnRequest>. This is intended
to simplify implementation and interoperability.
</t>
<t hangText="Responses:">
The profile only permits the Identity Provider to return a single
assertion that must contain exactly one authentication statement. Other
statements may be included within this assertion at the discretion of
the Identity Provider. This is intended to simplify implementation and
interoperability.
</t>
</list>
<figure anchor="AAP_swimlane">
<preamble>
<xref target="AAP_swimlane" /> below illustrates the flow of messages
within this profile.
</preamble>
<artwork>
User Agent Relying Party Identity Provider
| | |
| (1) | |
| - - - - - - - - - > | |
| | |
| | (2) |
| | - - - - - - - - - - - - > |
| | |
| (3) | |
| < - - - - - - - - - |- - - - - - - - - - - - -> |
| | |
| | (4) |
| | < - - - - - - - - - - - - |
| | |
| (5) | |
| < - - - - - - - - - | |
| | |
V V V
</artwork>
<postamble>
The following steps are described by the profile. Within an individual
step, there may be one or more actual message exchanges.
</postamble>
</figure>
<list style="numbers">
<t>
User Agent Request to Relying Party (<xref target="AAP_UA2RP" />):
In step 1, the Principal, via a User Agent, makes a request for a
secured resource at the Relying Party. The Relying Party determines
that no security context for the User Agent exists and initiates
GSS EAP authentication of the Principal.
</t>
<t>
Relying Party Issues <samlp:AuthnRequest> to Identity Provider
(<xref target="RP2IDP" />). In step 2, the Relying Party may optionally
issue a <samlp:AuthnRequest> message to be delivered to the Identity
Provider using the SAML RADIUS binding.
</t>
<t>
Identity Provider Identifies Principal (<xref target="IDP2P" />). In step
3, the Principal is identified by the Identity Provider using EAP
authentication, while honoring any requirements imposed by the Relying
Party in the <samlp:AuthnRequest> message if provided.
</t>
<t>
Identity Provider Issues <samlp:Response> to Relying Party
(<xref target="IDP2RP" />). In step 4, the Identity Provider issues a
<samlp:Response> message to the Relying Party using the SAML RADIUS
binding. The response either indicates an error or includes an
authentication statement in exactly one assertion.
</t>
<t>
Relying Party Grants or Denies Access to Principal (<xref target="RP2P" />).
In step 5, having received the response from the Identity Provider,
the Relying Party can respond to the Principal's User Agent with its own error,
or can establish its own security context for the Principal and return the
requested resource.
</t>
</list>
</section>
<section title="Profile Description">
<t>
The ABFAB Authentication Profile is a profile of the SAML V2.0
Authentication Request Protocol <xref target="OASIS.saml-core-2.0-os" />. Where
this specification conflicts with Core, the former takes precedence.
</t>
<section title="User Agent Request to Relying Party" anchor="AAP_UA2RP">
<t>
The profile is initiated by an arbitrary User Agent request to the 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 subsequent
interactions with the original request. The Relying Party, acting as a
GSS acceptor, MUST invoke the GSS EAP mechanism (either spontaneously or
as the result of a mechanism negotiation) and send an EAP-Identity/Request
message to the User Agent, acting as a GSS initiator.
</t>
</section>
<section title="Relying Party Issues <samlp:AuthnRequest> to Identity Provider" anchor="RP2IDP">
<t>
The Relying Party, on receiving the EAP-Identity/Response message from
the User Agent, MUST send it towards the Identity Provider using RADIUS
as described in <xref target="RFC3579"/>. The Relying Party MAY include a
<samlp:AuthnRequest> within this RADIUS Access-Request message using
the SAML RADIUS binding. The next hop destination MAY be the Identity
Provider or alternatively an intermediate RADIUS proxy.
</t>
<t>
Profile-specific rules for the contents of the <samlp:AuthnRequest>
element are given in <xref target="AAP_ARP_Usage" />.
</t>
</section>
<section title="Identity Provider Identifies Principal" anchor="IDP2P">
<t>
The Identity Provider MUST establish the identity of the Principal using
EAP authentication, or else it will return an error. If the ForceAuthn
attribute on the <samlp:AuthnRequest> element (if sent by the requester)
is present and true, the Identity Provider MUST freshly establish this
identity rather than relying on any existing session state it may have
with the Principal (for example, TLS state that may be used for session
resumption). Otherwise, and in all other respects, the Identity Provider
may use any EAP method to authenticate the Principal, subject to the
requirements of Section 5.8 of <xref target="I-D.ietf-abfab-gss-eap" />
and any others called out in the <samlp:AuthnRequest> message.
</t>
</section>
<section title="Identity Provider Issues <samlp:Response> to Relying Party" anchor="IDP2RP">
<t>
The Identity Provider MUST conclude the EAP authentication in a manner
consistent with the EAP authentication result, and MAY issue a
<samlp:Response> message to the Relying Party consisent with the
authentication result and as described in
<xref target="OASIS.saml-core-2.0-os" /> and delivered to the Relying
Party using the SAML RADIUS binding.
</t>
<t>
Profile-specific rules regarding the contents of the
<samlp:Response> element are given in <xref target="AAP_ARP_Response" />.
</t>
</section>
<section title="Relying Party Grants or Denies Access to Principal" anchor="RP2P">
<t>
If issued by the Identity Provider, the Relying Party MUST process the
<samlp:Response> message and any enclosed <saml:Assertion>
elements as described in <xref target="OASIS.saml-core-2.0-os" />. Any
subsequent use of the <saml:Assertion> elements is at the
discretion of the Relying Party, subject to any restrictions on use
contained within the assertions themselves or previously established
out-of-band policy governing interactions between the Identity Provider
and the Relying Party.
</t>
<t>
To complete the profile, the Relying Party creates a GSS security context
for the User Agent.
</t>
</section>
</section>
<section title="Use of Authentication Request Protocol">
<t>
This profile is based on the Authentication Request Protocol defined in
<xref target="OASIS.saml-core-2.0-os" />. In the nomenclature of actors
enumerated in section 3.4, the Relying Party is the requester, the User Agent
is the attesting entity and the Principal is the Requested Subject.
</t>
<section title="<samlp:AuthnRequest> Usage" anchor="AAP_ARP_Usage">
<t>
A Relying Party MAY include any message content described in
<xref target="OASIS.saml-core-2.0-os" />, section 3.4.1. All processing
rules are as defined in <xref target="OASIS.saml-core-2.0-os" />.
</t>
<t>
If the Identity Provider cannot or will not satisfy the request, it MAY
respond with a <samlp:Response> message containing an appropriate
error status code or codes.
</t>
<t>
If the Relying Party wishes to permit the Identity Provider to establish
a new identifier for the principal if none exists, it MUST include a
<saml:NameIDPolicy> element with the AllowCreate attribute set
to "true". Otherwise, only a principal for whom the Identity Provider
has previously established an identifier usable by the Relying Party
can be authenticated successfully.
</t>
<t>
The Relying Party MUST NOT include a <saml:Subject> element in
the request. The authenticated EAP Identity names the Principal of
the requested <samlp:AuthnRequest> to the Identity Provider.
</t>
<t>
The <samlp:AuthnRequest> message MAY be signed. Authentication
and integrity are also provided by the RADIUS SAML binding.
</t>
</section>
<section title="<samlp:Response message> Usage" anchor="AAP_ARP_Response">
<t>
If the Identity Provider 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 MUST conform to the following:
</t>
<list style="symbols">
<t>
It MAY be signed.
</t>
<t>
It MUST contain exactly one <saml:Assertion>. The
<saml:Subject> element of this assertion MUST refer to the
authenticated Principal.
</t>
<t>
The assertion MUST contain a <saml:AuthnStatement>. This MUST
contain a <saml:Subject> element with at least one
<saml:SubjectConfirmation> element containing a Method of
urn:oasis:names:tc:SAML:2.0:cm:sender-vouches that reflects the
authentication of the Principal to the Identity Provider. If the
containing message is in response to an <samlp:AuthnRequest>,
then the InResponseTo attribute MUST match the request's ID.
</t>
<t>
Other conditions MAY be included as requested by the Relying Party
or at the discretion of the Identity Provider. The Identity Provider
is NOT obligated to honor the requested set of conditions in the
<samlp:AuthnRequest>, if any.
</t>
</list>
</section>
<section title="samlp:Response Message Processing Rules">
<t>
The Relying Party MUST do the following:
</t>
<list style="symbols">
<t>
Verify that the InResponseTo attribute in the sender-vouches
<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.
</t>
<t>
If a <saml:AuthnStatement> used to establish a security
context for the Principal contains a SessionNotOnOrAfter attribute,
the security context SHOULD be discarded once this time is reached,
unless the service provider reestablishes the Principal's identity
by repeating the use of this profile.
</t>
<t>
Verify that any assertions relied upon are valid according to
processing rules in <xref target="OASIS.saml-core-2.0-os" />.
</t>
<t>
Any assertion which 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 Principal.
</t>
</list>
</section>
<section title="Unsolicited Responses">
<t>
An Identity Provider MAY initiate this profile by delivering an unsolicited <samlp:Response> message
to a Relying Party.
</t>
<t>
An unsolicited <samlp:Response> MUST NOT contain an InResponseTo attribute, nor should any sender-vouches
<saml:SubjectConfirmationData> elements contain one.
</t>
</section>
<section title="Use of the SAML RADIUS Binding">
<t>
It is RECOMMENDED that the RADIUS exchange is protected using TLS encryption for RADIUS
<xref target="I-D.ietf-radext-radsec" /> to provide confidentiality and improve integrity protection.
</t>
</section>
<section title="Use of XML Signatures">
<t>
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, but this usage is outside of the scope of this profile.
</t>
</section>
<section title="Metadata Considerations">
<t>
There are no metadata considerations particular to this binding.
</t>
</section>
</section>
</section>
<section title="ABFAB Assertion Query/Request Profile">
<t>
This profile builds on the SAML V2.0 Assertion Query/Request Profile defined by
<xref target="OASIS.saml-profiles-2.0-os" />. That profile describes the use of the
Assertion Query and Request Protocol defined by section 3.3 of <xref target="OASIS.saml-core-2.0-os" />
with synchronous bindings, such as the SOAP binding defined in <xref target="OASIS.saml-bindings-2.0-os" />
or the SAML RADIUS binding defined elsewhere in this document.
</t>
<t>
While the SAML V2.0 Assertion Query/Request Profile is independent of the underlying binding,
it is nonetheless useful to describe the use of this profile with the SAML RADIUS binding in the interests 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.
</t>
<section title="Required Information">
<t>
Identification: urn:ietf:params:xml:ns:abfab:profiles:query
</t>
<t>
Contact information: iesg@ietf.org
</t>
<t>
Description: Given below.
</t>
<t>
Updates: None.
</t>
</section>
<section title="Profile Overview">
<t>
As with the SAML V2.0 Assertion Query/Request Profile defined by <xref target="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
<xref target="OASIS.saml-core-2.0-os" /> that 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.
</t>
<figure anchor="AAQRP_swimlane">
<preamble>
<xref target="AAQRP_swimlane" /> below illustrates the basic template for the query/request profile.
</preamble>
<artwork>
SAML Requester SAML Authority
| |
| (1) |
| - - - - - - - - - - - - - - - - - - - - - - - > |
| |
| (2) |
| < - - - - - - - - - - - - - - - - - - - - - - - |
| |
| |
V V
</artwork>
<postamble>
The following steps are described by the profile.
</postamble>
</figure>
<list style="numbers">
<t>
Query/Request issued by SAML Requester: In step 1, a SAML requester initiates the profile by sending an
<AssertionIDRequest>, <SubjectQuery>, <AuthnQuery>, <AttributeQuery>, or
<AuthzDecisionQuery> message to a SAML authority.
</t>
<t>
<Response> issued by SAML Authority: In step 2, the responding SAML authority (after processing the
query or request) issues a <Response> message to the SAML requester.
</t>
</list>
</section>
<section title="Profile Description">
<section title="Differences from the SAML V2.0 Assertion Query/Request Profile">
<t>
This profile is identical to the SAML V2.0 Assertion Query/Request Profile, with the following exceptions:
</t>
<list style="symbols">
<t>
In respect to section 6.3.1 and 6.5, this profile does not consider the use of metadata
(as in <xref target="OASIS.saml-metadata-2.0-os" />); see <xref target="AAQRP_MC" />.
</t>
<t>
In respect to sections 6.3.2, 6.4.1 and 6.4.2, this profile additionally stipulates that implementations
of this profile MUST NOT require the use of XML signatures; see <xref"AAQRP_XS" />.
</t>
</list>
</section>
<section title="Use of the SAML RADIUS Binding">
<t>
It is RECOMMENDED that the RADIUS exchange is protected using TLS encryption for RADIUS
<xref target="I-D.ietf-radext-radsec" /> to provide confidentiality and improve integrity protection.
</t>
</section>
<section title="Use of XML Signatures" anchor="AAQRP_XS">
<t>
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, but this usage is outside of the scope of this profile.
</t>
</section>
<section title="Metadata Considerations" anchor="AAQRP_MC">
<t>
There are no metadata considerations particular to this binding.
</t>
</section>
</section>
</section>
<section title="Acknowledgements">
<t>TODO: Where should these go? Need to acknowledge OASIS SSTC, UoMurcia, Scott and Steven.</t>
</section>
<section title="Security Considerations">
<t>
TODO
</t>
</section>
<section title="IANA Considerations">
<t>
Assignments of additional enumerated values for the RADIUS attributes defined in this document are to be processed as described in <xref target="RFC3575" />, subject to the additional requirements of a published specification.
</t>
</section>
</middle>
<back>
<references title="Normative References">
&rfc2119;
&I-D.draft-ietf-radext-radsec;
&I-D.ietf-abfab-gss-eap;
&I-D.draft-perez-radext-radius-fragmentation;
</references>
<references title="Informative References">
&rfc2865;
&rfc3575;
&rfc3579;
&rfc3588;
&rfc4282;
&I-D.jones-diameter-abfab;
&I-D.ietf-abfab-arch;
&SAML2Bindings;
&SAML2Core;
&SAML2Profiles;
&SAML2Metadata;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 02:54:39 |