RFC 2946 (rfc2946) - Page 2 of 8
Telnet Data Encryption Option
Alternative Format: Original Text Document
RFC 2946 Telnet Data Encryption Option September 2000
DES3_CFB64 3
DES3_OFB64 4
CAST5_40_CFB64 8
CAST5_40_OFB64 9
CAST128_CFB64 10
CAST128_OFB64 11
Following historical practice, future encryption type numbers
will be assigned by the IANA under a First Come First Served
policy as outlined by RFC 2434 [3]. Despite the fact that
authentication type numbers are allocated out of an 8-bit number
space (as are most values in the telnet specification) it is not
anticipated that the number space is or will become in danger of
being exhausted. However, if this should become an issue, when
over 50% of the number space becomes allocated, the IANA shall
refer allocation requests to either the IESG or a designated
expert for approval.
2. Command Meanings
IAC WILL ENCRYPT
The sender of this command is willing to send encrypted data.
IAC WONT ENCRYPT
The sender of this command refuses to send encrypted data.
IAC DO ENCRYPT
The sender of this command is willing to receive encrypted data.
IAC DONT ENCRYPT
The sender of this command refuses to accept encrypted data.
IAC SB ENCRYPT SUPPORT encryption-type-list IAC SE
The sender of this command is stating which types of encryption it
will support. Only the side of the connection that is DO ENCRYPT
may send the SUPPORT command. The current types of encryption are
listed in the current version of the Assigned Numbers document
[1].
The encryption-type-list may only include types which can actually
be supported during the current session. If ENCRYPT is negotiated
in conjunction with AUTH the SUPPORT message MUST NOT be sent
until after the session key has been determined. Otherwise,
Ts'o Standards Track