W3C home > Mailing lists > Public > public-webauthn@w3.org > July 2017

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

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

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:38:22 UTC