TIGRESS C. Astiz Internet-Draft D. Vinokurov Intended status: Informational Apple Inc Expires: 22 August 2023 18 February 2023 Tigress-Signal-Sample Implementation draft-tigress-signal-impl-00 Abstract This document describes a sample implementation of transferring digital credentials securily (Tigress) using Signal protocol. About This Document 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. Status of This Memo 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 Notice Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved. Astiz & Vinokurov Expires 22 August 2023 [Page 1] Internet-Draft tigress-signal-impl February 2023 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 2 3. Signal Protocol Sample Implementation . . . . . . . . . . . . 3 4. Security Considerations . . . . . . . . . . . . . . . . . . . 4 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 6.1. Normative References . . . . . . . . . . . . . . . . . . 4 6.2. Informative References . . . . . . . . . . . . . . . . . 5 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 5 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction 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. 2. Conventions and Definitions 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. Astiz & Vinokurov Expires 22 August 2023 [Page 2] Internet-Draft tigress-signal-impl February 2023 3. Signal Protocol Sample Implementation 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 . Astiz & Vinokurov Expires 22 August 2023 [Page 3] Internet-Draft tigress-signal-impl February 2023 While this is guaranteed to be a secure method of transferring data between users, there are a few considerations. * Both sender and receiver devices have to implement support of Signal Protocol in credential management application (digital wallet) or have Signal application installed and Signal API supported in digital wallet. * Intermediate Signal server has to be implemented to support Signal Protocol or user accounts have to be created within Signal Application servers. * Intermediate server (servers) in Signal Protocol require user identities / authentication and device identities. Signal intermediate server, even though may not decrypt the content of the messages, may correlate the fact of information exchanges between certain users and certain devices by their identities. * More security considerations are listed in "Security considerations" section of Signal specification: https://signal.org/docs/specifications/sesame/#security- 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. 4. Security Considerations TODO Security 5. IANA Considerations This document has no IANA actions. 6. References 6.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . Astiz & Vinokurov Expires 22 August 2023 [Page 4] Internet-Draft tigress-signal-impl February 2023 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 6.2. Informative References [Signal-20] Marlinspike, M. and T. Perrin, "Signal Protocol. The Sesame Algorithm: Session Management for Asynchronous Message Encryption. Revision 2, 2017-04-143", April 2017, . [Tigress-req-02] Vinokurov, D., Pelletier, A., Astiz, C., and B. Lassey, "Tigress requirements", February 2023, . Acknowledgments TODO acknowledge. Authors' Addresses Casey Astiz Apple Inc Email: castiz@apple.com Dmitry Vinokurov Apple Inc Email: dvinokurov@apple.com Astiz & Vinokurov Expires 22 August 2023 [Page 5]