Network Working Group P. Alexander Internet-Draft No Affiliation Intended status: Informational November 04, 2017 Expires: May 8, 2018 This is an Internet-draft draft-name-wg-topic-00 Abstract [ Insert abstract here ] 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 http://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 May 8, 2018. Copyright Notice Copyright (c) 2017 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 (http://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 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. Alexander Expires May 8, 2018 [Page 1] Internet-Draft I-D November 2017 1. Introduction Maintaining security over long lasting network connections between endpoints often requires the encryption keys to be replaced periodically in order to ensure that the link remains secure. Traditional methods for replacing keys required the session to be torn down, and rebuilt in order for a new key exchange to occur. In many cases this loss of connectivity meant loss of productivity, as well as lost revenue. Another issue is that anyone observing the network is able to see that the connection has been restarted, and therefore knows what a key renegotiation has taken place. The Protected Point to Point (P3) solution described in this document aims to resolve those issues. It does so by building a tunnel between the endpoints in which keys or key information can be safely passed across. A second tunnel is built on to encompass the first, and is primarily used for network transport. Having two layers in this manner allows for re-negotiations to occur within the doubly- secure tunnel, while still allowing normal traffic to flow unhindered. 1.1. Terminology In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 [RFC2119]. 2. Diagram Showing Tunnel Layers +--------------------+ | Network | | Traffic | +--------------------+ <---+ Control Data +---> +--------------------+ | Network | | Traffic | +--------------------+ Alexander Expires May 8, 2018 [Page 2] Internet-Draft I-D November 2017 3. Initialization The P3 solution initialization conforms to the IPsec standard defined in RFC 4301 as well as all of its supporting standards. The protocol is modified to enable the encryption keys to be replaced dynamically. When the initial handshakes have completed, and the Data Channel has been established, the P3 system then initializes the Control Channel. The initialization messages are speicic to P3, and are designed to look like normal data which has been encrypted with a different key than the one used by the Data Channel. In order to further protect the keys used during initialization, the session re-keys itself once the endpoints have acknowledged the connection. 4. Session Processing The full IP packets received from the local network are encrypted and used as the payload data of the encrypted packet. These packets are structured using the Encapsulating Security Header (ESH), and Encapsulating Security Payload (ESP), as defined in RFC 4303. The P3 solution requires the addition of a 32-bit field at the end of the ESH and immediately before the ESP. The format of encrypted packets is: +----------+----------+-----------------+ | ESH size | 4 octets | Variable length | +----------+----------+-----------------+ | ESH | P3 ID | ESP | +----------+----------+-----------------+ Where the fields are: o ESH: The Encapsulating Security Header of the IPsec protocol. o P3 ID: The Identification number of the packet. o ESP: The Encapsulating Security Payload of the IPsec protocol. When Control Channel data is to be sent to another P3 System, predefined TCP and IP headers are prepended. Only the address fields are processed by the receiving P3 System, so the headers may be statically defined. The entire packet is encrypted using the control encryption key, and it is then treated as if it were a standard a data packet. If, after decrypting a packet, the destination is seen to be the P3 System itself, the packet is decrypted using the control encryption key. Then the IP and TCP headers are removed and the data is forwarded to the Control Channel application. Alexander Expires May 8, 2018 [Page 3] Internet-Draft I-D November 2017 5. Control Message Specification Authors Note: I still need to find the exact notes regarding control channel messages. This is a temporary placeholder. 6. Encryption Re-keying The system has been designed to allow the re-keying process to be configurable. Triggers for re-keying may include; packet count, time, or a combination of both. Other triggers may also be defined on an as-needed basis. When a re-key is triggered the primary P3 System notifies the secondary, supplies the new keys, and indicates when it will begin to use the new set of keys. The primary P3 System generates new keys for both the main session and the Control Channel. The keys are replaced using the P3 control messages according to the following process. The primary P3 System sends a control message with the data and control key values. This lets the secondary know that a re-key event is about to take place. When the secondary receives the message, it updates the keys it is using and returns a status message. If the status is good, the primary acknowledges, and sends a message to indicate the first packet it will encrypt using the new keys. The secondary then returns a success message indicating the first packet using the new keys has been successfully decrypted. If the status is not success, the primary attempts again for up to four times. If this does not result in success, session recovery is performed. 7. Session Recovery The session recovery process begins by discarding all keys used during the previous session, and is followed by a complete session tear-down so that a new session may be established. If a new session cannot be established it is then left to the user to determine whether or not the system is down or compromised. 8. Standards Compliance The implementation of the P3 System conforms to the following Internet Engineering Task Force (IETF) standards: 8.1. IP Security 1. RFC 4301: Security Architecture for the Internet Protocol 2. RFC 3723: Securing Block Storage Protocols over IP Alexander Expires May 8, 2018 [Page 4] Internet-Draft I-D November 2017 8.1.1. ESP and AH Headers 1. RFC 4302: IP Authentication Header (AH) 2. RFC 4303: Encapsulating Security Payload (ESP) 3. RFC 4835: Cryptographic Algorithm Implementation Requirements For ESP And AH 8.1.2. Key Exchange 1. RFC 3547: Group Domain of Interpretation 2. RFC 4109: Algorithms for IKEv1 3. RFC 4306: Internet Key Exchange (IKEv2) Protocol 4. RFC 4307: Cryptographic Algorithms for Use in the Internet Key Exchange Version2 (IKEv2) 5. RFC 4308: Cryptographic Suites for IPsec 6. RFC 4718: IKEv2 Clarifications and Implementation Guidelines 7. RFC 4945: IPsec PKI Profile of IKEv1/ISAKMP, IKEv2, and PKIX 8.1.3. Cryptographic Algorithms 1. RFC 2410: NULL Encryption Algorithm and Its Use With IPsec 2. RFC 3173: IP Payload Compression Protocol (IPComp) 3. RFC 3526: More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE) 4. RFC 3686: Using AES Counter Mode With IPsec ESP 5. RFC 4309: Using AES CCM Mode With IPsec ESP 6. RFC 4434: AES-XCBC-PRF-128 algorithm for IKE 7. RFC 4615: AES-CMAC-PRF-128 Algorithm for IKE 8. RFC 4754: IKE and IKEv2 Authentication Using ECDSA 9. RFC 5282: Using Authenticated Encryption Algorithms with the Encrypted Payload of IKEv2 Alexander Expires May 8, 2018 [Page 5] Internet-Draft I-D November 2017 9. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Author's Address Peter Alexander No Affiliation Email: drbanjofox@protonmail.com Alexander Expires May 8, 2018 [Page 6]