Revision history [back]

Looks like an oversight in the telnet dissector.
Original added here: "updated the TELNET dissector to dissect encryption negotiation commands as specified by RFC 2946"

RFC 2952 - "Telnet Encryption: DES 64 bit Cipher Feedback"

1.  Command Names and Codes

   Encryption Type

      DES_CFB64        1

   Suboption Commands

      CFB64_IV         1
      CFB64_IV_OK      2
      CFB64_IV_BAD     3

2.  Command Meanings


   IAC SB ENCRYPT IS DES_CFB64 CFB64_IV <initial vector> IAC SE

The extra byte (01) before the IV in your data: Type-specific data: 011213141516171819 is the Suboption Command to indicate an IV follows.
I don't see any open issues related to this. Steps to open one here: ReportingBugs

Looks like an oversight in the telnet dissector. could go a step farther and break out the IV.
Original added here: "updated the TELNET dissector to dissect encryption negotiation commands as specified by RFC 2946"

RFC 2952 - "Telnet Encryption: DES 64 bit Cipher Feedback"

1.  Command Names and Codes

   Encryption Type

      DES_CFB64        1

   Suboption Commands

      CFB64_IV         1
      CFB64_IV_OK      2
      CFB64_IV_BAD     3

2.  Command Meanings


   IAC SB ENCRYPT IS DES_CFB64 CFB64_IV <initial vector> IAC SE

The extra byte (01) before the IV in your data: Type-specific data: 011213141516171819 is the Suboption Command to indicate an IV follows.
I don't see any open issues related to this. Steps to open one here: ReportingBugs

Looks like the telnet dissector could go a step farther and break out the IV.
Original added here: "updated the TELNET dissector to dissect encryption negotiation commands as specified by RFC 2946"

RFC 2952 - "Telnet Encryption: DES 64 bit Cipher Feedback"

1.  Command Names and Codes

   Encryption Type

      DES_CFB64        1

   Suboption Commands

      CFB64_IV         1
      CFB64_IV_OK      2
      CFB64_IV_BAD     3

2.  Command Meanings


   IAC SB ENCRYPT IS DES_CFB64 CFB64_IV <initial vector> IAC SE

The extra byte (01) before the IV in your data: Type-specific data: 011213141516171819 is the Suboption Command to indicate an IV follows.
I don't see any open issues related to this. Steps to open one here: ReportingBugs

#define TN_ENCTYPE_NULL                 0
#define TN_ENCTYPE_DES_CFB64            1  https://tools.ietf.org/html/rfc2952
#define TN_ENCTYPE_DES_OFB64            2  https://tools.ietf.org/html/rfc2953
#define TN_ENCTYPE_DES3_CFB64           3  https://tools.ietf.org/html/rfc2947
#define TN_ENCTYPE_DES3_OFB64           4  https://tools.ietf.org/html/rfc2948
#define TN_ENCTYPE_CAST5_40_CFB64       8  https://tools.ietf.org/html/rfc2950
#define TN_ENCTYPE_CAST5_40_OFB64       9  https://tools.ietf.org/html/rfc2949
#define TN_ENCTYPE_CAST128_CFB64        10  https://tools.ietf.org/html/rfc2950
#define TN_ENCTYPE_CAST128_OFB64        11  https://tools.ietf.org/html/rfc2949

The sender of this command generates a random 8 byte initial
vector, and sends it to the other side of the connection using the
"encryption type"_IV command.

Looks like the telnet dissector could go a step farther and break out the IV.
Original added here: "updated the TELNET dissector to dissect encryption negotiation commands as specified by RFC 2946"

RFC 2952 - "Telnet Encryption: DES 64 bit Cipher Feedback"

1.  Command Names and Codes

   Encryption Type

      DES_CFB64        1

   Suboption Commands

      CFB64_IV         1
      CFB64_IV_OK      2
      CFB64_IV_BAD     3

2.  Command Meanings


   IAC SB ENCRYPT IS DES_CFB64 CFB64_IV <initial vector> IAC SE

The extra byte (01) before the IV in your data: Type-specific data: 011213141516171819 is the Suboption Command to indicate an IV follows.
I don't see any open issues related to this. Steps to open one here: ReportingBugs

#define TN_ENCTYPE_NULL                 0
#define TN_ENCTYPE_DES_CFB64            1  https://tools.ietf.org/html/rfc2952
#define TN_ENCTYPE_DES_OFB64            2  https://tools.ietf.org/html/rfc2953
#define TN_ENCTYPE_DES3_CFB64           3  https://tools.ietf.org/html/rfc2947
#define TN_ENCTYPE_DES3_OFB64           4  https://tools.ietf.org/html/rfc2948
#define TN_ENCTYPE_CAST5_40_CFB64       8  https://tools.ietf.org/html/rfc2950
#define TN_ENCTYPE_CAST5_40_OFB64       9  https://tools.ietf.org/html/rfc2949
#define TN_ENCTYPE_CAST128_CFB64        10  https://tools.ietf.org/html/rfc2950
#define TN_ENCTYPE_CAST128_OFB64        11  https://tools.ietf.org/html/rfc2949

The RFCs for currently support supported encryption types use the same verbage:

The sender of this command generates a random 8 byte initial
vector, and sends it to the other side of the connection using the
"encryption type"_IV command.