| ABFAB | J. Howlett |
| Internet-Draft | Janet |
| Intended status: Informational | S. Hartman |
| Expires: September 11, 2012 | Painless Security |
| March 12, 2012 |
A RADIUS Attribute, Binding and Profiles for SAML
draft-ietf-abfab-aaa-saml-03
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.
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 September 11, 2012.
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 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.
The SAML RADIUS attribute, binding and profiles are motivated by the requirements of the Abfab architecture [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.
SAML [OASIS.saml-core-2.0-os] defines a number of SAML protocol messages that are used for a range of different purposes [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 [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 [OASIS.saml-profiles-2.0-os].
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 [RFC2865] and Diameter [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 [I-D.jones-diameter-abfab] defines equivalent funtionality for Diameter.
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.
To summarise, this document specifies:
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] respectively. To this end, the binding and profiles provide a 'Required Information' section that enumerates:
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].
This attribute contains a SAML [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.
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
TODO: request a new RADIUS attribute
The SAML RADIUS binding defines how RADIUS [RFC2865] can be used to enable a RADIUS client and server to exchange SAML protocol messages.
Identification: TBD
Contact information: TBD
Updates: None.
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. It is also RECOMMENDED that RADIUS packet fragmentation [I-D.perez-radext-radius-fragmentation] is used to permit transport of large SAML messages.
The system model used for SAML conversations over RADIUS is a simple request-response model, using the RADIUS SAML-Message attribute defined in Section 3 to encapsulate the SAML protocol messages.
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).
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.
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.
There are no metadata considerations particular to this binding.
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.
Identification: TBD
Contact information: TBD
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.
To implement this scenario, a profile of the SAML Authentication Request protocol is used in conjuction with the SAML RADIUS binding defined in Section 4 and the GSS EAP mechanism [I-D.ietf-abfab-gss-eap].
This profile is based on the SAML Web Browser Single Sign-On Profile [OASIS.saml-profiles-2.0-os]. There are some important differences between these profiles; specifically:
Figure 2 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.
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.
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.
If the profile is initiated by the Relying Party, start with Section 5.3.1. If initiated by the Identity Provider, start with Section 5.3.4.
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.
The Relying Party, on receiving the EAP-Response/Identity message from the User Agent, MUST send it towards the Identity Provider using RADIUS [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.
Profile-specific rules for the contents of the <samlp:AuthnRequest> element are given in Section 5.4.1.
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 [I-D.ietf-abfab-gss-eap]. and any others called out in the <samlp:AuthnRequest> message.
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.
Profile-specific rules regarding the contents of the <samlp:Response> element are given in Section 5.4.2.
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.
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 Subject.
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 MUST 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 implicitly 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.
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:
The Relying Party MUST do the following:
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.
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.
There are no metadata considerations particular to this binding.
TODO
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.
| [RFC3588] | Calhoun, P., Loughney, J., Guttman, E., Zorn, G. and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003. |
| [I-D.jones-diameter-abfab] | Jones, M and H Tschofenig, "The Diameter 'Application Bridging for Federated Access Beyond Web (ABFAB)' Application", Internet-Draft draft-jones-diameter-abfab-00, March 2011. |
| [I-D.lear-abfab-arch] | Howlett, J, Hartman, S, Tschofenig, H and E Lear, "Application Bridging for Federated Access Beyond Web (ABFAB) Architecture", Internet-Draft draft-lear-abfab-arch-02, March 2011. |
| [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-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. |