Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Addition of a network transport #1381

Closed
nickmooney opened this issue Feb 29, 2020 · 10 comments
Closed

Addition of a network transport #1381

nickmooney opened this issue Feb 29, 2020 · 10 comments
Assignees
Milestone

Comments

@nickmooney
Copy link

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
Copy link
Author

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
Copy link
Contributor

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
Copy link
Contributor

emlun commented Mar 11, 2020

@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
Copy link
Author

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
Copy link

zbot473 commented Jun 2, 2020

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
Copy link

zbot473 commented Jun 2, 2020

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
Copy link
Contributor

equalsJeffH commented Jun 24, 2020

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
Copy link

zbot473 commented Jun 24, 2020

Ah, that's unfortunate

@equalsJeffH
Copy link
Contributor

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

@emlun
Copy link
Contributor

emlun commented Oct 6, 2022

I believe this is resolved by #1755.

@emlun emlun closed this as completed Oct 6, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants