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