Encryption using KEA and SKIPJACK
RFC 2773

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

• Versions
• 01

Network Working Group                                        R. Housley
Request for Comments: 2773                                       P. Yee
Updates: 959                                                     SPYRUS
Category: Experimental                                          W. Nace
                                                                    NSA
                                                          February 2000

                   Encryption using KEA and SKIPJACK

Status of this Memo

   This memo defines an Experimental Protocol for the Internet
   community.  It does not specify an Internet standard of any kind.
   Discussion and suggestions for improvement are requested.
   Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2000).  All Rights Reserved.

Abstract

   This document defines a method to encrypt a file transfer using the
   FTP specification STD 9, RFC 959, "File Transfer Protocol (FTP)",
   (October 1985) [3] and RFC 2228, "FTP Security Extensions" (October
   1997) [1].  This method will use the Key Exchange Algorithm (KEA) to
   give mutual authentication and establish the data encryption keys.
   SKIPJACK is used to encrypt file data and the FTP command channel.

1.0 Introduction

   The File Transfer Protocol (FTP) provides no protocol security except
   for a user authentication password which is transmitted in the clear.
   In addition, the protocol does not protect the file transfer session
   beyond the original authentication phase.

   The Internet Engineering Task Force (IETF) Common Authentication
   Technology (CAT) Working Group has proposed security extensions to
   FTP.  These extensions allow the protocol to use more flexible
   security schemes, and in particular allows for various levels of
   protection for the FTP command and data connections.  This document
   describes a profile for the FTP Security Extensions by which these
   mechanisms may be provisioned using the Key Exchange Algorithm (KEA)
   in conjunction with the SKIPJACK symmetric encryption algorithm.

Housley, et al.               Experimental                      [Page 1]
RFC 2773           Encryption using KEA and SKIPJACK      February 2000

   FTP Security Extensions [1] provides:

      *  user authentication -- augmenting the normal password
         mechanism;

      *  server authentication -- normally done in conjunction with user
         authentication;

      *  session parameter negotiation -- in particular, encryption keys
         and attributes;

      *  command connection protection -- integrity, confidentiality, or
         both;

      *  data transfer protection -- same as for command connection
         protection.

   In order to support the above security services, the two FTP entities
   negotiate a mechanism.  This process is open-ended and completes when
   both entities agree on an acceptable mechanism or when the initiating
   party (always the client) is unable to suggest an agreeable
   mechanism.  Once the entities agree upon a mechanism, they may
   commence authentication and/or parameter negotiation.

   Authentication and parameter negotiation occur within an unbounded
   series of exchanges.  At the completion of the exchanges, the
   entities will either be authenticated (unilateral or mutually), and
   may, additionally, be ready to protect FTP commands and data.

   Following the exchanges, the entities negotiate the size of the
   buffers they will use in protecting the commands and data that
   follow.  This process is accomplished in two steps: the client offers
   a suggested buffer size and the server may either refuse it, counter
   it, or accept it.

   At this point, the entities may issue protected commands within the
   bounds of the parameters negotiated through the security exchanges.
   Protected commands are issued by applying the protection services
   required to the normal commands and Base64 encoding the results. The
   encoded results are sent as the data field within a ENC (integrity
   and confidentiality) command.  Base64 is an encoding for mapping
   binary data onto a textual character set that is able to pass through
   most 7-bit systems without loss.  The server sends back responses in
   new result codes which allow the identical protections and Base64
   encoding to be applied to the results.  Protection of the data
   transfers can be specified via the PROT command which supports the

Housley, et al.               Experimental                      [Page 2]
RFC 2773           Encryption using KEA and SKIPJACK      February 2000

   same protections as those afforded the other FTP commands.  PROT
   commands may be sent on a transfer-by-transfer basis, however, the
   session parameters may not be changed within a session.

2.0  Key Exchange Algorithm (KEA) Profile

   This paper profiles KEA with SKIPJACK to achieve certain security
   services when used in conjunction with the FTP Security Extensions