[Bug 3839] New: Is OpenSSH violating RFC4253 section 6

[bugzilla-daemon at mindrot.org]

https://bugzilla.mindrot.org/show_bug.cgi?id=3839

            Bug ID: 3839
           Summary: Is OpenSSH violating RFC4253 section 6
           Product: Portable OpenSSH
           Version: 10.0p2
          Hardware: Other
                OS: Linux
            Status: NEW
          Severity: minor
          Priority: P5
         Component: ssh
          Assignee: unassigned-bugs at mindrot.org
          Reporter: nicolas.baranger at 3xo.fr

Created attachment 3884
  --> https://bugzilla.mindrot.org/attachment.cgi?id=3884&action=edit
SSH_MSG_NEWKEYS captured frame while rekey-ing

Currently working on Wireshark / TShark SSH dissector (decryptor) and
adding Post-Quantum algorithms and REKEY support, I was inspecting
frames and I discover that in case of a REKEY event, the
SSH_MSG_NEWKEYS send by the client seems to violate RFC4253 section 6: 

I was using mlkem768x25519-sha256 as algorithm and chacha20-poly1305 as
Cipher (stream AEAD Cipher)

Here is the NEWKEY frame OpenSSH sent after the second SSH_MSG_KEXINIT
and SSH_MSG_ECDH_REPLY:

After decryption, here is the SSH part of the frame:
00 00 00 08 06 15 cb 83 fd 7e 37 ab

Let break it down: 

00 00 00 08 : Length prefix (value 8) --> length 4 bytes
06 : padding length value: 6 bytes of padding --> length 1 byte
15 : effective payload of length 1, value decimal 21 (SSH_MSG_NEWKEYS)
--> length 1 byte
cb 83 fd 7e 37 ab: padding string of 6 bytes as defined by
padding_length field --> length 4 bytes

As you can see, the total length of this packet is 4 + 1 + 1 + 6 = 12
bytes.

But RFC4253 section 6 says: 

> Each packet is in the following format:
>
>       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
>
>       packet_length
>          The length of the packet in bytes, not including 'mac' or the
>          'packet_length' field itself.
>
>       padding_length
>          Length of 'random padding' (bytes).
>
>       payload
>          The useful contents of the packet.  If compression has been
>          negotiated, this field is compressed.  Initially, compression
>          MUST be "none".
>
>       random padding
>          Arbitrary-length padding, such that the total length of
>          (packet_length || padding_length || payload || random padding)
>          is a multiple of the cipher block size or 8, whichever is
>          larger.  There MUST be at least four bytes of padding.  The
>          padding SHOULD consist of random bytes.  The maximum amount of
>          padding is 255 bytes.
>
>       mac
>          Message Authentication Code.  If message authentication has
>          been negotiated, this field contains the MAC bytes.  Initially,
>          the MAC algorithm MUST be "none".
>
>    Note that the length of the concatenation of 'packet_length',
>    'padding_length', 'payload', and 'random padding' MUST be a multiple
>    of the cipher block size or 8, whichever is larger.  This constraint
>    MUST be enforced, even when using stream ciphers.  Note that the
>    'packet_length' field is also encrypted, and processing it requires
>    special care when sending or receiving packets.  Also note that the
>    insertion of variable amounts of 'random padding' may help thwart
>    traffic analysis.
>
>    The minimum size of a packet is 16 (or the cipher block size,
>    whichever is larger) bytes (plus 'mac').  Implementations SHOULD
>    decrypt the length after receiving the first 8 (or cipher block size,
>    whichever is larger) bytes of a packet.


So why OpenSSH is sending a packet with a length of 12 ?
Is there something I missed ? (particularly with AEAD ciphers ?)

I attached the picture of the decrypted captured frame.

Thanks for help

Kind regards,
Nicolas Baranger

-- 
You are receiving this mail because:
You are watching the assignee of the bug.