From the Editors

The REFEDS MFA Profile v1.1

To the MFA Profile reviewers,

First, thank you for taking the time to review and provide feedback for the latest revision to the REFEDS MFA Profile. 

The original REFEDS Multi-Factor Authentication (MFA) Profile was published in June 2017. Since its publication, the R&E community has provided a lot of valuable feedback on how the Profile should evolve to facilitate even wider adoption. Some of them were captured in an updated FAQ. 

This Profile 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. 

Now we need your help: we need you to give us feedback on whether this is the direction you’d like to see the REFEDS MFA Profile evolve. Tell us how well this Profile update reflects your expectation on the profile. 

Read the draft Profile document first. As you review that document, use this document as a companion guide. It should provide some insight into our discussions and rationale for including (or not) certain elements in this update. 

Thank you again. We look forward to hearing from you.

Best regards,

The Profile editors / REFEDS MFA Profile Subgroup

Content

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. 

...

Our current position is that while error handling is an important topic, this detail should be captured in a supplemental implementation guide or FAQ. For example, the following are some general scenarios:

...

.

SP requests REFEDS MFA, IdP understands it but is unable to perform MFA, responds with SAML Authn Assertion with something other than REFEDS MFA value (what happens?)

Earlier Working Material

The following links point to earlier discovery materials the Group compiled to organise/prioritise the Profile revision work.

Recording and Slides from the October 6 2022 REFEDS Community Chat

MFA Profile Priorities - The REFEDS MFA Subgroup recommendations to update the REFEDS MFA Profile.

...