doc: Add RFC documents

1 files changed, 507 insertions, 0 deletions

diff --git a/doc/rfc/rfc2773.txt b/doc/rfc/rfc2773.txt
new file mode 100644
index 0000000..4f93d6b
--- /dev/null
+++ b/doc/rfc/rfc2773.txt
@@ -0,0 +1,507 @@
+
+
+
+
+
+
+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
+   framework.  FTP entities may use KEA to give mutual authentication
+   and establish data encryption keys.  We specify a simple token format
+   and set of exchanges to deliver these services.  Functions that may
+   be performed by the Fortezza Crypto Card.
+
+   The reader should be familiar with the extensions in order to
+   understand the protocol steps that follow.  In the context of the FTP
+   Security Extensions, we suggest the usage of KEA with SKIPJACK for
+   authentication, integrity, and confidentiality.
+
+   A client may mutually authenticate with a server.  What follows are
+   the protocol steps necessary to perform KEA authentication under the
+   FTP Security Extensions framework.  Where failure modes are
+   encountered, the return codes follow those specified in the
+   Extensions.  They are not enumerated in this document as they are
+   invariant among the mechanisms used.  The certificates are ASN.1
+   encoded.
+
+   The exchanges detailed below presume a working knowledge of the FTP
+   Security Extensions.  The notation for concatenation is " || ".
+   Decryption of encrypted data and certification path validation is
+   implicitly assumed, but is not shown.
+
+---------------------------------------------------------------------
+  Client                             Server
+
+  AUTH KEA-SKIPJACK              -->
+                                      <-- 334 ADAT=Base64( Certb || Rb )
+  ADAT Base64( Certa || Ra ||
+    WMEK || IV || Encrypt(
+    Label-Type || Label-Length ||
+    Label-List || pad || ICV ) ) -->
+                                     <-- 235 ADAT=Base64( IV )
+---------------------------------------------------------------------
+                             Figure 1
+
+   The server and client certificates contain KEA public keys.  The
+   client and server use KEA to generate a shared SKIPJACK symmetric
+   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
+
+
+
+Housley, et al.               Experimental                      [Page 3]
+
+RFC 2773           Encryption using KEA and SKIPJACK      February 2000
+
+
+   the TEK for transfer to the server.  An initialization vector (IV)
+   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
+   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
+   as a one octet type value, a four octet label length, the security
+   label list, padding, followed by an eight octet integrity check value
+   (ICV).  Figure 3 lists the label types.  If the label type is absent
+   (value of zero length), then the label size must be zero.
+
+   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 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.
+   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
+   being added.  In hexadecimal, he possible pad strings are: 01, 0202,
+   030303, 04040404, 0505050505, 060606060606, 07070707070707, and
+   0808080808080808.  All input is padded with 1 to 8 octets to produce
+   a multiple of 8 octets in length.  This pad technique is used
+   whenever SKIPJACK CBC encryption is performed.
+
+   An ICV is calculated over the plaintext security label and padding.
+   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
+   used in conjunction with SKIPJACK CBC encryption to provide data
+   integrity.
+
+   ---------------------------------------------------------------------
+                 Label Type                1 Octet
+                 Label Length              4 octets
+                 Label List                variable length
+                 Pad                       1 to 8 octets
+                 ICV                       8 octets
+   ---------------------------------------------------------------------
+                                Figure 2
+
+   ---------------------------------------------------------------------
+              Label Type   Label Syntax                Reference
+              0            Absent                      Not applicable
+              1            MSP                         SDN.701[2]
+              2-255        Reserved for Future Use     To Be Determined
+
+   ---------------------------------------------------------------------
+                                Figure 3
+
+
+
+
+
+
+Housley, et al.               Experimental                      [Page 4]
+
+RFC 2773           Encryption using KEA and SKIPJACK      February 2000
+
+
+   FTP command channel operations are now confidentiality protected.  To
+   provide integrity, the command sequence number, padding, and ICV are
+   appended to each command prior to encryption.
+
+   Sequence integrity is provided by using a 16-bit sequence number
+   which is incremented for each command.  The sequence number is
+   initialized with the least significant 16-bits of Ra.  The server
+   response will include the same sequence number as the client command.
+
+   An ICV is calculated over the individual commands (including the
+   carriage return and line feed required to terminate commands), the
+   sequence number, and pad.
+
+   ---------------------------------------------------------------------
+     Client                             Server
+
+     ENC Base64(Encrypt("PBSZ 65535"
+         || SEQ || pad || ICV ))     -->
+                                        <-- 632  Base64(Encrypt("200" ||
+                                                   SEQ || pad || ICV))
+     ENC Base64(Encrypt("USER yee"
+           || SEQ || pad || ICV))    -->
+                                        <-- 632  Base64(Encrypt("331" ||
+                                                   SEQ || pad || ICV))
+     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: +1 703 707-0696
+   EMail: housley@spyrus.com
+
+
+   Peter Yee
+   SPYRUS
+   5303 Betsy Ross Drive
+   Santa Clara, CA 95054
+   USA
+
+   Phone: +1 408 327-1901
+   EMail: yee@spyrus.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+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]
+