Re: applying AES-GCM to secure shell: proposed "tweak" (fwd)

[David McGrew <[e-mail]>]

Hi Tim,

this email very nicely outlines the situation; some comments inline:

> ---------- Forwarded message ----------
> Date: Wed, 8 Apr 2009 09:02:00 -0400
> From: Tim Polk <[e-mail]>
> To: [e-mail]
> Cc: Tero Kivinen <[e-mail]>, Bill Sommerfeld  
> <[e-mail]>,
>   Chris Lonvick <[e-mail]>, [e-mail],
>   "Igoe, Kevin M." <[e-mail]>,
>   Jerome A. Solinas <[e-mail]>,
>   "<[e-mail]> Eronen" <[e-mail]>
> Subject: applying AES-GCM to secure shell: proposed "tweak"
>
> 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.

I also strongly prefer this solution, because partial decryption is  
counter to "authenticated encryption".   A lot of work has been done  
in the theoretical community and in standards groups in the direction  
of authenticated encryption, and it makes more sense to position SSH  
to benefit from that line work in the future.


>
> 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?
>

This message was forwarded to me (I'm not on the ssh list) so if  
security issues have been raised in further emails, I haven't seen  
them.  (If someone perceives a significant security implication in SSH  
itself, I would like to review it; please forward.)

Reading over the security considerations of RFC 4251, there are  
descriptions of various security issues due to the use of CBC.  I also  
noticed that it does not reference "Security Flaws Induced by CBC  
Padding", Vaudenay, EUROCRYPT'02, http://lasecwww.epfl.ch/pub/lasec/doc/Vau02a.ps 
, which is yet another security issue that can occur due to  
unauthenticated CBC (and SSH as it is currently defined requires that  
the first CBC block be decrypted prior to the MAC verification  
step).   These problems would not be present if we avoid partial- 
decryption and stick with authenticated encryption (and AE is what  
Vaudenay recommends in Section 7 of the above reference, FWIW).

best regards,

David

> 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/