Internet Engineering Task Force Moeller Internet-Draft Google Intended status: Standards Track February 22, 2016 Expires: August 25, 2016 Using AEAD with Secure Shell draft-nisse-secsh-aead-00 Abstract This document specifies an extension of the Secure Shell transport protocol, to enable use of Authenticated Encryption with Associated Data (AEAD) mechanisms within the Secure Shell protocol. It also specifies one concrete AEAD algorithm, chacha20-poly1305, for use with Secure Shell. 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 August 25, 2016. Copyright Notice Copyright (c) 2016 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. Moeller Expires August 25, 2016 [Page 1] Internet-Draft Using AEAD with Secure Shell February 2016 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. AEAD . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.2. Secure Shell . . . . . . . . . . . . . . . . . . . . . . 3 1.3. Requirements Language . . . . . . . . . . . . . . . . . . 3 2. Negotiation . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Binary packet format . . . . . . . . . . . . . . . . . . . . 4 3.1. Encrypting the packet length . . . . . . . . . . . . . . 4 3.2. The AEAD Nonce(s) . . . . . . . . . . . . . . . . . . . . 5 3.3. Packet encryption . . . . . . . . . . . . . . . . . . . . 5 3.4. Packet decryption . . . . . . . . . . . . . . . . . . . . 6 4. Cacha20-poly1305 . . . . . . . . . . . . . . . . . . . . . . 6 5. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 6 6. IANA Consideration . . . . . . . . . . . . . . . . . . . . . 7 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 7.1. Encrypting the packet length . . . . . . . . . . . . . . 7 7.2. Traffic analysis . . . . . . . . . . . . . . . . . . . . 7 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 8.1. Normative References . . . . . . . . . . . . . . . . . . 8 8.2. Informative References . . . . . . . . . . . . . . . . . 8 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 8 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 1. Introduction In the original specification of the Secure Shell protocol RFC 4253 [RFC4253], the encryption mechanism and message integrity mechanism are negotiated separately. The negotiation and the packet processing must be extended to support AEAD mechanisms (see RFC 5116 [RFC5116]) which provide both encryption and integrity. Please send comments on this draft to ietf-ssh@NetBSD.org. 1.1. AEAD An AEAD algorithm provides both confidentiality and integrity of messages. This section provides an overview, see RFC 5116 [RFC5116] for further details. For encryption, the inputs are a secret key K, a nonce N (which must be distinct for each mesage encrypted using the same key), a plaintext P, and associated data A, which is included in the integrity check, but not encrypted and usually not transmitted. The output is a ciphertext C, which includes additional data needed for checking the integrity. The length of the ciphertext is larger than the length of the plaintext, by an algorithm-specific constant. Moeller Expires August 25, 2016 [Page 2] Internet-Draft Using AEAD with Secure Shell February 2016 For decryption, the inputs are the key K, nonce N, the associated data A, and the ciphertext C. The output is either the original plaintext P or a special symbol FAIL. Recent interest in AEAD mechanisms are motivated by making cryptography easier for applications to use securely, since it eliminates application-specific design on how to combine encryption and integrity, and it discourages processing of decrypted messages which have not passed the integrity check. There is also some potential for improved performance, when encryption and integrity is done in a single step. 1.2. Secure Shell In this document, Secure Shell refers to the secure shell transport protocol, defined in RFC 4253 [RFC4253]. This is a binary protocol for exchange of SSH messages, including algorithm negotiation, encryption, integrity, and server authentication. A Secure Shell implementation also includes the user authentication protocol and the connection protocol running on top of the transport protocol; those higher-level parts of the Secure Shell family of protocols are out of scope for the this document. To support AEAD, we need to look closer at the algorithm negotiation, see Section 2 and the binary packet format, see Section 3. 1.3. Requirements Language 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 RFC 2119 [RFC2119]. 2. Negotiation For algorithm negotiation, both parties send a SSH_MSG_KEXINIT message, containing lists of supported algorithms in preference order. Of main interest here is this piece of the message name-list encryption_algorithms_client_to_server name-list encryption_algorithms_server_to_client For each direction, the first algorithm on the client's list which is supported by the server is the selected algorithm. This is specified in RFC 4253 [RFC4253], Sec. 7.1. To negotiate use of an AEAD algorithm, client and server adds the algorithm name to the encryption_algorithms_client_to_server and/or Moeller Expires August 25, 2016 [Page 3] Internet-Draft Using AEAD with Secure Shell February 2016 the encryption_algorithms_server_to_client name-lists in the SSH_MSG_KEXINIT message. For each direction, this specification applies if and only if the selected encryption algorithm is an AEAD mechanism, specified for use in Secure Shell with a reference to this specification. If the selected encryption algorithm for the client-to-server direction is of AEAD type, the contents of the mac_algorithms_client_to_server name-list is ignored, and similarly for the other direction. In particular, if one party advertises only AEAD algorithms, it MAY leave the corresponding list of MAC algorithms empty. 3. Binary packet format The binary packet format is defined in RFC 4253 [RFC4253], Section 6, as uint32 packet_length byte padding_length byte[n1] payload; n1 = packet_length - padding_length - 1 byte[n2] random padding; n2 = padding_length byte[m] mac (Message Authentication Code - MAC); m = mac_length To encrypt a packet as specified in RFC 4253 [RFC4253], the negotiated encryption algorithm is used to encrypt the data starting with the packet_length field and ending with the random padding; a total of packet_length + 4 bytes, and this size is required to be a multiple of the encryption algorithm's block size, typically 16 bytes. The MAC is applied to the cleartext, prepended by the packet sequence number, which is implicit and not transmitted over the wire. To decrypt a packet, the receiver must first decrypt the first block and extract the packet_length. It can then read and decrypt the rest of the packet and verify the MAC. If the MAC is correct, it strips the padding and passes the payload on for further processing. 3.1. Encrypting the packet length Conceptually, AEAD cannot do partial decryption of the packet. It is therefore not possible to encrypt the packet length together with the rest of the payload; the end of the message must be known prior to invoking the AEAD decryption function. The specification for a particular AEAD algorithms MAY specify any handling of the length field (or even a different binary packet format). However, the following method is RECOMMENDED, and it can be Moeller Expires August 25, 2016 [Page 4] Internet-Draft Using AEAD with Secure Shell February 2016 applied to any AEAD algorithm. Adhering to this method should make both specification and implementation of new AEAD ciphers easier. The inputs to length encryption are the session key, a nonce, and a four-byte message representing the packet length. Encrypt a message consisting of 4 zero bytes, using the session key and nonce, and empty associated data. Use the first four bytes of the ciphertext (the remainder of the ciphertext is discarded), and XOR with the length field to produce a four-byte encrypted packet length. The remainder of the ciphertext is discarded. The decryption procedure is identical. For many AEAD algorithms, this seemingly complex procedure boils down to CTR-mode encryption of the length using the underlying cipher. Implementations can choose whether to use such algorithm-specific shortcuts, or use the abstract AEAD interface. 3.2. The AEAD Nonce(s) The AEAD nonces are derived from the 32-bit sequence number, denoted I below. We define two nonces, N0 and N1. For N0, write the number 2*I in network byte order, using as many bytes as needed for the AEAD algorithm's specified nonce-length (since these are 33-bit numbers, the AEAD nonce length MUST be at least 5 bytes). Similarly form N1 by writing the number 2*I+1. TODO: Do we need to care about the "fixed-part"/"counter-part"? We could use separate "fixed part" to differentiate instead of the low bit, but I can't say if that makes anything simpler. 3.3. Packet encryption The inputs for encryption are the agreed session key K, the packet sequence number I, and the plaintext (including padding, but excluding the length field) P. The size of P MUST be a multiple of the algorithm block size. The associated data is formed as uint32_t sequence_number uint32_t packet_length To encrypt the data packet, first encrypt the length field using nonce N0, as described above. Then encrypt the rest of the packet, the plaintext P, using nonce N1 and the associated data A. The ciphertext includes additional authentication data, replacing the mac field in the encrypted when using a separate MAC. Moeller Expires August 25, 2016 [Page 5] Internet-Draft Using AEAD with Secure Shell February 2016 TODO: Drop the block size requirement? The AEAD interface doesn't expose any block size. Also drop the requirement of a minimum of 4 bytes padding? Unclear if there's any benefit when using AEAD. 3.4. Packet decryption To decrypt a packet, we initially know only the key and the sequence number. Form nonces N0, N1 based on the sequence number. Get the first four bytes, and decrypt it using the session key and nonce N0, as described above. Interpret it as the packet_length, and disconnect in case it exceeds the maximum supported by the implementation or is otherwise invalid. Using the packet length, get the corresponding ciphertext length (by adding the AEAD algorithm's tag length), and construct the associated data A. We are now ready to read the ciphtertext, and decrypt it using the key K, nonce N1 and associated data A. If the AEAD decryption fails, the implementation MAY reply with a SSH_DISCONNECT message with code SSH_DISCONNECT_MAC_ERROR, and it MUST disconnect. 4. Cacha20-poly1305 The chacha20-poly1305 AEAD is a combination of the chacha stream cipher and the poly1305 integrity algorithm, specified in RFC 7539 [RFC7539]. It is attractive because it provides high performance without requiring special hardware, and reasonably easy to implement without side-channel leaks. The cipher name "chacha20-poly1305" in SecureShell is defined to mean the AEAD algorithm, as defined in RFC 7539 [RFC7539], together with the length encryption scheme and binary packet processing defined in this specification. The "block size", as used to determine appropriate padding, is set to 8. Note that the length encryption boils down to plain chacha20-encryption, using a different nonce than for the main message. TODO: Naming is a bit confused, most papers use the name "chacha". Openssh and RFC 7539 write "chacha20", most likely for consistency with salsa20 (which has its own naming confusion). I'd prefer to drop the "20". 5. Compatibility The standard for using of AES-GCM with Secure Shell, RFC 5467 [RFC5647], differs from this specification by leaving the length field encrypted, and by different, more complex, negotiation rules. Moeller Expires August 25, 2016 [Page 6] Internet-Draft Using AEAD with Secure Shell February 2016 The AEAD cipher used under the name "chacha20-poly1305@openssh.com" is very similar to "chacha20-poly1305", but not compatible. The former predates RFC 7539 [RFC7539], and defines the AEAD construction slightly differently. It also encrypts the length field in a different way, using a separate key rather than a distinct nonces. The negotiation rules specified here are intended to be identical to those used by openssh. TODO: Refer to https://tools.ietf.org/html/draft-josefsson-ssh- chacha20-poly1305-openssh-00? It's unclear to me what "block size" is used by openssh. 6. IANA Consideration IANA is requested to update the SSH algorithm registry with the following entry: Encryption Algorithm Names Reference Note chacha20-poly1305 This Draft RECOMMENDED 7. Security Considerations The use of AEAD makes it easier to adopt new encryption schemes and use them in a secure manner. This is in contrast to the use of CBC- mode encryption and a separate MAC in the original Secure Shell protocol (for known weaknesses, see RFC 4344 [RFC4344]). 7.1. Encrypting the packet length The current specification RECOMMENDs that the packet length is encrypted, in order to avoid forcing users or applications to choose between using AEAD encryption and using traffic analysis countermeasures which require encrypted packet lengths. It is essential that the encryption of the packet lengths is independent from the authenticated encryption of the packet contents; otherwise, the response to an un-authenticated packet length, under the attacker's control, could reveal information about packet contents. 7.2. Traffic analysis The benefit of encrypting the packet length is debatable. Together with the use of SSH_MSG_IGNORE packets, encrypted packet lengths make it harder to find the boundaries based on observed TCP segment size and content. However, by itself, this is unlikely to prevent a sophisticated attacker from doing successful traffic analysis. The difficulty of attack and effective countermeasures are application Moeller Expires August 25, 2016 [Page 7] Internet-Draft Using AEAD with Secure Shell February 2016 specific, e.g, using Secure Shell for an interactive shell session, and using it to proxy web-browsing, are two quite different problems for traffic analysis. Further study is needed to define appropriate threat models and develop effective countermeasures. 8. References 8.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, . [RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253, January 2006, . [RFC7539] Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF Protocols", RFC 7539, DOI 10.17487/RFC7539, May 2015, . 8.2. Informative References [RFC4344] Bellare, M., Kohno, T., and C. Namprempre, "The Secure Shell (SSH) Transport Layer Encryption Modes", RFC 4344, DOI 10.17487/RFC4344, January 2006, . [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008, . [RFC5647] Igoe, K. and J. Solinas, "AES Galois Counter Mode for the Secure Shell Transport Layer Protocol", RFC 5647, DOI 10.17487/RFC5647, August 2009, . Appendix A. Acknowledgements The method for encrypting the length field was suggested by Bryan Ford. Moeller Expires August 25, 2016 [Page 8] Internet-Draft Using AEAD with Secure Shell February 2016 Author's Address Niels Moeller Google Email: nisse@google.com Moeller Expires August 25, 2016 [Page 9]