Internet DRAFT - draft-nisse-secsh-aead
draft-nisse-secsh-aead
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,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253,
January 2006, <http://www.rfc-editor.org/info/rfc4253>.
[RFC7539] Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF
Protocols", RFC 7539, DOI 10.17487/RFC7539, May 2015,
<http://www.rfc-editor.org/info/rfc7539>.
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,
<http://www.rfc-editor.org/info/rfc4344>.
[RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated
Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008,
<http://www.rfc-editor.org/info/rfc5116>.
[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,
<http://www.rfc-editor.org/info/rfc5647>.
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]
