TELNET Authentication Using KEA and SKIPJACK
RFC 2951
Document | Type |
RFC - Informational
(September 2000; No errata)
Was draft-housley-telnet-auth-keasj (individual)
|
|
---|---|---|---|
Authors | Russ Housley , Todd Horting , Peter Yee | ||
Last updated | 2013-03-02 | ||
Stream | Legacy | ||
Formats | plain text html pdf htmlized bibtex | ||
Stream | Legacy state | (None) | |
Consensus Boilerplate | Unknown | ||
RFC Editor Note | (None) | ||
IESG | IESG state | RFC 2951 (Informational) | |
Telechat date | |||
Responsible AD | (None) | ||
Send notices to | (None) |
Network Working Group R. Housley Request for Comments: 2951 T. Horting Category: Informational P. Yee SPYRUS September 2000 TELNET Authentication Using KEA and SKIPJACK Status of this Memo This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2000). All Rights Reserved. Abstract This document defines a method to authenticate TELNET using the Key Exchange Algorithm (KEA), and encryption of the TELNET stream using SKIPJACK. Two encryption modes are specified; one provides data integrity and the other does not. The method relies on the TELNET Authentication Option. 1. Command Names and Codes AUTHENTICATION 37 Authentication Commands: IS 0 SEND 1 REPLY 2 NAME 3 Authentication Types: KEA_SJ 12 KEA_SJ_INTEG 13 Modifiers: AUTH_WHO_MASK 1 AUTH_CLIENT_TO_SERVER 0 AUTH_SERVER_TO CLIENT 1 Housley, et al. Informational [Page 1] 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 [Page 2] RFC 2951 TELNET Authentication Using KEA & SKIPJACK September 2000 the authentication protocol to be used, and possibly the remote user name to be used for authorization checking. Encryption is negotiated along with the type of the authentication. Authentication and parameter negotiation occur within an unbounded series of exchanges. The server proposes a preference-ordered list of authentication types (mechanisms) that it supports. In addition to listing the mechanisms it supports, the server qualifies each mechanism with a modifier that specifies whether encryption of data is desired. The client selects one mechanism from the list and responds to the server indicating its choice and the first set of authentication data needed for the selected authentication type. The client may ignore a request to encrypt data and so indicate, but the server may also terminate the connection if the client refuses encryption. The server and the client then proceed through whatever number of iterations is required to arrive at the requested authentication. Encryption is started immediately after the Authentication Option is completed. 3. Use of Key Exchange Algorithm (KEA) This paper specifies the method in which KEA is used to achieve TELNET Authentication. KEA (in conjunction with SKIPJACK) [4] provides authentication and confidentiality. Integrity may also be provided. TELNET entities may use KEA to provide mutual authentication andShow full document text