- From: John Bradley via GitHub <sysbot+gh@w3.org>
- Date: Wed, 06 Sep 2017 16:09:02 +0000
- To: public-webauthn@w3.org
If you look at sec 8.1 of https://fidoalliance.org/specs/fido-u2f-v1.2-ps-20170411/fido-u2f-overview-v1.2-ps-20170411.html#counters-as-a-signal-for-detecting-cloned-u2f-devices The counter in client data is about cloning and not about replay attacks. The above says nothing about verifying the other elements of client data a) the random challenge sent by the origin, b) the origin host name seen by the browser for the web page making the javascript call, and c) [optionally] if the ChannelID extension to TLS is used, the connection's channelID public key (or token bindingID. Those all MUST be validated against the RP's local values for the authentication, or there is no man in the middle/replay protection no matter what you do with counter. It seems strange to call out the counter validation that is a weak signal of credential cloning, but not the others, that do prevent replay. To change the interpretation of counter CTAP needs to change. If that decision is fixing the value or returning a random negative number as a nonce, then we should document the validation rules. I understand Adam's concerns. As documented in the Fido spec I referenced a global counter can leak correlatable information. This is a particular problem when attestation batches are small. The small irony is that devices with attestations are likely far less susceptible to cloning than ones without (generally soft tokens), so perhaps the CTAP WG can find a solution that woks on that front. John B. -- GitHub Notification of comment by ve7jtb Please view or discuss this issue at https://github.com/w3c/webauthn/pull/539#issuecomment-327533618 using your GitHub account
Received on Wednesday, 6 September 2017 16:08:58 UTC