TELNET Authentication Using KEA and SKIPJACK(1)

　　Network Working Group R. Housley

　　Request for Comments: 2951 T. Horting

　　Category: Informational P. Yee

　　SPYRUS

　　September 2000

　　TELNETAuthentication 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

　　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　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 and　support for the setup of data encryption keys. A simple token format　and set of exchanges delivers these services.

　　NonceA and NonceB used in this exchange are 64-bit bit strings. The　client generates NonceA, and the server generates NonceB. The nonce　value is selected randomly. The nonce is sent in a big endian form.

　　The encryption of the nonce will be done with the same mechanism that　the session will use, detailed in the next section.

　　Ra and Rb used in this exchange are 1024 bit strings and are defined　by the KEA Algorithm [4].

　　The IVa and IVb are 24 byte Initialization Vectors. They are　composed of "THIS IS NOT LEAF" followed by 8 random bytes.

　　CertA is the client's certificate. CertB is the server's　certificate. Both certificates are X.509 certificates [6] that　contain KEA public keys [7]. The client must validate the server's　certificate before using the KEA public key it contains. Likewise,　the server must validate the client's certificate before using the　KEA public key it contains.