| ABFAB | J. Howlett |
| Internet-Draft | Janet |
| Intended status: Informational | S. Hartman |
| Expires: May 11, 2014 | Painless Security |
| November 07, 2013 |
A RADIUS Attribute, Binding, Profiles, Name Identifier Format, and Confirmation Methods for SAML
draft-ietf-abfab-aaa-saml-08
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.
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 May 11, 2014.
Copyright (c) 2013 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.
Within the ABFAB architecture [I-D.ietf-abfab-arch] it is often desirable to convey Security Assertion Mark-up Language (SAML) asertions and protocol messages.
SAML typically only considers the use of HTTP-based transports, known as bindings [OASIS.saml-bindings-2.0-os], which are primarily intended for use with the SAML V2.0 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 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 [RFC2865] and Diameter [RFC3588], in addition to HTTP.
A companion specification [I-D.jones-diameter-abfab] specifies equivalent funtionality for Diameter.
In summary this document specifies:
This document aspires 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, 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:
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].
The RADIUS SAML binding defined by this binding Section 5 uses two attributes to convey SAML assertions and protocol messages respectively [OASIS.saml-core-2.0-os] . Owing to the typical size of these structures, these attributes use the Long Extended Type format [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.
| Name | Type | Extended-Type | Value |
|---|---|---|---|
| SAML-Assertion | TBD | TBD | One or more octets encoding a SAML assertion |
| SAML-Message | TBD | TBD | One or more octets encoding a SAML protocol message |
The SAML RADIUS binding defines how RADIUS [RFC2865] can be used to enable a RADIUS client and server to exchange SAML assertions and protocol messages.
Identification: urn:ietf:params:abfab:bindings:radius
Contact information: iesg@ietf.org
Updates: None.
RADIUS can be used over multiple underlying transports; this binding calls out for the use of Transport Layer Security (TLS) Encryption for RADIUS [RFC6614] as REQUIRED to provide interoperability, confidentiality, improve integrity protection and support the use of longer SAML messages.
Implementations of this profile can take advantage of other mechanisms such as RADIUS packet fragmentation [I-D.perez-radext-radius-fragmentation] to permit transport of longer SAML messages over UDP-based RADIUS transports, such as those described in [RFC2865] and [I-D.ietf-radext-dtls]. Support for fragmentation over UDP is not mandatory.
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 Section 4 to encapsulate the SAML protocol messages.
The second system model permits a RADIUS server acting as a SAML responder to use the RADIUS SAML-Assertion attribute defined in Section 4 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.
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.
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.
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.
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.
These rules relate to the processing of AAA names by SAML entities using profiles of this binding.
These rules relate to the processing of SAML names by SAML entities using profiles of this binding.
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:
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.
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:
A digitally signed request alone is not sufficient.
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.
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.
Implementations MAY support other configurations including the use of metadata.
URI: urn:ietf:params:abfab:nameid-format:nai
Indicates that the content of the element is in the form of a Network Access Identifier (NAI) using the syntax described by [I-D.ietf-radext-nai].
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.
Identification: urn:ietf:params: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.
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.
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:
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
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.
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.
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.
Profile-specific rules for the contents of the <samlp:AuthnRequest> element are given in Section 7.4.1.
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.
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 [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 7.4.2.
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.
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.
The Relying Party MUST NOT include a <saml:Subject> element in the request. The authenticated RADIUS user identifies the principal to the Identity Provider.
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 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 <samlp:AuthnRequest> message MAY be signed. Authentication and integrity are also provided by the RADIUS SAML binding.
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 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 <saml:Assertion> to a Relying Party. This MUST NOT contain any sender-vouches <saml:SubjectConfirmationData> elements containing an InResponseTo attribute.
It is RECOMMENDED that the RADIUS exchange is protected using TLS encryption for RADIUS [RFC6614] to provide confidentiality and improve integrity protection.
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.
There are no metadata considerations particular to this binding.
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.
Identification: urn:ietf:params:abfab:profiles:query
Contact information: iesg@ietf.org
Description: Given below.
Updates: None.
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.
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
This profile is identical to the SAML V2.0 Assertion Query/Request Profile, with the following exceptions:
The RADIUS Access-Request sent by the SAML requester:
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.
It is RECOMMENDED that the RADIUS exchange is protected using TLS encryption for RADIUS [RFC6614] to provide confidentiality and improve integrity protection.
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.
There are no metadata considerations particular to this binding.
URI: urn:ietf:params:abfab:cm:user
URI: urn:ietf:params:abfab:cm:machine
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 [I-D.ietf-emu-eap-tunnel-method].
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.
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.
The SAML requester MAY disclose privacy-sensitive information about itself as part of the request. This is unlikely in typical deployments.
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.
The use of TLS to provide confidentiality for the RADIUS exchange is strongly encouraged. Without this, passive observers can observe the assertions.
TODO: Need to acknowledge OASIS SSTC, UoMurcia, Scott, Jim, and Steven.
TODO: Elaborate on the following
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.
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.
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.
Assignments of additional enumerated values for the RADIUS attribute defined in this document are to be processed as described in [RFC6929], subject to the additional requirements of a published specification.
A new top-level registry is created titled "ABFAB Parameters".
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 [RFC5226].
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.
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:
| Parameter | Reference |
|---|---|
| bindings:radius | Section 5 |
| nameid-format:nai | Section 6 |
| profiles:authentication | Section 7 |
| profiles:query | Section 8 |
| cm:user | Section 9 |
| cm:machine | Section 9 |
IANA is requested to register the "abfab" URN sub-namespace in the IETF URN sub-namespace for protocol parameters defined in [RFC3553].
Registry Name: abfab
Specification: draft-ietf-abfab-aaa-saml
Repository: ABFAB URN Parameters (Section Section 13.2)
Index Value: Sub-parameters MUST be specified in UTF-8 using standard URI encoding where necessary.