Secure Telnet Working Group                    Russell Housley (SPYRUS)
                                                  Todd Horting (SPYRUS)
Internet-Draft                                       Peter Yee (SPYRUS)
Expire in six months                                          July 1998

              Telnet Authentication Using KEA and SKIPJACK


Status of this Memo

   This document is an Internet-Draft. Internet-Drafts are working
   documents of the Internet Engineering Task Force (IETF), its areas,
   and its working groups.

   Note that other groups may also distribute working documents as

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time. It is inappropriate to use Internet- Drafts as reference
   material or to cite them other than as "work in progress."

   To view the entire list of current Internet-Drafts, please check the
   "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
   Directories on (Africa), (Northern
   Europe), (Southern Europe), (Pacific
   Rim), (US East Coast), or (US West Coast).

   Distribution of this memo is unlimited.  Please send comments to the
   <> mailing list.


   This document defines a method to authenticate telnet using the Key
   Exchanage Algorithm (KEA), and encryption of the telnet stream using
   SKIPJACK.  Two encryption modes are specified; one provides data
   integrity and the other does not.  It relies on the Telnet
   Authentication Option [1].

1 Introduction

   The Telnet protocol provides no protocol security. Telnet servers may
   require users to login.  This is typically a host level login

Housley, Horting & Yee                                          [Page 1]

INTERNET DRAFT                                                 July 1998

   consisting of a user name and a password, transmitted in the clear.

   The mechanism specified in this document relies on the Telnet
   Authentication Option [1].

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
     *  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 and Data Encryption Options.  Upon agreeing to
   support these options, the parties are then able to perform
   suboptions 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) which it supports.  In addition
   to listing the mechanisms it supports, the server qualifies each
   mechanism with a modifier that specifies whether the authentication
   is to be unilateral or mutual, and in which direction the
   authentication is to be performed, and if 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

Housley, Horting & Yee                                          [Page 2]

INTERNET DRAFT                                                 July 1998

   encryption.  The server and the client then proceed through whatever
   number of iterations is required to arrive at the requested

   If encryption is requested, it is started immediately after the
   Authentication options are completed.  Afterwards either party may
   use the Data Encryption Options to turn off encryption, but once this
   has been disabled, there is no ability to re-enable encryption
   without repeating the complete authentication phase.

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) provides
   authentication, integrity and confidentiality.  Figure 1 illustrates
   the authentication mechanism.

   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.

   The nonce used in this exchanged is a 64 bit unsigned integer.  The
   server generates one, and the client generates another.  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.

   In figure 1 the two-octet authentication type pair is denoted by
   '0?06'.  This will be filled in with either hexadecimal '0C06' for
   KEA SKIPJACK without integrity mechanism or '0D06' for KEA SKIPJACK
   with integrity mechanism.

Housley, Horting & Yee                                          [Page 3]

INTERNET DRAFT                                                 July 1998

    Client (Party A)                   Server (Party B)

                                       <-- IAC DO AUTHENTICATION


                                       <-- IAC SB AUTHENTICATION SEND
                                           <list of authentication options>
                                           IAC SE

    NAME <user name>               -->

    '0?06' '1' CertA||Ra IAC SE    -->

                                       <-- IAC SB AUTHENTICATION REPLY
                                           '0?06' '2'
                                                      Encrypt( NonceB )
                                           IAC SE

    '0?06' '3'
    IV'||Encrypt( NonceB+1||NonceA )
    IAC SE                         -->

                                      <-- IAC SB AUTHENTICATION REPLY
                                          '0?06' '4' Encrypt( NonceA+1 )
                                          IAC SE

                                 Figure 1

   On completing these exchanges, the parties have a common SKIPJACK
   key.  Mutual authentication is provided by verification of the
   certificates used to establish the SKIPJACK encryption key and
   successful use of the derived SKIPJACK session key.  To protect from
   an active attacker, encryption will take place after successful
   authentication.  There will be no way to turn off encryption and
   safely turn it back on; repeating the entire authentication is the
   only safe way to restart it.  If the user does not want to use
   encryption, he will have to logoff and logon with the desired
   security mechanism.

Housley, Horting & Yee                                          [Page 4]

INTERNET DRAFT                                                 July 1998

3.1  SKIPJACK Modes

   There are two distinct modes for encrypting telnet streams; one
   provides integrity and the other does not.  Because telnet is
   normally operated in a character-by-character mode, the KEA SKIPJACK
   with stream integrity mechanism requires the transmission of 4 bytes
   for every telnet data byte.  However, a more simplified mode KEA
   SKIPJACK without integrity mechanism will only require the
   transmission of one byte for every telnet data byte.

   The cryptographic mode for KEA SKIPJACK with stream integrity is
   Cipher Feedback on 32 bits of data (CFB-32) and the mode of KEA
   SKIPJACK is Cipher Feedback on 8 bits of data (CFB-8).

3.1.1  SKIPJACK without stream integrity

   The first and least complicated mode is the SKIPJACK CFB-8.  This
   mode provides no stream integrity.

   For SKIPJACK without stream integrity, the two-octet authentication
   type pair (0?06 in Figure 1) is "KEA_SJ CLIENT_TO_SERVER MUTUAL
   ENCRYPT_ON INI_CRED_FWD_OFF".  This is encoded as two-octets: '0C06'
   in hexadecimal.  This indicates that the KEA SKIPJACK without
   integrity mechanism will be used for mutual authentication and telnet
   stream encryption.

3.1.2  SKIPJACK with stream integrity

   SKIPJACK with stream integrity is more complicated.  It uses a hash
   function to bind integrity into the encryption stream as follows:

       Set H0 to be the SHA-1 [3] hash of a zero length string.
       Cn is the nth character in the stream.
       Hn = SHA-1( Hn-1||Cn ), where Hn is the hash value
            associated with the nth character in the stream.
       ICVn is set to the three most significant bytes of Hn.
       Transmit Encrypt( Cn||ICVn ).

   The ciphertext that is transmitted is the SKIPJACK CFB-32 encryption
   of ( Cn||ICVn ).  The receiving end of the Telnet link reverses the
   process, first decrypting the ciphertext, separating Cn and ICVn,
   recalculating Hn, recalculating ICVn, and then comparing the received
   ICVn with the recalculated ICVn.  Integrity is indicated if the
   comparison succeeds, and Cn can then be processed normally as part of
   the Telnet stream.  Failure of the comparison indicates some loss of
   integrity, whether due to active manipulation or loss of
   cryptographic synchronization.  In either case, the only recourse is
   to drop the telnet connection and start over.

Housley, Horting & Yee                                          [Page 5]

INTERNET DRAFT                                                 July 1998

   For SKIPJACK with stream integrity, the two-octet authentication type
   ENCRYPT_ON INI_CRED_FWD_OFF".  This is encoded as two-octets: '0D06'
   in hexadecimal.  This indicates that the KEA SKIPJACK with integrity
   mechanism will be used for mutual authentication and telnet stream

3.1.3  Telnet SYNCH Handling

   Telnet supports a "Synch" mechanism to solve the problem of Telnet
   control commands from being blocked by network flow control.
   Basically, the sender of the Synch is telling the recipient to
   discard all incoming data except Telnet commands until the DM (and
   end of urgent) is reached.  The Synch signal is sent via a TCP Urgent
   notification, but does not arrive out of sequence, all data received
   will be decrypted and only acted upon if it is a Telnet command.
   Since sequence is preserved, no special cryptographic processing is

4.0  Security Considerations

   This entire memo is about security mechanisms.  For KEA to provide
   the authentication discussed, the implementation must protect the
   private key from disclosure.  Likewise, the SKIPJACK keys must be
   protected form disclosure.

   By linking the enabling of encryption as a side effect of successful
   authentication, protection is provided against an active attacker.
   If encryption were enabled as a separate negotiation, it would
   provide a window of vulnerability from when the authentication
   completes, up to and including the negotiation to turn on encryption.
   The only safe way to restart encryption, if it is turned off, is to
   repeat the entire authentication process.

5.0  Acknowledgements

   We would like to thank William Nace for support during implementation
   of this specification.

Housley, Horting & Yee                                          [Page 6]

INTERNET DRAFT                                                 July 1998

6.0  References

   [1] - Borman, David A. "Telnet Authentication Option".
         RFC 1416.  February 1993.

   [2] - T. Ts'o, "Telnet Data Encryption Option".
         <draft-tso-telnet-auth-enc-00.txt>, February 1998.

   [3] - Secure Hash Standard. FIPS Pub 180-1. April 17, 1995.

7.0  Author's Address

   Russell Housley
   PO Box 1198
   Herndon, VA 20172
   Phone: +1 703 435-7344

   Todd Horting
   PO Box 1198
   Herndon, VA 20172
   Phone: +1 703 435-4711

   Peter Yee
   2460 N. First Street
   Suite 100
   San Jose, CA 95131-1023
   Phone: +1 408 432-8180

Housley, Horting & Yee                                          [Page 7]