draft-ietf-cat-ftpkeasj-01.txt   rfc2773.txt 
CAT Working Group Russell Housley (SPYRUS) Network Working Group R. Housley
<draft-ietf-cat-ftpkeasj-01.txt> William A. Nace (NSA) Request for Comments: 2773 P. Yee
Updates: RFC 959 Peter Yee (SPYRUS) Updates: 959 SPYRUS
Internet-Draft Category: Experimental W. Nace
Expire in six months January 1999 NSA
February 2000
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 This memo defines an Experimental Protocol for the Internet
documents of the Internet Engineering Task Force (IETF), its areas, community. It does not specify an Internet standard of any kind.
and its working groups. Note that other groups may also distribute Discussion and suggestions for improvement are requested.
working documents as Internet-Drafts. Distribution of this memo is unlimited.
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 learn the current status of any Internet-Draft, please check the Copyright Notice
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ds.internic.net (US East Coast), nic.nordu.net
Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim).
Distribution of this memo is unlimited. Please send comments to the Copyright (C) The Internet Society (2000). All Rights Reserved.
<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 STD 9, RFC 959, "File Transfer Protocol (FTP)",
1985) and the work in progress document 'FTP Security Extensions' (October 1985) [3] and RFC 2228, "FTP Security Extensions" (October
<draft-ietf-cat-ftpsec-09.txt>[1]. This method will use the Key 1997) [1]. This method will use the Key Exchange Algorithm (KEA) to
Exchange Algorithm (KEA) to give mutual authentication and establish give mutual authentication and establish the data encryption keys.
the data encryption keys. SKIPJACK is used to encrypt file data and 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 FTP. These extensions allow the protocol to use more flexible
security schemes, and in particular allows for various levels of security schemes, and in particular allows for various levels of
protection 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 FTP Security Extensions [1] 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
authentication; authentication;
* session parameter negotiation -- in particular, encryption keys * session parameter negotiation -- in particular, encryption keys
and attributes; and attributes;
* 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 party (always the client) is unable to suggest an agreeable
mechanism. Once the entities agree upon a mechanism, they may mechanism. Once the entities agree upon a mechanism, they may
commence 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 series of exchanges. At the completion of the exchanges, the
skipping to change at page 3, line 41 skipping to change at page 3, line 35
encountered, the return codes follow those specified in the encountered, the return codes follow those specified in the
Extensions. They are not enumerated in this document as they are Extensions. They are not enumerated in this document as they are
invariant among the mechanisms used. The certificates are ASN.1 invariant among the mechanisms used. The certificates are ASN.1
encoded. 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 -->
<-- 334 ADAT=Base64( Certb || Rb ) <-- 334 ADAT=Base64( Certb || Rb )
ADAT Base64( Certa || Ra || ADAT Base64( Certa || Ra ||
WMEK || IV || Encrypt( WMEK || IV || Encrypt(
Label-Type || Label-Length || Label-Type || Label-Length ||
Label-List || pad || ICV ) ) --> Label-List || pad || ICV ) ) -->
<-- 235 ADAT=Base64( IV ) <-- 235 ADAT=Base64( IV )
--------------------------------------------------------------------- ---------------------------------------------------------------------
Figure 1 Figure 1
The server and client certificates contain KEA public keys. The The server and client certificates contain KEA public keys. The
client and server use KEA to generate a shared SKIPJACK symmetric client and server use KEA to generate a shared SKIPJACK symmetric
key, called the TEK. The client uses the random number generator to key, called the TEK. The client uses the random number generator to
create a second SKIPJACK key, called the MEK. The MEK is wrapped in create a second SKIPJACK key, called the MEK. The MEK is wrapped in
the TEK for transfer to the server. An initialization vector (IV) the TEK for transfer to the server. An initialization vector (IV)
associated with the MEK is generated by the client and transferred to associated with the MEK is generated by the client and transferred to
the server. A list of security labels that the client wants to use the server. A list of security labels that the client wants to use
for this FTP session may be transferred to the server encrypted in for this FTP session may be transferred to the server encrypted in
the MEK. As shown in Figure 2, the security label data is formatted the MEK. As shown in Figure 2, the security label data is formatted
skipping to change at page 4, line 45 skipping to change at page 4, line 39
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
Label List variable length Label List variable length
Pad 1 to 8 octets Pad 1 to 8 octets
ICV 8 octets ICV 8 octets
--------------------------------------------------------------------- ---------------------------------------------------------------------
Figure 2 Figure 2
--------------------------------------------------------------------- ---------------------------------------------------------------------
Label Type Label Syntax Reference Label Type Label Syntax Reference
0 Absent Not applicable 0 Absent Not applicable
1 MSP SDN.701[1] 1 MSP SDN.701[2]
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 which is incremented for each command. The sequence number is
initialized 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.
skipping to change at page 5, line 43 skipping to change at page 5, line 34
SEQ || pad || ICV)) SEQ || pad || ICV))
ENC Base64(Encrypt("USER yee" ENC Base64(Encrypt("USER yee"
|| SEQ || pad || ICV)) --> || SEQ || pad || ICV)) -->
<-- 632 Base64(Encrypt("331" || <-- 632 Base64(Encrypt("331" ||
SEQ || pad || ICV)) SEQ || pad || ICV))
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 validation of the certificates containing the KEA public keys
provides 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
At this point, files may be sent or received with encryption and At this point, files may be sent or received with encryption and
integrity services in use. If encryption is used, then the first integrity services in use. If encryption is used, then the first
buffer will contain the token followed by enough encrypted file buffer will contain the token followed by enough encrypted file
octets to completely fill the buffer (unless the file is too short to octets to completely fill the buffer (unless the file is too short to
fill the buffer). Subsequent buffers contain only encrypted file fill the buffer). Subsequent buffers contain only encrypted file
octets. All buffers are completely full except the final buffer. octets. All buffers are completely full except the final buffer.
--------------------------------------------------------------------- ---------------------------------------------------------------------
Client Server Client Server
ENC Base64(Encrypt( ENC Base64(Encrypt(
("RETR foo.bar") || ("RETR foo.bar") ||
SEQ || pad || ICV)) --> SEQ || pad || ICV)) -->
<-- 632 Base64(Encrypt("150" || <-- 632 Base64(Encrypt("150" ||
SEQ || pad || ICV)) SEQ || pad || ICV))
--------------------------------------------------------------------- ---------------------------------------------------------------------
Figure 6 Figure 6
The next figure shows the header information and the file data. The next figure shows the header information and the file data.
--------------------------------------------------------------------- ---------------------------------------------------------------------
Plaintext Token IV 24 octets Plaintext Token IV 24 octets
WMEK 12 octets WMEK 12 octets
Hashvalue 20 octets Hashvalue 20 octets
IV 24 octets IV 24 octets
Label Type 1 octets Label Type 1 octets
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 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 includes a hash computed on the complete file. The token also
contains 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;
however, it is suggested that if a file is pre-encrypted, then the however, it is suggested that if a file is pre-encrypted, then the
FEK be wrapped in a local storage key. When the file is needed, the FEK be wrapped in a local storage key. When the file is needed, the
FEK is unwrapped using the local storage key, and then rewrapped in FEK is unwrapped using the local storage key, and then rewrapped in
the session TEK. Figure 8 shows the assembled token. the session TEK. Figure 8 shows the assembled token.
---------------------------------------------------------------------- ---------------------------------------------------------------------
Plaintext Token IV 24 octets Plaintext Token IV 24 octets
Wrapped FEK 12 octets Wrapped FEK 12 octets
Hashvalue 20 octets Hashvalue 20 octets
IV 24 octets IV 24 octets
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, In order to clarify the usage of various keys in this protocol,
Figure 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
file, also wraps the MEK each file, also wraps the MEK and the FEK
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
of scope of FTP) done out 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 must protect the private key from disclosure. For SKIPJACK to
provide the confidentiality discussed, the implementation must provide the confidentiality discussed, the implementation must
protect 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 We would like to thank Todd Horting for insights gained during
implementation of this specification. implementation of this specification.
6.0 References 6.0 References
[1] - M. Horowitz and S. J. Lunt. FTP Security Extensions. [1] Horowitz, M. and S. Lunt, "FTP Security Extensions", RFC 2228,
RFC 2228. October 1997. October 1997.
[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 [3] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, RFC
959, October 1985.
7.0 Authors' Addresses
Russell Housley Russell Housley
SPYRUS SPYRUS
381 Elden Street 381 Elden Street
Suite 1120 Suite 1120
Herndon, VA 20170 Herndon, VA 20170
USA USA
Phone: +1 703 707-0696 Phone: +1 703 707-0696
Email: housley@spyrus.com EMail: housley@spyrus.com
DIRNSA
Attn: X22 (W. Nace)
9800 Savage Road
Fort Meade, MD 20755-6000
USA
Phone: +1 410 859-4464
Email: WANace@missi.ncsc.mil
Peter Yee Peter Yee
SPYRUS SPYRUS
5303 Betsy Ross Drive 5303 Betsy Ross Drive
Santa Clara, CA 95054 Santa Clara, CA 95054
USA USA
Phone: +1 408 327-1901 Phone: +1 408 327-1901
Email: yee@spyrus.com EMail: yee@spyrus.com
8.0 Full Copyright Statement
Copyright (C) The Internet Society (2000). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
 End of changes. 33 change blocks. 
92 lines changed or deleted 77 lines changed or added

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