1

I've been trying to find the major differences between "U2F" versus "FIDO2" two-factor authentication standards. Reading some of the articles posted by different companies and even the FIDO site itself give the impression that the main work of the FIDO2 standard was the WebAuthn API, and that both U2F and FIDO2 are based on the "CTAP" protocol which at least one source [perhaps not a good one] claimed:

In the same release, FIDO also introduced CTAP2, which is basically the same as U2F but relaxes its requirements to also include mobile devices as acceptable external authenticators.

(Source: https[:]//doubleoctopus[.]com/blog/your-complete-guide-to-fido-fast-identity-online/)

So they're claiming the only thing CTAP2 did was "relax requirements" and the big changes were all in the browser side, i.e. exposing a new WebAuthn interface to JavaScript?

If that's the case then why can't all existing U2F keys be used as FIDO2 authenticators? Rationale:

  1. We had Protocol A which said "you must X/Y/Z and your device can only be a USB dongle" — we called that "U2F".
  2. We introduce Protocol A′ which says "this is Protocol A, still X/Y/Z except now your device can be a USB dongle or a mobile phone". At the same time say "hey btw we're giving websites a way to access to Protocol A′ devices". We called this all "FIDO2".

Now, if the only change [supposedly!] to Protocol A itself was "you're allowed to implement this protocol on mobile devices, now, too" then it would logically follow that any U2F device would be forward-compatible as a FIDO2 device:

  • it already does "X/Y/Z" (because those were required by the old rules too)
  • it already satisfies "must be a USB dongle or a mobile phone" (because the old rules were "must be a USB dongle").

But… not all U2F devices work as FIDO2 devices! For example, the Feitian K13 authenticator supports "FIDO U2F" but not "FIDO2". So the logic above must be incorrect — and I suspect the reason is that CTAP2 made more changes than the "Your Complete Guide to FIDO, FIDO2 and WebAuthn" article claims.

What specifically does the CTAP2 specification include beyond the "U2F" functionality that makes "FIDO2" possible?

natevw
  • 131
  • 5

1 Answers1

1

The specification must encompass all roles in the authentication - including how the authenticator identifies itself - robustly across time (both backwards and forwards compatibility). Designing the protocol to be precise about that is the best way to achieve that robustness.

From https://fidoalliance.org/specs/fido-v2.0-ps-20190130/fido-client-to-authenticator-protocol-v2.0-ps-20190130.html

  • If the authenticator implements CTAP1/U2F, the version information SHALL be the string "U2F_V2", or 0x5532465f5632, to maintain backwards-compatibility with CTAP1/U2F-only clients.

  • If the authenticator ONLY implements CTAP2, the device SHALL respond with "FIDO_2_0", or 0x4649444f5f325f30.

  • If the authenticator implements both CTAP1/U2F and CTAP2, the version information SHALL be the string "U2F_V2", or 0x5532465f5632, to maintain backwards-compatibility with CTAP1/U2F-only clients. CTAP2-aware clients may then issue a CTAP authenticatorGetInfo command to determine if the device supports CTAP2 or not.

In other words, the Feitian K13 can't claim to "support" (be compatible via version information) FIDO2 ... but FIDO2 supports the Feitian K13.

Royce Williams
  • 9,128
  • 1
  • 31
  • 55
  • 1
    Thanks, this is a good lead. So the CTAP2 protocol does make a number of changes and bumps the version information in some cases. https://fidoalliance.org/specs/fido-v2.0-ps-20190130/fido-client-to-authenticator-protocol-v2.0-ps-20190130.html#u2f-interoperability also implies that CTAP1 did not support flexible pubKeyCredParams, or "resident key" or "user verification" options either — and from the general sound of that section the command protocol itself may have been significantly different too! – natevw Apr 07 '21 at 20:56