Date: 30 Oct, 2006
Revision 2
1 Introduction
1.1 Notation
2 Architectural Overview
2.1 Constraints
2.2 Access Point (AP)
2.3 R1 (Radius Server)
2.4 R2 (Radius Server)
2.5 Shibboleth Attribute Authority
2.6 Overview of Extended Radius Flow
3 Protocols and Profiles
3.1 Authentication Request and Response
3.1.1 Processing Rules
3.2 Attribute Exchange Profile
3.2.1 Attribute Request
3.2.1.1 Processing Rules
3.2.1.2 Example
3.2.2 Attribute Response
3.2.2.1 Processing Rules
3.2.2.2 Example
3.2.3 NameIdentifier Format
4 Security and Privacy Considerations
5 Outstanding Issues
6 References
6.1 Normative
This specification defines a profile that includes messages and flows from both RADIUS [RFC2865] and SAML v1.1 constructs. This allows a RADIUS infrastructure to obtain attributes describing the requesting user; these atributes can then be used to decide whether or not to grant the user access to the network. The availability of attributes provides the 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.
This profile was written by a Radius novice. My understanding of Radius is described here. Please let me know if there are errors. In addition, this profile likely contains errors when referring to various messages and flows in both the 802.1x protocol and the Radius protocol.
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 Shibboleth 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 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 attributes have been added to the Access-Accept message that R2 builds. This profile will also describe a new flow, between R1 and the Shibboleth 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 Shibboleth-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 attribute to a Access-Request message, asking R2 to return its new optional attributes. It MAY utilize a SAML protocol binding to send a SAML <samlp:Request> message containing a <samlp:AttributeQuery> element to Shibboleth Attribute Authorities and then process the returned attribute assertions. It MAY use the returned 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 attributes to a Access-Accept response message, one of which could be used as a NameIdentifier value when querying a Shibboleth 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 wil be encrypted using one of the EAP/PEAP defined mechanisms.
In step 2, the AP sends a Access-Request message to R1, the Radius Server at the Network Provider site. This message includes the credentials provided by the client.
In step 3, R1 proxies the Access-Request message to R2, the Radius Server at the User Home Site. It MAY add the optional attribute/value pair requesting that R2 return the attribute/value pairs that would be used to request attributes about the user.
In step 4, R2 validates the credentials contained in the Access-Request message (probably by using a local Authentication Service). If authenticaiton fails, R2 returns a Access-Reject message. If authentication succeeds, and the Access-Request message is asking for optional attributes, then R2 generates a NameIdentifier value for the user, and returns it and a url for the local Shibboleth 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 attributes, then R1 constructs a SAML Attribute Query message whose Subject element contains the NameIdentifier value returned by R2. R1 constructs and 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 (including ARP processing); and returns a SAML response message, possibly containing one or more assertions containing 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 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 attributes.
R1 MAY insert an optional attribute [DEFINE]into the Access-Request message, asking R2 to return its optional attributes in a radius-accetp message.
If the Access-Request message contains R1's request attribute/value pair, then R2 MAY add two new optional 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 attributes, executes the Attribute Exchange Profile.
To support out-of-band attribute exchange from a Shibboleth Attribute Authority to R1, this profile specifies the use of the SAML request/response protocol using the <samlp:AttributeQuery> element as defined in [SAMLCore], along with the additional constraints and guidelines defined in this section. Other scenarios involving different actors MAY be supported by the same software components but are beyond the scope of this profile.
R1, on seeing a Access-Accept message that it is forwarding to a local AP and which contains the two new optional attributes, performs the message exchanges described in this profile.
An Attribute Request message is a <samlp:Request> element containing a <samlp:AttributeQuery> element.
The Resource attribute in the Query MUST contain R1's unique identifier. This is used to make up for the lack of an explicit element or attribute in SAML 1.1 to indicate the issuing service provider.
The QUERY MAY contain an AttributeDesignator element defining which attributes should be included in the response.
The Subject element of the SAML Attribute Query MUST contain a NameIdentifier element with a
The Attribute Request MUST be transmitted over an SSL/TLS tunnel. It MUST be sent using a valid SAML protocol binding.
The Attribute Authority MUST verify that the value of the Resource Attribute of the AttributeQuery element is present in the Shibboleth metadata as the entityID value of an EntityDescriptor element. Otherwise, processing must proceed assuming this is an anonymous request.
The Attribute Authority MUST verify that the certificate used to create the SSL/TLS tunnel is associated with the value of the Resource Attribute of the AttributeQuery element.
The Attribute Authority MUST validate the value of the NameIdentifier element:
<Request xmlns="urn:oasis:names:tc:SAML:1.0:protocol" xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion" xmlns:samlp="urn:oasis:names:tc:SAML:1.0:protocol" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" IssueInstant="2006-10-30T15:14:48Z" MajorVersion="1" MinorVersion="1" RequestID="_4537920a31a07d5eb99f6300d22f5352">
<AttributeQuery Resource="https://radius.brown.edu/">
<Subject xmlns="urn:oasis:names:tc:SAML:1.0:assertion">
<NameIdentifier Format="urn:mace:shibboleth:1.0:RadiusNameIdentifier" NameQualifier="https://radius.brown.edu/">_646ed774da0de695d9533aa6a63e4b75</NameIdentifier>
</Subject>
</AttributeQuery>
</Request>
An attribute response is a <samlp:Response> element containing a <samlp:Status> element and zero or one <saml:Assertion> elements. The assertion, if present, should contain only attribute statements. The Issuer attribute of the assertions MUST be set to the unique identifier of the identity provider whose attribute authority is issuing the assertion.
The Attribute Authority MUST perform the Shibboleth AA's normal ARP processing.
The Attribute Authority MUST place the providerid of R1 in the Audience element.
The Attribute Authority MUST filter the set of Attributes it places in the response using the AttributeDesignator element in the Query.
R1 MUST validate the retturned Attribute Response using standard Shibboleth algorithms.
<Response xmlns="urn:oasis:names:tc:SAML:1.0:protocol" xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion" xmlns:samlp="urn:oasis:names:tc:SAML:1.0:protocol" InResponseTo="_c3747c1bac71ebf53b72959fe07cce1b" IssueInstant="2006-10-25T21:00:08.136Z" MajorVersion="1" MinorVersion="1" ResponseID="_03ce8243753f50a008cd1ead8ab48e9c"> <Status> <StatusCode Value="samlp:Success"> </StatusCode> </Status> <Assertion xmlns="urn:oasis:names:tc:SAML:1.0:assertion" AssertionID="_813f3f8ebe7b6f3c0466a1e72e465fa6" IssueInstant="2006-10-25T21:00:08.136Z" Issuer="urn:mace:inqueue:example.edu" MajorVersion="1" MinorVersion="1"> <Conditions NotBefore="2006-10-25T21:00:08.136Z" NotOnOrAfter="2006-10-25T21:30:08.136Z"> <AudienceRestrictionCondition> <Audience>https://radius.brown.edu/</Audience> </AudienceRestrictionCondition> </Conditions> <AttributeStatement> <Subject> <NameIdentifier Format="urn:mace:shibboleth:1.0:nameIdentifier" NameQualifier="urn:mace:inqueue:example.edu">_2baf2994ce810d8c910d517467d3ef39</NameIdentifier> </Subject> <Attribute xmlns:typens="urn:mace:shibboleth:1.0" AttributeName="urn:mace:dir:attribute-def:eduPersonEntitlement" AttributeNamespace="urn:mace:shibboleth:1.0:attributeNamespace:uri"> <AttributeValue xsi:type="typens:AttributeValueType">urn:mace:example.edu:exampleEntitlement</AttributeValue> <AttributeValue xsi:type="typens:AttributeValueType">urn:mace:incommon:entitlement:common:1</AttributeValue> </Attribute> <Attribute xmlns:typens="urn:mace:shibboleth:1.0" AttributeName="urn:mace:dir:attribute-def:eduPersonScopedAffiliation" AttributeNamespace="urn:mace:shibboleth:1.0:attributeNamespace:uri"> <AttributeValue Scope="example.edu" xsi:type="typens:AttributeValueType">member</AttributeValue> </Attribute> </AttributeStatement> </Assertion> </Response>
The NameIdentifier value is created by R2, and used by the Shibboleth 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 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 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.