TELNET Authentication Using KEA and SKIPJACK
RFC 2951

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 05

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 and