A RADIUS Attribute, Binding and Profiles for SAML
draft-ietf-abfab-aaa-saml-04
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft that was ultimately published as RFC 7833.
|
|
|---|---|---|---|
| Authors | Josh Howlett , Sam Hartman | ||
| Last updated | 2012-10-19 | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Formats | |||
| Reviews |
GENART Last Call review
(of
-12)
by Roni Even
Almost ready
|
||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | WG Document | |
| Document shepherd | (None) | ||
| IESG | IESG state | Became RFC 7833 (Proposed Standard) | |
| Consensus boilerplate | Unknown | ||
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-ietf-abfab-aaa-saml-04
ABFAB J. Howlett
Internet-Draft Janet
Intended status: Informational S. Hartman
Expires: April 21, 2013 Painless Security
October 18, 2012
A RADIUS Attribute, Binding and Profiles for SAML
draft-ietf-abfab-aaa-saml-04
Abstract
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.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 21, 2013.
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
Howlett & Hartman Expires April 21, 2013 [Page 1]
Internet-Draft SAML RADIUS October 2012
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. TODO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. RADIUS SAML-Message Attribute . . . . . . . . . . . . . . . . 5
5. SAML RADIUS Binding . . . . . . . . . . . . . . . . . . . . . 6
5.1. Required Information . . . . . . . . . . . . . . . . . . . 6
5.2. Operation . . . . . . . . . . . . . . . . . . . . . . . . 6
5.2.1. Use of XML Signatures . . . . . . . . . . . . . . . . 7
5.2.2. Metadata Considerations . . . . . . . . . . . . . . . 8
6. ABFAB Authentication Profile . . . . . . . . . . . . . . . . . 8
6.1. Required Information . . . . . . . . . . . . . . . . . . . 8
6.2. Profile Overview . . . . . . . . . . . . . . . . . . . . . 8
6.3. Profile Description . . . . . . . . . . . . . . . . . . . 10
6.3.1. User Agent Request to Relying Party . . . . . . . . . 10
6.3.2. Relying Party Issues <samlp:AuthnRequest> to
Identity Provider . . . . . . . . . . . . . . . . . . 10
6.3.3. Identity Provider Identifies Principal . . . . . . . . 11
6.3.4. Identity Provider Issues <samlp:Response> to
Relying Party . . . . . . . . . . . . . . . . . . . . 11
6.3.5. Relying Party Grants or Denies Access to Principal . . 11
6.4. Use of Authentication Request Protocol . . . . . . . . . . 11
6.4.1. <samlp:AuthnRequest> Usage . . . . . . . . . . . . . . 12
6.4.2. <samlp:Response message> Usage . . . . . . . . . . . . 12
6.4.3. samlp:Response Message Processing Rules . . . . . . . 13
6.4.4. Unsolicited Responses . . . . . . . . . . . . . . . . 13
6.4.5. Use of the SAML RADIUS Binding . . . . . . . . . . . . 13
6.4.6. Use of XML Signatures . . . . . . . . . . . . . . . . 13
6.4.7. Metadata Considerations . . . . . . . . . . . . . . . 14
7. ABFAB Assertion Query/Request Profile . . . . . . . . . . . . 14
7.1. Required Information . . . . . . . . . . . . . . . . . . . 14
7.2. Profile Overview . . . . . . . . . . . . . . . . . . . . . 14
7.3. Profile Description . . . . . . . . . . . . . . . . . . . 15
7.3.1. Differences from the SAML V2.0 Assertion
Query/Request Profile . . . . . . . . . . . . . . . . 15
7.3.2. Use of the SAML RADIUS Binding . . . . . . . . . . . . 15
7.3.3. Use of XML Signatures . . . . . . . . . . . . . . . . 16
7.3.4. Metadata Considerations . . . . . . . . . . . . . . . 16
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
9. Security Considerations . . . . . . . . . . . . . . . . . . . 16
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
Howlett & Hartman Expires April 21, 2013 [Page 2]
Internet-Draft SAML RADIUS October 2012
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
11.1. Normative References . . . . . . . . . . . . . . . . . . . 16
11.2. Informative References . . . . . . . . . . . . . . . . . . 17
Howlett & Hartman Expires April 21, 2013 [Page 3]
Internet-Draft SAML RADIUS October 2012
1. TODO
o Clean up use of terminology (e.g., "principal") to ensure
consistency with other ABFAB docs.
o Understand Alan DeK's preferences with respect to choreography of
SAML messages and the RADIUS exchange(s).
o Request a new RADIUS attribute
o Check that binding/profiles identification URNs are reasonable
2. Introduction
The SAML RADIUS attribute, binding and profiles are motivated by the
requirements of the ABFAB architecture [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.
SAML defines a number of SAML protocol messages
[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 [OASIS.saml-bindings-2.0-os];
and these are primarily intended for use with the SAML V2.0 Web
Browser Single Sign-On Profile [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
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 [RFC2865] and Diameter [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.
In addition to this attribute and binding, this document also
Howlett & Hartman Expires April 21, 2013 [Page 4]
Internet-Draft SAML RADIUS October 2012
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.
A companion specification [I-D.jones-diameter-abfab] specifies
equivalent funtionality for Diameter.
In summary this document specifies:
o A SAML RADIUS attribute that defines how to encapsulate a SAML
protocol message within a RADIUS attribute.
o A SAML RADIUS binding that defines how SAML requesters and
responders can exchange SAML protocol messages.
o An Authentication Profile that defines how the SAML RADIUS binding
is used to effect SAML-based authentication and authorization.
o An Assertion Query/Request Profile that defines how the SAML
RADIUS binding is used to effect SAML-based assertion request.
The RADIUS SAML binding and profile specifications aspire to adhere
to the guidelines stipulated by [OASIS.saml-bindings-2.0-os] and
[OASIS.saml-profiles-2.0-os] for defining new SAML bindings and
profiles respectively. These new bindings and profiles are asked to
provide a 'Required Information' section that enumerates:
o A URI that uniquely identifies the protocol binding or profile
o Postal or electronic contact information for the author
o A reference to previously defined bindings or profiles that the
new binding updates or obsoletes
o In the case of a profile, any SAML confirmation method identifiers
defined and/or utilized by the profile
3. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
4. RADIUS SAML-Message Attribute
This attribute contains a SAML [OASIS.saml-core-2.0-os] protocol
message. Where multiple SAML-Message attributes are included in a
Howlett & Hartman Expires April 21, 2013 [Page 5]
Internet-Draft SAML RADIUS October 2012
RADIUS message, the Message fields of these attributes are to be
concatenated to form a single SAML message.
A summary of the SAML-Message format is shown below. The fields are
transmitted from left to right.
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
Type: TBD
Length: >=3
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.
5. SAML RADIUS Binding
The SAML RADIUS binding defines how RADIUS [RFC2865] can be used to
enable a RADIUS client and server to exchange SAML protocol messages.
5.1. Required Information
Identification: urn:ietf:params:xml:ns:abfab:bindings:radius
Contact information: iesg@ietf.org
Updates: None.
5.2. Operation
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
[I-D.ietf-radext-radsec] to provide confidentiality and improve
integrity protection. Implementations of this profile MUST support
RADIUS packet fragmentation [I-D.perez-radext-radius-fragmentation]
to permit transport of large SAML messages.
The system model used for SAML conversations over RADIUS is a simple
Howlett & Hartman Expires April 21, 2013 [Page 6]
Internet-Draft SAML RADIUS October 2012
request-response model, using the RADIUS SAML-Message attribute
defined in Section 4 to encapsulate the SAML protocol messages.
1. 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 [RFC4282] scheme. The SAML requester MUST NOT include
more than one SAML request element.
2. 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.
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).
This binding is intended to be composed with other uses of RADIUS,
such as network access. Therefore, other arbitrary RADIUS attributes
MAY be used in either the request or response.
In the case of a SAML processing error and successful authentication,
the RADIUS server SHOULD include a SAML-specified <samlp:Status>
element in the SAML response that is transported within the Access-
Accept packet sent by the RADIUS server.
In the case of a SAML processing error and failed authentication, the
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.
5.2.1. Use of XML Signatures
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.
Howlett & Hartman Expires April 21, 2013 [Page 7]
Internet-Draft SAML RADIUS October 2012
5.2.2. Metadata Considerations
There are no metadata considerations particular to this binding.
6. ABFAB Authentication Profile
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.
6.1. Required Information
Identification: urn:ietf:params:xml:ns:abfab:profiles:authentication
Contact information: iesg@ietf.org
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.
Updates: None.
6.2. Profile Overview
To implement this scenario, a profile of the SAML Authentication
Request protocol is used in conjuction with the SAML RADIUS binding
defined in Section 5 and the GSS EAP mechanism
[I-D.ietf-abfab-gss-eap].
This profile is based on the SAML V2.0 Web Browser Single Sign-On
Profile [OASIS.saml-profiles-2.0-os]. There are some important
differences, specifically:
Authentication: This profile 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.
Howlett & Hartman Expires April 21, 2013 [Page 8]
Internet-Draft SAML RADIUS October 2012
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 Section 5. This is
intended to reduce the number of bindings that implementations
must support to be interoperable.
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.
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.
Figure 1 below illustrates the flow of messages within this profile.
User Agent Relying Party Identity Provider
| | |
| (1) | |
| - - - - - - - - - > | |
| | |
| | (2) |
| | - - - - - - - - - - - - > |
| | |
| (3) | |
| < - - - - - - - - - |- - - - - - - - - - - - -> |
| | |
| | (4) |
| | < - - - - - - - - - - - - |
| | |
| (5) | |
| < - - - - - - - - - | |
| | |
V V V
The following steps are described by the profile. Within an
individual step, there may be one or more actual message exchanges.
Figure 1
1. User Agent Request to Relying Party (Section 6.3.1): 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.
Howlett & Hartman Expires April 21, 2013 [Page 9]
Internet-Draft SAML RADIUS October 2012
2. Relying Party Issues <samlp:AuthnRequest> to Identity Provider
(Section 6.3.2). 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.
3. Identity Provider Identifies Principal (Section 6.3.3). 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.
4. Identity Provider Issues <samlp:Response> to Relying Party
(Section 6.3.4). 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.
5. Relying Party Grants or Denies Access to Principal
(Section 6.3.5). 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.
6.3. Profile Description
The ABFAB Authentication Profile is a profile of the SAML V2.0
Authentication Request Protocol [OASIS.saml-core-2.0-os]. Where this
specification conflicts with Core, the former takes precedence.
6.3.1. User Agent Request to Relying Party
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.
6.3.2. Relying Party Issues <samlp:AuthnRequest> to Identity Provider
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 [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.
Howlett & Hartman Expires April 21, 2013 [Page 10]
Internet-Draft SAML RADIUS October 2012
Profile-specific rules for the contents of the <samlp:AuthnRequest>
element are given in Section 6.4.1.
6.3.3. Identity Provider Identifies Principal
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 [I-D.ietf-abfab-gss-eap] and any others called out in the
<samlp:AuthnRequest> message.
6.3.4. Identity Provider Issues <samlp:Response> to Relying Party
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 [OASIS.saml-core-2.0-os]
and delivered to the Relying Party using the SAML RADIUS binding.
Profile-specific rules regarding the contents of the <samlp:Response>
element are given in Section 6.4.2.
6.3.5. Relying Party Grants or Denies Access to Principal
If issued by the Identity Provider, the Relying Party MUST process
the <samlp:Response> message and any enclosed <saml:Assertion>
elements as described in [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.
To complete the profile, the Relying Party creates a GSS security
context for the User Agent.
6.4. Use of Authentication Request Protocol
This profile is based on the Authentication Request Protocol defined
in [OASIS.saml-core-2.0-os]. In the nomenclature of actors
enumerated in section 3.4, the Relying Party is the requester, the
User Agent is the attesting entity and the Principal is the Requested
Howlett & Hartman Expires April 21, 2013 [Page 11]
Internet-Draft SAML RADIUS October 2012
Subject.
6.4.1. <samlp:AuthnRequest> Usage
A Relying Party MAY include any message content described in
[OASIS.saml-core-2.0-os], section 3.4.1. All processing rules are as
defined in [OASIS.saml-core-2.0-os].
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.
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.
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.
The <samlp:AuthnRequest> message MAY be signed. Authentication and
integrity are also provided by the RADIUS SAML binding.
6.4.2. <samlp:Response message> Usage
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:
o It MAY be signed.
o It MUST contain exactly one <saml:Assertion>. The <saml:Subject>
element of this assertion MUST refer to the authenticated
Principal.
o 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.
Howlett & Hartman Expires April 21, 2013 [Page 12]
Internet-Draft SAML RADIUS October 2012
o 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.
6.4.3. samlp:Response Message Processing Rules
The Relying Party MUST do the following:
o 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.
o 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.
o Verify that any assertions relied upon are valid according to
processing rules in [OASIS.saml-core-2.0-os].
o 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.
6.4.4. Unsolicited Responses
An Identity Provider MAY initiate this profile by delivering an
unsolicited <samlp:Response> message to a Relying Party.
An unsolicited <samlp:Response> MUST NOT contain an InResponseTo
attribute, nor should any sender-vouches <saml:
SubjectConfirmationData> elements contain one.
6.4.5. Use of the SAML RADIUS Binding
It is RECOMMENDED that the RADIUS exchange is protected using TLS
encryption for RADIUS [I-D.ietf-radext-radsec] to provide
confidentiality and improve integrity protection.
6.4.6. Use of XML Signatures
This profile calls for the use of SAML elements that support XML
signatures. To promote interoperability implementations of this
profile MUST NOT require the use of XML signatures. Implementations
MAY choose to use XML signatures, but this usage is outside of the
Howlett & Hartman Expires April 21, 2013 [Page 13]
Internet-Draft SAML RADIUS October 2012
scope of this profile.
6.4.7. Metadata Considerations
There are no metadata considerations particular to this binding.
7. ABFAB Assertion Query/Request Profile
This profile builds on the SAML V2.0 Assertion Query/Request Profile
defined by [OASIS.saml-profiles-2.0-os]. That profile describes the
use of the Assertion Query and Request Protocol defined by section
3.3 of [OASIS.saml-core-2.0-os] with synchronous bindings, such as
the SOAP binding defined in [OASIS.saml-bindings-2.0-os] or the SAML
RADIUS binding defined elsewhere in this document.
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.
7.1. Required Information
Identification: urn:ietf:params:xml:ns:abfab:profiles:query
Contact information: iesg@ietf.org
Description: Given below.
Updates: None.
7.2. Profile Overview
As with the SAML V2.0 Assertion Query/Request Profile defined by
[OASIS.saml-profiles-2.0-os] the message exchange and basic
processing rules that govern this profile are largely defined by
Section 3.3 of [OASIS.saml-core-2.0-os] 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.
Howlett & Hartman Expires April 21, 2013 [Page 14]
Internet-Draft SAML RADIUS October 2012
Figure 2 below illustrates the basic template for the query/request
profile.
SAML Requester SAML Authority
| |
| (1) |
| - - - - - - - - - - - - - - - - - - - - - - - > |
| |
| (2) |
| < - - - - - - - - - - - - - - - - - - - - - - - |
| |
| |
V V
The following steps are described by the profile.
Figure 2
1. 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.
2. <Response> issued by SAML Authority: In step 2, the responding
SAML authority (after processing the query or request) issues a
<Response> message to the SAML requester.
7.3. Profile Description
7.3.1. Differences from the SAML V2.0 Assertion Query/Request Profile
This profile is identical to the SAML V2.0 Assertion Query/Request
Profile, with the following exceptions:
o In respect to section 6.3.1 and 6.5, this profile does not
consider the use of metadata (as in [OASIS.saml-metadata-2.0-os]);
see Section 7.3.4.
o 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 .
7.3.2. Use of the SAML RADIUS Binding
It is RECOMMENDED that the RADIUS exchange is protected using TLS
encryption for RADIUS [I-D.ietf-radext-radsec] to provide
confidentiality and improve integrity protection.
Howlett & Hartman Expires April 21, 2013 [Page 15]
Internet-Draft SAML RADIUS October 2012
7.3.3. Use of XML Signatures
This profile calls for the use of SAML elements that support XML
signatures. To promote interoperability implementations of this
profile MUST NOT require the use of XML signatures. Implementations
MAY choose to use XML signatures, but this usage is outside of the
scope of this profile.
7.3.4. Metadata Considerations
There are no metadata considerations particular to this binding.
8. Acknowledgements
TODO: Where should these go? Need to acknowledge OASIS SSTC,
UoMurcia, Scott and Steven.
9. Security Considerations
TODO
10. IANA Considerations
Assignments of additional enumerated values for the RADIUS attributes
defined in this document are to be processed as described in
[RFC3575], subject to the additional requirements of a published
specification.
11. References
11.1. Normative References
[RFC2119] Bradner, S., "Key words for
use in RFCs to Indicate
Requirement Levels", BCP 14,
RFC 2119, March 1997.
[I-D.ietf-radext-radsec] Winter, S., McCauley, M.,
Venaas, S., and K. Wierenga,
"TLS encryption for RADIUS",
draft-ietf-radext-radsec-09
(work in progress),
July 2011.
[I-D.ietf-abfab-gss-eap] Howlett, J. and S. Hartman,
"A GSS-API Mechanism for the
Extensible Authentication
Protocol",
Howlett & Hartman Expires April 21, 2013 [Page 16]
Internet-Draft SAML RADIUS October 2012
draft-ietf-abfab-gss-eap-04
(work in progress),
October 2011.
[I-D.perez-radext-radius-fragmentation] Perez-Mendez, A., Lopez, R.,
Pereniguez-Garcia, F.,
Lopez-Millan, G., Lopez, D.,
and A. DeKok, "Support of
fragmentation of RADIUS
packets", draft-perez-
radext-radius-fragmentation-
01 (work in progress),
February 2012.
11.2. Informative References
[RFC2865] Rigney, C., Willens, S.,
Rubens, A., and W. Simpson,
"Remote Authentication Dial
In User Service (RADIUS)",
RFC 2865, June 2000.
[RFC3575] Aboba, B., "IANA
Considerations for RADIUS
(Remote Authentication Dial
In User Service)", RFC 3575,
July 2003.
[RFC3579] Aboba, B. and P. Calhoun,
"RADIUS (Remote
Authentication Dial In User
Service) Support For
Extensible Authentication
Protocol (EAP)", RFC 3579,
September 2003.
[RFC3588] Calhoun, P., Loughney, J.,
Guttman, E., Zorn, G., and
J. Arkko, "Diameter Base
Protocol", RFC 3588,
September 2003.
[RFC4282] Aboba, B., Beadles, M.,
Arkko, J., and P. Eronen,
"The Network Access
Identifier", RFC 4282,
December 2005.
Howlett & Hartman Expires April 21, 2013 [Page 17]
Internet-Draft SAML RADIUS October 2012
[I-D.jones-diameter-abfab] Jones, M. and H. Tschofenig,
"The Diameter 'Application
Bridging for Federated
Access Beyond Web (ABFAB)'
Application", draft-jones-
diameter-abfab-00 (work in
progress), March 2011.
[I-D.ietf-abfab-arch] Howlett, J., Hartman, S.,
Tschofenig, H., Lear, E.,
and J. Schaad, "Application
Bridging for Federated
Access Beyond Web (ABFAB)
Architecture",
draft-ietf-abfab-arch-03
(work in progress),
July 2012.
[OASIS.saml-bindings-2.0-os] Cantor, S., Hirsch, F.,
Kemp, J., Philpott, R., and
E. Maler, "Bindings for the
OASIS Security Assertion
Markup Language (SAML)
V2.0", OASIS Standard saml-
bindings-2.0-os, March 2005.
[OASIS.saml-core-2.0-os] Cantor, S., Kemp, J.,
Philpott, R., and E. Maler,
"Assertions and Protocol for
the OASIS Security Assertion
Markup Language (SAML)
V2.0", OASIS Standard saml-
core-2.0-os, March 2005.
[OASIS.saml-profiles-2.0-os] Hughes, J., Cantor, S.,
Hodges, J., Hirsch, F.,
Mishra, P., Philpott, R.,
and E. Maler, "Profiles for
the OASIS Security Assertion
Markup Language (SAML)
V2.0", OASIS Standard OASIS.
saml-profiles-2.0-os,
March 2005.
[OASIS.saml-metadata-2.0-os] Cantor, S., Moreh, J.,
Philpott, R., and E. Maler,
"Metadata for the Security
Assertion Markup Language
Howlett & Hartman Expires April 21, 2013 [Page 18]
Internet-Draft SAML RADIUS October 2012
(SAML) V2.0", OASIS Standard
saml-metadata-2.0-os,
March 2005.
Authors' Addresses
Josh Howlett
Janet
Lumen House, Library Avenue, Harwell
Oxford OX11 0SG
UK
Phone: +44 1235 822363
EMail: Josh.Howlett@ja.net
Sam Hartman
Painless Security
Phone:
EMail: hartmans-ietf@mit.edu
Howlett & Hartman Expires April 21, 2013 [Page 19]