RE: Proposal: Chrome privacy CA

Denis, I don’t have an answer for you on where to go, I know this will be continued to be discussed in FIDO.

From: Denis Pinkas [mailto:denis.w3c@free.fr]
Sent: Friday, November 10, 2017 3:40 AM
To: Anthony Nadalin <tonynad@microsoft.com>; Adam Langley <agl@google.com>
Cc: W3C Web Authn WG <public-webauthn@w3.org>
Subject: Re: Proposal: Chrome privacy CA

Anthony, you said :
OK, This WG is not here to discuss the merits or the design of a Privacy CA, if there are certain changes needed to WebAuthn
to allow a particular attestation type to be used then let’s have that discussion otherwise we should take this discussion elsewhere.

I wonder where we could take this discussion elsewhere. My company is not a member of the FIDO Alliance so cannot participate
to the discussions restricted to FIDO Alliance members.

The following address https://groups.google.com/a/fidoalliance.org/forum/#!forum/fido-dev<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgroups.google.com%2Fa%2Ffidoalliance.org%2Fforum%2F%23%2521forum%2Ffido-dev&data=02%7C01%7Ctonynad%40microsoft.com%7C07e6648dbd05435d838f08d5282fd077%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636459108192053964&sdata=4p8usA16GKVB7foatHdu%2BF1lfd%2F2M7w52v2t3G8OkWg%3D&reserved=0>
"is not designed to suggest technical changes to the base FIDO specifications".

However, if you have another address to continue this discussion, please indicate it to me.

In the mean time, the topics raised in this thread are quite important. The more options we have for the Attestation Types (section 5.3.3)
the less interoperability there will be and the more fragmentation there will be.

"Privacy CA" and "Elliptic Curve based Direct Anonymous Attestation (ECDAA)" introduce an additional level of complexity that was not originally
present in the FIDO specifications. It cannot be expected that all RPs shall support it and hence this would lead to market fragmentation.
Furthermore, the Privacy CA model would allow a third party to gather information that could be used to take some benefits of that information.
If several third parties would implement the Privacy CA model, this would lead to further market segmentation.

Dropping the "Privacy CA" and "Elliptic Curve based Direct Anonymous Attestation (ECDAA)" types would be reasonable
and this would leave us with Basic Attestation and Self Attestation.

The API draft states in section 5.3.3 for the Basic Attestation:
authenticators of the same model often share the same attestation key pair.
It does not state:

          authenticators of the same model must share the same attestation key pair.

This means that :

         hardware authenticators of the same model MAY or MAY NOT share the same attestation key pair.

Considering the argumentation sent on this thread to make a difference between "RPs that need to know whether an authenticator
conforms to some security and functional requirements" and "RPs that don't need to know whether an authenticator conforms to
some security and functional requirements" this would lead to the following rephrasing in section 5.3.3 for the Basic Attestation:

Basic Attestation

In the case of basic attestation, the authenticator’s attestation key pair is either unique to a specific hardware-backed U2F device
or shared by a batch of hardware-backed U2F devices. RPs that care about the properties of the authenticator and are able
to check these properties typically use this attestation type.
In the same way, this would lead to the following rephrasing in section 5.3.3 for the Self-Attestation:
Self Attestation

In the case of self attestation, the Authenticator uses the authentication key itself to create the attestation signature.
RPs that do not care about the properties of the authenticator or are unable to check these properties typically use this attestation type.

This is directly related to the compliance or the non-compliance of hardware authenticators with NISP SP 800-63 raised in this thread
which is in itself also an important topic.

Finally, the current API draft states in section 5. WebAuthn Authenticator model:
"Each authenticator has an AAGUID, which is a 128-bit identifier that indicates the type (e.g. make and model) of the authenticator.
The AAGUID MUST be chosen by the manufacturer to be identical across all substantially identical authenticators made by that manufacturer,
and different (with probability 1-2-128 or greater) from the AAGUIDs of all other types of authenticators".
I have difficulty to understand how a U2F device implemented in software can construct such a AAGUID.

The Universal 2nd Factor (U2F) Overview. FIDO Alliance Implementation Draft 15 September 2016 states:
"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.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".
Should I understand that the use of U2F devices implemented in software is no more supported ?
Clarifications would be welcomed.

Denis



From: Denis Pinkas [mailto:denis.w3c@free.fr]
Sent: Thursday, November 9, 2017 2:29 AM
To: Adam Langley <agl@google.com><mailto:agl@google.com>
Cc: W3C Web Authn WG <public-webauthn@w3.org><mailto:public-webauthn@w3.org>
Subject: Re: Proposal: Chrome privacy CA

Hi Adam,
On Wed, Nov 8, 2017 at 9:02 AM, Denis Pinkas <denis.w3c@free.fr<mailto:denis.w3c@free.fr>> wrote:
By default, self-attestations should be used. So nothing at all would be given away. This is what comes out when you apply "Privacy by Design" and "Privacy by Default" rules.

By "self-attestation" I'm assuming that you have in mind that the private key itself signs the registration data, as opposed to some attestation key in the token. This would show possession of the private key.

However, no U2F device that I'm aware of does this and the CTAP2 spec doesn't have this either, I think. So, while I'd be very happy for tokens to do that by default, that ship may have sailed.

But we might agree that privacy by default makes sense. Our requests (2) and (3) say that, by default, RPs should not get attestation data. In that case, no information need be sent to any Privacy CA.

You say that "by default, RPs should not get attestation data". I am not sure how to interpret this sentence.
An attestation is always needed, either a certificate attestation (where currently a batch of hardware tokens share the same private key)
or a self-attestation (where a self-signed certificate is generated using the private key used to open the account).
This means that the RP must always get and verify attestation data.




Revocation of a specific token is currently impossible in FIDO since all RPs are considered to be equal. If you remove this equality, then a new bunch of possibilities emerges.
So saying that is is a "non-goal of FIDO" may not be an appropriate statement. From a functional point of view, it would be nice to be able to revoke a specific token
and this is possible as soon as you introduce a distinction between :

  *   RPs that need to know whether an authenticator conforms to some security and functional requirements,
and in this case the use of an attestation certificate will be required.
  *   RPs that don't need to know whether an authenticator conforms to some security and functional requirements,
and in this case the use of an self-signed certificate will be required.
This means that a given hardware token should be able either to generate a self-signed certificate or to use its attestation certificate upon the request from the client.

I think we're in agreement there, although we do have to deal with the existing population of tokens in the world. Thus we're asking for a flag from RPs to indicate which of those two groups that they're in (point #5) and we'll have Chrome generate a dummy attestation certificate for RPs that don't care about requirements. That's not as good as having the token sign the registration message with the registration private key, but it's the best that we can do with the current population of tokens.

It is not a good way at all to solve the problem. By doing so, you introduce an easy way to create a bunch of dummy registrations,
because at the time of the registration you do not even know that the user is knowing the private key corresponding to the public key that is being registered.
In other words, you do not have any PoP (Proof of Possession of the private key) at registration time. Adding a signature of the registration message
with the private key would be the smartest and the simplest way to correct the problem rather that, as currently, asking to create a self-signed certificate
to keep a single profile for the registration protocol.



If CTAP2 were to define a "no-op" attestation form that tokens would use on request, we would happy with that.




Hardware authenticators do not last for ever. Since current hardware authenticators are unable to support revocation,
it may be time to think of an architecture able to support revocation. My proposal paves the way for such an architecture.
The topic of the Webinar of the FIDO Alliance from Wednesday, September 20, 2017 was : "NIST 800-63 Guidance and FIDO Authentication".

The agenda was:

  *   Introduction/Updates on FIDO Alliance
  *   Overview of NIST 800-63-3
  *   Exceeding NIST Guidance with FIDO Authentication
One of the speakers was Paul Grassi, Senior Standards and Technology Advisor, NIST.
According" to NISP SP 800-63A, FIDO hardware authenticators are in the category of "Multi-Factor Cryptographic Device Authenticators".
However currently FIDO authenticators do not comply with a requirement 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.
FIDO authenticators do not encapsulate a private key that is unique to the authenticator but to a batch of authenticators.
FIDO authenticators do not comply either to another requirement from section 5.2.1 of NISP SP 800-63B which states:
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.

If revocation is "a non-goal" for FIDO authenticators, is it reasonable to claim at the same time that FIDO authenticators are exceeding NIST Guidance ?

Both within an enterprise environment and in an Internet environment revocation is an important concern. It is time to address and to solve this issue.




If you want to remain compatible with the current situation, you always request the use of an attestation certificate, ... if some way or another
you know that the same certificate is being used for a batch of at least 100K tokens. BTW, today there is no mean being defined to know whether the attestation certificate
applies to a single token or a batch of tokens.

Making the distinction between two kinds of RPs opens the door to new possibilities, in particular, the revocation of a specific token.



That is a balance between the wider interests of common users (who do not wish to have a tracking token) and the interests of closed, enterprise deployments,
who might like to be able to identify specific tokens, track them in inventory systems etc.

The balance is simply not between two parties (common users and RPs) but between three parties :

  *   common users,
  *   RPs that need to know whether an authenticator conforms to some security and functional requirements, and
  *   RPs that don't need to know whether an authenticator conforms to some security and functional requirements.
Item #5 in our requests attempts to reconcile this a little differently and envisions a signal to tokens that they are being used in a context where individual attestation is appropriate, and might thus return a different, unique attestation certificate.

By default, the use of an attestation certificate (whether unique or shared) would be inappropriate. By exception (i.e. upon request), it would be.



In Chrome, that signal would be wired up to our enterprise policy to allow administrators to enable direct attestation for enumerated RP IDs.

FIDO is intended to be usable on the Internet, I mean not only within an enterprise environment.
Within an enterprise environment the added value of FIDO will be "ease of use" and "security", it will not be "privacy".
Within an enterprise environment privacy is not the major concern, but on the Internet it is.

I do not object to any of that. While I don't think tokens should use individual attestation certificates by default (because not all browsers will use a Privacy CA in all likelihood), we've no problem with them doing so when signalled that they're in an enterprise environment.

Coming back to the Privacy CA proposal, you postulate that many consumers services in reality don’t care about provenance of authenticators. That's true.

You also consider that, "in enterprise environments, there are usually the need for a much stricter enforcement of authenticator types
and as such it is important in these cases for the device to disclose information about itself to the RP". I would not phrase this this way,
but I would say that some RPs (whether or not in an enterprise environment) need for a much stricter enforcement of authenticator types.

So the requirement is not necessarily associated with the enterprise environment.

You are trying to find a solution for hardware authenticators that are not compliant with NISP SP 800-63.

I am proposing a solution for hardware authenticators that would be compliant with NISP SP 800-63.

Since the functionalities of the Google Private CA are going to remain private and non verifiable by independent parties,
the information that could be gathered, as well as its use, is going to be unknown. This is a serious concern.

If the Privacy CA were being deployed, this would introduce a Big Brother component into the FIDO architecture.
Such a component should be and can be avoided.

If the project was going anyway to proceed, at the minimum, the drawbacks of the approach should be mentioned in the proposal.
Denis



Cheers

AGL