Remote Two-factor Protected Services

1.1. Applicability for EU trust frameworks

EU has defined a level of assurance framework for user authentication based on an eID [1502]. On the highest assurance level (LoA High) the key used to authenticate the user must be protected by tamper resistant hardware (HSM) that protects against an adversary with high attack potential. This framework further specifies that access to the protected authentication key must be protected by 2-factor authentication.¶

The EU Digital Identity Wallet (EUDI Wallet) defined by the new eIDAS regulation [{add ref}] specifies that HSM protection when the wallet provides authentication on LoA High, must be realized by a Wallet Secure Cryptographic Application (WSCA) that includes a Wallet Secure Cryptographic Device (WSCD).¶

The WSCA is a software module responsible for controlling access to keys protected by the hardware module (WSCD).¶

Some wallet actions, such as presenting a Verifiable Presentation on LoA High, requires the user to provide a knowledge-factor or a biometric factor together with a possession factor to access necessary keys. This action may require one or more service request to a backend service such as the WSCA.¶

This protocol is designed as a framework for such service exchanges based on two-factor user authentication that allows the client and server to use any suitable mechanism for user authentication.¶

2.1. Definitions

The following terms have a defined meaning in this document:¶

• context: A security scope, cryptographically separated from other contexts by a unique set of context keys held at the client and the server. The client-side context keys also represent the user's possession factor in two-factor protection modes.¶

• context key: A public/private key pair. Each context is bound to one context key-agreement key and one context signing key, at both the server and the client.¶

• protection mode: This document defines two protection modes, one-factor protection (1FA) and two-factor protection (2FA). 1FA provides protection based on one user factor (the possession factor); 2FA provides protection based on two user factors (the possession factor together with a knowledge or biometric factor).¶

• session: A scope bound to a session key derived from two-factor authentication of the user, which requires the user to be present to provide a knowledge or biometric factor. A session MAY be bound to a specific task.¶

• service type: A defined message type, with its own data structure, that can be exchanged using R2PS.¶

• task: Defines what a session is to achieve before it is terminated. A task MAY be negotiated when creating a session and lets the client and the server terminate the session as soon as the task completes or fails, even before the session timeout is reached.¶

• first factor: The user's possession factor, which corresponds to a set of client context keys.¶

• second factor: The user's knowledge factor or biometric factor.¶

3.1. Bootstrapping the protocol

The protocol is designed to serve the need for service exchange with many different server resources, each cryptographically separated from the others.¶

This is achieved by means of separate "context keys" at the client and server. A security context is a named scope identified by a context id, under which a set of service types is offered with a common security and key-management policy. Each security context has its own context key set (a signing key and a key-agreement key) and is cryptographically separated from all other security contexts.¶

The manner through which the client and server share trusted context keys is out of scope of this specification.¶

Initial registration of a user's 2nd factor may need authorization data that was provided to the user by out-of-band means. This MAY be a one-time password or other authorization data that asserts that the user factor is provided by the intended user. The protocol facilitates exchange of such authorization data in the registration process, but the composition of this data and the means for providing this data to the user is out of scope for this specification.¶

3.2. Protection modes and sessions

The main purpose of this protocol is to exchange service data that is protected and authenticated under two user factors: a possession factor (the device key) and a user-bound factor (knowledge or biometric). Establishing the user-bound factor must complete before a two-factor protected exchange can take place, so the protocol also provides a one-factor protection mode, protected by the possession factor alone.¶

The one-factor protection mode MAY be used:¶

• to register or verify a user's knowledge or biometric factor; and¶

• for exchanges with lower protection requirements that are permitted without the user presenting a second factor.¶

The two-factor protection mode is used within a session bound to the user having presented a second factor, as typically required when the user signs a transaction or presents an identity. A session MAY be bound to a task, which in turn MAY bind to a sequence of service exchanges, each identified by a service type. This session lets both client and server track the task's progress within the session and terminate the session as soon as the task completes or the session times out.¶

4.1. Outer JWE object

The outer JWE object [RFC7516] provides end-to-end encryption of the exchanged service data. It is used in one of two protection modes:¶

• 1FA, where the Content Encryption Key (CEK) is derived from a static recipient key and an ephemeral sender key.¶

• 2FA, where the session key derived from authentication of the user's two factors is used directly as the CEK. This mode provides forward secrecy.¶

The recipient determines the mode from the typ parameter of the JWE protected header. The JWE protected header is the only header used; per-recipient and unprotected headers are not used.¶

This document defines the following typ parameters:¶

• r2ps-1fa : identifies the 1FA mode defined in this document.¶

• r2ps-2fa : identifies the 2FA mode defined in this document.¶

Deployments MAY define and agree on alternative protection modes identified by other typ parameter values.¶

4.2. Inner JWS object

The inner JWS object [RFC7515] is signed by the sender with its context signing key and carries the request or response structure common to all service types. Variant content specific to a service type resides entirely within the data member of the payload.¶

The JWS protected header MUST contain at least:¶

• alg: SHOULD be ES256.¶

• kid: identifies the signing key. In a request it MUST identify the client's Client Signing Key (CSK) for the security context; implementations SHOULD use the JWK Thumbprint [RFC7638] of the CSK public key. In a response it MUST identify the server's Server Signing Key (SSK).¶

• typ: MUST be r2ps-request+jwt in a request and r2ps-response+jwt in a response.¶

The JWS payload is a JSON object. Members that hold a binary value are encoded as base64 strings as defined in [RFC4648], Section 4 (the standard base64 alphabet, with padding). The following members are common to all exchanges and MUST be present in both requests and responses:¶

• ver (string): the protocol version; "1.0" for this document.¶

• nonce (string): a base64-encoded random byte array carrying at least 16 bytes of entropy. The client generates it for each request, and the server echoes it unchanged in the corresponding response.¶

• iat (integer): the message creation time as a Unix timestamp. The server MUST enforce a maximum iat age and MUST reject a duplicate nonce received within that window. Freshness windows and the state required for replay protection are deployment-defined.¶

• data (object): the service-specific payload, whose structure is determined by the service type.¶

jwe_hash = SHA-256( ASCII( BASE64URL(UTF8(JWE Protected Header)) ) )

4.3. Second factor establishment and session creation

This section defines common service types for registration, update and authentication of a user's second factor to support session creation based on the user's two factors.¶

The output of session creation is:¶

• session key: a key suitable for direct use as the CEK in the 2FA protection mode in use; its length and parameters are determined by that mode's encryption algorithm. This key MUST be uniformly distributed, MUST be unique per session, and MUST provide forward secrecy.¶

• session identifier: an identifier of the session key and the properties bound to it.¶

• context: the context under which the session is exchanged.¶

• task: an optional identifier of the task to be performed within the session.¶

• session expiration: the time at which the session expires, regardless of whether its task has completed.¶

A second-factor authentication mechanism that already outputs a key meeting these requirements (for example, the session key produced by OPAQUE [RFC9807]) MAY use that key directly as the session key. Otherwise, the mechanism MUST derive a suitable key from its output, for example using HKDF [RFC5869].¶

{
  "challenge": "<base64 challenge, at least 16 bytes>",
  "token": "<opaque server state token>",
  "user_verification": "required"
}

{
  "token": "<token from the challenge response>",
  "assertion": {
    "client_epub : "<base64 client ephemeral public key for session derivation>",
    "credential_id": "<base64 credential id>",
    "authenticator_data": "<base64 authenticatorData>",
    "client_data": "<base64 clientDataJSON>",
    "signature": "<base64 signature>"
  }
}

{
  "server_epub : "<base64 server ephemeral public key for session derivation>",
}

{
  "challenge": "<base64 challenge, at least 16 bytes>"
}

{
  "credential_id": "<base64 credential id>",
  "attestation_object": "<base64 attestationObject>",
  "client_data": "<base64 clientDataJSON>"
}