"convenient reauthentication UX" vs. "phishing-resistant 2nd factor"

[maxhata]

Naming of "convenient reauthentication UX" vs. "phishing-resistant 2nd
factor" is misleading and should be changed, to start with.

The naming is used to contrast the difference between Platform and
Roaming authenticators. "phishing-resistant" is used for roaming
authenticators.

Here is the problem.

When you say roaming authenticators are "phishing-resistant", it gives an
implication that platform authenticators are not. This is very
misleading.

The difference of platform and roaming authenticators cannot/should not
be characterized by being resistant to phishing or not.

If you register a platform authenticator in addition to passwords,
allowing the OR model and leaving passwords alive, then it is not
phishing resistant.

This is the same for security keys.

Thus the being phishing resistant is not due to being platform or
roaming, but how you logically put it with respect to passwords, i.e., OR
or AND. If you use the AND structure, both platform and roaming
authenticators are phishing resistant. If you use OR structure, neither
platform nor roaming authenticators are phishing resistant.

---

More important issue that seems to be missing when characterizing platform
and roaming authenticator is "locking out" users from account.

If you use AND structure for platform authenticator and if the user has
not yet registered an additional roaming authenticator, the user is locked
out where the user has no other way to log in without the platform
authenticator. So if the user loses the platform authenticator, RP must
take them into friction of account recovery operation.

If this is the case for roaming authenticator, user is not locked out.

So, as Shane's "How to FIDO" POC is implementing,
https://howtofido.securitypoc.com/

This paper should stress the following points, instead of being phishing
resistant or not, in relation to platform authenticators.

• describe this lock out problem in detail due to only one platform
  authenticator; introduce the OR and AND models and discuss phishing
  resistance w.r.t. the two models.
• recommend not to allow registering a platform authenticator into the
  AND model until RP knows that the user has registered at least one
  roaming authenticator, so that lock out will not happen. Until then,
  recommend staying with the OR model (users can log in with password or FIDO), with a caution
  that it may not be phishing resistant but it is for convenience to help users due to, e.g., use of built in biometrics.

[j-hayakawa]

Regarding the "Capabilities of authenticator", I wonder about the lack of phishing-resistance in the Platform.

Referring to Chapter 6, I assume that the background to this is user lockout, i.e., whether or not you can bootstrap other devices. That needs to be clarified.

First, let's look at the characteristics of the Authenticator

• PFA: Platform Authenticator
  • The Authenticator is built into the device
  • You can only sign in with your registered device.
  • Can't Bootstrap other devices
• RA: Roaming Authenticator
  • The Authenticator is separated from the device
  • You can sign in with your connected devices
  • I can bootstrap other devices.

Secondly, in terms of User Lock-Out, i.e., would you be unable to Bootstrap other devices, there is a risk of that with only PFA registered.
On the other hand, since PFA and RA are not exclusive and can coexist, User Lock-out can be avoided by combining them.
The following is a transition image from the initial state.

Thus, with only the PFA registered, it becomes User Lock-out, which requires leaving other Bootstrap methods, such as passwords, in place. This is why we believe that the situation is not resistant to phishing.

I think adding the above background information will help the reader to understand it better.

[sbweeden]

Feel free to submit a PR to the wording for consideration.

[maxhata]

Created a new PR on this:

#21