Addition of a network transport

nickmooney commented 4 years ago

This issue is to track progress on the addition of a network transport, which is mostly happening in FIDO world. Here is a summary of progress so far:

@arnar, @nicksteele and I discussed the issue at the FIDO plenary in Lisbon
Google participants are amenable to the addition of a network transport for after-pairing communication, provided that the initial client/authenticator pairing takes place over a channel that ensures proximity

Our current plan is to submit a PR on top of the caBLE v2 PR, fido-alliance/fido-2-specs#724. Since this PR will be on top of Google's branch, we'll also open an issue on the FIDO2 specs repo.

We are currently hammering out some details of how communication will actually happen via the network transport. We are leaning toward, but not settled on, sticking with the caBLE model of a channel established via Noise handshake that then passes CTAP2 messages.

We hope to have a PR submitted in the next month or so, and will certainly be ready to discuss the transport ahead of the member plenary colocated with the FIDO Authenticate conference.

Please let me know if you have any questions!

nickmooney commented 4 years ago

We have submitted a PR on top of the caBLE v2 PR. Please see this issue on the FIDO 2 specs repo, as well as the PR itself.

The PR has been made against Adam's fork of the fido-2-specs repo since caBLE v2 has not yet landed.

equalsJeffH commented 4 years ago

on 2020-03-11 call, noted that we may need to add another transport enum value. @emlun requested clarification of need for proximity, @nickmooney described the threat model (see minutes).

emlun commented 4 years ago

@nickmooney explained the rationale on the call - thanks! In short, the client and authenticator will set up a cryptographically secured channel for future communications. I think where I got hung up was that I read the "initial pairing" part to mean just a Bluetooth pairing, rather than setting up a cryptographic channel. I think I even described the latter scenario in an earlier draft of #1333.

nickmooney commented 4 years ago

Here are our updated thoughts on the network transport as of early May. This document should explain most of what we're thinking. In short:

caBLE pairing can happen via BLE or mDNS
authenticators may provide a FQDN/port of a network relay during the pairing process
if provided, the authenticator can be contacted via the network relay using the HTTPS protocol outlined in the document

The Network Transport, May 2020.pdf

zbot473 commented 4 years ago

Why does the google chrome flag for caBLE v2 say pairingless?

Also how does one handle the fido:// url scheme? Nevermind, this was in the PDF you sent.

zbot473 commented 4 years ago

Also another question, how do you use gatt to advertise the EID? Are there any libraries (for android at least) or would I have to implement this on my own?

equalsJeffH commented 4 years ago

changed milestone to L3-WD-01 because caBLEv2 https://github.com/fido-alliance/fido-2-specs/pull/724 likely will not be in CTAP 2.1.

zbot473 commented 4 years ago

Ah, that's unfortunate

equalsJeffH commented 3 years ago

on 2021-01-06 call: keep this in-scope. likely addressed at webauthn abstraction layer by adding transport enum member(s).

emlun commented 2 years ago

I believe this is resolved by #1755.

w3c / webauthn

Addition of a network transport #1381