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
