Silent/touchless Authn? clarification of bit 0 in AuthenticatorData

[equalsJeffH]

Originally submitted by: smachani1, on: Monday Oct 05, 2015 at 01:43 GMT

---

Section 4. Authenticator data

re: authenticatorData bit 0. In which case the authenticator will generate a signature without first detecting/verifying user presence via some authenticator specific gesture? Does FIOD 2.0 support silent authentication? If not, I suppose the TUP bit will always be set if an assertion is generated.

[equalsJeffH]

Note also that the abstract at this time (commit master-2b72ddf) states..

Authenticators are responsible for ensuring that no operation is performed without user consent.

..and searching for "consent" reveals several other similar statements. Thus at this time, the webauthn spec does not support the "silent authenticator" notion.

the definition of a silent authenticator is "an authnr that does not prompt the user or perform any user verification".

See also..
https://fidoalliance.org/specs/fido-uaf-v1.0-ps-20141208/fido-glossary-v1.0-ps-20141208.html

https://fidoalliance.org/specs/fido-uaf-v1.0-ps-20141208/fido-uaf-asm-api-v1.0-ps-20141208.html#security-and-privacy-guidelines

The latter features this text..

ASMs SHOULD ensure that applications cannot use silent authenticators for tracking purposes. ASMs implementing support for a silent authenticator MUST show, during every registration, a user interface which explains what a silent authenticator is, asking for the users consent for the registration. Also, it is RECOMMENDED that ASMs designed to support roaming silent authenticators either

o Run with a special permission/privilege on the system, or
o Have a built-in binding with the authenticator which ensures that other applications cannot directly communicate with the authenticator by bypassing this ASM.

[equalsJeffH]

as Vijay says in #199 : I suggest moving this out to a v2 of the spec. For v1 I would focus on the core use case of an interactive user in an active browsing context.

[nadalin]

Use case: development or production machines often need to make API calls to other hosts when the user is not present. A USB device cannot be copied from the machine to another machine, and can provide an additional factor and increased security for the machine to authenticate. While there are other hardware mechanisms for this, U2F devices will be low cost, and developers will already have one.

[nadalin]

Developer running Test Suite
Developer is running a test suite on his PC that is making API calls to a cloud service.
The Developer would like to enhance the security posture and use a second factor when making API calls to the cloud service.
The Developer has previously enrolled his FIDO device with the cloud service, using standard enrolment, and has enabled MFA for API calls.
MFA API calls require the standard cloud service authentication, and FIDO device
The test suite runs the same code a number of times for code coverage, and each time, the code requires a 2F from a FIDO device to make the API call.
The user does not want to touch the U2F device on each invocation of the code in the test suite.

Production Server
A PC is a production server that is making regular API calls to a cloud service.
The admin enrolls the FIDO token with a set of credentials at the cloud service and enables MFA on API calls.
The admin installs the standard credentials on the PC, and inserts the FIDO device into the PC.
The admin launches the application that makes the API calls on the PC, and the application uses the standard credentials and the FIDO device to regularly authenticate with no user present.

In both of these cases, an attacker needs to acquire both the standard cloud credentials and the physical FIDO device to make API calls from a separate machine.

[equalsJeffH]

note that some folks are referring to "silent authn" as "touchless authn".

[rlin1]

Is this already clarified?

[AngeloKai]

From the comment and the current progress of the spec, it seems clear that in the V1 of the spec, the API would not have silent auth capability. I think we can agree that the developer use case that @nadalin laid out, while valid, is not the core use case for the API. To resolve this, I think we will need an all-up discussion about silent auth in V2 of the spec. I propose that we close this issue and make #199 the master issue tracking all discussions of silent authentication.

[AngeloKai]

@equalsJeffH @rlin1 if you disagree, please re-open the issue.