idnits 2.17.1 draft-ietf-cat-ftpkeasj-01.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-25) 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 280 has weird spacing: '...ty, the token...' == Line 281 has weird spacing: '...e. The token...' == Line 283 has weird spacing: '...K. The token...' == Line 284 has weird spacing: '...e. The token...' == Line 287 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 (January 1999) is 9232 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 344, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '2' Summary: 10 errors (**), 0 flaws (~~), 11 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CAT Working Group Russell Housley (SPYRUS) 3 William A. Nace (NSA) 4 Updates: RFC 959 Peter Yee (SPYRUS) 5 Internet-Draft 6 Expire in six months January 1999 8 Encryption using KEA and SKIPJACK 10 Status of this Memo 12 This document is an Internet-Draft. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its areas, 14 and its working groups. Note that other groups may also distribute 15 working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet-Drafts as reference 20 material or to cite them other than as ''work in progress.'' 22 To learn the current status of any Internet-Draft, please check the 23 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 24 Directories on ds.internic.net (US East Coast), nic.nordu.net 25 Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 27 Distribution of this memo is unlimited. Please send comments to the 28 mailing list. 30 Abstract 32 This document defines a method to encrypt a file transfer using the 33 FTP specification RFC 959, 'FILE TRANSFER PROTOCOL (FTP)' (October 34 1985) and the work in progress document 'FTP Security Extensions' 35 [1]. This method will use the Key 36 Exchange Algorithm (KEA) to give mutual authentication and establish 37 the data encryption keys. SKIPJACK is used to encrypt file data and 38 the FTP command channel. 40 1.0 Introduction 42 The File Transfer Protocol (FTP) provides no protocol security except 43 for a user authentication password which is transmitted in the clear. 44 In addition, the protocol does not protect the file transfer session 45 beyond the original authentication phase. 47 The Internet Engineering Task Force (IETF) Common Authentication 48 Technology (CAT) Working Group has proposed security extensions to 49 FTP. These extensions allow the protocol to use more flexible 50 security schemes, and in particular allows for various levels of 51 protection for the FTP command and data connections. This document 52 describes a profile for the FTP Security Extensions by which these 53 mechanisms may be provisioned using the Key Exchange Algorithm (KEA) 54 in conjunction with the SKIPJACK symmetric encryption algorithm. 56 The FTP Security Extensions are likely to become a standards track 57 RFC in 1997. It provides: 59 * user authentication -- augmenting the normal password mechanism; 61 * server authentication -- normally done in conjunction with user 62 authentication; 64 * session parameter negotiation -- in particular, encryption keys 65 and attributes; 67 * command connection protection -- integrity, confidentiality, or 68 both; 70 * data transfer protection -- same as for command connection 71 protection. 73 In order to support the above security services, the two FTP entities 74 negotiate a mechanism. This process is open-ended and completes when 75 both entities agree on an acceptable mechanism or when the initiating 76 party (always the client) is unable to suggest an agreeable 77 mechanism. Once the entities agree upon a mechanism, they may 78 commence authentication and/or parameter negotiation. 80 Authentication and parameter negotiation occur within an unbounded 81 series of exchanges. At the completion of the exchanges, the 82 entities will either be authenticated (unilateral or mutually), and 83 may, additionally, be ready to protect FTP commands and data. 85 Following the exchanges, the entities negotiate the size of the 86 buffers they will use in protecting the commands and data that 87 follow. This process is accomplished in two steps: the client offers 88 a suggested buffer size and the server may either refuse it, counter 89 it, or accept it. 91 At this point, the entities may issue protected commands within the 92 bounds of the parameters negotiated through the security exchanges. 93 Protected commands are issued by applying the protection services 94 required to the normal commands and Base64 encoding the results. The 95 encoded results are sent as the data field within a ENC (integrity 96 and confidentiality) command. Base64 is an encoding for mapping 97 binary data onto a textual character set that is able to pass through 98 most 7-bit systems without loss. The server sends back responses in 99 new result codes which allow the identical protections and Base64 100 encoding to be applied to the results. Protection of the data 101 transfers can be specified via the PROT command which supports the 102 same protections as those afforded the other FTP commands. PROT 103 commands may be sent on a transfer-by-transfer basis, however, the 104 session parameters may not be changed within a session. 106 2.0 Key Exchange Algorithm (KEA) Profile 108 This paper profiles KEA with SKIPJACK to achieve certain security 109 services when used in conjunction with the FTP Security Extensions 110 framework. FTP entities may use KEA to give mutual authentication 111 and establish data encryption keys. We specify a simple token format 112 and set of exchanges to deliver these services. Functions that may 113 be performed by the Fortezza Crypto Card. 115 The reader should be familiar with the extensions in order to 116 understand the protocol steps that follow. In the context of the FTP 117 Security Extensions, we suggest the usage of KEA with SKIPJACK for 118 authentication, integrity, and confidentiality. 120 A client may mutually authenticate with a server. What follows are 121 the protocol steps necessary to perform KEA authentication under the 122 FTP Security Extensions framework. Where failure modes are 123 encountered, the return codes follow those specified in the 124 Extensions. They are not enumerated in this document as they are 125 invariant among the mechanisms used. The certificates are ASN.1 126 encoded. 128 The exchanges detailed below presume a working knowledge of the FTP 129 Security Extensions. The notation for concatenation is " || ". 130 Decryption of encrypted data and certification path validation is 131 implicitly assumed, but is not shown. 133 --------------------------------------------------------------------- 134 Client Server 136 AUTH KEA-SKIPJACK --> 137 <-- 334 ADAT=Base64( Certb || Rb ) 138 ADAT Base64( Certa || Ra || 139 WMEK || IV || Encrypt( 140 Label-Type || Label-Length || 141 Label-List || pad || ICV ) ) --> 142 <-- 235 ADAT=Base64( IV ) 143 --------------------------------------------------------------------- 144 Figure 1 146 The server and client certificates contain KEA public keys. The 147 client and server use KEA to generate a shared SKIPJACK symmetric 148 key, called the TEK. The client uses the random number generator to 149 create a second SKIPJACK key, called the MEK. The MEK is wrapped in 150 the TEK for transfer to the server. An initialization vector (IV) 151 associated with the MEK is generated by the client and transferred to 152 the server. A list of security labels that the client wants to use 153 for this FTP session may be transferred to the server encrypted in 154 the MEK. As shown in Figure 2, the security label data is formatted 155 as a one octet type value, a four octet label length, the security 156 label list, padding, followed by an eight octet integrity check value 157 (ICV). Figure 3 lists the label types. If the label type is absent 158 (value of zero length), then the label size must be zero. 160 In order to ensure that the length of the plain text is a multiple of 161 the cryptographic block size, padding shall be performed as follows. 162 The input to the SKIPJACK CBC encryption process shall be padded to a 163 multiple of 8 octets. Let n be the length in octets of the input. 164 Pad the input by appending 8 - (n mod 8) octets to the end of the 165 message, each having the value 8 - (n mod 8), the number of octets 166 being added. In hexadecimal, he possible pad strings are: 01, 0202, 167 030303, 04040404, 0505050505, 060606060606, 07070707070707, and 168 0808080808080808. All input is padded with 1 to 8 octets to produce 169 a multiple of 8 octets in length. This pad technique is used 170 whenever SKIPJACK CBC encryption is performed. 172 An ICV is calculated over the plaintext security label and padding. 173 The ICV algorithm used is the 32-bit one's complement addition of 174 each 32-bit block followed by 32 zero bits. This ICV technique is 175 used in conjunction with SKIPJACK CBC encryption to provide data 176 integrity. 178 --------------------------------------------------------------------- 179 Label Type 1 Octet 180 Label Length 4 octets 181 Label List variable length 182 Pad 1 to 8 octets 183 ICV 8 octets 184 --------------------------------------------------------------------- 185 Figure 2 187 --------------------------------------------------------------------- 188 Label Type Label Syntax Reference 189 0 Absent Not applicable 190 1 MSP SDN.701[1] 191 2-255 Reserved for Future Use To Be Determined 193 --------------------------------------------------------------------- 194 Figure 3 196 FTP command channel operations are now confidentiality protected. To 197 provide integrity, the command sequence number, padding, and ICV are 198 appended to each command prior to encryption. 200 Sequence integrity is provided by using a 16-bit sequence number 201 which is incremented for each command. The sequence number is 202 initialized with the least significant 16-bits of Ra. The server 203 response will include the same sequence number as the client command. 205 An ICV is calculated over the individual commands (including the 206 carriage return and line feed required to terminate commands), the 207 sequence number, and pad. 209 --------------------------------------------------------------------- 210 Client Server 212 ENC Base64(Encrypt("PBSZ 65535" 213 || SEQ || pad || ICV )) --> 214 <-- 632 Base64(Encrypt("200" || 215 SEQ || pad || ICV)) 216 ENC Base64(Encrypt("USER yee" 217 || SEQ || pad || ICV)) --> 218 <-- 632 Base64(Encrypt("331" || 219 SEQ || pad || ICV)) 220 ENC Base64(Encrypt("PASS 221 fortezza" || SEQ || 222 pad || ICV)) --> 223 <-- 631 Base64(Sign("230")) 224 --------------------------------------------------------------------- 225 Figure 4 227 After decryption, both parties verifying the integrity of the PBSZ 228 commands by checking for the expected sequence number and correct 229 ICV. The correct SKIPJACK key calculation, ICV checking, and the 230 validation of the certificates containing the KEA public keys 231 provides mutual identification and authentication. 233 --------------------------------------------------------------------- 234 Client Server 236 ENC Base64(Encrypt("PROT P" || 237 SEQ || pad || ICV)) --> 238 <-- 632 Base64(Encrypt("200" || SEQ 239 || pad || ICV)) 240 --------------------------------------------------------------------- 241 Figure 5 243 At this point, files may be sent or received with encryption and 244 integrity services in use. If encryption is used, then the first 245 buffer will contain the token followed by enough encrypted file 246 octets to completely fill the buffer (unless the file is too short to 247 fill the buffer). Subsequent buffers contain only encrypted file 248 octets. All buffers are completely full except the final buffer. 250 --------------------------------------------------------------------- 251 Client Server 253 ENC Base64(Encrypt( 254 ("RETR foo.bar") || 255 SEQ || pad || ICV)) --> 256 <-- 632 Base64(Encrypt("150" || 257 SEQ || pad || ICV)) 258 --------------------------------------------------------------------- 259 Figure 6 261 The next figure shows the header information and the file data. 263 --------------------------------------------------------------------- 264 Plaintext Token IV 24 octets 265 WMEK 12 octets 266 Hashvalue 20 octets 267 IV 24 octets 268 Label Type 1 octets 269 Label Length 4 octets 270 Label Label Length octets 271 Pad 1 to 8 octets 272 ICV 8 octets 273 --------------------------------------------------------------------- 274 Figure 7 276 2.1 Pre-encrypted File Support 278 In order to support both on-the-fly encryption and pre-encrypted 279 files, a token is defined for carrying a file encryption key (FEK). 280 To prevent truncation and ensure file integrity, the token also 281 includes a hash computed on the complete file. The token also 282 contains the security label associate with the file. This FEK is 283 wrapped in the session TEK. The token is encrypted in the session 284 TEK using SKIPJACK CBC mode. The token contains a 12 octet wrapped 285 FEK, a 20 octet file hash, a 24 octet file IV, a 1 octet label type, 286 a 4 octet label length, a variable length label value, a one to 8 287 octet pad, and an 8 octet ICV. The first 24 octets of the token are 288 the plaintext IV used to encrypt the remainder of the token. The 289 token requires its own encryption IV because it is transmitted across 290 the data channel, not the command channel, and ordering between the 291 channels cannot be guaranteed. Storage of precomputed keys and 292 hashes for files in the file system is a local implementation matter; 293 however, it is suggested that if a file is pre-encrypted, then the 294 FEK be wrapped in a local storage key. When the file is needed, the 295 FEK is unwrapped using the local storage key, and then rewrapped in 296 the session TEK. Figure 8 shows the assembled token. 298 ---------------------------------------------------------------------- 299 Plaintext Token IV 24 octets 300 Wrapped FEK 12 octets 301 Hashvalue 20 octets 302 IV 24 octets 303 Label Type 1 octet 304 Label Length 4 octets 305 Label Label Length octets 306 Pad 1 to 8 octets 307 ICV 8 octets 308 ---------------------------------------------------------------------- 309 Figure 8 311 3.0 Table of Key Terminology 313 In order to clarify the usage of various keys in this protocol, 314 Figure 9 summarizes key types and their usage: 316 ---------------------------------------------------------------------- 317 Key Type Usage 318 TEK Encryption of token at the beginning of each 319 file, also wraps the MEK 320 MEK Encryption of command channel 321 FEK Encryption of the file itself (may be done out 322 of scope of FTP) 323 ---------------------------------------------------------------------- 324 Figure 9 326 4.0 Security Considerations 328 This entire memo is about security mechanisms. For KEA to provide 329 the authentication and key management discussed, the implementation 330 must protect the private key from disclosure. For SKIPJACK to 331 provide the confidentiality discussed, the implementation must 332 protect the shared symmetric keys from disclosure. 334 5.0 Acknowledgements 336 I would like to thank Todd Horting for insights gained during 337 implementation of this specification. 339 6.0 References 341 [1] - M. Horowitz and S. J. Lunt. FTP Security Extensions. 342 RFC 2228. October 1997. 344 [2] - Message Security Protocol 4.0 (MSP), Revision A. Secure Data 345 Network System (SDNS) Specification, SDN.701, 346 February 6, 1997. 348 7.0 Author's Address 350 Russell Housley 351 SPYRUS 352 381 Elden Street 353 Suite 1120 354 Herndon, VA 20170 355 USA 357 Phone: +1 703 707-0696 358 Email: housley@spyrus.com 360 DIRNSA 361 Attn: X22 (W. Nace) 362 9800 Savage Road 363 Fort Meade, MD 20755-6000 364 USA 366 Phone: +1 410 859-4464 367 Email: WANace@missi.ncsc.mil 369 Peter Yee 370 SPYRUS 371 5303 Betsy Ross Drive 372 Santa Clara, CA 95054 373 USA 375 Phone: +1 408 327-1901 376 Email: yee@spyrus.com