Update `duo-labs/webauthn` up to `20220122034320`, which is the latest version
we can get without dipping into dependency hell (`etcd` and `opentelemetry` woes
ensue after [2365c59d9f][1]).
`tstranex` could be dropped for a while now (we moved on to WebAuthn-like
interfaces for mocks). `cfssl` was only imported due to what I assume was an
IDE mishap.
I've elected to keep `fxamacker/cbor`, instead of trying to move to
[webauthncbor][2]. fxamacker is solid, past v0, seems more appropriate for
client-side libs and still backs webauthncbor.
There are no updates for `flynn/hid` and `flynn/u2f`.
Release notes for fxamacker/cbor:
https://github.com/fxamacker/cbor/releases/tag/v2.4.0.
[1]: https://github.com/duo-labs/webauthn/commit/2365c59d9fb666cb5f5b6bbae86910632198a8d4
[2]: https://pkg.go.dev/github.com/duo-labs/webauthn@v0.0.0-20220815211337-00c9fb5711f5/protocol/webauthncbor
* Drop tstranex/u2f dependency
* Drop direct dependency to cloudflare/cfssl
* Update fxamacker/cbor/v2 to v2.4.0
* Update duo-labs/webauthn to 2022-01-22
* Fix: Make sure all credentials are set in the user
* Simplify: Drop now unnecessary AuthenticationSelection copy
Wire passwordless registration and authorization into Auth and Proxy APIs, thus
making passwordless logins possible.
API changes are described by RFD 52: Passwordless [1].
#9160
[1] https://github.com/gravitational/teleport/blob/master/rfd/0052-passwordless.md#authentication-api-changes
* Add passwordless settings to Auth protos
* Update generated protos
* Register: Apply DeviceUsage in lib/auth
* Register: Apply DeviceUsage in lib/web
* Login: Generate passwordless challenge
* Login: Allow passwordless authentication
* Wire passwordless in lib/web endpoints
* Make mocku2f passwordless setup a bit nicer
I've opted to keep MFA and passwordless authorization interfaces separate, as
they have slight interface differences, storage needs, and allow for different
use-cases.
LoginFlow, the existing API, is now focused on MFA. A new type,
PasswordlessFlow, provides support for passwordless authorization. Both
implementations are backed by a private loginFlow type, refactored from the guts
of the old LoginFlow, which is a superset of MFA and Passwordless.
All registration use-cases are provided by the existing RegistrationFlow. In
this case the change is simpler, as a single passwordless parameter suffices.
Registration is always performed by a previously-authorized user, so it's
storage interactions remain uniform.
Finally, login methods won't create a WebAuthn ID anymore, instead they rely on
registration to do it. The simplification relies on the fact that user handles
are not mandatory. (They do matter for resident key registration, which does
provide them.)
#9160
* Add verification support to mocku2f
* Support passwordless login on lib/auth/webauthn
* Support passwordless registration on lib/auth/webauthn
* Refactor web ID creation
Attestation allows Teleport admins a manner of control over the devices used for
MFA.
Attestation support for Webauthn works similarly to U2F attestation, but
provides both allow and deny lists for device CAs. The device's attestation
certificate must clear both lists before registration is complete.
Previously-registered devices are not affected (similarly to U2F).
* Better error messages on webauthn/httpserver
* Make mocku2f attestation cert public
* Implement attestation for Webauthn
The toy interface serves a few purposes:
Easy testing of Webauthn login and of interop between CLI and Web
Reference for the actual Web UI implementation
* Add a toy Webauthn web interface
* Use the device type to decide whether to use the App ID
* Small tweaks in server and Js
* Fix webauthncli TestLogin breakage
* Replace Printf with Println
Plug Webauthn registration into the *MFADevice RPC family: AddMFADevice,
DeleteMFADevice and GetMFADevices.
As a consequence, Webauthn authentication and registration become supported by
various other gRPC endpoints that defer authn and registration to the RPCs
above.
Further RPC support and refactors are punted to upcoming PRs.
* Add streaming tests for Webauthn
* Add further login/registration failure tests
* Add Webauthn support for streaming RPCs
* Guard against unexpected second factor type in deletion
Add server-side Webauthn registration logic to lib/auth/webauthn.
This allows both U2F and Webauthn-enabled devices to be registered.
* Implement Webauthn registration
* Add clone warning to Webauthn login
* Handle Webauthn devices on login
Implement the device polling loop for Webauthn devices and apply it to
tsh login.
A separate package, lib/auth/webauthncli, is introduced to hold client-focused
Webauthn logic. The separation highlights the distinction between server- and
client-side code and isolates client-side dependencies from the existing
lib/auth/webauthn.
Includes improved test coverage for TeleportClient.Login (local logins only) and
refactoring of existing code to support Webauthn challenges (PromptMFAChallenge
logic has less branching and U2F device loop extracted and refactored into
lib/auth/webauthncli).
In terms of device compatibility, this is identical to the existing U2F
solution- we are using the same underlying libraries and adapting the CTAP1
responses to Webauthn. This is easy to do and easy to reason about. I'm planning
for a native Webauthn solution, such as libfido2, but that is larger change that
doesn't seem to get us all the way to where we want for now (looking at you,
Touch ID).
* Add transformations and validations to lib/auth/webauthn
* Implement client-side Webauthn login
* Use RunOnU2FDevices in the lib/auth/u2f package
This one is optional: it cuts a bit of the codebase today, but one could
argue that it is safer to keep U2F untouched (up to the point where it
gets removed).
* Use CollectedClientData definition in lib/auth/mocku2f
* Fix data race on auth.Server clock usage
* Add direct test for TeleportClient.Login
* Reply to Webauthn challenges on `tsh login`
Allow login using Webauthn instead of U2F.
Installs with second_factor:on will automatically support Webauthn, generating
challenges for any U2F devices and allowing Webauthn to be used throughout the
entire login process.
Web REST API modified as follows:
Added /webapi/mfa/login/begin (1st login step)
Added /webapi/mfa/login/finish (2nd login step, SSH)
Added /webapi/mfa/login/finishsession (2nd login step, web session)
U2F endpoints deprecated, but support full breadth of MFA login options
(/webapi/u2f/signrequest, /webapi/u2f/certs and /webapi/u2f/sessions,
respectively)
Auth REST API modified as follows:
Added /:version/mfa/users/:user/login/begin (1st login step)
ssh/authenticate and web/authenticate now support Webauthn (2nd login step)
U2F endpoints deprecated, but support full breadth of MFA options as well
(/:version/u2f/users/:user/sign)
RFD: https://github.com/gravitational/teleport/pull/7808.
* Plug Webauthn into MFAAuth protos
* Generate protos
* Make CredentialAssertionResponse json-friendly
* Add Webauthn proto conversions
* Wire Webauthn to auth apiserver
* Wire Webauthn login to web apiserver
* Wire Webauthn to web login
* Add missing license headers
* Delete login_identity_test.go
* Use previously acquired devices on mfaAuthChallenge
* Take U2F App ID literally if it's not a proper URL
* Add direct tests for auth.Server
* Use trace.BadParameter consistently
* Include user name in "failed to authenticate" logs
* Add more login-related tests to auth.Server
Add the necessary logic to perform WebAuthn logins/authentication, including
both necessary steps (named "Begin" and "Finish" after the Duo Labs
API/reference implementation).
Note that the login logic is not yet wired to Teleport, that is to come in a
future PR.
Part of the WebAuthn Support[1] work.
[1] https://github.com/gravitational/teleport/pull/7808
* Vendor duo-labs/webauthn and fxamacker/cbor/v2
* Implement the first step of login
* Implement the second step of login
* Add WebAuthn support for mock U2F devices
* Add tests for the complete login flow
* Be explicit about the default attestation value
* Refactor "appid" into a constant
* Add missing license headers
Add 3 new RPCs for the auth server:
- AddMFADevice
- DeleteMFADevice
- GetMFADevices
All RPCs act on the user calling them, rather than specifying the user
in parameters. It's one less thing to validate and also prevents authz
bugs with one user messing with other user's MFA devices.
Add and Delete RPCs are streaming both ways, to allow MFA using an
existing device (prevents MFA bypass) and a challenge/response
registration used in U2F and TOTP. This approach makes the challenge
bound to the RPC connection and doesn't require backend storage.
Tobiasz Heller