merge heads

master
Claudio Luck 4 years ago
commit 9a9d76d62b

@ -0,0 +1,8 @@
syntax: glob
*.xml
*.txt
*.html
.refcache

@ -1,728 +0,0 @@
Network Working Group V. Birk
Internet-Draft H. Marques
Intended status: Standards Track pEp Foundation
Expires: September 15, 2019 March 14, 2019
pretty Easy privacy (pEp): Key Synchronization Protocol
draft-birk-pep-keysync-NN
Abstract
The pretty Easy privacy (pEp) propositions for email are based upon
already existing email and encryption formats (i.e., PGP/MIME) and
designed to allow for easy implementable and interoperable
opportunistic encryption.
The goal of pEp KeySync is to automatize operations in order to make
handling of multiple devices usable by a wider range of Internet
users, to achieve wide application of confidentiality and privacy
practices in the real world.
...
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 September 15, 2019.
Copyright Notice
Copyright (c) 2019 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
Birk & Marques Expires September 15, 2019 [Page 1]
Internet-Draft pretty Easy privacy (pEp) Key Sync March 2019
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 Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. General function . . . . . . . . . . . . . . . . . . . . . . 3
4. Sync Handshake Signals . . . . . . . . . . . . . . . . . . . 4
5. Sync State Machine . . . . . . . . . . . . . . . . . . . . . 5
6. Sync Messages . . . . . . . . . . . . . . . . . . . . . . . . 7
7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 9
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
10. Implementation Status . . . . . . . . . . . . . . . . . . . . 9
10.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 9
10.2. Current software implementing pEp . . . . . . . . . . . 9
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
12.1. Normative References . . . . . . . . . . . . . . . . . . 10
12.2. Informative References . . . . . . . . . . . . . . . . . 10
Appendix A. Excerpts from the pEp Reference Implementation . . . 11
Appendix B. Document Changelog . . . . . . . . . . . . . . . . . 11
Appendix C. Open Issues . . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction
When a user has different devices, it is convenient to read existing,
send new and receive messages from any of those devices, and to share
the same identity on all of them (e.g., a specific email address).
In this part of the pretty Easy privacy (pEp) protocols, a way to
synchronize private key material is presented, which is non-
centralized and easy to implement.
For pEp implementations, pEp KeySync for key synchronization is part
of the pEp Sync protocol.
2. Terms
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
Birk & Marques Expires September 15, 2019 [Page 2]
Internet-Draft pretty Easy privacy (pEp) Key Sync March 2019
o pEp Handshake: The process when Alice - e.g., in-person or via
phone - contacts Bob to verify Trustwords (or by fallback:
fingerprints) is called pEp Handshake.
[I-D.marques-pep-handshake]
o Trustwords: A scalar-to-word representation of 16-bit numbers (0
to 65535) to natural language words. When doing a Handshake,
peers are shown combined Trustwords of both public keys involved
to ease the comparison. [I-D.birk-pep-trustwords]
o Trust on First Use (TOFU): cf. [RFC7435]
o Man-in-the-middle attack (MITM): cf. [RFC4949]
o Device Group: All devices that share a common mailbox to exchange
user keys, trust, calendar and other information.
o Beacon (message): A text message that is stored inside the mailbox
which contains control commands and serves as communication
channel between the devices of the device group
3. General function
Assume two devices from Alice configured with pEp-implementing
messaging clients, Alice_A and Alice_B and sharing the same identity
for some communication channel (e.g., an email address). Both
devices will already have a key pair, which was automatically
generated by the pEp protocol. Neither device knows anything about
the other nor are the chances realistic that the independently
created key pairs match.
If Alice wants to communicate from both of her devices, she expects
not only that messages be readable across the devices, but also that
she can send messages expecting the same level of privacy she's used
to with just using one device, i.e., she wants all of the trust she
gave her contacts synchronized. That is, the trust should be
reflected on any device she uses. This requires her to have her
devices be part of a so-called Device Group.
This scenario can be fulfilled using the following steps, assuming
the process is started with device Alice_A:
1. Alice automatically invokes a broadcast from the first device,
which is connected, e.g. Alice_A: its public key is attached.
2. Both devices, Alice_A and Alice_B, might see the beacon message.
* Alice_A will ignore the message, as it was the sending device.
Birk & Marques Expires September 15, 2019 [Page 3]
Internet-Draft pretty Easy privacy (pEp) Key Sync March 2019
3. Alice_B picks up on the message and does a Handshake Request:
that device's public key is attached.
4. If the devices do not yet form a Device Group, Alice_A now sends
a Handshake Request to Alice_B.
1. On both devices, the user confirms the Trustwords. This
establishes trust.
2. Alice_A and Alice_B now send each other all of their secrets,
i.e., their private keys.
3. The oldest key is used as the Group Key for the established
Device Group: it's the one now used for any outside communication
with other peers.
In any case, both devices can now read any message encrypted with
either encryption key: be it Alice_1's or Alice_2's public key, which
was involved in some former communications with the outside world.
FIXME: Refine; sketch update processes.
4. Sync Handshake Signals
From the reference implementation, src/sync.h:
typedef enum _sync_handshake_signal {
SYNC_NOTIFY_UNDEFINED = 0,
// request show handshake dialog
SYNC_NOTIFY_INIT_ADD_OUR_DEVICE,
SYNC_NOTIFY_INIT_ADD_OTHER_DEVICE,
SYNC_NOTIFY_INIT_FORM_GROUP,
// handshake process timed out
SYNC_NOTIFY_TIMEOUT,
// handshake accepted by user
SYNC_NOTIFY_ACCEPTED_DEVICE_ADDED,
SYNC_NOTIFY_ACCEPTED_GROUP_CREATED
} sync_handshake_signal;
Birk & Marques Expires September 15, 2019 [Page 4]
Internet-Draft pretty Easy privacy (pEp) Key Sync March 2019
5. Sync State Machine
Finite-State-Machine from reference implementation from sync/
devicegroup.fsm:
include ./fsm.yml2
protocol DeviceGroup {
// all messages have a timestamp, time out and are removed after timeout
broadcast sendBeacon;
broadcast sendGroupUpdate;
broadcast sendUpdateRequest;
unencrypted sendBeacon;
fsm DeviceState filename=sync {
condition storedGroupKeys();
condition keyElectionWon(Identity partner);
state InitState {
on Init {
if storedGroupKeys()
go Grouped;
go Sole;
}
}
state Sole end=1 {
on KeyGen // injected by generate_keypair()
do sendBeacon;
on CannotDecrypt
do sendBeacon; // cry, baby
on Beacon(Identity partner) // this event will not happen for already
// rejected partners
do sendHandshakeRequest(partner);
on HandshakeRequest(Identity partner) {
do sendHandshakeRequest(partner);
go HandshakingSole(partner);
}
}
state HandshakingSole timeout=600 (Identity expected) {
on Init{
if keyElectionWon(partner) { // an already existing group
do notifyInitFormGroup(partner);
} else {
do notifyInitAddOurDevice(partner);
}
Birk & Marques Expires September 15, 2019 [Page 5]
Internet-Draft pretty Easy privacy (pEp) Key Sync March 2019
}
on HandshakeRejected(Identity partner) {
do rejectHandshake(partner); // stores rejection of partner
go Sole;
}
on HandshakeAccepted(Identity partner) {
do acceptHandshake(partner);
if keyElectionWon(partner) { // an already existing group
// always wins
do sendGroupKeys(partner);
do notifyAcceptedGroupCreated(partner);
go Grouped;
}
go WaitForGroupKeysSole(partner);
}
on Cancel go Sole;
on Timeout {
do notifyTimeout(expected);
go Sole;
}
}
state WaitForGroupKeysSole timeout=600 (Identity expected) {
on GroupKeys(Identity partner, Stringlist keys) {
// TODO ensure partner == expected
do storeGroupKeys(partner, keys);
do notifyAcceptedDeviceAdded(partner);
go Grouped;
}
on Timeout {
do notifyTimeout(expected);
go Sole;
}
}
state Grouped end=1 {
on Init
do enterGroup;
on KeyGen
do sendGroupUpdate;
on CannotDecrypt
do sendUpdateRequest; // TODO: narrow request to missing key
on UpdateRequest
do sendGroupUpdate;
on Beacon(Identity partner)
do sendHandshakeRequest(partner);
on HandshakeRequest(Identity partner) {
Birk & Marques Expires September 15, 2019 [Page 6]
Internet-Draft pretty Easy privacy (pEp) Key Sync March 2019
do sendHandshakeRequest(partner);
go HandshakingGrouped(partner);
}
on GroupUpdate(Identity partner, Stringlist keys)
do storeGroupKeys(partner, keys);
}
state HandshakingGrouped timeout=600 (Identity expected) {
on Init
do notifyInitAddOurDevice(partner);
on HandshakeRejected(Identity partner) {
do rejectHandshake(partner); // stores rejection of partner
go Grouped;
}
on HandshakeAccepted(Identity partner) {
do acceptHandshake(partner);
// an already existing group always wins
do sendGroupKeys(partner);
go Grouped;
}
on Timeout {
do notifyTimeout(expected);
go Grouped;
}
}
tag Init 1;
tag Beacon 2;
tag HandshakeRequest 3;
tag GroupKeys 4;
}
}
6. Sync Messages
ASN.1 reference implementation from asn1/devicegroup.asn1:
DEVICEGROUP
{ iso(1) org(3) dod(6) internet(1) private(4)
enterprise(1) pEp (47878) sync(1) keysync(1) }
DEFINITIONS AUTOMATIC TAGS EXTENSIBILITY IMPLIED ::=
BEGIN
EXPORTS DeviceGroup-Protocol;
Birk & Marques Expires September 15, 2019 [Page 7]
Internet-Draft pretty Easy privacy (pEp) Key Sync March 2019
IMPORTS Version, Identity, IdentityList FROM PEP;
Beacon ::= NULL
HandshakeRequest ::= SEQUENCE {
partner Identity /* identity of the receiver */
}
GroupKeys ::= SEQUENCE {
partner Identity, /* identity of the receiver */
ownIdentities IdentityList
}
GroupUpdate ::= SEQUENCE {
ownIdentities IdentityList
}
/* TODO: narrow request to single key */
UpdateRequest ::= NULL
/* for the tags see end of sync.fsm */
DeviceGroup-Protocol ::= SEQUENCE {
header SEQUENCE {
version Version,
sequence INTEGER, /* always increases */
me Identity, /* identity of the sender */
state INTEGER, /* state the sender is in */
devicegroup BOOLEAN
/* signals if this message is coming from
a device group member */
},
payload CHOICE {
beacon [APPLICATION 2] Beacon,
handshakeRequest [APPLICATION 3] HandshakeRequest,
groupKeys [APPLICATION 4] GroupKeys,
groupUpdate [APPLICATION 5] GroupUpdate,
updateRequest [APPLICATION 6] UpdateRequest
}
}
END
Birk & Marques Expires September 15, 2019 [Page 8]
Internet-Draft pretty Easy privacy (pEp) Key Sync March 2019
7. Security Considerations
[[ TODO ]]
8. Privacy Considerations
[[ TODO ]]
9. IANA Considerations
This document has no actions for IANA.
10. Implementation Status
10.1. Introduction
This section records the status of known implementations of the
protocol defined by this specification at the time of posting of this
Internet-Draft, and is based on a proposal described in [RFC7942].
The description of implementations in this section is intended to
assist the IETF in its decision processes in progressing drafts to
RFCs. Please note that the listing of any individual implementation
here does not imply endorsement by the IETF. Furthermore, no effort
has been spent to verify the information presented here that was
supplied by IETF contributors. This is not intended as, and must not
be construed to be, a catalog of available implementations or their
features. Readers are advised to note that other implementations may
exist.
According to [RFC7942], "[...] this will allow reviewers and working
groups to assign due consideration to documents that have the benefit
of running code, which may serve as evidence of valuable
experimentation and feedback that have made the implemented protocols
more mature. It is up to the individual working groups to use this
information as they see fit."
10.2. Current software implementing pEp
The following software implementing the pEp protocols (to varying
degrees) already exists:
o pEp for Outlook as add-on for Microsoft Outlook, release
[SRC.pepforoutlook]
o pEp for Android (based on a fork of the K9 MUA), release
[SRC.pepforandroid]
Birk & Marques Expires September 15, 2019 [Page 9]
Internet-Draft pretty Easy privacy (pEp) Key Sync March 2019
o Enigmail/pEp as add-on for Mozilla Thunderbird, release
[SRC.enigmailpep]
o pEp for iOS (implemented in a new MUA), beta [SRC.pepforios]
pEp for Android, iOS and Outlook are provided by pEp Security, a
commercial entity specializing in end-user software implementing pEp
while Enigmail/pEp is pursued as community project, supported by the
pEp Foundation.
All software is available as Free Software and published also in
source form.
11. Acknowledgements
The authors would like to thank the following people who have
provided feedback or significant contributions to the development of
this document: [[ TODO ]]
This work was initially created by pEp Foundation, and then reviewed
and extended with funding by the Internet Society's Beyond the Net
Programme on standardizing pEp. [ISOC.bnet]
12. References
12.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/info/rfc2119>.
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2",
FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007,
<https://www.rfc-editor.org/info/rfc4949>.
[RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection
Most of the Time", RFC 7435, DOI 10.17487/RFC7435,
December 2014, <https://www.rfc-editor.org/info/rfc7435>.
12.2. Informative References
[I-D.birk-pep-trustwords]
Birk, V., Marques, H., and B. Hoeneisen, "IANA
Registration of Trustword Lists: Guide, Template and IANA
Considerations", draft-birk-pep-trustwords-03 (work in
progress), March 2019.
Birk & Marques Expires September 15, 2019 [Page 10]
Internet-Draft pretty Easy privacy (pEp) Key Sync March 2019
[I-D.marques-pep-handshake]
Marques, H. and B. Hoeneisen, "pretty Easy privacy (pEp):
Contact and Channel Authentication through Handshake",
draft-marques-pep-handshake-01 (work in progress), October
2018.
[ISOC.bnet]
Simao, I., "Beyond the Net. 12 Innovative Projects
Selected for Beyond the Net Funding. Implementing Privacy
via Mass Encryption: Standardizing pretty Easy privacy's
protocols", June 2017, <https://www.internetsociety.org/
blog/2017/06/12-innovative-projects-selected-for-beyond-
the-net-funding/>.
[RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
Code: The Implementation Status Section", BCP 205,
RFC 7942, DOI 10.17487/RFC7942, July 2016,
<https://www.rfc-editor.org/info/rfc7942>.
[SRC.enigmailpep]
"Source code for Enigmail/pEp", March 2019,
<https://enigmail.net/index.php/en/download/source-code>.
[SRC.pepforandroid]
"Source code for pEp for Android", March 2019,
<https://pep-security.lu/gitlab/android/pep>.
[SRC.pepforios]
"Source code for pEp for iOS", March 2019,
<https://pep-security.ch/dev/repos/pEp_for_iOS/>.
[SRC.pepforoutlook]
"Source code for pEp for Outlook", March 2019,
<https://pep-security.lu/dev/repos/pEp_for_Outlook/>.
Appendix A. Excerpts from the pEp Reference Implementation
This section provides excerpts of the running code from the pEp
reference implementation pEp engine (C99 programming language). [[
TODO: Maybe rewrite sentence a bit ]]
[[ TODO ]]
Appendix B. Document Changelog
[[ RFC Editor: This section is to be removed before publication ]]
o draft-birk-pep-keysync-00:
Birk & Marques Expires September 15, 2019 [Page 11]
Internet-Draft pretty Easy privacy (pEp) Key Sync March 2019
* Initial version
Appendix C. Open Issues
[[ RFC Editor: This section should be empty and is to be removed
before publication ]]
o Include shared file (cf. other drafts)
o Major update
o Verify Dummy Sections
* Implementation Status
* Acknowledgements
* Excerpts from the pEp Reference Implementation
* Open Issues
o Remove unused references
o Remove unused Terms
o Check List of Authors
o shorten overlong lines in code examples
Authors' Addresses
Volker Birk
pEp Foundation
Oberer Graben 4
CH-8400 Winterthur
Switzerland
Email: volker.birk@pep.foundation
URI: https://pep.foundation/
Birk & Marques Expires September 15, 2019 [Page 12]
Internet-Draft pretty Easy privacy (pEp) Key Sync March 2019
Hernani Marques
pEp Foundation
Oberer Graben 4
CH-8400 Winterthur
Switzerland
Email: hernani.marques@pep.foundation
URI: https://pep.foundation/
Birk & Marques Expires September 15, 2019 [Page 13]
Loading…
Cancel
Save