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

Add to sec cons a brief discussion of the sec properties accrued by authnr & client platform proximity #1333

Merged
merged 5 commits into from
Feb 19, 2020

Conversation

emlun
Copy link
Member

@emlun emlun commented Oct 22, 2019

How about something like this?

Fixes #1257.


Preview | Diff

@emlun emlun added this to the L2-WD-02 milestone Oct 22, 2019
@emlun emlun self-assigned this Oct 22, 2019
Copy link
Contributor

@equalsJeffH equalsJeffH left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Overall this seems really good. I was wondering if we need to go into this detail with something aimed at protocol designers, but then we have an extant case (cases?) of folks building on top of webauthn and running directly into these issues. So perhaps we ought to include this, tho a consideration is how much detail to get into. e.g., fig 8 is discussing attacks at authn time, but there's also, say, MITM attacks at "binding" time when the authnr is introduced to the authnr service server. Etc.

index.bs Outdated Show resolved Hide resolved
index.bs Outdated Show resolved Hide resolved
@emlun emlun added the stat:puntable Issue or PR that is candidate to move to a later milestone label Oct 23, 2019
@equalsJeffH equalsJeffH requested review from agl, leshi and equalsJeffH and removed request for leshi October 29, 2019 23:22
Copy link
Contributor

@equalsJeffH equalsJeffH left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, thx @emlun!

@emlun emlun changed the base branch from fignumfollowing-table-too to master October 30, 2019 16:31
@emlun
Copy link
Member Author

emlun commented Oct 30, 2019

Rebased onto master.

@nadalin nadalin requested a review from akshayku October 30, 2019 19:14
@nadalin
Copy link
Contributor

nadalin commented Nov 4, 2019

@akshayku Please review so we can merge this or move it to next WD

@equalsJeffH equalsJeffH removed the request for review from agl November 6, 2019 19:20
@equalsJeffH
Copy link
Contributor

AFAIK @agl doesn't have time in the next 30 min to review this, and it was my thought to have him do so, thus I've removed him from reviewer list, and suggest we land this -- can always revise if necessary in the run-up to WD-03, CR, etc.

@emlun emlun modified the milestones: L2-WD-02, L2-WD-03 Nov 6, 2019
@emlun emlun removed the stat:puntable Issue or PR that is candidate to move to a later milestone label Nov 6, 2019
@agl agl self-requested a review November 6, 2019 20:21
@leshi leshi self-requested a review November 6, 2019 20:21
@nadalin
Copy link
Contributor

nadalin commented Nov 27, 2019

@agl @leshi @akshayku Please review

@agl
Copy link
Contributor

agl commented Dec 6, 2019

I think something like this is valuable but I'm not sure that the current working is quite capturing what I see as the essence. (Or, perhaps nobody else views the essence in the same way, in which case LGTM.)

As currently written, this text emphasises that client and RP enforcement of the RP ID is critical to security. Absolutely agree with this part. Then, in my mind the critical point is that the authenticator (which is the trusted device here, assuming that the phisher controls their own client machine) gets assurances by transmitting over a medium that has limited range. (Direct USB connections have the most limited range, but BLE is still local.)

This ensures that an attacker must have a subverted a device physically close to the authenticator, which is a much higher bar than if the authenticator is willing to communicate across the internet.

@nickmooney
Copy link

I think @agl's concerns are partially addressed by the section that discusses what tradeoffs may be made if the client and the authenticator are not being discussed directly. I still see compelling use cases for authentications where a "proximal" transport isn't possible (and I would argue that proximity is a bandaid, not a guarantee).

It would be reasonable to add some discussion more directly of what the benefits of proximity are; ultimately I think it's a choice that is best left up to implementors equipped with an understanding of the security tradeoffs involved rather than being mandated in any way.

@emlun
Copy link
Member Author

emlun commented Jan 17, 2020

Thanks @agl, that's a very good point and I agree. I've rewritten the section (now much shorter!) with equal focus on both the physical proximity aspect and the direct communication aspect.

@emlun emlun force-pushed the issue-1257-proximity-cons branch 3 times, most recently from 5ed7270 to 43dc06a Compare January 17, 2020 15:28
Copy link
Contributor

@agl agl left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(Your call on whether to add the commas. I know that opinions vary on these things and am fine either way.)

index.bs Outdated Show resolved Hide resolved
Copy link
Contributor

@equalsJeffH equalsJeffH left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, thx @emlun :)

Co-Authored-By: Adam Langley <agl@google.com>
@equalsJeffH equalsJeffH removed the request for review from leshi January 29, 2020 20:07
@equalsJeffH
Copy link
Contributor

on 2020-02-19 call: akshay reports msft looking into using remote SKs to remote desktop and in the desktop do things via webauthn. AGL reports that this use case is supported in chrome remote desktop. threat model remains that an attacker must compromise something nearby the user. Ought to add something to client data when operating in such a scenario. Ie. this PRs language does not preclude remote desktop use cases.

@akshayku akshayku merged commit d54a92a into master Feb 19, 2020
WebAuthnBot pushed a commit that referenced this pull request Feb 19, 2020
… sec properties accrued by authnr & client platform proximity (#1333)
WebAuthnBot pushed a commit that referenced this pull request Feb 19, 2020
… sec properties accrued by authnr & client platform proximity (#1333)
@emlun emlun deleted the issue-1257-proximity-cons branch June 22, 2022 21:51
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Add to sec cons a brief discussion of the sec properties accrued by authnr & client platform proximity
6 participants