| Internet-Draft | CRIMP | August 2023 |
| Steele | Expires 3 February 2024 | [Page] |
This document defines a protocol to securely move one or more credentials between two credential providing applications same or separate devices.¶
This note is to be removed before publishing as an RFC.¶
The latest revision of this draft can be found at https://example.com/LATEST. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-cpsig-crimp/.¶
Discussion of this document takes place on the WG Working Group mailing list (mailto:WG@example.com), which is archived at https://example.com/WG.¶
Source for this draft and an issue tracker can be found at https://github.com/Credential-Provider-SIG/cred-migration.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 3 February 2024.¶
Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
Individuals and organizations use credential providers to create and manage credentials on their behalf as a means to use stronger authentication factors. These credential providers can be used in browsers, on network servers, and mobile and desktop platforms, and often sharing or synchronizing credentials between different instances of the same provider is an easy and common task. However, transfer of credentials between two different providers has traditionally been an infrequent occurence, such as when a user or organization is attempting to migrate credentials from one provider to another. As it becomes more common for users to have multiple credential providers that they use to create a manage credentials, it becomes important to address some of the security concerns with regards to migration currently:¶
In order to support credential provider interoporability and provide more secure means of credential transfer between providers, this document outlines a protocol for the import and export of one or more credentials between two credential providers on behalf of a user or organization in both an offline or online context. Using Diffie-Hellman key exchange, this protocol allows the creation of a secure channel or data payload between two providers.¶
Credential transfer must occur with user consent and intent in mind. This section outlines several different flows for how credential import and export can be used and what the user's involvement in the process would look like.¶
A user has installed or been instructed to install a new credential provider and wants to migrate the contents of their existing credential provider to the new service. The user would go to the new provider and request export of some types or all credentials from another provider. The platform will then prompt the user to choose the intended export provider, which the user can then select. After making their selection, the exporting credential provider will either confirm with the user that they're going to export their credentials, and the user will authorize the release. Once the credentials are imported, the importer will inform the user that the operation was completed and the success of the transfer.¶
There are several different modalities through which a credential owner can migrate across devices, and depending on network or policy requirements, the means with which they transfer credentials may differ. Below outlines several different device to device flows depending on networking and constraints and A user has been given a new phone or laptop and wishes to move credententials from an application on one device to another.¶
This protocol is scoped to describing the secure transmission of one or more credentials between two credential providers on the same or different devices managed by the same credential owner, capable of function in both online and offline contexts. This protocol does not make any assumptions about the channels in which credential data is passed from the source provider to the destination provider. The destruction of credentials after migration by the credential provider source is out of scope as well.¶
The goal of this specification is to develop a secure way to transport credentials between two applications.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
Certain security-related terms are to be understood in the sense defined in [RFC4949]. These terms include, but are not limited to, "attack", "authentication" "authorization", "certificate", "credential", "encryption", "identity", "sign", "signature", "trust", "validate", and "verify".¶
An entity that is able to authenticate, authorize, access one or more credentials from within a credential provider. The credential owner is in charge of authorizing or delegating authorization of the migration between the source credential provider and destination provider. In the case of a credential owner being an individual, they are referred to as the end-user, an individual or service being delegated by an organization are considered credential owner agents.¶
Hardware or software capable of securely storing and managing credentials on behalf of their owner. There are two credential providers when discussing migration: the source provider and the destination provider. The destination provider, which can also be referred to as the importing provider, initiates the export request and is where the credential data should arrive after migration, while the source (or export provider) encrypts and transfers the credential data to the destination provider. These two credential providers will generally be two distinct pieces of hardware or software.¶
An OPTIONAL certificate authority that can grant and attest certificates on behalf of a credential owner. These certificates are used to authenticate the credential agent and MAY be used to create the migration key used on behalf of the source and destination credential providers.¶
┌──────────────────────────────────────────────────────┐
│ Authorizing Party │
└─────┬──────────────────────────────────────────┬─────┘
│ (2) Determine (1) Create Export │
Migration Key Request
┌────────────┴──┐ ┌────┴──────────┐
│ ◀─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ┤ │
│ │ │ │
│ │ │ │
│ │ │ │
│┌─────────────┐│ │ │
││ (3)Encrypt ││ │ │
││ Credential ││ │ │
││ Data ││ │ │
│└─────────────┘│ │ │
│ │ (4) Send Export Response │ │
│ │─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ▶┌─────────────┐│
│ │ ││ (5) Decrypt ││
│ │ ││ Bundle ││
│ │ │└─────────────┘│
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│Credential Data│ │Credential Data│
│ Source │ │ Destination │
└───────────────┘ └───────────────┘
The flow illustrated in Figure 1 shows the following: 1. The destination credential provider initiates the flow by creating an export request for the source. The import request includes a challenge, the scope of the export request, and a public key provided via X.509 certificate that has been generated by the destination credential provider or an authorizing party. 2. If an end-user and/or authorizing party authorize the request, the source credential provider uses the export request to derive the migration key, a symmetric key created from the export request public key and a private key controlled by the source credential provider, or a key can be provided by the authorizing party. 3. The source collects and encrypts the requested credential data for export and signs the challenge provided by the destination 4. The export response is sent to the destination provider and includes the encrypted credential data, the signed challenge response, and an x509 certificate containing the public key of the source credential provider's migration key. 5. The destination provider validates the challenge and rederives the migration key, decrypting the credential data which is then stored.¶
CRIMP is designed to be operational in settings where network access may be limited between the credential providers and their platforms. This protocol can work in both online and offline scenarios, as well as in airgapped networks where one or both devices might not have access to the internet. In these s¶
The export request intitiates the protocol and contains a credential alongside set of request parameters for the source credential provider to create a response with. This request or elements of it MAY be created by the authorizing server if one is present, or created by the destination credential provider with or without input from the credential owner.¶
The credential payload includes both¶
This document has no IANA actions.¶
This section defines which algorithms and features of this specification are mandatory to implement. Applications using this specification can impose additional requirements upon implementations that they use.¶
TODO Security¶
TODO acknowledge.¶