A RADIUS Attribute, Binding, Profiles, Name Identifier Format, and Confirmation Methods for the Security Assertion Markup Language (SAML)
Extracted elements (30)
A digitally signed SAML request alone is insufficient to establish the identity of the RP because a malicious RADIUS entity could relay the SAML message in a different RADIUS exchange without the original issuer's consent; the RADIUS client identity must therefore be confirmed via trusted metadata or a signed message containing that identity.
The ABFAB Authentication Profile intentionally prohibits HTTP-based bindings, requires all SAML messages to use the SAML RADIUS binding, forbids naming the Subject in AuthnRequest, and restricts responses to a single assertion with exactly one authentication statement — all to reduce the number of bindings implementations must support and simplify interoperability.
A successful <samlp:Response> in the ABFAB Authentication Profile MUST contain exactly one assertion; that assertion MUST contain a <saml:AuthnStatement> and a <saml:SubjectConfirmation> with a cm:user or cm:machine confirmation method. The InResponseTo attribute MUST match the request ID when the response is solicited.
IdPs SHOULD return a RADIUS State attribute as part of the Access-Accept message so that future SAML queries or requests can be correlated to the same authentication exchange context.
If SAML metadata is used with this binding, the RADIUS IdP and RADIUS RP roles described in Section 4.3.3 (RADIUSIDPDescriptorType and RADIUSRPDescriptorType) MUST be present.
Implementations of the SAML RADIUS binding MUST support a default configuration that does not require the use of XML signatures, though implementations MAY choose to use them.
In the ABFAB Assertion Query/Request Profile, the RADIUS Access-Request MUST include a Service-Type attribute with value Authorize-Only, and SHOULD include the RADIUS State attribute when the query pertains to a previously authenticated client.
In the ABFAB Authentication Profile, the RP MUST NOT include a <saml:Subject> element in the <samlp:AuthnRequest>; the authenticated RADIUS identity alone identifies the client to the IdP.
In the request-response model, the RADIUS Access-Request MUST include exactly one RADIUS User-Name attribute whose value MUST conform to the Network Access Identifier (NAI) scheme, and the RP MUST NOT include more than one SAML request element.
In the unsolicited assertion model, the SAML-Assertion attribute MUST be included in a RADIUS Access-Accept message and MUST contain a single SAML Assertion; RADIUS servers MUST NOT include both SAML-Protocol and SAML-Assertion in the same RADIUS message.
RADIUS entities MUST NOT include both the SAML-Assertion and SAML-Protocol attributes in the same RADIUS message; they represent exclusive alternatives for conveying SAML information.
The IdP MUST establish the identity of the client using a RADIUS authentication method. If ForceAuthn is present and true in the AuthnRequest, the IdP MUST freshly authenticate rather than relying on existing session state.
The RADIUS exchange underpinning the SAML RADIUS binding MUST be protected using TLS encryption for RADIUS (RFC 6614) to provide confidentiality and integrity, unless alternative methods such as IPsec tunnels or a sufficiently secure internal network are used.
The RP MUST treat a client identifier in a SAML <Subject> element as taking precedence over the identifier in the RADIUS User-Name attribute, and MUST discard any assertion whose subject confirmation requirements cannot be met.
When processing an Assertion Query/Request, the IdP MUST give precedence to the client identifier implied by the RADIUS State attribute over any identifier implied by the SAML request's <Subject>.
Attributes released by an IdP — even generic affiliation attributes shared across many clients — can enable client re-identification or cross-session and cross-RP linkage. The profiles do not provide a client-facing mechanism to express release preferences; such preferences must be expressed out of band.
IdPs MUST apply policy to decide what information is released to a particular RP. When RADIUS proxies are used without TLS encryption, SAML Assertions containing potentially identifying attributes are visible to all intermediate proxies, representing a significant privacy exposure that must be carefully evaluated.
The NAI Name Identifier Format (URN: urn:ietf:params:abfab:nameid-format:nai) indicates that a SAML name identifier element contains a Network Access Identifier using the syntax defined in RFC 7542.
The SAML-Assertion RADIUS attribute (Type 245, Extended-Type 1) encodes a SAML Assertion using the Long Extended Type format defined in RFC 6929, accommodating the typical large size of SAML structures.
The SAML-Protocol RADIUS attribute (Type 245, Extended-Type 2) encodes a SAML protocol message using the Long Extended Type format, enabling transport of SAML request/response messages over RADIUS.
The SAML RADIUS binding (URN: urn:ietf:params:abfab:bindings:radius) defines how RADIUS can transport SAML Assertions and protocol messages, supporting two system models: a request-response model using SAML-Protocol and an unsolicited assertion model using SAML-Assertion.
Two new SAML metadata role types extend SAML's RoleDescriptorType: RADIUSIDPDescriptorType (carrying RADIUSIDPService endpoints and RADIUSRealm values) and RADIUSRPDescriptorType (carrying RADIUSRPService, RADIUSNasIpAddress, RADIUSNasIdentifier, and RADIUSGssEapName elements).
Two RADIUS State confirmation method identifiers are defined: urn:ietf:params:abfab:cm:user and urn:ietf:params:abfab:cm:machine. Each indicates the subject is a previously authenticated entity identified by the RADIUS State attribute of a prior Access-Accept message.
IANA created a new top-level registry 'Application Bridging for Federated Access Beyond Web (ABFAB) Parameters' with a sub-registry 'ABFAB URN Parameters' (registration via IETF Review or Expert Review). Initial registrations include bindings:radius, nameid-format:nai, profiles:authentication, profiles:query, cm:user, and cm:machine.
IANA registered the 'abfab' URN sub-namespace within the IETF URN sub-namespace for protocol parameters (RFC 3553). Sub-parameters MUST be specified in UTF-8 using standard URI encoding.
IANA registered two new RADIUS long extended attributes: SAML-Assertion (Type 245, Extended-Type 1, Length>=5) and SAML-Protocol (Type 245, Extended-Type 2, Length>=5), placed in the RADIUS types registry at iana.org/assignments/radius-types.
The RP MUST trust SAML messages from the IdP to the same degree as RADIUS attributes, relying on the RADIUS infrastructure for integrity. The RP MUST also apply policy to filter information based on what the IdP is permitted to assert and the level of trust placed in any intermediate proxies.
XML signatures and encryption are provided as an OPTIONAL end-to-end security mechanism that protects SAML messages from modification by RADIUS proxies. They are appropriate when end-to-end security is required but proxies cannot be removed, or when SAML messages must be verifiable after the authentication exchange.
SAML-Assertion attribute: Type=245, Length>=5, Extended-Type=1, M (More) bit as per RFC 6929, Reserved field as per RFC 6929, followed by one or more octets encoding the SAML Assertion.
SAML-Protocol attribute: Type=245, Length>=5, Extended-Type=2, M (More) bit as per RFC 6929, Reserved field as per RFC 6929, followed by one or more octets encoding a SAML protocol message.