Re: WebAuthn Spec Status

Hi all,

*A) **Privacy across Relying Parties*

The introduction states:

Additionally, privacy across Relying Parties is maintained; Relying 
Parties are not able to detect any properties,
or even the existence, of credentials scoped to other Relying Parties.

Well, this is not really true for three reasons: the presence of the 
signature counter, the structure of the Key Handle and the use of 
attestation certificates.
These three reasons are detailed hereafter.*
*

*1) Signature counter*

The document is using the wording "signature counter" which is undefined 
in section 3, but which is being used in section 5.1. (Authenticator data).

 From the discussion on the list, it appears that the intent is not to 
have one signature counter for each RP, but a single one, hence this 
parameter will be leaking information.

Worse, the controls defined in section 6.2. "Verifying an authentication 
assertion" do not mention what to do with the "signature counter".
So the benefits, if any, of having such a parameter are not understandable.

 From the discussion on the list, some people wanted to have it 
optional. I would think that it should be possible to have it set to 
zero and not incrementing.
Nevertheless, for those who would like it to be maintained in some 
contexts, its usefulness, if any, should be explained.

In any case, the text should be amended.

*2) Key Handle*

The document is using the wording "Key Handle" which is undefined in 
section 3. Key Handle is simply an identifier of a particular key on the 
U2F device.

The text refers to [FIDO-U2F-Message-Formats] section 4.3. There is no 
definition section is this document, hence "Key Handle" is not formally 
defined in this document.

The only explanations are the following in section 5.1

A *key handle* [length specified in previous field]. This a handle that 
allows the U2F token to identify the generated key pair.


This means that the length is specific to the U2F token. As a 
consequence, a RP might be able to know which users are using a specific 
type of authenticator
provided by some manufacturer or some software provider.

But from a security point of view there is worse: the entropy of this 
parameter is left unspecified and thus collisions between key handles 
issued
by different authenticators are in theory possible.

Since it is too late to change the format of the "Authentication Request 
Message - U2F_AUTHENTICATE", the text should recommend the use of a 
fixed length
and mandate to have a pseudo random number in this field whatever kind 
of generation scheme will be supported by the hardware or software 
authenticator.

This would solve this privacy concern.

*3) Attestation certificates*

Section 5.3.5.1. (Privacy) recognizes that attestation keys may be used 
to track users or link various online identities of the same user together.
The indications about how this may be mitigated is not convincing and 
there is a much simpler alternative which should be considered, as it 
will be explained below.

Four kinds of attestation types are being considered: Basic Attestation, 
Self Attestation, Privacy CA and Elliptic Curve based Direct Anonymous 
Attestation/(/ECDAA/)./

  This kind of approach is likely to be a nightmare for interoperability 
considerations. A RP should not be required to support all options, in 
particular not ECDAA.

Privacy CA is a "school case" which would be very costly to implement. 
Let us consider two cases only that should be mandatory to support both 
by Authenticators and RPs:
Basic Attestations and Self Attestations. Self-attestations have a merit 
since they do not allow to track the users.

Currently it is assumed that hardware authenticators always use Basic 
Attestations while software authenticators always use Self Attestations. 
Let us change this assumption.

Hardware authenticators should be to use, */upon the request from the 
caller/* of the API, *either* Basic Attestations *or* Self Attestations.

In the real world, there are two kinds of RPs: IdPs and SPs (Service 
Providers).

It is useful to use Basic Attestations when talking to an IdP (which 
knows the identity of its user /anyway/). However, it is sufficient in 
most cases to use Self Attestations when talking to a SP.
In the second case, the SP does not need to learn anything about the 
client and cannot learn anything when Self Attestations are being used.

This approach would be a much easier way to mitigate the risk than any 
of the methods that are currently included in the last draft in section 
5.3.5.1.
Furthermore, it does not change the bits on the wires.

Either this should be supported by making a change in the APIs or by 
supporting two "logical authenticators" behind each hardware authenticator
when using the discovery mechanism to know which are the available 
platform authenticators:

     - one would be supporting Basic Attestations, while
     - another one would be supporting Self-attestations.

Going one step further, *when Basic Attestations are being used*, it 
should be noticed that*the current specification does not meet the 
requirements from NIST SP 800-63 A*.


        FIDO hardware authenticators are in the category of
        "Multi-Factor Cryptographic Device Authenticators which should
        follow the requirements from section 5.1.9.1 of NISP SP 800-63A
        which states:


        5.1.9.1 Multi-Factor Cryptographic Device Authenticators

Multi-factor cryptographic device authenticators use tamper-resistant 
hardware to encapsulate a secret key that is unique to the authenticator.


It is possible to address this issue by making a difference between the 
enrollment to a CSP and the enrollment to a SP.

It makes sense to demonstrate possession of a unique private key when 
talking to a CSP, but to address a privacy issue, this shall not be done 
when talking to SPs.
So there should be two variants of the registration protocol :

-for CSPs, using an attestation certificate that is *unique to the 
hardware authenticator*, and

-for SPs, using self-assertions.


Making these two variants would also allow to address *a **requirement 
from NISP SP 800-63B, _that is currently not met_*:


        5.2.1 Physical Authenticators

CSPs SHALL provide subscriber instructions on how to appropriately 
protect the authenticator against theft or loss.
The CSP SHALL provide a mechanism to revoke or suspend the authenticator 
immediately upon notification from subscriber
that loss or theft of the authenticator is suspected.

In the same way, it would solve "the risk of not being able to revoke a 
particular attestation key" as mentioned in section 5.3.5.1,
since this is currently impossible using either Basic Attestations or 
Self Attestations.

*Let us make FIDO hardware authenticators compliant with **NISP SP 800-63 !*

*B) Public Key Credential*

The text is confusing when defining the term "Public Key Credential" in 
section 3. Clarifications are required.

Public Key Credential

Generically, a /credential/ is *data one entity presents to another* in 
order to /authenticate/ the former to the latter [RFC4949] 
<https://w3c.github.io/webauthn/#biblio-rfc4949>.

A WebAuthn /public key credential 
<https://w3c.github.io/webauthn/#public-key-credential>/ is a |{ 
identifier, type }|pair identifying authentication 
informationestablished by the authenticator 
<https://w3c.github.io/webauthn/#authenticator>
and the Relying Party <https://w3c.github.io/webauthn/#relying-party>, 
together, at registration <https://w3c.github.io/webauthn/#registration> 
time.

The authentication information consists of an asymmetric key pair, where 
the public key portion 
<https://w3c.github.io/webauthn/#credential-public-key> is returned to 
the Relying Party <https://w3c.github.io/webauthn/#relying-party>,
who then stores it in conjunction with the present user’s account.


The following questions arise:

 1. what is "identifying authentication information" ? This term is not
    being used elsewhere.
 2. if a /credential/ is truly "data one entity presents to another", it
    is clear that the private key which is one element of the Public Key
    Credential/
    /is not */presented/* to the RP, but only the result of some
    computation made upon some data using the private key. So the
    sentence is incorrect.
    The easiest solution to solve the problem would be to delete it.
 3. is only the credential private keystored in the authenticator or are
    both the credential private keyand the credential public keystored
    in the authenticator ?
    This is unclear since the (non normative) text from the introduction
    states: " A *public key credential is* created and*stored by an
    authenticator*
    at the behest of a Relying Party, subject to user consent".
 4. is the Key Handle part of the authentication information ?
 5. is the RP ID part of the authentication information ?

Section 6 (Relying Party Operations) states:

Upon successful execution of create() or get(), the Relying Party's 
script receives a PublicKeyCredential containing
an AuthenticatorAttestationResponse or AuthenticatorAssertionResponse 
structure, respectively, from the client.


The Relying Party's script receives anAuthenticatorAttestationResponse 
or anAuthenticatorAssertionResponse but not a PublicKeyCredential.
The sentence should be corrected.

It is proposed to revisit the definition of the term "Public Key 
Credential" in section 3 to clarify its concept and its elements.

*C) Token binding*

The draft should make clear upfront that the APIs allow to support of 
TSL Token Binding but does not mandates its support.
There is currently no such information.

The text does not mandate it for the client :

4.7.1. Client data used in WebAuthn signatures (dictionary 
CollectedClientData)

The tokenBindingId member contains the base64url encoding of the Token 
Binding ID that this client uses
for the Token Binding protocol when communicating with the Relying Party.

This can be omitted if no Token Binding has been negotiated between the 
client and the Relying Party.

Unfortunately, it seems to mandate it for the RP.

6.1. Registering a new credential

When registering a new credential, represented by a 
AuthenticatorAttestationResponse structure,
as part of a registration ceremony, a Relying Party MUST proceed as follows:

(...)

4. Verify that the tokenBindingId in C matches the Token Binding ID for 
the TLS connection over which the attestation was obtained.


Item 4 should be corrected, e.g. saying :

4. when Token Binding has been negotiated between the client and the 
Relying Party, verify that the tokenBindingId in C matches
the Token Binding ID for the TLS connection over which the attestation 
was obtained.


For the above reasons, I believe that the last draft should not be 
considered to be mature enough.

*D)* *U**sability
*

The document should also indicate that usability is currently not 
supported using the described APIs : the user has currently no way to 
delete
a subset of the oldest entries, since no date/time is being currently 
associated with aPublic Key Credential//.

Denis


> I agree. The core functionality is close enough that we can get 
> inter-operable implementations, and announcing a movement CR is 
> important to get RPs to start their adoption.
>
> To me, WD-08 appears to be a perfect goal to announce as a Candidate 
> Recommendation.
>
> Cheers,
> J.C.
>
> On Sun, Sep 24, 2017 at 10:43 PM, Alexei Czeskis <aczeskis@google.com 
> <mailto:aczeskis@google.com>> wrote:
>
>     Hi all,
>
>     From my point of view, the spec is pretty much feature complete as
>     we finish of WD-07.
>
>     I propose making WD-08 only about clean-up (no renaming APIs or
>     variables -- just clarifying wording, etc).  Let's make WD-08 the
>     final draft that we then propose to go to CR.
>
>     What do you all think?
>
>     Thanks!
>     -Alexei
>
>     **____****_****__****_****_****_****_****_****_****_****_****_**
>
>     . Alexei Czeskis .:. Securineer .
>
>