Date: 30 Nov, 2006
Revision 2
1 Introduction
1.1 Notation
2 Architectural Overview
2.1 Constraints
2.2 Items that are Out-of-Scope
2.3 Access Point (AP)
2.4 R1 (Radius Server)
2.5 R2 (Radius Server)
2.6 Shibboleth Attribute Authority
2.7 Overview of Extended Radius Flow
3 Protocols and Profiles
3.1 Authentication Request and Response
3.1.1 Processing Rules
3.2 SAML Attribute Exchange Profile
3.2.1 Processing Rules
3.2.2 NameIdentifier Format
4 Security and Privacy Considerations
5 Outstanding Issues
6 References
6.1 Normative
7 Change Log
This specification defines a profile that includes messages and flows from both RADIUS [RFC2865] and SAML specifications (both v1.1 and 2.0). In traditional Radius usage, the User's Home Site Radius server makes the access control decision, and tells the Radius server at the Network Provider site whether to grant the user access to its network. When the two Radius servers are in different organizations, the use of the additonal SAML flows allows the Radius server at the Network Provider site to obtain trusted information describing the requesting user; it can then make its own access control decision. This specification is taking advantage of SAML services that are already defined and deployed for exactly this purpose. The availability of these SAML attributes provides the Network Provider RADIUS server with the option of implementing a more flexible access control policy than possible with standard RADIUS. Note that the existing SAML profiles describe web browser use cases. This specification describes a server comunicating with SAML entities; no web browsers are involved.
Unless specifically noted, nothing in this document should be taken to conflict with the SAML 1.1 specification, or any bindings and profiles referenced within it. Readers are advised to familiarize themselves with those specifications first.
It is assumed that the reader is familiar with both the Radius and SAML protocols.
Broadly speaking, this specification describes a subset of the interactions between a user/client requesting access to a network, an Access Point (AP), a Network Provider Radius Server (R1), some number of intermediate Proxy Radius Servers (PR), a User Home Radius Server (R2), and a SAML Identity Provider (IdP).
Note that in the simplest case R1 and R2 are the same RADIUS server, and there are no intermediate Proxy RADIUS servers; this coresponds to the situation where a user is attempting to access their local campus network. No changes are suggested to the processing done by the intermediate Proxy Radius Servers (PR); consequently, they are not referenced in the descriptions in the remainder of this document.
In some deploy situations, a controller sits between the AP and R1, and the controller initiates and receives the radius messages. This addition does not materially change the flow, however. Consequently, this document will describe the AP as initiating the radius messages.
Note also that the standard SAML Domain Model, and the other SAML profiles, contain a Service Provider (SP) entity. In this profile, R1 performs some of the functions typically performed by the SP in the other profiles (eg querying for SAML attributes). However, there are enough differences in the relationships between the entities in this profile and the other SAML profiles that calling an entity an SP would add more confusion than value.
This profile will not address the conversation between the client and the AP; that remains unchanged. This profile extends the basic RADIUS Access-Request --> Access-Accept flow. Two new optional Radius attributes have been added to the Access-Accept message that R2 builds. This profile will also describe a new flow, between R1 and the SAML IdP at the user's home site.
This profile will not change how proxying is done among a set of Radius servers. Currently, a client connects to an Access Point (AP) using the 802.1x protocol; the AP contains a RADIUS client and sends a Access-Request message to a local RADIUS server (R1). R1 looks, sees that the user is "foo@some.other.edu", knows that "some.other.edu" is R2, and proxies the request to R2 (optionally through some set of intermediate Proxy Radius Servers (PR)).
The AP is an entity that participates in an 802.1x message exchange with a client requesting access to a local network, and initiates a Radius protocol message exchange with a local Radius server in order to authenticate and authorize the requesting user. No changes are being proposed to the messages that APs receive or send.
R1 is a Radius server at the Network Provider site that also functions as a SAML-defined Attribute Requestor [ShibArch]. It accepts Radius protocol messages from a local AP, and optionally proxies them to remote Radius servers. It MAY add a new optional Radius attribute to a Access-Request message, asking R2 to return its new optional Radius attributes. It MAY utilize a SAML protocol binding to send a SAML <samlp:Request> message containing a <samlp:AttributeQuery> element to SAML Attribute Authorities and then process the returned SAML attribute assertions. It MAY use the returned SAML attributes as input to an acccess control decision. Implementations MUST provide for mutual authentication of this exchange, typically relying on SSL/TLS [RFC 2246] or SAML message signatures.
Each R1 entity MUST be assigned a unique identifier, or providerId. The identifier MUST be a URI [RFC 2396] of no more than 1024 characters. Use of an "https" URL for this purpose may be advantageous for metadata publication
R2 is a Radius Server at the User Home site. It accepts Radius protocol messges proxied from R1, and responds with appropriate Radius protocol messages. It MAY add new optional Radius attributes to a Access-Accept response message, one of which could be used as a NameIdentifier value when querying a SAML Attribue Authority. It MUST generate the NameIdentifier value in a manner consistent with Section 3.2.3.
This is an entity that functions as described in Section 2.1.2 of the Shibboleth Architecture [ShibArch].
This entity MUST implement support for the new NameIdentifier elements described in Section 3.2.3.
The following sequence diagram illustrates the set of required and optional interactions among the entities.
In step 1, a client requesting access to a network sends a 802.1x connection/authentication request to an AP. This sequence of messages will, at some point, contain a set of credentials provided by the client; it is highly likely that these credentials will be encrypted using one of the EAP/PEAP defined mechanisms.
In step 2, the AP determines where the Client is to be authenticated and sends a Access-Request message to the appropriate place (R1), the Radius Server at the Network Provider site. This message includes the credentials provided by the client.
In step 3, R1 forwards the Request to the authenticating authority (R2) for the client, and includes its own id by adding a RADIUS attribute that carries the id. It MAY add the optional Radius attribute/value pair requesting that R2 return the Radius attribute/value pairs that would be used to request SAML attributes describing the user.
In step 4, R2 has a dialog with the client, probably using EAP, to authenticate the client. R2 validates the credentials (probably by using a local Authentication Service). If authentication fails, R2 returns a Access-Reject message. If authentication succeeds, R2 can return standard Radius attributes in the Access-Accept message. If the Access-Request message is asking for the new optional Radius attributes, then R2 generates a NameIdentifier value for the user, and returns it and the entityID for the local SAML Attribute Authority.
In step 5, if R1 receives a Access-Reject message, it sends this on to the AP. If R1 receives a Access-Accept message, and the message contains the new optional Radius attributes, then R1 constructs a SAML Attribute Query message whose Subject element contains the NameIdentifier value returned by R2. R1 constructs an SSL/TLS tunnel and sends the SAML Attribute Query message to the Home Site Attribute Authority.
In step 6, The Home Site Attribute Authority validates the <samlp:AttributeQuery> according to the standard Shibboleth profile [ShibArch]; performs standard Shibboleth proccessing; and returns a SAML response message, possibly containing one or more assertions containing SAML attributes that apply to the principal described in the Subject element.
Note: Steps 5 and 6 MUST complete within the time prescribed by the AP's retransmit timers.
In step 7, R1 validates the received SAML response message, and MAY make an access control decision based on the SAML attributes contained in the SAML response message. (The mechanism for implementing policy is outside the bounds of this specification.) R1 returns an appropriate response to the AP.
In step 8, the AP returns an appropriate response to the client.
This is a standard Access-Request and radius-[response] sequence of messages, with the addition of new optional Radius attributes.
R1 MAY insert an optional Radius attribute [DEFINE]into the Access-Request message, asking R2 to return its optional Radius attributes in an Access-Accept message.
If the Access-Request message contains R1's request Radius attribute/value pair, then R2 MAY add two new optional Radius attributes in the Access-Accept message that it is returning:
The NameIdentifier value generated by R2 MUST be opaque and MUST be compatible with the description in Section 3.2.3; neither R1 (or any of the intervening proxy Radius servers) should be able to discover the user's identity directly from the value. See Section 3.2.3.
R1, on seeing an Access-Accept message that it is forwarding to a local AP and which contains the two new optional Radius attributes, executes the SAML Attribute Exchange Profile.
To support out-of-band SAML attribute exchange between R1 and a SAML Attribute Authority, this profile specifies the use of an Attribute Exchange Profile. For SAML 1.1, use the Attribute Exchange Profile described in Section 3.2 of [ShibArch]; for SAML 2.0, use a SAML 2.0 AttributeQuery/Response exchange in accordance with section 6 of [SAMLProf20].These profiles allow a requestor (R1) to create an SSL/TLS tunnel to the Attribute Authority endpoint of an Identity Provider, send a SAML <samlp:AttributeQuery>, and receive zero or more SAML Attribute Assertions in response.
R1, on seeing a Access-Accept message that it is forwarding to a local AP and which contains the two new optional Radius attributes, performs the message exchanges described in this profile.
Note that R1 can decide whether to use SAML v1.1 or SAML 2.0 when requesting attributes, based on the metadata entry for the IdP's entityID.
The NameIdentifier value is created by R2, and used by the SAML Attribute Authority. It MUST have several properties:
A "NameMapping" approach to generating this value similar to the SAML-defined artifact is to:
This new NameIdentifier format MUST be defined as urn:mace:shibboleth:1.0:RadiusNameIdentifier
This profile relies on R2 successfully authenticating the user, with the credentials included with the Access-Request message.
The current Shibboleth Trust Management implementation is described in [ShibTrust]. R1 will have to implement these algorithms.
New NameIdentifier Format -- privacy considerations. The suggested algorithm for the new NameIdentifier format is designed to protect against MITM attacks.
The AA will likely be configured to return no SAML attributes, or an extremely minimal set, in response to an anonymous request. R1 MUST be present in the shared metadata, and must be able to prove its identity, in order to obtain a useful set of SAML attributes.
I refer you to RFC 3579, Section 2.6.3 (Conflicting messages):
Where the encapsulated EAP packet does not match the result implied by the RADIUS Packet Type, the combination is likely to cause confusion, because the NAS and peer will arrive at different conclusions as to the outcome of the authentication.
For example, if the NAS receives an Access-Reject with an encapsulated EAP Success, it will not grant access to the peer. However, on receiving the EAP Success, the peer will be lead to believe that it authenticated successfully.