applying AES-GCM to secure shell: proposed "tweak"

[Tim Polk <[e-mail]>]

Folks,

The IESG is currently considering publication of draft-igoe-secsh-aes-
gcm-01, "AES Galois Counter Mode for the Secure Shell Transport Layer
Protocol", as an Informational RFC.  The draft specifies the
application of the Authenticated Encryption with Associated Data
(AEAD) block cipher mode AES Galois/Counter Mode to provide both
confidentiality and data integrity for SSH.  (See RFC 5116, "An
Interface and Algorithms for Authenticated Encryption", for a general
look at AEAD algorithms and NIST Special Publication 800-38D for the
specification of the GCM mode; see URLs below.)

The draft was designed to minimize the changes to RFC 4253 (the SSH
Transport Layer Protocol), so it encrypts the whole SSH binary packet,
including the packet_length field.

However, AEAD decryption as defined in both RFC 5116 and SP 800-38D
takes the ciphertext as input, and returns either (1) the plaintext if
the authentication succeeds or (2) failure. The ciphertext here is an
octet string of known length, not an ubounded stream.

Since the packet_length field is also encrypted, SSH cannot determine
the ciphertext boundary before passing the data to AEAD decryption.
(This differs from current SSH encryption modes where the data is
first decrypted, then the packet length field is parsed, and finally
the MAC is verified.)

Two solutions have been proposed: (1) explicitly allowing "partial
decryption" so that an implementation can recover the packet_length
without authenticating the data; or (2) sending the packet_length
unencrypted so that it is always available.

The first solution requires less security analysis about SSH, but more
analysis about the AEAD algorithm. The exposure of intermediate values
in AES GCM would require review, and it is inconsistent with RFC
5116. Even if this solution is determined to be secure for AES GCM,
this might not apply to other AEAD algorithms (where returning
plaintext fragments before authentication may not be even possible, or
may not be secure). In a more parochial concern, inconsistency with SP
800-38D means that current validation processes (i.e. NIST's FIPS
140-based Cryptographic Module Validation Program [CMVP]) would need
to be revised, as well as SP 800-38D, to permit use of this protocol
with validated modules.

The second solution (sending packet_length unencrypted) has a number
of desirable properties: it conforms to RFC 5116 so the design should
apply to any AEAD algorithm, and it is consistent with the algorithm
specification (NIST SP 800-38D).  It does require a change to the
padding calculations: since the plaintext for encryption excludes the
packet_length, the concatenation of the 'padding length', 'payload',
and 'random padding' MUST be a multiple of the cipher block size.
(This modifies a requirement from Section 6 of RFC 4253.)  Since this
calculation is algorithm specific anyway, it is hoped this would not
be an issue. As you might have guessed, I strongly prefer this
solution.  However, we are concerned about making such a change
without ensuring that the security implications have been thoroughly
reviewed.

The SSHv1 protocol revealed the exact plaintext length, which is
clearly undesirable in many situations (see e.g. link below).  In
SSHv2, the packet length includes the random padding, so sending it
unencrypted does not reveal the exact the plaintext length. Also, in
many cases the packet length can be inferred from the data stream
(e.g. TCP segment lengths). In applications where there is some fear
that the packet lengths might reveal sensitive information, the use of
random padding probably provides a much more effective countermeasure
than encrypting the packet_length.

So, it seems that encryption of the packet_length field would be of
little practical use, and might lead to a false sense of security.  As
a consequence, we hypothesize that sending packet_length in the clear
would not negatively impact the security of the protocol.

Before moving forward with this protocol using either of the proposed
solutions, we would appreciate feedback from this mailing list.
Questions to consider:

(1) does the exposure of the ssh packet length have significant
security implications for ssh itself?

(2) were applications that rely on ssh for security designed to take
advantage of the encrypted packet length?

(3) does the change in padding length calculation (caused by excluding
the packet_length from the ciphertext) impose a significant impediment
to migrating existing implementations?

Thanks,

Tim Polk
(Security co-AD and document sponsor)

P.S. I've tried to contact as many of the usual suspects as possible,  
but I am sure I have
missed some folks.   Please forward this to anyone I've left off  
distribution that might
have an interest!]

References:

http://tools.ietf.org/html/rfc5116
http://tools.ietf.org/html/draft-igoe-secsh-aes-gcm-01
http://csrc.nist.gov/publications/nistpubs/800-38D/SP-800-38D.pdf
http://www.openwall.com/advisories/OW-003-ssh-traffic-analysis/