Encryption using KEA and SKIPJACK
RFC 2773
| Document | Type |
RFC - Experimental
(February 2000; No errata)
Updates RFC 959
|
|
|---|---|---|---|
| Last updated | 2013-03-02 | ||
| Stream | IETF | ||
| Formats | plain text pdf html bibtex | ||
| Stream | WG state | (None) | |
| Document shepherd | No shepherd assigned | ||
| IESG | IESG state | RFC 2773 (Experimental) | |
| Consensus Boilerplate | Unknown | ||
| Telechat date | |||
| Responsible AD | (None) | ||
| Send notices to | (None) | ||
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
Show full document text