RE: returning a multi-factor authenticator's factor-in-use and protection scheme to the server

Attaching the presentation we discussed in today's meeting. Will send out an updated proposal later this week.

Rahul

From: Vijay Bharadwaj [mailto:vijaybh@microsoft.com]
Sent: Tuesday, August 02, 2016 11:19 PM
To: Anthony Nadalin <tonynad@microsoft.com>; Sarangdhar, Nitin V <nitin.v.sarangdhar@intel.com>; Ghosh, Rahuldeva <rahuldeva.ghosh@intel.com>; W3C Web Authn WG <public-webauthn@w3.org>
Cc: Bakshi, Sanjay <sanjay.bakshi@intel.com>
Subject: RE: returning a multi-factor authenticator's factor-in-use and protection scheme to the server

Thanks, Tony.

About this proposal, I do feel that returning the data proposed here (i.e. type of biometric used) is potentially more valuable to the RP in making risk decisions than an opaque UVI. I wonder if the structure would feel more logical if the current UVI was an "additional data" field after the UVM. Also, should we rename the extension now that it's not just UVI?

From: Anthony Nadalin [mailto:tonynad@microsoft.com]
Sent: Monday, August 01, 2016 12:55 PM
To: Sarangdhar, Nitin V <nitin.v.sarangdhar@intel.com<mailto:nitin.v.sarangdhar@intel.com>>; Ghosh, Rahuldeva <rahuldeva.ghosh@intel.com<mailto:rahuldeva.ghosh@intel.com>>; W3C Web Authn WG <public-webauthn@w3.org<mailto:public-webauthn@w3.org>>
Cc: Bakshi, Sanjay <sanjay.bakshi@intel.com<mailto:sanjay.bakshi@intel.com>>
Subject: RE: returning a multi-factor authenticator's factor-in-use and protection scheme to the server

Lets put this on the agenda for this weeks meeting

From: Sarangdhar, Nitin V [mailto:nitin.v.sarangdhar@intel.com]
Sent: Friday, July 29, 2016 9:41 AM
To: Ghosh, Rahuldeva <rahuldeva.ghosh@intel.com<mailto:rahuldeva.ghosh@intel.com>>; W3C Web Authn WG <public-webauthn@w3.org<mailto:public-webauthn@w3.org>>
Cc: Bakshi, Sanjay <sanjay.bakshi@intel.com<mailto:sanjay.bakshi@intel.com>>
Subject: RE: returning a multi-factor authenticator's factor-in-use and protection scheme to the server

Tony, Vijay

When would the W3C group take this request up for discussion/resolution?
The motivation for the request is very clear based on the following goals:

SG-9. Attestable Properties: A Relying Party must be able to verify the FIDO Authenticator model/type (in order to calculate the associated risk).


Nitin Sarangdhar
Sr. Principal Engineer
(503)-264-6140

From: Ghosh, Rahuldeva
Sent: Tuesday, July 26, 2016 10:27 AM
To: W3C Web Authn WG <public-webauthn@w3.org<mailto:public-webauthn@w3.org>>
Cc: Bakshi, Sanjay <sanjay.bakshi@intel.com<mailto:sanjay.bakshi@intel.com>>; Sarangdhar, Nitin V <nitin.v.sarangdhar@intel.com<mailto:nitin.v.sarangdhar@intel.com>>
Subject: RE: returning a multi-factor authenticator's factor-in-use and protection scheme to the server

Thanks Jeff.

Here's a proposal with the UVI extension updates in brown. This makes the extension a 4 element CBOR array, retains the current byte array based opaque UVI index to support the multiple finger use case that Rolf had brought up and adds 3 new fields for UVM, key and matcher protection from the FIDO registry. This should support the case where factor stays the same and say a different finger is used (UVI value changes) as well as the case where the factor itself changes entirely (UVM/protection type changes). Looking forward to comments.
8.4. User Verification Index (UVI) Extension

        Extension identifier

webauthn_uvi



Client argument

The Boolean value true to indicate that this extension is requested by the WebAuthn Relying Party.



      Client processing

None, except default forwarding of client argument to authenticator argument.



      Authenticator argument

The Boolean value true, encoded in CBOR (major type 7, value 21).



      Authenticator processing

The authenticator<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fw3c.github.io%2fwebauthn%2f%23authenticator&data=01%7c01%7ctonynad%40microsoft.com%7c023ae1d8309a4e643d9f08d3b7f1a524%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=AangZvMYmJ2%2fdcQy8%2brDMcuiPToQvZ0pUmfJOOgMorI%3d> augments the authenticator data with a user verification index indicating the method used by the user to authorize the operation along with the authentication factor used and the type of authenticator protection environment it is executing in, as defined below. This extension can be added to attestation statements and assertions.



      Authenticator data

The UVI is encoded as a 4 element CBOR array (type 0x84).  (this is byte string in current spec)

Element 1 - User verification index (UVI). This is a value uniquely identifying a user verification data record. The UVI is encoded as CBOR byte string (type 0x58). Each UVI value MUST be specific to the related key (in order to provide unlinkability). It also must contain sufficient entropy that makes guessing impractical. UVI values MUST NOT be reused by the Authenticator (for other biometric data or users)..

The UVI data can be used by servers to understand whether an authentication was authorized by the exact same biometric data as the initial key generation. This allows the detection and prevention of "friendly fraud".

As an example, the UVI could be computed as SHA256(KeyID | SHA256(rawUVI)), where the rawUVI reflects (a) the biometric reference data, (b) the related OS level user ID and (c) an identifier which changes whenever a factory reset is performed for the device, e.g. rawUVI = biometricReferenceData | OSLevelUserID | FactoryResetCounter.

Servers supporting UVI extensions MUST support a length of up to 32 bytes for the UVI value.

Element 2 - User Verification Method. This is the authentication method/factor used by the authenticator to verify the user. Available values are defined in the FIDO Registry of Predefined Values, 'User Verification Methods' section. It is encoded as a CBOR unsigned integer (0x1A).

Element 3 - Key Protection Type. This is the method used by the authenticator to protect the FIDO registration private key material. Available values are defined in the FIDO Registry of Predefined Values, 'Key Protection Types' section.. It is encoded as a CBOR 2 byte unsigned short (0x19).

Element 4 - Matcher Protection Type. This is the method used by the authenticator to protect the matcher that performs user verification. Available values are defined in the FIDO Registry of Predefined Values, 'Matcher Protection Types' section. It is encoded as a CBOR 2 byte unsigned short (0x19).

Example for rawData containing one UVI extension

F1 D0                                       -- This is a WebAuthn packed rawData object

81                                          -- TUP and ED set

00 00 00 01                                 -- (initial) signature counter

...                                         -- all public key alg etc.

A1                                          -- extension: CBOR map of one element

    6C                                      -- Key 1: CBOR text string of 12 bytes

        77 65 62 61 75 74 68 6E 2E 75 76 69 -- "webauthn.uvi" UTF-8 string

   84                                       -- Value 1: CBOR array of four elements

        58 20                                   -- Element 1: CBOR byte string with 0x20 bytes

             00 43 B8 E3 BE 27 95 8C             -- the UVI value itself

             28 D5 74 BF 46 8A 85 CF

             46 9A 14 F0 E5 16 69 31

             DA 4B CF FF C1 BB 11 32

        1A 00 00 00 02                      -- Element 2: CBOR integer for User Verification Method Fingerprint

        19 00 04                            -- Element 3: CBOR short for Key Protection Type TEE

        19 00 02                            -- Element 4: CBOR short for Matcher Protection Type TEE




Rahul

From: Hodges, Jeff [mailto:jeff.hodges@paypal.com]
Sent: Tuesday, July 26, 2016 8:12 AM
To: Ghosh, Rahuldeva <rahuldeva.ghosh@intel.com<mailto:rahuldeva.ghosh@intel.com>>
Cc: W3C Web Authn WG <public-webauthn@w3.org<mailto:public-webauthn@w3.org>>; Bakshi, Sanjay <sanjay.bakshi@intel.com<mailto:sanjay.bakshi@intel.com>>; Sarangdhar, Nitin V <nitin.v.sarangdhar@intel.com<mailto:nitin.v.sarangdhar@intel.com>>
Subject: Re: returning a multi-factor authenticator's factor-in-use and protection scheme to the server

On 7/24/16, 11:35 PM, "Ghosh, Rahuldeva" <rahuldeva.ghosh@intel.com<mailto:rahuldeva.ghosh@intel.com>> wrote:
I can send out a change proposal to the UVI extension if we are all ok with this approach.

sure, I'm fine with reviewing such a proposal.

=JeffH