| Internet-Draft | tigress-signal-impl | February 2023 |
| Astiz & Vinokurov | Expires 22 August 2023 | [Page] |
This document describes a sample implementation of transferring digital credentials securily (Tigress) using Signal protocol.¶
This note is to be removed before publishing as an RFC.¶
The latest revision of this draft can be found at https://datatracker.ietf.org/doc/draft-tigress-signal-impl/. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-tigress-signal-impl/.¶
Source for this draft and an issue tracker can be found at https://github.com/dimmyvi/tigress-requirements.¶
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 22 August 2023.¶
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.¶
Prevously Tigress reviewed an implementation of digital credentials transfer using Tigress protocol (https://datatracker.ietf.org/doc/draft-art-tigress/). In previous IETF meetings community asked to review other possible solutions using alternative standards to illustrate how Tigress problem can be solved differently. In this document we are trying to describe how an alternative potential implementation of a solution to Tigress [Tigress-req-02] problem of transferring digital credentials securily can be done using Signal Protocol.¶
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.¶
The Signal Protocol [Signal-20] is a secure messaging protocol that provides end-to-end encryption for instant messaging and voice/video calls. The Signal Protocol is primarily used through the Signal app, which is available for both Android and iOS devices. Users are free to implement Signal Protocol on their own in a custom application or integrate with Signal application via set of documented APIs. For this document, we will focus on this implementation of the Signal Protocol.¶
## Secure Credential Transfer with Signal Protocol:¶
For Secure Credential Transfer [Tigress-req-02] with Signal Protocol, the message sequence and message contents between Sender and Receiver devices will be the same as the other approaches. Per Signal protocol specification [Signal-20] there is a requirement to implement an intermediary server that is used to store user and device records containing security keys (one-time prekeys and signed prekeys), identity keys, user and device identities and all encrypted messages stored in mailboxes. In real system these functions might be distributed across multiple servers.¶
Once the common secret is established using X3DH agreement and secure session is created between sender and receiver devices using Double Ratchet session, the credential application on the sender’s device will encrypt the provisioning information using sender encryption key and send it to the intermediary server. Receiver device will receive the encrypted message from signal intermediary server, using X3DH and Double Ratchet algorithms will create the receiver encryption key will decrypt the message and get the provisioning data. Credential management application (digital wallet) on both sender and receiver devices will have to implement Signal Protocol or integrate with Signal application API in order to exchange encrypted messages. For stateless sharing, the receiver digital wallet will take that provisioning information and provision the credential.¶
For the stateful sharing flow, the receiving credential application will encrypt modified data (e.g. CCC Key Signing Request) and send it to Signal intermediary server. Sender device will read the encrypted data, re-create receiving decryption key and decrypt the message. Sender will then generate CCC Key Import Request, encrypt the data with sending encryption key and upload it to intermediary server. Receiver device will read the encrypted message from intermediary server, generate receiver decryption key and decrypt the data. Now receiver device can provision new credential in the digital wallet .¶
While this is guaranteed to be a secure method of transferring data between users, there are a few considerations.¶
Signal application is currently available on iOS and Android, so most users are able to make accounts for free. However, it may limit sharing for sender and receiver pairs that only have one method of contact outside of Signal. It is worth noting that while the Signal Protocol is open source, the Signal Protocol libraries for iOS and Android are not. The libraries are licensed under the GPLv3 license, which allows for use and modification, but they also include some proprietary components that are not open source.¶
TODO Security¶
This document has no IANA actions.¶
TODO acknowledge.¶