RFC 2951 (rfc2951) - Page 2 of 11
TELNET Authentication Using KEA and SKIPJACK
Alternative Format: Original Text Document
RFC 2951 TELNET Authentication Using KEA & SKIPJACK 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:
KEA_CERTA_RA 1
KEA_CERTB_RB_IVB_NONCEB 2
KEA_IVA_RESPONSEB_NONCEA 3
KEA_RESPONSEA 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 normally 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 -- replacing or augmenting the normal host
password mechanism;
* Server authentication -- normally done in conjunction with user
authentication;
* Session parameter negotiation -- in particular, encryption key
and attributes;
* Session protection -- primarily encryption of the data and
embedded command stream, but the encryption algorithm may also
provide data integrity.
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 determine
Housley, et al. Informational