- From: Ghosh, Rahuldeva <rahuldeva.ghosh@intel.com>
- Date: Tue, 9 Aug 2016 04:13:53 +0000
- To: 'W3C Web Authn WG' <public-webauthn@w3.org>
- CC: "Bakshi, Sanjay" <sanjay.bakshi@intel.com>, "Sarangdhar, Nitin V" <nitin.v.sarangdhar@intel.com>
- Message-ID: <6CB7FFDD0048944F93D6E9ACFB7DB6CD7E35811E@ORSMSX102.amr.corp.intel.com>
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 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 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<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>>; 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 - 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<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 - 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<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
Received on Tuesday, 9 August 2016 04:14:26 UTC