RE: Eleven comments on " Web Authentication: An API for accessing Public Key Credentials". W3C Working Draft, 5 May 2017

Comments are inline in RED text

From: Denis Pinkas [mailto:denis.w3c@free.fr]
Sent: Monday, July 24, 2017 7:21 AM
To: public-webauthn@w3.org
Cc: Samuel Weiler <weiler@w3.org>
Subject: Eleven comments on " Web Authentication: An API for accessing Public Key Credentials". W3C Working Draft, 5 May 2017


Hello,
I am a member of the OAuth WG and of the SAAG WG. I read the draft notes from the SAAG IETF 99 where a few words
from Sam Weiler (W3C) have been reported:
WebAuthn making good progress. Trying to get more eyes doing privacy and security reviews on specs.
Please get in touch with me if you want to keep our WGs from doing stupid things.
The terms used by Sam are rather odd: "keep our WGs from doing stupid things" and I am wondering why these terms have been used.
If it was simply to draw our attention, the goal has been reached.
So I reviewed the W3C draft "An API for accessing Public Key Credentials" and afterwards I subscribed to this mailing list
in order to post comments. Hereafter I submit eleven comments. There are related to privacy, security but also to usability.

1. The document is hard to read and understand. It does not really describe APIs, but the way to implement every API which may be useful
for an implementer, but not very useful for an API user.
The document is missing to clearly indicate what are the input parameters, the output parameters and the error codes. An overview of all the APIs is missing.
The rational for each API is not indicated. There is no text to indicate the purpose of every API. The quality of the document would need to be improved.
This is still a draft, so things will improve, these are also developer APIs and as we work through these the implementors will comment, if you have specific recommendations pleas open up and issue on each concern.

2. The key point is that using hardware authenticators should be highly recommended ... but this does not mean every Relying Party shall necessarily
be made aware of it.
The Universal 2nd Factor (U2F) Overview FIDO Alliance Implementation Draft 15 September 2016 states in section 8.1:
"In practice, we do not want to prevent other protocol compliant vendors, perhaps even those without any formal secure element,
perhaps even completely software implementations".
The Universal 2nd Factor (U2F) Overview FIDO Alliance Implementation Draft 15 September 2016 also states in section 8:
"So, for example, a financial services site may choose to only accept hardware-backed U2F devices,
while some other site may allow U2F devices implemented in software".
However, this W3 draft as well as the FIDO U2F Raw Message Formats Draft from 15 September 2016 both contradict these two statements.
Using hardware authenticators raises many issues. As soon as hardware authenticators (devices) are being used, a fundamental privacy property
is being lost: full pseudonymity. At least, Relying parties will be able to know which type of hardware device is being used. They will also know
which ones share the same attestation key.
The benefits of using a hardware authenticator should also be to support revocation, but unfortunately with the current approach it is not possible.
In section 4.3 (Registration Response Message: Success) of this document, the text states:
"The signature is to be verified by the relying party using the public key certified in the attestation certificate".
This mandates the use of hardware devices that got an attestation certificate.
However, it was crystal clear that in September 2016, that U2F devices implemented in software were allowed. Unless there is a strong rational
for such a change (and in such a case, it should be clearly indicated and explained), the use of software devices should remain possible.
It should also be remembered that on page 5 of the "FIDO U2F Raw Message Formats", there is the following sentence:
"The exact process of setting up trusted certification authorities is to be defined by the FIDO Alliance and is outside the scope of this document".
At this time, the security properties that the hardware devices should have in order to obtain an attestation certificate are left completely undefined.
So it does not really make sense to mandate the use of hardware devices with undefined common minimum characteristics.
At this time, the exact process of setting up trust relationships with authorities providing the attestation certificates is also left undefined.
An additional document for setting up the trust relationships would need to be written to support hardware authenticators equipped with authorization certificates.
This will add a level a complexity that would not necessarily be beneficial for a wide adoption of the U2F protocol by all the Service Providers.
Let us make the world simple. There should be two flavors of the registration protocol:
(a)   one which demonstrates the use of an hardware authenticator,
(b)   one which does not demonstrate the use of an hardware authenticator.
However, such a proposal has a major implication: the current registration protocol would not work anymore.
In section 4.3 (Registration Response Message: Success) of this W3C draft, the text states:
"The signature is to be verified by the relying party using the public key certified in the attestation certificate".
If there is no attestation certificate, there is no attestation private key and hence the registration message cannot be signed anymore
and thus signature field cannot be verified.
If a fake certificate were being used, then registration could occur (if the relying party was willing to accept it) but without any guarantee
that the client will know the private key corresponding to the public key: proof of possession (PoP) of the private key would not be demonstrated
at registration time. This would be a very bad practice. One of the consequences is that it would be possible to create numerous unused accounts
without even the burden of generating key pairs. This is a door wide opened for denial of service.
The registration protocol would need to be fixed. Two changes would need to be done.
A first change would be the following:
-         when it is not required to demonstrate that an hardware authenticator is being used, the registration message shall be signed
  using the private key associated with the client for the relying party on which the client is willing to register.
At registration time, the client creates a pseudo-random public key pair and a unique pseudonym used as a Client Identifier and
then sends to the Relying Party the public key portion of the key pair as well as the Client Identifier and uses the private key portion
of the key pair to authenticate the registration message. Therefore, it demonstrates proof of possession (PoP) of the private key.
When an hardware authenticator are being used and when it is required to demonstrate that it is indeed being used, the current message description
is usable, ... if some assumptions are made about the properties of the hardware devices. Unfortunately such assumptions are not described
(nor referenced) in the document.
The description of the minimum functional and security properties that are required by the hardware devices should be documented
and referenced in this W3C document.

I think you are confused as we are NOT implementing U2F, we will allow for U2F devices to be used and there have been updates to make this clear

3. In section 4.3 (Registration Response Message: Success) of this document, the text states:
A key handle [length specified in previous field]. This a handle that allows the U2F token to identify the generated key pair.
U2F tokens may wrap the generated private key and the application id it was generated for, and output that as the key handle.
In the W3C draft, the texts states:
This API does not constrain the format or length of this identifier, except that it must be sufficient for the platform to uniquely select a key.
If software devices are allowed or if hardware devices are used but the Relying Parties do not want to know their characteristics,
the size of the key handle cannot be dependant upon the type of the hardware authenticator and therefore the so-called "the key handle"
shall have a fixed length.
A second change would be the following:
-          the key handle shall be a large pseudo-random number with a fixed length.
The key handle does not need to have anything to do with the "wrapping of the generated private key and the application id",
which was one suggested method, but is not mandated in any way in a FIDO specification.
The key handle should be used as a client identifier and the Relying Party will not use this parameter as a Key Handle,
but as a Client Identifier. In order to avoid pseudonyms collisions, a 128 bits random number appears to be sufficient.
The wording "Key Handle" should be changed into "Client Identifier". Its definition should be modified as well.

I think you are confused as we are NOT implementing U2F, we will allow for U2F devices to be used and there have been updates to make this clear

4. The terminology section 3 defines both a "Public Key Credential" and a "Credential Public Key".
With such a wording, the difference is not immediately understandable. The current definitions are as follows:
Public Key Credential
Generically, a credential is data one entity presents to another in order to authenticate the former’s identity [RFC4949].
A WebAuthn public key credential is a { identifier, type } pair identifying authentication information established by the authenticator
and the Relying Party, together, at registration time. The authentication information consists of an asymmetric key pair,
where the public key portion is returned to the Relying Party, which stores it in conjunction with the present user’s account.
The authenticator maps the private key to the Relying Party’s RP ID and stores it. Subsequently, only that Relying Party,
as identified by its RP ID, is able to employ the public key credential in authentication ceremonies, via the get() method.
The Relying Party uses its copy of the stored public key to verify the resultant Authentication Assertion.
Credential Public Key
The public key portion of an Relying Party-specific credential key pair, generated by an authenticator and returned to an Relying Party
at registration time (see also public key credential). The private key portion of the credential key pair is known as the credential private key.
When a client wants to authenticate to Relying Party using public key technology, it creates a key pair and an identifier for that Relying Party.
Hence the credentials are composed of four elements: a Relying Party Identifier, a Client Identifier, a private key and a public key.
So naming the credential a " Public Key Credential" is confusing because it places the emphasis on only one of the four elements, i.e. the public key,
and omits to consider the three main other elements. This creates confusion.
What should be done with these four elements should not be part of the definition, but may be placed in a note or in the main body of the text.
The use of an identifier is not clearly mentioned in the current text.
In the definition of the 4.1. (PublicKeyCredential Interface) an identifier is mentioned in the following way:
This internal slot contains an identifier for the credential, chosen by the platform with help from the authenticator.
This identifier is used to look up credentials for use, and is therefore expected to be globally unique with high probability
across all credentials of the same type, across all authenticators. This API does not constrain the format or length of this identifier,
except that it must be sufficient for the platform to uniquely select a key. (...).
One again, if software devices are allowed or if hardware devices are used but the Relying Parties do not need to know their characteristics,
the size of the key handle shall have a fixed length.
Such an identifier should be sent to the Relying Party and, in order to achieve uniqueness and to be independent of the type of device
(hardware or software), it should be large enough to avoid collisions. In practice, it will be a large random number rather than a local handle
related to the type of device and only used by the client.
The current text under the heading "Public Key Credential" is supposed to refer to RFC 4949. It states:
"Generically, a credential is data one entity presents to another in order to authenticate the former’s identity [RFC4949]."
However, such a wording placed before the reference is not present in RFC 4949.
It is admitted that it is difficult to find a good generic definition for "credential".
Hereafter is a proposal for four definitions: "Client Credential", "Client Identifier", "Credential Public Key" and "Credential Private Key".
Client Credential (or WebAuthn Client Credential)
Generically, a credential contains data used by a client to support one or more types of entity authentication
or/and of data origin authentication mechanisms with a given type of Relying Party. A WebAuthn client credential
is composed of the following four major data elements: a Relying Party Identifier, a Client Identifier, a private signature key
and a public verification key.
Note : At authentication time, the client sends to the Relying Party its Client Identifier and authentication data
and the Relying Party uses that Client Identifier to identify the appropriate client's account and, if that account exists,
it then uses the public key associated with that account to verify that the authentication exchange is well formed and correctly signed.
Client Identifier
The client identifier portion of a Client Credential which is a pseudo random number with a fixed length of 128 bits specific to a given Relying Party.
Note: The client identifier is first used by the client to register to that Relying Party and then after to authenticate to that Relying Party.
Credential Public Key
The public key portion of a Client Credential.
Credential Private Key
The private key portion of a Client Credential.
Note that the title of the document, which currently is "An API for accessing Public Key Credentials" might also need to be reconsidered.
The API is not used to "access" "Public Key Credentials" but to manage and to use client credentials which contains (among various other elements),
in particular a private key and an identifier.
The fact is that the Public Key technology is being used for creating and verifying digital signatures: it is not used for any encryption or decryption purpose.
What about the following new title: "A Client Authentication API using digital signatures" ?
The WG has decided to use CredMan as the top level credential management API, I suggest you read over the the CredMan proposal as we have spent a lot of time in this WG to come to that conclusion and also the names, so far none of the implementors have an issue with the naming chosen

5. Since the text states that "it is expected to be globally unique with high probability across all credentials of the same type, across all authenticators",
it should be noticed that the current definition of a key handle makes that parameter dependent upon the device where the credential is being stored,
There is a use case that is not addressed: in case an hardware device is getting "old" (or its form factor is no more adequate) and new devices exist
with more storage, how the credentials initially stored in one hardware device can be securely transferred into another hardware device ?
Since the size of the handle is dependent upon the type of hardware device, there is no guarantee that the new device will use the same size
for the key handle.
This is an additional argument to use a fixed size in order to make that parameter independent of the characteristics of the hardware device
and to allow, in the future, to define mechanisms able to transfer the credentials from one hardware device into another hardware device.

You are in a territory that is out of scope for this document as xfer of credentials is not part of this charter and it may not be a goal of some of the implementors

6. Several 'management' APIs are missing. Since the memory size of some hardware authenticators may be limited, at some point of time,
the number of registered credentials might exceed the memory capacity of the hardware authenticator. Some kind of garbage collection mechanism
is needed.
To this respect, two dates should be managed:
(a) the creation date of the credential, and
(b) the last time the credential was successful used in an authentication exchange.
Using these two dates, a garbage collection mechanism may be implemented. This is a critical point for allowing the deployment of such a mechanism.
A user friendly name for each target application should also be possible.
Getting a list of the credentials with all their attributes is a fundamental need.
This is a first release of the specification we can’t do everything in the first release so we have taken the approach that smartcards have for years and that is there is a management app that can reset the card if needed, and that is outside the scope of the actual protocol. You are welcome to open new issues for the next level of the document if you so desire and the WG will evaluate these issues

7. Which document(s) should be used to know what will be the "bits on the wire" (i.e. the protocols) for every API that does not have a local behavior ?
The webauthn specification does describe the bits on the wire, this is a protocol specification which the W3C does not really do as a normal things

8. At a security workshop of the OAuth WG held in Zurich in July 2017, there was an interesting presentation from David Basin (Institute of Information Security,
ETH Zürich). He is working on finding weaknesses of security protocols and his talk ended with recommendations.
The slides are available here: https://zisc.ethz.ch/wp-content/uploads/2017/02/basin-securityprotocols.pdf<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fzisc.ethz.ch%2Fwp-content%2Fuploads%2F2017%2F02%2Fbasin-securityprotocols.pdf&data=02%7C01%7Ctonynad%40microsoft.com%7Cf2fcaf0d92dd492a017908d4d2c8cc8b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636365207244826420&sdata=gf5eO%2B0FhCkc5tjY8dyjdX2u4mveIB2EAvUZH2Imubs%3D&reserved=0>
On slides 23, he identified "New principles":
Positional tagging
“Cryptographic message components should contain information that uniquely identifies their origin.
In particular, the information should identify the protocol, the protocol variant, the message number,
and the particular position within the message, from which the component was sent.”
The "bits on the wire" should take into account these principles, in particular the use of an identifier for each "message on the wire"
generated as the result of a given API, so that no message can be confused with another one, in particular if additional messages
are added later on.
This is interesting but out of scope for this WG in general, if David wants to help out here and do some analysis he is very welcome to join the WG and help, otherwise this may be done as part of a particular vendor that is producing a product that wants extra insurance they are doing the right thing.

9. In section "5.3.5.1. Privacy", the two last suggested mitigation cases are against interoperability. It should clearly be indicated
that the demonstration of the use of an hardware authenticator during the registration phase is not required to claim conformance
to this document and if a demonstration is being used only the first method needs to be supported (otherwise interoperability
would be much more difficult to achieve).

Not sure what you are trying to say here as there is no conformance suit or anything to deal with how registration happened, you may be confused with the U2F specifications

10. Privacy is different of security. So it is rather odd to have privacy embedded into security:
5.3.5. Security Considerations
5.3.5.1. Privacy
Please make a "Privacy Considerations" section independent from the "Security Considerations" section.
There will be the standard sections before we go to CR so there will be a Security Considerations section and a Privacy Considerations section

11. Hereafter are two text proposals that would fit into these tow sections:
5.3.5. Security Considerations
The use of the same private key and certificate by hardware authenticators introduces a security risk. If the private key is extracted
using a set of authenticators sharing the same private key, it is possible to create "fake" hardware authenticators using the same private key
and hence indistinguishable from the original authenticators. This would affect the entire set of authenticators sharing the same "group" key.
Thus the demonstration, at registration time, that an hardware authenticator sharing some private key is being used is rather limited.
Furthermore, the sharing of a same private key and certificate by hardware authenticators does not allow to revoke a single hardware authenticator.
5.3.6. Privacy Considerations
The advantages of demonstrating to a Relying Party, at the registration time, that an hardware authenticator is being used should be balanced
with the drawbacks. When such a demonstration is supported, Relying Parties will be able to know the type of authenticator being used and,
in addition, the use of the same private key and certificate by hardware authenticators does not allow to achieve full pseudonymity.
However, when such a demonstration is not done, large pseudo random numbers used as client identifiers allow to achieve full pseudonymity,
since no other information than a random number (used as a client identifier) is disclosed to the Relying Party.

Thank you for your suggested text

Denis

DP Security Consulting SAS. France