idnits 2.17.1 draft-ietf-cat-ftpkeasj-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 8 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 9 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 5 instances of too long lines in the document, the longest one being 2 characters in excess of 72. ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. -- The draft header indicates that this document updates RFC959, but the abstract doesn't seem to directly say this. It does mention RFC959 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 278 has weird spacing: '...ty, the token...' == Line 279 has weird spacing: '...e. The token...' == Line 281 has weird spacing: '...K. The token...' == Line 282 has weird spacing: '...e. The token...' == Line 285 has weird spacing: '... of the token...' == (2 more instances...) (Using the creation date from RFC959, updated by this document, for RFC5378 checks: 1985-10-01) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 1997) is 9782 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '2' is defined on line 343, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' Summary: 10 errors (**), 0 flaws (~~), 11 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 CAT Working Group Russell Housley (SPYRUS) 2 William A. Nace (NSA) 3 Updates: RFC 959 Peter Yee (SPYRUS) 4 Internet-Draft Expire in six months 5 July 1997 7 Encryption using KEA and SKIPJACK 9 Status of this Memo 11 This document is an Internet-Draft. Internet-Drafts are working doc- 12 uments of the Internet Engineering Task Force (IETF), its areas, and 13 its working groups. Note that other groups may also distribute work- 14 ing documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six months 17 and may be updated, replaced, or obsoleted by other documents at any 18 time. It is inappropriate to use Internet-Drafts as reference mate- 19 rial or to cite them other than as ''work in progress.'' 21 To learn the current status of any Internet-Draft, please check the 22 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 23 Directories on ds.internic.net (US East Coast), nic.nordu.net 24 Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 26 Distribution of this memo is unlimited. Please send comments to the 27 mailing list. 29 Abstract 31 This document defines a method to encrypt a file transfer using the 32 FTP specification RFC 959, "FILE TRANSFER PROTOCOL (FTP)" (October 33 1985) and the work in progress document "FTP Security Extensions" 34 [1]. This method will use the Key 35 Exchange Algorithm (KEA) to give mutual authentication and establish 36 the data encryption keys. SKIPJACK is used to encrypt file data and 37 the FTP command channel. 39 1.0 Introduction 41 The File Transfer Protocol (FTP) provides no protocol security except 42 for a user authentication password which is transmitted in the clear. 43 In addition, the protocol does not protect the file transfer session 44 beyond the original authentication phase. 46 The Internet Engineering Task Force (IETF) Common Authentication 47 Technology (CAT) Working Group has proposed security extensions to 48 FTP. These extensions allow the protocol to use more flexible secu- 49 rity schemes, and in particular allows for various levels of protec- 50 tion for the FTP command and data connections. This document 51 describes a profile for the FTP Security Extensions by which these 52 mechanisms may be provisioned using the Key Exchange Algorithm (KEA) 53 in conjunction with the SKIPJACK symmetric encryption algorithm. 55 The FTP Security Extensions are likely to become a standards track 56 RFC in 1997. It provides: 58 * user authentication -- augmenting the normal password mechanism; 60 * server authentication -- normally done in conjunction with user 61 authentication; 63 * session parameter negotiation -- in particular, encryption keys 64 and attributes; 66 * command connection protection -- integrity, confidentiality, or 67 both; 69 * data transfer protection -- same as for command connection 70 protection. 72 In order to support the above security services, the two FTP entities 73 negotiate a mechanism. This process is open-ended and completes when 74 both entities agree on an acceptable mechanism or when the initiating 75 party (always the client) is unable to suggest an agreeable mecha- 76 nism. Once the entities agree upon a mechanism, they may commence 77 authentication and/or parameter negotiation. 79 Authentication and parameter negotiation occur within an unbounded 80 series of exchanges. At the completion of the exchanges, the enti- 81 ties will either be authenticated (unilateral or mutually), and may, 82 additionally, be ready to protect FTP commands and data. 84 Following the exchanges, the entities negotiate the size of the 85 buffers they will use in protecting the commands and data that fol- 86 low. This process is accomplished in two steps: the client offers a 87 suggested buffer size and the server may either refuse it, counter 88 it, or accept it. 90 At this point, the entities may issue protected commands within the 91 bounds of the parameters negotiated through the security exchanges. 92 Protected commands are issued by applying the protection services 93 required to the normal commands and Base64 encoding the results. The 94 encoded results are sent as the data field within a ENC (integrity 95 and confidentiality) command. Base64 is an encoding for mapping 96 binary data onto a textual character set that is able to pass through 97 most 7-bit systems without loss. The server sends back responses in 98 new result codes which allow the identical protections and Base64 99 encoding to be applied to the results. Protection of the data trans- 100 fers can be specified via the PROT command which supports the same 101 protections as those afforded the other FTP commands. PROT commands 102 may be sent on a transfer-by-transfer basis, however, the session 103 parameters may not be changed within a session. 105 2.0 Key Exchange Algorithm (KEA) Profile 107 This paper profiles KEA with SKIPJACK to achieve certain security 108 services when used in conjunction with the FTP Security Extensions 109 framework. FTP entities may use KEA to give mutual authentication 110 and establish data encryption keys. We specify a simple token format 111 and set of exchanges to deliver these services. Functions that may 112 be performed by the Fortezza Crypto Card. 114 The reader should be familiar with the extensions in order to under- 115 stand the protocol steps that follow. In the context of the FTP 116 Security Extensions, we suggest the usage of KEA with SKIPJACK for 117 authentication, integrity, and confidentiality. 119 A client may mutually authenticate with a server. What follows are 120 the protocol steps necessary to perform KEA authentication under the 121 FTP Security Extensions framework. Where failure modes are encoun- 122 tered, the return codes follow those specified in the Extensions. 123 They are not enumerated in this document as they are invariant among 124 the mechanisms used. The certificates are ASN.1 encoded. 126 The exchanges detailed below presume a working knowledge of the FTP 127 Security Extensions. The notation for concatenation is " || ". 128 Decryption of encrypted data and certification path validation is 129 implicitly assumed, but is not shown. 131 --------------------------------------------------------------------- 132 Client Server 134 AUTH KEA-SKIPJACK --> 135 <-- 334 ADAT=Base64( Certb || Rb ) 136 ADAT Base64( Certa || Ra || 137 WMEK || IV || Encrypt( 138 Label-Type || Label-Length || 139 Label-List || pad || ICV ) ) --> 140 <-- 235 ADAT=Base64( IV ) 141 --------------------------------------------------------------------- 142 Figure 1 144 The server and client certificates contain KEA public keys. The 145 client and server use KEA to generate a shared SKIPJACK symmetric 146 key, called the TEK. The client uses the random number generator to 147 create a second SKIPJACK key, called the MEK. The MEK is wrapped in 148 the TEK for transfer to the server. An initialization vector (IV) 149 associated with the MEK is generated by the client and transferred to 150 the server. A list of security labels that the client wants to use 151 for this FTP session may be transferred to the server encrypted in 152 the MEK. As shown in Figure 2, the security label data is formatted 153 as a one octet type value, a four octet label length, the security 154 label list, padding, followed by an eight octet integrity check value 155 (ICV). Figure 3 lists the label types. If the label type is absent 156 (value of zero length), then the label size must be zero. 158 In order to ensure that the length of the plain text is a multiple of 159 the cryptographic block size, padding shall be performed as follows. 160 The input to the SKIPJACK CBC encryption process shall be padded to a 161 multiple of 8 octets. Let n be the length in octets of the input. 162 Pad the input by appending 8 - (n mod 8) octets to the end of the 163 message, each having the value 8 - (n mod 8), the number of octets 164 being added. In hexadecimal, he possible pad strings are: 01, 0202, 165 030303, 04040404, 0505050505, 060606060606, 07070707070707, and 166 0808080808080808. All input is padded with 1 to 8 octets to produce 167 a multiple of 8 octets in length. This pad technique is used when- 168 ever SKIPJACK CBC encryption is performed. 170 An ICV is calculated over the plaintext security label and padding. 171 The ICV algorithm used is the 32-bit one's complement addition of 172 each 32-bit block followed by 32 zero bits. This ICV technique is 173 used in conjunction with SKIPJACK CBC encryption to provide data 174 integrity. 176 --------------------------------------------------------------------- 177 Label Type 1 Octet 178 Label Length 4 octets 179 Label List variable length 180 Pad 1 to 8 octets 181 ICV 8 octets 182 --------------------------------------------------------------------- 183 Figure 2 185 --------------------------------------------------------------------- 186 Label Type Label Syntax Reference 187 0 Absent Not applicable 188 1 MSP SDN.701[1] 189 2-255 Reserved for Future Use To Be Determined 191 --------------------------------------------------------------------- 192 Figure 3 194 FTP command channel operations are now confidentiality protected. To 195 provide integrity, the command sequence number, padding, and ICV are 196 appended to each command prior to encryption. 198 Sequence integrity is provided by using a 16-bit sequence number 199 which is incremented for each command. The sequence number is ini- 200 tialized with the least significant 16-bits of Ra. The server 201 response will include the same sequence number as the client command. 203 An ICV is calculated over the individual commands (including the car- 204 riage return and line feed required to terminate commands), the 205 sequence number, and pad. 207 --------------------------------------------------------------------- 208 Client Server 210 ENC Base64(Encrypt("PBSZ 65535" 211 || SEQ || pad || ICV )) --> 212 <-- 632 Base64(Encrypt("200" || 213 SEQ || pad || ICV)) 214 ENC Base64(Encrypt("USER yee" 215 || SEQ || pad || ICV)) --> 216 <-- 632 Base64(Encrypt("331" || 217 SEQ || pad || ICV)) 218 ENC Base64(Encrypt("PASS 219 fortezza" || SEQ || 220 pad || ICV)) --> 221 <-- 631 Base64(Sign("230")) 222 --------------------------------------------------------------------- 223 Figure 4 225 After decryption, both parties verifying the integrity of the PBSZ 226 commands by checking for the expected sequence number and correct 227 ICV. The correct SKIPJACK key calculation, ICV checking, and the 228 validation of the certificates containing the KEA public keys pro- 229 vides mutual identification and authentication. 231 --------------------------------------------------------------------- 232 Client Server 234 ENC Base64(Encrypt("PROT P" || 235 SEQ || pad || ICV)) --> 236 <-- 632 Base64(Encrypt("200" || SEQ 237 || pad || ICV)) 238 --------------------------------------------------------------------- 239 Figure 5 241 At this point, files may be sent or received with encryption and 242 integrity services in use. If encryption is used, then the first 243 buffer will contain the token followed by enough encrypted file 244 octets to completely fill the buffer (unless the file is too short to 245 fill the buffer). Subsequent buffers contain only encrypted file 246 octets. All buffers are completely full except the final buffer. 248 --------------------------------------------------------------------- 249 Client Server 251 ENC Base64(Encrypt( 252 ("RETR foo.bar") || 253 SEQ || pad || ICV)) --> 254 <-- 632 Base64(Encrypt("150" || 255 SEQ || pad || ICV)) 256 --------------------------------------------------------------------- 257 Figure 6 259 The next figure shows the header information and the file data. 261 --------------------------------------------------------------------- 262 Plaintext Token IV 24 octets 263 WMEK 12 octets 264 Hashvalue 20 octets 265 IV 24 octets 266 Label Type 1 octets 267 Label Length 4 octets 268 Label Label Length octets 269 Pad 1 to 8 octets 270 ICV 8 octets 271 --------------------------------------------------------------------- 272 Figure 7 274 2.1 Pre-encrypted File Support 276 In order to support both on-the-fly encryption and pre-encrypted 277 files, a token is defined for carrying a file encryption key (FEK). 278 To prevent truncation and ensure file integrity, the token also 279 includes a hash computed on the complete file. The token also con- 280 tains the security label associate with the file. This FEK is 281 wrapped in the session TEK. The token is encrypted in the session 282 TEK using SKIPJACK CBC mode. The token contains a 12 octet wrapped 283 FEK, a 20 octet file hash, a 24 octet file IV, a 1 octet label type, 284 a 4 octet label length, a variable length label value, a one to 8 285 octet pad, and an 8 octet ICV. The first 24 octets of the token are 286 the plaintext IV used to encrypt the remainder of the token. The 287 token requires its own encryption IV because it is transmitted across 288 the data channel, not the command channel, and ordering between the 289 channels cannot be guaranteed. Storage of precomputed keys and 290 hashes for files in the file system is a local implementation matter; 291 however, it is suggested that if a file is pre-encrypted, then the 292 FEK be wrapped in a local storage key. When the file is needed, the 293 FEK is unwrapped using the local storage key, and then rewrapped in 294 the session TEK. Figure 8 shows the assembled token. 296 ---------------------------------------------------------------------- 297 Plaintext Token IV 24 octets 298 Wrapped FEK 12 octets 299 Hashvalue 20 octets 300 IV 24 octets 301 Label Type 1 octet 302 Label Length 4 octets 303 Label Label Length octets 304 Pad 1 to 8 octets 305 ICV 8 octets 306 ---------------------------------------------------------------------- 307 Figure 8 309 3.0 Table of Key Terminology 311 In order to clarify the usage of various keys in this protocol, Fig- 312 ure 9 summarizes key types and their usage: 314 ---------------------------------------------------------------------- 315 Key Type Usage 316 TEK Encryption of token at the beginning of each 317 file, also wraps the MEK 318 MEK Encryption of command channel 319 FEK Encryption of the file itself (may be done out 320 of scope of FTP) 321 ---------------------------------------------------------------------- 322 Figure 9 324 4.0 Security Considerations 326 This entire memo is about security mechanisms. For KEA to provide 327 the authentication and key management discussed, the implementation 328 must protect the private key from disclosure. For SKIPJACK to pro- 329 vide the confidentiality discussed, the implementation must protect 330 the shared symmetric keys from disclosure. 332 5.0 Acknowledgements 334 I would like to thank Todd Horting for insights gained during imple- 335 mentation of this specification. 337 6.0 References 339 [1] - M. Horowitz and S. J. Lunt. FTP Security Extensions. 340 Internet-Draft , 341 November, 1996. 343 [2] - Message Security Protocol 4.0 (MSP), Revision A. Secure Data 344 Network System (SDNS) Specification, SDN.701, 345 February 6, 1997. 347 7.0 Author's Address 349 Russell Housley 350 SPYRUS 351 PO Box 1198 352 Herndon, VA 20172 353 USA 355 Phone: +1 703 435-7344 356 Email: housley@spyrus.com 358 DIRNSA 359 Attn: X22 (W. Nace) 360 9800 Savage Road 361 Fort Meade, MD 20755-6000 362 USA 364 Phone: +1 410 859-4464 365 Email: WANace@missi.ncsc.mil 367 Peter Yee 368 SPYRUS 369 2460 N. First Street 370 Suite 100 371 San Jose, CA 95131-1023 372 USA 374 Phone: +1 408 432-8180 375 Email: yee@spyrus.com