One document matched: draft-ietf-abfab-aaa-saml-08.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 rfc3553 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3553.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 rfc5226 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5226.xml">
<!ENTITY rfc6614 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6614.xml">
<!ENTITY rfc6929 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6929.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.jones-diameter-abfab SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-jones-diameter-abfab-00.xml">
<!ENTITY I-D.perez-radext-radius-fragmentation SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-perez-radext-radius-fragmentation-01.xml">
<!ENTITY I-D.ietf-radext-dtls SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-radext-dtls-05.xml">
<!ENTITY I-D.ietf-radext-nai SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-radext-nai-03.xml">
<!ENTITY I-D.ietf-emu-eap-tunnel-method SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-emu-eap-tunnel-method-06.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-08" ipr="trust200902">
<front>
<title abbrev="SAML RADIUS">A RADIUS Attribute, Binding, Profiles, Name Identifier Format, and Confirmation Methods 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="2013" />
<area>Security Area</area>
<workgroup>ABFAB</workgroup>
<keyword>ABFAB</keyword>
<keyword>AAA</keyword>
<keyword>EAP</keyword>
<keyword>RADIUS</keyword>
<keyword>SAML</keyword>
<abstract>
<t>
This document describes the use of the Security Assertion Mark-up Language (SAML)
with RADIUS in the context of the ABFAB architecture. It defines two RADIUS
attributes, a SAML binding, a SAML name identifier format, two SAML profiles, and two
SAML confirmation methods. The RADIUS attributes permit encapsulation of SAML assertions and
protocol messages within RADIUS, allowing SAML entities to communicate using the binding.
The two profiles describe the application of this binding for ABFAB
authentication and assertion query/request, enabling a Relying Party to
request authentication of, or assertions for, user or machine principals.
These principals may be named using an NAI name identifier format. Finally,
the subject confirmation methods allow requests and queries to be issued for
a previously authenticated user or machine without needing to explicitly
identify them as the subject. These artifacts have been defined
to permit application in AAA scenarios other than ABFAB, such as network access.
</t>
</abstract>
</front>
<middle>
<section title="TODO">
<t>
<list style="symbols">
<t>
Clean up use of terminology (e.g., "principal") to ensure consistency with
other ABFAB docs.
</t>
<t>
Complete the Acknowledgements and Security and Privacy Considerations sections.
</t>
</list>
</t>
</section>
<section title="Introduction">
<t>
Within the ABFAB architecture <xref target="I-D.ietf-abfab-arch" />
it is often desirable to convey Security Assertion Mark-up Language
(SAML) asertions and protocol messages.
</t>
<t>
SAML typically only considers the use of HTTP-based transports, known as bindings
<xref target="OASIS.saml-bindings-2.0-os" />, which are primarily intended for use
with the SAML V2.0 Web Browser
Single Sign-On Profile <xref target="OASIS.saml-profiles-2.0-os" />.
However the goal of ABFAB is to extend the applicability of federated identity
beyond the Web to other applications by building on the AAA framework.
Consequently there exists a requirement for SAML to integrate with the AAA
framework and protocols such as RADIUS
<xref target="RFC2865"/> and Diameter <xref target="RFC3588"/>, in addition
to HTTP.
</t>
<t>
A companion specification <xref target="I-D.jones-diameter-abfab" /> specifies
equivalent funtionality for Diameter.
</t>
<t>
In summary this document specifies:
</t>
<t>
<list style="symbols">
<t>
Two RADIUS attributes to encapsulate SAML assertions and protocol messages respectively.
</t>
<t>
A SAML RADIUS binding that defines how SAML assertions and protocol messages
can be transported by RADIUS within a SAML exchange.
</t>
A SAML name identifier format in the form of a Network Access Identifier.
<t>
A profile of the SAML Authentication Request Protocol that uses the SAML RADIUS binding
to effect SAML-based authentication and authorization.
</t>
<t>
A profile of the SAML Assertion Query And Request Protocol that uses the SAML RADIUS binding
to effect the query and request of SAML assertions.
</t>
<t>
Two SAML Subject Confirmation Methods for indicating that a user or machine
principal is the subject of an assertion.
</t>
</list>
</t>
<t>
This document aspires 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, and other conventions applied formally or otherwise
within SAML. In particular where this document provides a 'Required Information'
section for the binding and profiles that enumerate:
<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 Attributes" anchor="SAML_RADIUS_attributes">
<t>
The RADIUS SAML binding defined by this binding <xref target="SAML_RADIUS_binding" />
uses two attributes to convey SAML assertions and protocol messages
respectively <xref target="OASIS.saml-core-2.0-os" /> .
Owing to the typical size of these structures, these attributes use the
Long Extended Type format <xref target="RFC6929" /> to encapsulate their data.
The table below defines these attributes. The Length of both of these attributes is >=5.
The More and Reserved fields are handled as described in RFC 6929.
</t>
<texttable anchor="SAML_RADIUS_attributes_table_defn" title="RADIUS SAML attribute definitions">
<ttcol align='center'>Name</ttcol>
<ttcol align='center'>Type</ttcol>
<ttcol align='center'>Extended-Type</ttcol>
<ttcol align='center'>Value</ttcol>
<c>SAML-Assertion</c>
<c>TBD</c>
<c>TBD</c>
<c>One or more octets encoding a SAML assertion</c>
<c>SAML-Message</c>
<c>TBD</c>
<c>TBD</c>
<c>One or more octets encoding a SAML protocol message</c>
</texttable>
</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 assertions and
protocol messages.
</t>
<section title="Required Information">
<t>
Identification: urn:ietf:params: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 for the use of Transport Layer Security (TLS) Encryption for
RADIUS <xref target="RFC6614" /> as REQUIRED to
provide interoperability, confidentiality, improve integrity protection
and support the use of longer SAML messages.
</t>
<t>
Implementations of this profile can take advantage of other mechanisms
such as RADIUS packet fragmentation
<xref target="I-D.perez-radext-radius-fragmentation" /> to permit
transport of longer SAML messages over UDP-based RADIUS transports,
such as those described in <xref target="RFC2865" /> and
<xref target="I-D.ietf-radext-dtls" />. Support for fragmentation over
UDP is not mandatory.
</t>
<t>
There are two system models for the use of SAML over RADIUS. The first is a
request-response model, using the RADIUS SAML-Message attribute
defined in <xref target='SAML_RADIUS_attributes' /> to
encapsulate the SAML protocol messages.
</t>
<list style="numbers">
<t>
The RADIUS client, acting as a SAML requester, transmits a SAML
request element within a RADIUS Access-Request message. This
message MUST include a single instance of the RADIUS User-Name
attribute whose value MUST conform to the Network Access Identifier
<xref target="I-D.ietf-radext-nai" /> scheme. The SAML requester MUST NOT
include more than one SAML request element.
</t>
<t>
The RADIUS server, acting as a SAML responder, returns a SAML
protocol message within a RADIUS Access-Accept or Access-Reject
message. These messages necessarily conclude a RADIUS exchange
and therefore this is the only opportunity for the 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. This often results in a RADIUS access-reject as the same conditions that cause the SAML responder to discard the SAML request will cause the RADIUS server to fail to authenticate.
</t>
</list>
<t>
The second system model permits a RADIUS server acting as a SAML responder
to use the RADIUS SAML-Assertion attribute defined in
<xref target='SAML_RADIUS_attributes' /> to encapsulate
an unsolicited, unencrypted SAML assertion. This attribute MAY be included
in a RADIUS Access-Accept message. When included, the attribute MUST contain
a single SAML assertion.
</t>
<t>
RADIUS servers MUST NOT include both the SAML-Message and the SAML-Assertion
attribute in the same RADIUS message. If a SAML responder is producing a
response to a SAML request, then the first system model is used. A SAML
responder MAY ignore a SAML request and send an unsolicited assertion using
the second system model using the RADIUS SAML-Assertion attribute.
</t>
<t>
In either system model, SAML responders SHOULD return a RADIUS state attribute
as part of the Access-Accept message so that future SAML queries or requests
can be run against the same context of an authentication exchange.
</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>
<section title="Processing of names">
<t>
SAML entities using profiles of this binding will typically possess
both the SAML and AAA names of their correspondents.
Frequently these entities will need to apply policy using
these names; for example, when deciding to release attributes. Often
these policies will be security-sensitive, and so
it is important that policy is applied on these names consistently.
</t>
<section title="AAA names">
<t>
These rules relate to the processing of AAA names by SAML entities
using profiles of this binding.
</t>
<list style="symbols">
<t>
SAML responders SHOULD apply policy based on the NAS identity
associated with the RADIUS Access-Request.
</t>
<t>
SAML requesters SHOULD apply policy based on the NAI realm
associated with the RADIUS Access-Accept.
</t>
</list>
</section>
<section title="SAML names">
<t>
These rules relate to the processing of SAML names by SAML entities
using profiles of this binding.
</t>
<t>
SAML issuers MAY apply policy based on the requester's <entityId>
after validating that the request comes from the NAS. The following
methods are sufficient:
</t>
<list style="symbols">
<t>NAS identity in trusted digitally signed request.</t>
<t>NAS identity in trusted SAML federation metadata.</t>
</list>
<t>A digitally signed request alone is not
sufficient. A RADIUS entity can observe a
SAML message and include it in a RADIUS
message without the concent of the issuer of
that SAML message. If a SAML consumer were to
process the SAML message without confirming
that it applied to the RADIUS message,
inappropriate policy would be used.</t>
<t>
SAML consumers MAY apply policy based on the SAML issuer's
<entityId> after validating that the response comes from
the RADIUS server. The following methods are sufficient:
</t>
<list style="symbols">
<t>RADIUS realm in trusted digitally signed request.</t>
<t>RADIUS realm in trusted SAML federation metadata.</t>
</list>
<t>A digitally signed request alone is not sufficient.</t>
</section>
<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 support a default configuration that does 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, because this
binding and profiles of this binding are intended to be used without metadata.
In this usage, RADIUS infrastructure is used to provide integrity and naming.
RADIUS configuration is used to provide policy including which attributes are
accepted from a SAML responder and which attributes are sent by a SAML responder.
</t>
<t>
Implementations MAY support other configurations including the use of metadata.
</t>
</section>
</section>
</section>
<section title="Network Access Identifier Name Identifier Format" anchor="NAI_name_id">
<t>
URI: urn:ietf:params:abfab:nameid-format:nai
</t>
<t>
Indicates that the content of the element is in the form of a Network Access
Identifier (NAI) using the syntax described by <xref target="I-D.ietf-radext-nai" />.
</t>
</section>
<section title="ABFAB Authentication Profile" anchor="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 uses RADIUS to authenticate the Principal.
The Relying Party, acting as a NAS, attempts to validate the Principal's
credentials against a RADIUS server acting 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: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" />.
</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 does not require the use of any particular authentication
method. The ABFAB architecture does require the use of EAP
<xref target="RFC3579"/>, but this specification may be used in other
non-ABFAB scenarios.
</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
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 authenticated and identified by the Identity Provider,
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 NAS,
attempts to authenticate the User Agent.
</t>
</section>
<section title="Relying Party Issues <samlp:AuthnRequest> to Identity Provider" anchor="RP2IDP">
<t>
The Relying Party uses RADIUS to communicate with the Principal's
Identity Provider. 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
RADIUS 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 method to authenticate the Principal, subject to the
constraints 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 authentication in a manner
consistent with the RADIUS 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>
</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>
The Relying Party MUST NOT include a <saml:Subject> element in
the request. The authenticated RADIUS user identifies the principal
to the Identity Provider.
</t>
<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 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 <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 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 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 RADIUS user.
</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>
Assume that the principal implied by a SAML <Subject> element, if present, takes
precedence over a principal implied by the RADIUS User-Name attribute.
</t>
<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 <saml:Assertion>
to a Relying Party. This MUST NOT contain any sender-vouches
<saml:SubjectConfirmationData> elements containing an InResponseTo attribute.
</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="RFC6614" /> 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" anchor="ABFAB_query_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: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>
When processing the SAML request, the SAML responder MUST give
precedence to the principal implied by RADIUS State attribute, if present,
over the principal implied by the SAML request's <Subject>, if any.
</t>
<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 target="AAQRP_XS" />.
</t>
</list>
</section>
<section title="Use of the SAML RADIUS Binding">
<t>
The RADIUS Access-Request sent by the SAML requester:
<list style="symbols">
<t>
MUST use a RADIUS User-Name attribute whose value is "@REALM", where
REALM is the destination NAI realm.
</t>
<t>
MUST include an instance of the RADIUS Service-Type attribute, having
a value of Authorize-Only.
</t>
<t>
SHOULD include the RADIUS State attribute, where this Query/Request
pertains to previously authenticated principal.
</t>
</list>
</t>
<t>
When processing the SAML request, the SAML responder MUST give precedence to the principal implied by RADIUS State attribute over the principal implied by the SAML request's <Subject>, if any.
</t>
<t>
It is RECOMMENDED that the RADIUS exchange is protected using TLS encryption for RADIUS
<xref target="RFC6614" /> 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="RADIUS State Confirmation Methods" anchor="RADIUS_cm_methods">
<t>
URI: urn:ietf:params:abfab:cm:user
</t>
<t>
URI: urn:ietf:params:abfab:cm:machine
</t>
<t>
The RADIUS State Confirmation Methods indicate that the Subject is the system entity
(either the user or machine) authenticated by a previously transmitted RADIUS Access-Accept
message, as identified by the value of that RADIUS message's State attribute, in the sense
of <xref target="I-D.ietf-emu-eap-tunnel-method" />.
</t>
</section>
<section title="Privacy considerations">
<t>
The profiles defined in this document allow a SAML requester to
request specific information about the principal and allow a SAML
responder to disclose information about a requester. Responders MUST
apply policy to decide what information is released. The SAML
requester does not typically know the identity of the principal unless
informed by the SAML responder or RADIUS server. The SAML requester
does typically know the realm of the IDP. Information that
is released MAY include generic attributes such as affiliation shared
by many principals. Even these generic attributes can help to
identify a specific principal. Other attributes MAY provide a SAML
requester with the ability to link the same principals between
sessions with the same SAML requester. Other attributes MAY provide
the requester with the ability to link the principal between
requesters or with personally identifyable information about the
principal.</t>
<t>These profiles do not directly provide a principal with a
mechanism to express preferences about what information is released.
That information can be expressed out-of-band, for example as part of
enrollment.</t>
<t>The SAML requester MAY disclose privacy-sensitive information
about itself as part of the request. This is unlikely in typical
deployments.</t>
<t>If RADIUS proxies are used, then attributes disclode by the
SAML responder are visible to the proxies. This is a significant
privacy exposure in some deployments. Ongoing work is exploring
mechanisms for creating TLS connections directly between the NAS and
the RADIUS server to reduce this exposure. If proxies are used, the
impact of exposing SAML assertions to the proxies needs to be
carefully considered.</t>
<t>The use of TLS to provide confidentiality for the RADIUS
exchange is strongly encouraged. Without this, passive observers can
observe the assertions.</t>
</section>
<section title="Acknowledgements">
<t>TODO: Need to acknowledge OASIS SSTC, UoMurcia, Scott, Jim, and Steven.</t>
</section>
<section title="Security Considerations">
<t>
TODO: Elaborate on the following
</t>
<t>
The RADIUS server vouches for its SAML messages. The
NAS trusts any statement in the SAML messages from the
RADIUS server in the same way that it trusts
information contained in RADIUS attributes. The NAS
MUST apply policy and filter the information based on
what information the RADIUS server is permitted to
assert and on what trust is reasonable to place in
proxies between the NAS and RADIUS server.
</t>
<t>
SAML entities' level of trust in the SAML messages that they recieve from other
entities should be consistent with the trust it holds
in the RADIUS infrastructure. That is SAML entities
SHOULD trust RADIUS to authenticate the principal and
to reach the right IDP. SAML entities trust the
RADIUS infrastructure to provide integrity of the SAML
messages. However policy MUST be applied to limit
what statements are permitted.
</t>
<t>XML signatures and encryption are provided as an OPTIONAL
mechanism for end-to-end security. These mechanism can protect
SAML messages from being modified by proxies in the RADIUS
infrastructure. These mechanisms are not
mandatory-to-implement. It is believed that ongoing work to
provide direct TLS connections between a NAS and RADIUS server
will provide similar assurances but better deployability. XML
security is appropriate for deployments where end-to-end
security is required but proxies cannot be removed or where SAML
messages need to be verified at a later time ro by parties not
involved in the authentication exchange.</t>
</section>
<section title="IANA Considerations">
<section title="RADIUS Attributes">
<t>
Assignments of additional enumerated values for the RADIUS attribute defined in
this document are to be processed as described in <xref target="RFC6929" />,
subject to the additional requirements of a published specification.
</t>
</section>
<section title="ABFAB Parameters" anchor="ABFAB_PARAMS">
<t>
A new top-level registry is created titled "ABFAB Parameters".
</t>
<t>
In this top-level registry, a sub-registry titled "ABFAB URN Parameters" is
created. Registration in this registry is by the IETF review or expert review
procedures <xref target="RFC5226" />.
</t>
<t>
This paragraph gives guidance to designated experts. Registrations in this
registry are generally only expected as part of protocols published as RFCs
on the IETF stream; other URIs are expected to be better choices for non-IETF work.
Expert review is permitted mainly to permit early registration related to
specifications under development when the community believes they have reach sufficient
maturity. The expert SHOULD evaluate the maturity and stability of such an IETF-stream
specification. Experts SHOULD review anything not from the IETF stream for consistency
and consensus with current practice. Today such requests would not typically be approved.
</t>
<t>
If the "paramname" parameter is registered in this registry then its URN will be
"urn:ietf:params:abfab:paramname". The initial registrations are as follows:
</t>
<texttable title="ABFAB Parameters">
<ttcol>Parameter</ttcol><ttcol>Reference</ttcol>
<c>bindings:radius</c><c><xref target="SAML_RADIUS_binding" /></c>
<c>nameid-format:nai</c><c><xref target="NAI_name_id" /></c>
<c>profiles:authentication</c><c><xref target="ABFAB_authentication_profile" /></c>
<c>profiles:query</c><c><xref target="ABFAB_query_profile" /></c>
<c>cm:user</c><c><xref target="RADIUS_cm_methods" /></c>
<c>cm:machine</c><c><xref target="RADIUS_cm_methods" /></c>
</texttable>
</section>
<section title="Registration of the ABFAB URN Namespace">
<t>
IANA is requested to register the "abfab" URN sub-namespace in the IETF
URN sub-namespace for protocol parameters defined in <xref target="RFC3553" />.
</t>
<t>
Registry Name: abfab
</t>
<t>
Specification: draft-ietf-abfab-aaa-saml
</t>
<t>
Repository: ABFAB URN Parameters (Section <xref target="ABFAB_PARAMS" />)
</t>
<t>
Index Value: Sub-parameters MUST be specified in UTF-8 using standard
URI encoding where necessary.
</t>
</section>
</section>
</middle>
<back>
<references title="Normative References">
&rfc2119;
&rfc2865;
&rfc3579;
&rfc6614;
&rfc6929;
&I-D.ietf-radext-nai;
&SAML2Bindings;
&SAML2Core;
&SAML2Profiles;
&SAML2Metadata;
</references>
<references title="Informative References">
&rfc3553;
&rfc3575;
&rfc3588;
&rfc5226;
&I-D.perez-radext-radius-fragmentation;
&I-D.jones-diameter-abfab;
&I-D.ietf-abfab-arch;
&I-D.ietf-radext-dtls;
&I-D.ietf-emu-eap-tunnel-method;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 16:19:21 |