RFC 2943 (rfc2943) - Page 2 of 12
TELNET Authentication Using DSA
Alternative Format: Original Text Document
RFC 2943 TELNET Authentication Using DSA September 2000
AUTH_HOW_MASK 2
AUTH_HOW_ONE_WAY 0
AUTH_HOW_MUTUAL 2
ENCRYPT_MASK 20
ENCRYPT_OFF 0
ENCRYPT_USING_TELOPT 4
ENCRYPT_AFTER_EXCHANGE 16
ENCRYPT_RESERVED 20
INI_CRED_FWD_MASK 8
INI_CRED_FWD_OFF 0
INI_CRED_FWD_ON 8
Sub-option Commands:
DSS_INITIALIZE 1
DSS_TOKENBA 2
DSS_CERTA_TOKENAB 3
DSS_CERTB_TOKENBA2 4
2. TELNET Security Extensions
TELNET, as a protocol, has no concept of security. Without
negotiated options, it merely passes characters back and forth
between the NVTs represented by the two TELNET processes. In its
most common usage as a protocol for remote terminal access (TCP port
23), TELNET connects to a server that requires user-level
authentication through a user name and password in the clear; the
server does not authenticate itself to the user.
The TELNET Authentication Option provides for user authentication and
server authentication. User authentication replaces or augments the
normal host password mechanism. Server authentication is normally
done in conjunction with user authentication.
In order to support these security services, the two TELNET entities
must first negotiate their willingness to support the TELNET
Authentication Option. Upon agreeing to support this option, the
parties are then able to perform sub-option negotiations to the
authentication protocol to be used, and possibly the remote user name
to be used for authorization checking.
Authentication and parameter negotiation occur within an unbounded
series of exchanges. The server proposes a preference-ordered list
of authentication types (mechanisms) which it supports. In addition
to listing the mechanisms it supports, the server qualifies each
mechanism with a modifier that specifies whether the authentication
Housley, et al. Standards Track