| Table of Contents |
|---|
...
From the Editors
The REFEDS MFA Profile v1.1 update continues our effort to make the REFEDS MFA Profile clearer and easier to adopt. With V1v1.1, we focused on clarifying key implementation details and making the Profile usable with multiple messaging protocols (SAML and OIDC), while staying true to the intent of the original Profile. Along the way, we encountered issues that needed to be addressed, but fell outside the scope of this update. This document captures those issues. Where applicable, we also include recommendations for future actions.
Editors Notes
Under Section 1. Introduction
Relationship to institution-specific MFA signalling needs
We included this paragraph to clarify when it is (and isn’t) appropriate to use the identifier defined in this Profile to signal MFA. This will likely need additional explanation in an accompanying FAQ.
Under Section 3. Profile Identifier
Version Numbering for this Update
The MFA Profile editors group (Editors) has chosen Version 1.1 as a tentative version number of this Update. This is a controversial and potentially confusing choice. The primary goal of this update is to clarify the intent of the original REFEDS MFA Profile to make implementation more consistent. In doing so, we have introduced details (e.g., 4.3 Validity Lifetime) that could be interpreted as breaking changes: a current implementation of REFEDS MFA Profile may not satisfy the requirements laid out in this Update.
...
E.g., Fed Operators may need to add an "attestation" process for IdPs to confirm they are complying with the updated version of the Profile (perhaps beyond a certain date).
Ongoing Profile Maintenance and Versioning
Given the rapid changes in the authentication space, we anticipate this Profile will require more frequent attention to ensure it maintains pace with technology changes, evolving threat vectors, and community’s need for strong authentication. The Editors recommend establishing a regular review cycle to update the Profiles as needed. Going forward, the Editors recommend following a versioning scheme where breaking changes - like those included in this update - are clearly signalled by incrementing the Profile’s major version number.
Under Section 4. Authentication Requirements
4.2 Factor Independence
We received this comment from an early reviewer:
...
The editors also considered adding further language around requirements for recovering/resetting individual factors. After much discussion, we concluded that dictating constraints on deployments may unrealistically limit implementations. We thus leave such topics to supporting documentation.
4.3 Validity Lifetime
Note that this section establishes a maximum session length for both the IdP authentication sessions overall and for factor-related sessions such as Duo “Remember Me” option. This is one of the more notable “breaking changes” introduced in this revision.
The WG for now has settled on wording in the profile that seeks to harmonize the treatment of SSO overall and the use of features such as Duo's "Remember Me" cookie with a unified limit of 12 hours. The WG believes that the general tone of discussion has moved beyond making life as easy as possible for end users towards a more security-sensitive posture in general. We are aware this is not consistent with existing practice by some communities and welcome feedback and suggestions on how to deal with the two issues in a way that balances existing practice with security expectations.
Under Section 5. Protocol Specific Bindings
5.1.2 and 5.1.3.3 SAML 2.0 Binding - AuthnInstant and ForceAuthn
A question that comes up frequently in reference to the REFEDS MFA profile is how to respond to “ForceAuthn” - which is a request to “authenticate the presenter directly rather than rely on a previous security context” and to “require explicit user interaction during authentication to the identity provider” (to quote SAML standards material)- when the authentication process involves two completely independent factors. This question often arises around the use of the Duo product (which is pervasively deployed in higher ed) and its “Remember Me” option.
...
Note also, the requirements in section 4.3 define a time limit for how long authentication challenges (including “Remember Me”) meet the profile requirements.
5.2 OIDC 1.0 Binding
The OIDC 1.0 Binding section is brand new to this Profile. There remains a number of outstanding questions to be addressed. We have and are actively seeking input from OIDC experts to help with that effort. Example questions include:
- Implications and usage of the max_age request parameter.
- Use of the acr_values request parameter, which acts as a non-essential claims request (i.e., does not strictly require use of MFA).
Additional Observations
Strong Authentication vs “MFA”
The Editors note that while this Profile specifically references “multi-factor authentication”, the real intention behind the Profile is to signal the need for “stronger authentication”. While signing in with multiple factors is one way to achieve stronger authentication than passwords, alternate “single factor” techniques exist to achieve equivalent strength. The community may wish to reconsider the choice to solely use “MFA” to characterise “strong authentication” in future revisions of this Profile.
Expressing QoA via AuthnContext
It may be worthwhile to produce separate resource/material to expand on the notion of “Quality of Authentication”: explain what it is, why conveying “QoA” is preferable to expressing “method of authentication”, particularly since improving “QoA” is the foundational premise of this Profile.
...
The REFEDS MFA Profile is an example of such a general category.
Error Handling discussions
During the Profile update, the Editors debated at length whether to include error handling instructions in the specification.
...