draft-ietf-cat-ftpkeasj-00.txt   draft-ietf-cat-ftpkeasj-01.txt 
CAT Working Group Russell Housley (SPYRUS) CAT Working Group Russell Housley (SPYRUS)
<draft-ietf-cat-ftpkeasj-00.txt> William A. Nace (NSA) <draft-ietf-cat-ftpkeasj-01.txt> William A. Nace (NSA)
Updates: RFC 959 Peter Yee (SPYRUS) Updates: RFC 959 Peter Yee (SPYRUS)
Internet-Draft Expire in six months Internet-Draft
Expire in six months January 1999
Encryption using KEA and SKIPJACK Encryption using KEA and SKIPJACK
Status of this Memo Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working doc- This document is an Internet-Draft. Internet-Drafts are working
uments of the Internet Engineering Task Force (IETF), its areas, and documents of the Internet Engineering Task Force (IETF), its areas,
its working groups. Note that other groups may also distribute work- and its working groups. Note that other groups may also distribute
ing documents as Internet-Drafts. working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference mate- time. It is inappropriate to use Internet-Drafts as reference
rial or to cite them other than as ''work in progress.'' material or to cite them other than as ''work in progress.''
To learn the current status of any Internet-Draft, please check the To learn the current status of any Internet-Draft, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ds.internic.net (US East Coast), nic.nordu.net Directories on ds.internic.net (US East Coast), nic.nordu.net
Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim).
Distribution of this memo is unlimited. Please send comments to the Distribution of this memo is unlimited. Please send comments to the
<cat-ietf@mit.edu> mailing list. <cat-ietf@mit.edu> mailing list.
Abstract Abstract
This document defines a method to encrypt a file transfer using the This document defines a method to encrypt a file transfer using the
FTP specification RFC 959, "FILE TRANSFER PROTOCOL (FTP)" (October FTP specification RFC 959, 'FILE TRANSFER PROTOCOL (FTP)' (October
1985) and the work in progress document "FTP Security Extensions" 1985) and the work in progress document 'FTP Security Extensions'
<draft-ietf-cat-ftpsec-09.txt>[1]. This method will use the Key <draft-ietf-cat-ftpsec-09.txt>[1]. This method will use the Key
Exchange Algorithm (KEA) to give mutual authentication and establish Exchange Algorithm (KEA) to give mutual authentication and establish
the data encryption keys. SKIPJACK is used to encrypt file data and the data encryption keys. SKIPJACK is used to encrypt file data and
the FTP command channel. the FTP command channel.
1.0 Introduction 1.0 Introduction
The File Transfer Protocol (FTP) provides no protocol security except The File Transfer Protocol (FTP) provides no protocol security except
for a user authentication password which is transmitted in the clear. for a user authentication password which is transmitted in the clear.
In addition, the protocol does not protect the file transfer session In addition, the protocol does not protect the file transfer session
beyond the original authentication phase. beyond the original authentication phase.
The Internet Engineering Task Force (IETF) Common Authentication The Internet Engineering Task Force (IETF) Common Authentication
Technology (CAT) Working Group has proposed security extensions to Technology (CAT) Working Group has proposed security extensions to
FTP. These extensions allow the protocol to use more flexible secu- FTP. These extensions allow the protocol to use more flexible
rity schemes, and in particular allows for various levels of protec- security schemes, and in particular allows for various levels of
tion for the FTP command and data connections. This document protection for the FTP command and data connections. This document
describes a profile for the FTP Security Extensions by which these describes a profile for the FTP Security Extensions by which these
mechanisms may be provisioned using the Key Exchange Algorithm (KEA) mechanisms may be provisioned using the Key Exchange Algorithm (KEA)
in conjunction with the SKIPJACK symmetric encryption algorithm. in conjunction with the SKIPJACK symmetric encryption algorithm.
The FTP Security Extensions are likely to become a standards track The FTP Security Extensions are likely to become a standards track
RFC in 1997. It provides: RFC in 1997. It provides:
* user authentication -- augmenting the normal password mechanism; * user authentication -- augmenting the normal password mechanism;
* server authentication -- normally done in conjunction with user * server authentication -- normally done in conjunction with user
skipping to change at page 2, line 32 skipping to change at page 2, line 32
* command connection protection -- integrity, confidentiality, or * command connection protection -- integrity, confidentiality, or
both; both;
* data transfer protection -- same as for command connection * data transfer protection -- same as for command connection
protection. protection.
In order to support the above security services, the two FTP entities In order to support the above security services, the two FTP entities
negotiate a mechanism. This process is open-ended and completes when negotiate a mechanism. This process is open-ended and completes when
both entities agree on an acceptable mechanism or when the initiating both entities agree on an acceptable mechanism or when the initiating
party (always the client) is unable to suggest an agreeable mecha- party (always the client) is unable to suggest an agreeable
nism. Once the entities agree upon a mechanism, they may commence mechanism. Once the entities agree upon a mechanism, they may
authentication and/or parameter negotiation. commence authentication and/or parameter negotiation.
Authentication and parameter negotiation occur within an unbounded Authentication and parameter negotiation occur within an unbounded
series of exchanges. At the completion of the exchanges, the enti- series of exchanges. At the completion of the exchanges, the
ties will either be authenticated (unilateral or mutually), and may, entities will either be authenticated (unilateral or mutually), and
additionally, be ready to protect FTP commands and data. may, additionally, be ready to protect FTP commands and data.
Following the exchanges, the entities negotiate the size of the Following the exchanges, the entities negotiate the size of the
buffers they will use in protecting the commands and data that fol- buffers they will use in protecting the commands and data that
low. This process is accomplished in two steps: the client offers a follow. This process is accomplished in two steps: the client offers
suggested buffer size and the server may either refuse it, counter a suggested buffer size and the server may either refuse it, counter
it, or accept it. it, or accept it.
At this point, the entities may issue protected commands within the At this point, the entities may issue protected commands within the
bounds of the parameters negotiated through the security exchanges. bounds of the parameters negotiated through the security exchanges.
Protected commands are issued by applying the protection services Protected commands are issued by applying the protection services
required to the normal commands and Base64 encoding the results. The required to the normal commands and Base64 encoding the results. The
encoded results are sent as the data field within a ENC (integrity encoded results are sent as the data field within a ENC (integrity
and confidentiality) command. Base64 is an encoding for mapping and confidentiality) command. Base64 is an encoding for mapping
binary data onto a textual character set that is able to pass through 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 most 7-bit systems without loss. The server sends back responses in
new result codes which allow the identical protections and Base64 new result codes which allow the identical protections and Base64
encoding to be applied to the results. Protection of the data trans- encoding to be applied to the results. Protection of the data
fers can be specified via the PROT command which supports the same transfers can be specified via the PROT command which supports the
protections as those afforded the other FTP commands. PROT commands same protections as those afforded the other FTP commands. PROT
may be sent on a transfer-by-transfer basis, however, the session commands may be sent on a transfer-by-transfer basis, however, the
parameters may not be changed within a session. session parameters may not be changed within a session.
2.0 Key Exchange Algorithm (KEA) Profile 2.0 Key Exchange Algorithm (KEA) Profile
This paper profiles KEA with SKIPJACK to achieve certain security This paper profiles KEA with SKIPJACK to achieve certain security
services when used in conjunction with the FTP Security Extensions services when used in conjunction with the FTP Security Extensions
framework. FTP entities may use KEA to give mutual authentication framework. FTP entities may use KEA to give mutual authentication
and establish data encryption keys. We specify a simple token format and establish data encryption keys. We specify a simple token format
and set of exchanges to deliver these services. Functions that may and set of exchanges to deliver these services. Functions that may
be performed by the Fortezza Crypto Card. be performed by the Fortezza Crypto Card.
The reader should be familiar with the extensions in order to under- The reader should be familiar with the extensions in order to
stand the protocol steps that follow. In the context of the FTP understand the protocol steps that follow. In the context of the FTP
Security Extensions, we suggest the usage of KEA with SKIPJACK for Security Extensions, we suggest the usage of KEA with SKIPJACK for
authentication, integrity, and confidentiality. authentication, integrity, and confidentiality.
A client may mutually authenticate with a server. What follows are A client may mutually authenticate with a server. What follows are
the protocol steps necessary to perform KEA authentication under the the protocol steps necessary to perform KEA authentication under the
FTP Security Extensions framework. Where failure modes are encoun- FTP Security Extensions framework. Where failure modes are
tered, the return codes follow those specified in the Extensions. encountered, the return codes follow those specified in the
They are not enumerated in this document as they are invariant among Extensions. They are not enumerated in this document as they are
the mechanisms used. The certificates are ASN.1 encoded. invariant among the mechanisms used. The certificates are ASN.1
encoded.
The exchanges detailed below presume a working knowledge of the FTP The exchanges detailed below presume a working knowledge of the FTP
Security Extensions. The notation for concatenation is " || ". Security Extensions. The notation for concatenation is " || ".
Decryption of encrypted data and certification path validation is Decryption of encrypted data and certification path validation is
implicitly assumed, but is not shown. implicitly assumed, but is not shown.
--------------------------------------------------------------------- ---------------------------------------------------------------------
Client Server Client Server
AUTH KEA-SKIPJACK --> AUTH KEA-SKIPJACK -->
skipping to change at page 4, line 27 skipping to change at page 4, line 29
In order to ensure that the length of the plain text is a multiple of In order to ensure that the length of the plain text is a multiple of
the cryptographic block size, padding shall be performed as follows. the cryptographic block size, padding shall be performed as follows.
The input to the SKIPJACK CBC encryption process shall be padded to a The input to the SKIPJACK CBC encryption process shall be padded to a
multiple of 8 octets. Let n be the length in octets of the input. multiple of 8 octets. Let n be the length in octets of the input.
Pad the input by appending 8 - (n mod 8) octets to the end of the Pad the input by appending 8 - (n mod 8) octets to the end of the
message, each having the value 8 - (n mod 8), the number of octets message, each having the value 8 - (n mod 8), the number of octets
being added. In hexadecimal, he possible pad strings are: 01, 0202, being added. In hexadecimal, he possible pad strings are: 01, 0202,
030303, 04040404, 0505050505, 060606060606, 07070707070707, and 030303, 04040404, 0505050505, 060606060606, 07070707070707, and
0808080808080808. All input is padded with 1 to 8 octets to produce 0808080808080808. All input is padded with 1 to 8 octets to produce
a multiple of 8 octets in length. This pad technique is used when- a multiple of 8 octets in length. This pad technique is used
ever SKIPJACK CBC encryption is performed. whenever SKIPJACK CBC encryption is performed.
An ICV is calculated over the plaintext security label and padding. An ICV is calculated over the plaintext security label and padding.
The ICV algorithm used is the 32-bit one's complement addition of The ICV algorithm used is the 32-bit one's complement addition of
each 32-bit block followed by 32 zero bits. This ICV technique is each 32-bit block followed by 32 zero bits. This ICV technique is
used in conjunction with SKIPJACK CBC encryption to provide data used in conjunction with SKIPJACK CBC encryption to provide data
integrity. integrity.
--------------------------------------------------------------------- ---------------------------------------------------------------------
Label Type 1 Octet Label Type 1 Octet
Label Length 4 octets Label Length 4 octets
skipping to change at page 5, line 18 skipping to change at page 5, line 18
2-255 Reserved for Future Use To Be Determined 2-255 Reserved for Future Use To Be Determined
--------------------------------------------------------------------- ---------------------------------------------------------------------
Figure 3 Figure 3
FTP command channel operations are now confidentiality protected. To FTP command channel operations are now confidentiality protected. To
provide integrity, the command sequence number, padding, and ICV are provide integrity, the command sequence number, padding, and ICV are
appended to each command prior to encryption. appended to each command prior to encryption.
Sequence integrity is provided by using a 16-bit sequence number Sequence integrity is provided by using a 16-bit sequence number
which is incremented for each command. The sequence number is ini- which is incremented for each command. The sequence number is
tialized with the least significant 16-bits of Ra. The server initialized with the least significant 16-bits of Ra. The server
response will include the same sequence number as the client command. response will include the same sequence number as the client command.
An ICV is calculated over the individual commands (including the car- An ICV is calculated over the individual commands (including the
riage return and line feed required to terminate commands), the carriage return and line feed required to terminate commands), the
sequence number, and pad. sequence number, and pad.
--------------------------------------------------------------------- ---------------------------------------------------------------------
Client Server Client Server
ENC Base64(Encrypt("PBSZ 65535" ENC Base64(Encrypt("PBSZ 65535"
|| SEQ || pad || ICV )) --> || SEQ || pad || ICV )) -->
<-- 632 Base64(Encrypt("200" || <-- 632 Base64(Encrypt("200" ||
SEQ || pad || ICV)) SEQ || pad || ICV))
ENC Base64(Encrypt("USER yee" ENC Base64(Encrypt("USER yee"
skipping to change at page 5, line 47 skipping to change at page 5, line 47
ENC Base64(Encrypt("PASS ENC Base64(Encrypt("PASS
fortezza" || SEQ || fortezza" || SEQ ||
pad || ICV)) --> pad || ICV)) -->
<-- 631 Base64(Sign("230")) <-- 631 Base64(Sign("230"))
--------------------------------------------------------------------- ---------------------------------------------------------------------
Figure 4 Figure 4
After decryption, both parties verifying the integrity of the PBSZ After decryption, both parties verifying the integrity of the PBSZ
commands by checking for the expected sequence number and correct commands by checking for the expected sequence number and correct
ICV. The correct SKIPJACK key calculation, ICV checking, and the ICV. The correct SKIPJACK key calculation, ICV checking, and the
validation of the certificates containing the KEA public keys pro- validation of the certificates containing the KEA public keys
vides mutual identification and authentication. provides mutual identification and authentication.
--------------------------------------------------------------------- ---------------------------------------------------------------------
Client Server Client Server
ENC Base64(Encrypt("PROT P" || ENC Base64(Encrypt("PROT P" ||
SEQ || pad || ICV)) --> SEQ || pad || ICV)) -->
<-- 632 Base64(Encrypt("200" || SEQ <-- 632 Base64(Encrypt("200" || SEQ
|| pad || ICV)) || pad || ICV))
--------------------------------------------------------------------- ---------------------------------------------------------------------
Figure 5 Figure 5
skipping to change at page 7, line 4 skipping to change at page 7, line 4
Pad 1 to 8 octets Pad 1 to 8 octets
ICV 8 octets ICV 8 octets
--------------------------------------------------------------------- ---------------------------------------------------------------------
Figure 7 Figure 7
2.1 Pre-encrypted File Support 2.1 Pre-encrypted File Support
In order to support both on-the-fly encryption and pre-encrypted In order to support both on-the-fly encryption and pre-encrypted
files, a token is defined for carrying a file encryption key (FEK). files, a token is defined for carrying a file encryption key (FEK).
To prevent truncation and ensure file integrity, the token also To prevent truncation and ensure file integrity, the token also
includes a hash computed on the complete file. The token also con- includes a hash computed on the complete file. The token also
tains the security label associate with the file. This FEK is contains the security label associate with the file. This FEK is
wrapped in the session TEK. The token is encrypted in the session wrapped in the session TEK. The token is encrypted in the session
TEK using SKIPJACK CBC mode. The token contains a 12 octet wrapped TEK using SKIPJACK CBC mode. The token contains a 12 octet wrapped
FEK, a 20 octet file hash, a 24 octet file IV, a 1 octet label type, FEK, a 20 octet file hash, a 24 octet file IV, a 1 octet label type,
a 4 octet label length, a variable length label value, a one to 8 a 4 octet label length, a variable length label value, a one to 8
octet pad, and an 8 octet ICV. The first 24 octets of the token are octet pad, and an 8 octet ICV. The first 24 octets of the token are
the plaintext IV used to encrypt the remainder of the token. The the plaintext IV used to encrypt the remainder of the token. The
token requires its own encryption IV because it is transmitted across token requires its own encryption IV because it is transmitted across
the data channel, not the command channel, and ordering between the the data channel, not the command channel, and ordering between the
channels cannot be guaranteed. Storage of precomputed keys and channels cannot be guaranteed. Storage of precomputed keys and
hashes for files in the file system is a local implementation matter; hashes for files in the file system is a local implementation matter;
skipping to change at page 7, line 36 skipping to change at page 7, line 36
Label Type 1 octet Label Type 1 octet
Label Length 4 octets Label Length 4 octets
Label Label Length octets Label Label Length octets
Pad 1 to 8 octets Pad 1 to 8 octets
ICV 8 octets ICV 8 octets
---------------------------------------------------------------------- ----------------------------------------------------------------------
Figure 8 Figure 8
3.0 Table of Key Terminology 3.0 Table of Key Terminology
In order to clarify the usage of various keys in this protocol, Fig- In order to clarify the usage of various keys in this protocol,
ure 9 summarizes key types and their usage: Figure 9 summarizes key types and their usage:
---------------------------------------------------------------------- ----------------------------------------------------------------------
Key Type Usage Key Type Usage
TEK Encryption of token at the beginning of each TEK Encryption of token at the beginning of each
file, also wraps the MEK file, also wraps the MEK
MEK Encryption of command channel MEK Encryption of command channel
FEK Encryption of the file itself (may be done out FEK Encryption of the file itself (may be done out
of scope of FTP) of scope of FTP)
---------------------------------------------------------------------- ----------------------------------------------------------------------
Figure 9 Figure 9
4.0 Security Considerations 4.0 Security Considerations
This entire memo is about security mechanisms. For KEA to provide This entire memo is about security mechanisms. For KEA to provide
the authentication and key management discussed, the implementation the authentication and key management discussed, the implementation
must protect the private key from disclosure. For SKIPJACK to pro- must protect the private key from disclosure. For SKIPJACK to
vide the confidentiality discussed, the implementation must protect provide the confidentiality discussed, the implementation must
the shared symmetric keys from disclosure. protect the shared symmetric keys from disclosure.
5.0 Acknowledgements 5.0 Acknowledgements
I would like to thank Todd Horting for insights gained during imple- I would like to thank Todd Horting for insights gained during
mentation of this specification. implementation of this specification.
6.0 References 6.0 References
[1] - M. Horowitz and S. J. Lunt. FTP Security Extensions. [1] - M. Horowitz and S. J. Lunt. FTP Security Extensions.
Internet-Draft <draft-ietf-cat-ftpsec-09.txt>, RFC 2228. October 1997.
November, 1996.
[2] - Message Security Protocol 4.0 (MSP), Revision A. Secure Data [2] - Message Security Protocol 4.0 (MSP), Revision A. Secure Data
Network System (SDNS) Specification, SDN.701, Network System (SDNS) Specification, SDN.701,
February 6, 1997. February 6, 1997.
7.0 Author's Address 7.0 Author's Address
Russell Housley Russell Housley
SPYRUS SPYRUS
PO Box 1198 381 Elden Street
Herndon, VA 20172 Suite 1120
Herndon, VA 20170
USA USA
Phone: +1 703 435-7344 Phone: +1 703 707-0696
Email: housley@spyrus.com Email: housley@spyrus.com
DIRNSA DIRNSA
Attn: X22 (W. Nace) Attn: X22 (W. Nace)
9800 Savage Road 9800 Savage Road
Fort Meade, MD 20755-6000 Fort Meade, MD 20755-6000
USA USA
Phone: +1 410 859-4464 Phone: +1 410 859-4464
Email: WANace@missi.ncsc.mil Email: WANace@missi.ncsc.mil
Peter Yee Peter Yee
SPYRUS SPYRUS
2460 N. First Street 5303 Betsy Ross Drive
Suite 100 Santa Clara, CA 95054
San Jose, CA 95131-1023
USA USA
Phone: +1 408 432-8180 Phone: +1 408 327-1901
Email: yee@spyrus.com Email: yee@spyrus.com
 End of changes. 25 change blocks. 
59 lines changed or deleted 61 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/