- From: Denis Pinkas <denis.w3c@free.fr>
- Date: Mon, 24 Jul 2017 16:21:17 +0200
- To: public-webauthn@w3.org
- Cc: Samuel Weiler <weiler@w3.org>
- Message-ID: <4f199309-c933-cac2-2d61-dd33af79d2d4@free.fr>
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.
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.
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.
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. (PublicKeyCredentialInterface)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" ?
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.
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.
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 ?
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
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.
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).
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.
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.
Denis
DP Security Consulting SAS. France
****
*
*
Received on Monday, 24 July 2017 19:18:08 UTC