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

Hi Rahul,

 

one comment:  I would expect arrays tob e used to encoding a dynamic number
of elements having the same semantics.

More specifically it means the “outer” array is what I think we should have.

  82                                      -- Value 1: CBOR array of length 2
indicating two factor usage

But the “inner” array 

       83                                   -- Item 1: CBOR array of length
3

Should be a “struct” in my opinion (so just a concatenation of elements or a
map of elements with their respective meaning (being userVerificationMethod,
matcherProtectionType, keyProtectionType).

 

Kind regards,

   Rolf

 

Von: Ghosh, Rahuldeva [mailto:rahuldeva.ghosh@intel.com] 
Gesendet: Dienstag, 9. August 2016 06:14
An: 'W3C Web Authn WG'
Cc: Bakshi, Sanjay; Sarangdhar, Nitin V
Betreff: RE: returning a multi-factor authenticator's factor-in-use and
protection scheme to the server - UVM extension proposal v2

 

Updated UVM extension proposal with fixed length array as per Vijay’s
suggestion:

 


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  <https://w3c.github.io/webauthn/#authenticator> 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 CBOR array (major type 4) with a maximum
allowed length of 3 -
Type 0x81 – only 1 factor was used for authentication.
Type 0x82 – 2 factors were used.
Type 0x83 – 3 or more factors were used. 

                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
   82                                      -- Value 1: CBOR array of length
2 indicating two factor usage
        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
 

       

Rahul

 

 

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

 

IMO it would be nicer to have the representation be as specific as possible,
to help parsers and avoid creating attack surface.

 

Any given authenticator will likely be manufactured with support for a fixed
number of methods at a time (usually 1 or 2 at most) so they can still
hardcode that number in their implementations.

 

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

 

Yep, that can be done too. I chose to take advantage of CBOR’s extendable
length array mechanism and keep as many fields of the extension fixed as
possible. 

But I am open to changing the length field to the # of entries present
instead of indefinite length, especially if it keeps the server side
implementation simpler.

 

Rahul

 

From: Vijay Bharadwaj [mailto:vijaybh@microsoft.com] 
Sent: Monday, August 08, 2016 9:48 AM
To: Ghosh, Rahuldeva <rahuldeva.ghosh@intel.com>; 'W3C Web Authn WG'
<public-webauthn@w3.org>
Cc: Bakshi, Sanjay <sanjay.bakshi@intel.com>; Sarangdhar, Nitin V
<nitin.v.sarangdhar@intel.com>
Subject: RE: returning a multi-factor authenticator's factor-in-use and
protection scheme to the server - UVM extension proposal

 

Ø  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.

Why not just use the definite length form with the length set to the number
of entries actually present?

 

From: Ghosh, Rahuldeva [mailto:rahuldeva.ghosh@intel.com] 
Sent: Sunday, August 07, 2016 11:06 PM
To: 'W3C Web Authn WG' <public-webauthn@w3.org>
Cc: Bakshi, Sanjay <sanjay.bakshi@intel.com>; Sarangdhar, Nitin V
<nitin.v.sarangdhar@intel.com>
Subject: 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. 

 

Rahul

 

From: Hodges, Jeff [mailto:jeff.hodges@paypal.com] 
Sent: Tuesday, July 26, 2016 8:12 AM
To: Ghosh, Rahuldeva <rahuldeva.ghosh@intel.com>
Cc: W3C Web Authn WG <public-webauthn@w3.org>; Bakshi, Sanjay
<sanjay.bakshi@intel.com>; Sarangdhar, Nitin V
<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> 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