rfc2773.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 508 行 · 第 1/2 页

     ENC Base64(Encrypt("PASS
           fortezza" || SEQ ||
           pad || ICV))              -->
                                        <-- 631  Base64(Sign("230"))
   ---------------------------------------------------------------------
                                Figure 4

   After decryption, both parties verifying the integrity of the PBSZ
   commands by checking for the expected sequence number and correct
   ICV.  The correct SKIPJACK key calculation, ICV checking, and the
   validation of the certificates containing the KEA public keys
   provides mutual identification and authentication.

   ---------------------------------------------------------------------
     Client                          Server

     ENC Base64(Encrypt("PROT P" ||
             SEQ || pad || ICV))  -->
                                     <-- 632 Base64(Encrypt("200" || SEQ
                                                    ||  pad || ICV))
   ---------------------------------------------------------------------
                                Figure 5





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


   At this point, files may be sent or received with encryption and
   integrity services in use.  If encryption is used, then the first
   buffer will contain the token followed by enough encrypted file
   octets to completely fill the buffer (unless the file is too short to
   fill the buffer).  Subsequent buffers contain only encrypted file
   octets.  All buffers are completely full except the final buffer.

   ---------------------------------------------------------------------
     Client                         Server

     ENC Base64(Encrypt(
        ("RETR foo.bar") ||
        SEQ || pad || ICV))    -->
                                    <-- 632 Base64(Encrypt("150" ||
                                                SEQ || pad || ICV))
   ---------------------------------------------------------------------
                                Figure 6

   The next figure shows the header information and the file data.

   ---------------------------------------------------------------------
                Plaintext Token IV    24 octets
                WMEK                  12 octets
                Hashvalue             20 octets
                IV                    24 octets
                Label Type            1 octets
                Label Length          4 octets
                Label                 Label Length octets
                Pad                   1 to 8 octets
                ICV                   8 octets
   ---------------------------------------------------------------------
                                Figure 7

2.1  Pre-encrypted File Support

   In order to support both on-the-fly encryption and pre-encrypted
   files, a token is defined for carrying a file encryption key (FEK).
   To prevent truncation and ensure file integrity, 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
   wrapped in the session TEK.  The token is encrypted in the session
   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,
   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
   the plaintext IV used to encrypt the remainder of the token.  The
   token requires its own encryption IV because it is transmitted across
   the data channel, not the command channel, and ordering between the



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


   channels cannot be guaranteed.  Storage of precomputed keys and
   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
   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
   the session TEK.  Figure 8 shows the assembled token.

   ---------------------------------------------------------------------
               Plaintext Token IV            24 octets
               Wrapped FEK                   12 octets
               Hashvalue                     20 octets
               IV                            24 octets
               Label Type                    1 octet
               Label Length                  4 octets
               Label                         Label Length octets
               Pad                           1 to 8 octets
               ICV                           8 octets
   ---------------------------------------------------------------------
                                 Figure 8

3.0  Table of Key Terminology

   In order to clarify the usage of various keys in this protocol,
   Figure 9 summarizes key types and their usage:

   ---------------------------------------------------------------------
                Key Type         Usage
                TEK              Encryption of token at the beginning of
                                 each file, also wraps the MEK and the FEK
                MEK              Encryption of command channel
                FEK              Encryption of the file itself (may be
                                 done out of scope of FTP)

   ---------------------------------------------------------------------
                                 Figure 9

4.0  Security Considerations

   This entire memo is about security mechanisms.  For KEA to provide
   the authentication and key management discussed, the implementation
   must protect the private key from disclosure.  For SKIPJACK to
   provide the confidentiality discussed, the implementation must
   protect the shared symmetric keys from disclosure.

5.0  Acknowledgements

   We would like to thank Todd Horting for insights gained during
   implementation of this specification.



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


6.0  References

   [1]  Horowitz, M. and S. Lunt,  "FTP Security Extensions", RFC 2228,
        October 1997.

   [2]  Message Security Protocol 4.0 (MSP), Revision A. Secure Data
        Network System (SDNS) Specification, SDN.701, February 6, 1997.

   [3]  Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, RFC
        959, October 1985.

7.0  Authors' Addresses

   Russell Housley
   SPYRUS
   381 Elden Street
   Suite 1120
   Herndon, VA 20170
   USA

   Phone: [phone]
   EMail: [e-mail]


   Peter Yee
   SPYRUS
   5303 Betsy Ross Drive
   Santa Clara, CA 95054
   USA

   Phone: [phone]
   EMail: [e-mail]



















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


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.



















Housley, et al.               Experimental                      [Page 9]