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

Here's a proposal for the User Verification Method (UVM) extension as discussed in last week's meeting. This extension supports multi-factor authenticators where multiple factors can potentially be in used in a single authentication instance. The max number of factors that can be reported by the extension is capped at 3 and the choice on which 3 to include, in case >3 factors are used, is left to the authenticator vendor. This of course is an extreme case, usually there will only be one factor used in any single authentication instance. Looking forward to comments.
User Verification Method (UVM) Extension

        Extension identifier

webauthn_uvm



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://w3c.github.io/webauthn/#authenticator> augments the authenticator data with a user verification method extension indicating the authentication factor(s) used to authorize the operation and the type of authenticator protection environment each factor was executing in, as defined below. This extension can be added to attestation statements and assertions.



      Authenticator data

Authenticators can report up to 3 different user verification methods (factors) used in a single authentication instance. To accommodate this possibility the UVM is encoded as an indefinite length CBOR array (type 0x9F) with a maximum allowed length of 3.

                Each data item is in turn a CBOR array of length 3 (type 0x83) with the following data items:

Data Item 1 - 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 (Major type 0).

Data Item 2 - 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 (Major type 0).

Data Item 3 - 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 (Major type 0).

This is repeated for each factor used in the authentication instance.

If >3 factors can be used in an authentication instance the authenticator vendor must select the 3 factors it believes will be most relevant to the Server to include in the UVM.

Servers supporting the UVM extension MUST support a length up to 36 bytes for a 3 factor maximum UVM value.

Example for rawData containing one UVM extension for a multi-factor authentication instance where 2 factors were used:

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 6d -- "webauthn_uvm" UTF-8 string

   9F                                      -- Value 1: CBOR array of indefinite length

        83                                   -- Item 1: CBOR array of length 3

            02                                 -- Subitem 1: CBOR integer for User Verification Method Fingerprint

            04                                 -- Subitem 2: CBOR short for Key Protection Type TEE

            02                                 -- Subitem 3: CBOR short for Matcher Protection Type TEE

        83                                   -- Item 2: CBOR array of length 3

            04                                  -- Subitem 1: CBOR integer for User Verification Method Passcode

            01                                  -- Subitem 2: CBOR short for Key Protection Type Software

            01                                  -- Subitem 3: CBOR short for Matcher Protection Type Software

        FF




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