Internet DRAFT - draft-tigress-signal-impl
draft-tigress-signal-impl
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,
<https://www.rfc-editor.org/rfc/rfc2119>.
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, <https://www.rfc-editor.org/rfc/rfc8174>.
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,
<https://signal.org/docs/specifications/sesame/>.
[Tigress-req-02]
Vinokurov, D., Pelletier, A., Astiz, C., and B. Lassey,
"Tigress requirements", February 2023,
<https://github.com/dimmyvi/tigress-requirements/>.
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]
