One document matched: draft-ietf-abfab-aaa-saml-03.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.lear-abfab-arch SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-lear-abfab-arch-02.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">
]>
<rfc category="info" docName="draft-ietf-abfab-aaa-saml-03" 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>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, while the binding describes the transport
of this attribute, and the SAML protocol messages within, using RADIUS. The profiles describe the application
of this binding for Abfab authentication and assertion query/request. 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="Introduction">
<t>
The SAML RADIUS attribute, binding and profiles are motivated by the requirements of the Abfab architecture
<xref target="I-D.lear-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; for example, to allow a Relying Party to obtain a SAML assertion containing
attributes that describe a principal.
</t>
<t>
SAML <xref target="OASIS.saml-core-2.0-os" /> defines a number of SAML protocol messages that are
used for a range of different purposes <xref target="OASIS.saml-profiles-2.0-os" />. These messages
are derived from common request and reponse abstract types. These request and
response protocol messages can be exchanged using a variety of underlying transport protocols,
such as HTTP. In the SAML model, the means by which
a SAML protocol message exchange is framed over an underlying transport protocol is known as a
SAML 'binding'. SAML already defines <xref target="OASIS.saml-bindings-2.0-os" /> a number of mainly
HTTP-based bindings; these principally use HTTP as the underlying transport protocol, generally for
use with the SAML Web Browser Single Sign-On Profile <xref target="OASIS.saml-profiles-2.0-os" />.
</t>
<t>
However, the goal of Abfab is to extend the applicability of federated identity beyond the Web
to other application protocols by building on the AAA framework. Consequently here exists a
requirement for an AAA-based binding, that is functionally equivalent to the existing bindings,
that uses the RADIUS <xref target="RFC2865"/> and Diameter <xref target="RFC3588"/> protocols,
rather than HTTP. This document defines a new RADIUS-based SAML binding, building on a SAML RADIUS attribute
also defined by this document. A companion specification <xref target="I-D.jones-diameter-abfab"/>
defines equivalent funtionality for Diameter.
</t>
<t>
This attribute and binding are likely to be useful for purposes besides Abfab; an example of one
potential application is SAML-based authorisation for network access. The attribute and binding
are therefore defined generically to facilitate general applicability. Nonetheless it is useful
to also define how the SAML RADIUS binding should be used for Abfab-specific
purposes to facilitate interoperability. This document therefore also define two profiles of this
binding to support authentication and assertion request.
</t>
<t>
To summarise, 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>
The Abfab Authentication Profile that defines how the SAML RADIUS binding is used
to effect SAML-based authentication and authorisation within the Abfab architecture.
</t>
<t>
The Abfab Assertion Request Profile that defines how the SAML RADIUS binding is used
to effect SAML-based assertion request within the Abfab architecture.
</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" />
respectively. To this end, the binding and profiles 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>
<t>TODO: request a new RADIUS attribute</t>
</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: TBD
</t>
<t>
Contact information: TBD
</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. It is also
RECOMMENDED that RADIUS packet fragmentation <xref target="I-D.perez-radext-radius-fragmentation" />
is used 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, 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="RFC4282" /> scheme. The NAI SHOULD be used to route the message
towards the SAML responder, which MAY be more than one RADIUS hop distant. 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. 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 responser (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 any use of RADIUS, such as network access.
Therefore, other arbitrary RADIUS attributes MAY be used in either the request of 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="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: TBD
</t>
<t>
Contact information: TBD
</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 Web Browser Single Sign-On Profile <xref target="OASIS.saml-profiles-2.0-os" />.
There are some important differences between these profiles; specifically:
</t>
<list style="symbols">
<t>
Authentication. This profile specifically calls out the use of a particular authentication
framework (although not a particular authentication mechanism). This is necessary so that
the profile is able to build on the AAA and GSS frameworks.
</t>
<t>
Bindings. This profile does not use any 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 minimize the number of bindings that interoperable implementations must support.
</t>
<t>
Requests. The profile does not permit the Relying Party to name the <saml:Subject> of the
<samlp:AuthnRequest>. This is intended to simplify the business logic of interoperable
implementations.
</t>
<t>
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 disgression of the Identity Provider. This is intended to simplify the business logic of interoperable
implementations.
</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 issues
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.
</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>
<t>
Note that an Identity Provider can initiate this profile at step 4 and issue a <samlp:Response> message to a
Relying Party without the preceding steps.
</t>
</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>
<t>
If the profile is initiated by the Relying Party, start with <xref target="AAP_UA2RP" />. If initiated by the Identity Provider,
start with <xref target="IDP2RP" />.
</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-Response/Identity message from the User Agent, MUST send it
towards the Identity Provider using RADIUS <xref target="RFC3579"/>. The Relying Party MAY include a
<samlp:AuthnRequest> within this RADIUS Access-Request message.
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
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>
Regardless of the success or failure of the <samlp:AuthnRequest>, the Identity Provider MUST produce
a <samlp:Response> message to be 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>
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 MUST 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 implicitly 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 statements and confirmation methods MAY be included in the assertion at the discretion
of the Identity Provider. In particular, <samlp:AttributeStatement> elements MAY be included.
Deployers should be aware of the implications of allowing weaker confirmation as the processing as defined
in section 2.4.1.1 of <xref target="OASIS.saml-core-2.0-os" /> is effectively satisfy-any.
</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="Metadata Considerations">
<t>
There are no metadata considerations particular to this binding.
</t>
</section>
</section>
</section>
<section title="Abfab Assertion Query/Request Profile">
</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;
&rfc2865;
&SAML2Core;
&rfc3575;
&rfc3579;
&rfc4282;
&I-D.draft-ietf-radext-radsec;
&I-D.ietf-abfab-gss-eap;
&I-D.draft-perez-radext-radius-fragmentation;
</references>
<references title="Informative References">
&rfc3588;
&I-D.jones-diameter-abfab;
&I-D.lear-abfab-arch;
&SAML2Bindings;
&SAML2Profiles;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 10:07:43 |