idnits 2.17.1 draft-ietf-pppext-feep-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-19) 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 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 abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 73: '... MUST This word, or the ad...' RFC 2119 keyword, line 77: '... MUST NOT This phrase means th...' RFC 2119 keyword, line 80: '... SHOULD This word, or the ad...' RFC 2119 keyword, line 86: '... MAY This word, or the ad...' RFC 2119 keyword, line 88: '...hich does not include this option MUST...' (3 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 207 has weird spacing: '...rotocol packe...' -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '1' on line 488 looks like a reference -- Missing reference section? '2' on line 491 looks like a reference Summary: 9 errors (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group William A. Nace(NSA) 3 Internet Draft James E. Zmuda(SPYRUS) 4 expires in six months November 21st, 1997 6 PPP Fortezza Encryption Encapsulation Protocol 7 9 Status of this Memo 11 This document is a submission to the Point-to-Point Protocol 12 Extensions Working Group of the Internet Engineering Task Force 13 (IETF). Comments should be submitted to the ietf-ppp@merit.edu 14 mailing list. 16 Distribution of this memo is unlimited. 18 This document is an Internet-Draft. Internet-Drafts are working 19 documents of the Internet Engineering Task Force (IETF), its 20 areas, and its working groups. Note that other groups may also 21 distribute working documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six 24 months and may be updated, replaced, or obsoleted by other 25 documents at any time. It is not appropriate to use Internet- 26 Drafts as reference material or to cite them other than as 'work 27 in progress.' 29 To learn the current status of any Internet-Draft, please check 30 the '1id-abstracts.txt' listing contained in the Internet-Drafts 31 Shadow Directories on ds.internic.net (US East Coast), 32 nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or 33 munnari.oz.au (Pacific Rim). 35 Abstract 37 The Point-to-Point Protocol (PPP) [1] provides a standard method 38 for transporting multi-protocol datagrams over point-to-point 39 links 41 PPP also defines an extensible Link Control Protocol, which 42 allows negotiation of an Authentication Protocol for 43 authentication of its peer before allowing Network Layer 44 protocols to transmit over the link. 46 One of the Authentication protocols that can be negotiated is 48 DRAFT PPP Fortezza Encryption Encapsulation ProtocolNovember 1997 50 the EAP. The EAP can be used in any of a number of variants. 51 When the EAP is used in it's KEA variant, this results in mutual 52 authentication and key generation. This key is available for 53 use during the PPP data transfer phase by an encryption 54 encapsulation. The encryption encapsulation that is described 55 in this memo is one possible encapsulation that can use the 56 keying material generated by the EAP KEA protocol. 58 1. Introduction 60 The PPP encryption encapsulation will take a PPP packet including the 61 protocol field, apply the chosen encryption algorithm, place the 62 resulting cipher text (and in this specification, an explicit 63 sequence number) in the information field of another PPP packet. The 64 decryptor will apply the inverse algorithm and interpret the result- 65 ing plain text as if it were a PPP packet which had arrived directly 66 on the interface. 68 1.1. Specification of Requirements 70 In this document, several words are used to signify the requirements 71 of the specification. These words are often capitalized. 73 MUST This word, or the adjective required, means that the 74 definition is an absolute requirement of the specifi- 75 cation. 77 MUST NOT This phrase means that the definition is an absolute 78 prohibition of the specification. 80 SHOULD This word, or the adjective recommended, means that 81 there may exist valid reasons in particular cir- 82 cumstances to ignore this item, but the full implica- 83 tions must be understood and carefully weighed before 84 choosing a different course. 86 MAY This word, or the adjective optional, means that this 87 item is one of an allowed set of alternatives. An 88 implementation which does not include this option MUST 89 be prepared to interoperate with another implementa- 90 tion which does include the option. 92 1.2. Terminology 94 This document frequently uses the following terms: 96 DRAFT PPP Fortezza Encryption Encapsulation ProtocolNovember 1997 98 Cryptographic Algorithm 99 The algorithm used to encrypt data. In the Fortezza 100 Encryption Encapsulation Protocol, the Cryptographic 101 Algorithm is Skipjack. 103 Cryptographic mode 104 Block ciphers may be used in several different 105 manners, known as modes. The basic mode of operation 106 of a block cipher is called Electronic Code Book 107 (ECB). This mode always produces the same block of 108 ciphertext as output for the same block of ciphertext 109 as input. In the interest of increasing the random 110 character of the outputs of encipherment other modes 111 were introduced. One such mode is called Cipher Block 112 Chaining (CBC). 114 Cipher Block Chaining (CBC) 115 The CBC mode of operation for Block Ciphers was intro- 116 duced to further obscure the relationship between the 117 ciphertext blocks and the actual input data blocks by 118 manipulating the input data block before encipherment. 119 Block ciphers in CBC mode exhibit the property that 120 the result of an encryption or decryption is deter- 121 mined by not only the value of this particular block 122 of data, but also the value of the ciphertext from the 123 previous block. Hence the term "Chaining" in the name. 125 Cryptographic Synchronization 126 For Block ciphers in CBC mode the loss of a block of 127 data will result in not only failing to decrypt that 128 block, but may also result in failure to decrypt the 129 immediately succeeding block. This condition is known 130 as a loss of "cryptographic synchronization." Note 131 that for block mode algorithms in CBC mode, the loss 132 of cryptographic synchronization only persists for one 133 block after the missing block in the case of decryp- 134 tion. On the other hand, any error during the encryp- 135 tion process will propagate through all subsequent 136 blocks. This is not however, strictly speaking, a loss 137 of cryptographic synchronization. This phenomenon is 138 known as "error-propagation." Therefore, the CBC mode 139 of a block cipher may be said to exhibit "error- 140 propagation" during encryption and be subject to the 141 loss of "cryptographic synchronization" during 142 decrypt. 144 encapsulation The term used to describe the technique of burying one 145 completely formed Protocol Data Unit (PDU), or packet, 147 DRAFT PPP Fortezza Encryption Encapsulation ProtocolNovember 1997 149 in another PDU. The advantages of using this method 150 for providing encryption services is that it can be 151 provided without impacting the operation of protocols 152 above the encapsulation protocol. 154 encipherment Synonym for encryption. 156 Initialization Vector (IV) 157 For a block cipher algorithm in CBC mode, the IV is 158 input into the encryption of the first block in order 159 to further obscure the relationship between the 160 ciphertext and the actual input data by manipulating 161 the input data block before encipherment. For non- 162 streaming protocols, it is required to provide an IV 163 for each individual packet, since the order of 164 delivery of packets may vary in such protocols, and an 165 attempt to decrypt out of order would result in a 166 "loss of cryptographic synchronization." For stream- 167 ing protocols (like PPP) it is not necessary to pro- 168 vide an IV for each individual packet, as the in-order 169 nature of deliver in a streaming protocol means that 170 the "IV" needed to perform a decryption can be 171 obtained from the preceding block of ciphertext. 172 (Note: although not necessary, an IV MAY still be pro- 173 vided for each protected PPP packet. In fact, for a 174 number of reasons, this is the approach suggested 175 here.) 177 Integrity Check Value (ICV) 178 An Integrity Check Value is a value that is computed 179 by the originator over the 180 entire data value that is to be protected. This ICV 181 value is then sent with the data value 182 being protected. Using the same algorithm an ICV 183 value is computed by the recipient over the received 184 data value. The receiver compares the received ICV 185 with the ICV he has computed. If they match, it is 186 probable that the protected data value has not been 187 modified. 189 padding For a block mode algorithm, the data that is encrypted 190 must consist of a whole number of "blocks", where the 191 "block" size is determined by the algorithm (often 192 being 8 bytes in length). If the input data does not 193 contain a whole number of crypto block sized units, it 194 will need to be padded until it reaches that length. 195 Padding can be supplied in two forms: 1) with an 196 explicit length field, or 2) as self-describing 198 DRAFT PPP Fortezza Encryption Encapsulation ProtocolNovember 1997 200 padding. Self-describing padding is the type of pad- 201 ding used in the FEEP encapsulation. 203 peer The other end of the point-to-point link. 205 2. PPP Fortezza Encryption Encapsulation Format 207 The PPP Fortezza Encryption Encapsulation Protocol packet has the 208 following format: 210 0 1 2 3 211 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 213 | Address | Control | 0000 | Protocol ID | 214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 215 | Ciphertext ... 216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 Figure 2.0-1 - The Fortezza Encryption Encapsulation protocol 219 Address and Control 221 These fields MUST be present unless the PPP Address and 222 Control Field Compression option (ACFC) has been nego- 223 tiated. 225 Protocol ID 227 The value of this field is 0x53 or 0x55; the latter indi- 228 cates that ciphertext includes headers for the Multilink 229 Protocol, and REQUIRES that the Individual Link Encryp- 230 tion Control Protocol has reached the Opened state. The 231 leading zero MAY be absent if the PPP Protocol Field 232 Compression option (PFC) has been negotiated. 234 Ciphertext 236 The ciphertext is arrived at as described in the follow- 237 ing section. 239 3. PPP Fortezza Encryption Encapsulation Protocol processing 241 The following sections define the procedures associated with process- 242 ing the PPP Fortezza Encryption Encapsulation. 244 These procedures are threefold: First, a pad is appended to the 246 DRAFT PPP Fortezza Encryption Encapsulation ProtocolNovember 1997 248 protocol and information fields of a PPP packet in order to produce a 249 data block that is a multiple of 8 bytes. Second, an Integrity Check 250 Value (ICV) is computed over the result, and this ICV is appended to 251 the packet. Third, and finally, the SKIPJACK Algorithm in CBC mode is 252 applied over this entire packet, including the pad and ICV value. 254 The following diagram depicts what the ciphertext field in the For- 255 tezza Encryption Encapsulation looks like in detail. 257 0 1 2 3 258 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 | Initialization Vector... | 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 262 | ...Initialization Vector | 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 | Original PPP Packet... | 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 | . | 267 . 268 . 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 | ...Original PPP Packet | 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 | Self Describing Padding... | 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 | ...Self Describing Padding | 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 | Integrity Check Value... | 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 | ...Integrity Check Value | 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 Figure 3.0-1 - The format of the Ciphertext field of the Fortezza 282 Encryption Encapsulation protocol 284 Initialization Vector 286 This 8 byte field holds the IV. These are carried on a 287 per PPP packet basis even though PPP is a stream- 288 oriented, or in-order delivery protocol. This is in 289 order to simplify loss-of-sync recovery. 291 Original PPP packet 293 This arbitrary sized field holds the original PPP packet. 295 DRAFT PPP Fortezza Encryption Encapsulation ProtocolNovember 1997 297 Self-describing Padding 299 This field contains the self-describing padding required 300 to produce an 8-byte aligned packet. It is 1 to 8 bytes 301 in length. 303 Integrity Check Value 305 This field contains the Integrity Check value computed 306 over everything above. It is 8 bytes in length. The 307 first four bytes are the ICV value itself, as a 4 byte 308 big-endian integer. The second four bytes are all 309 zeroes. 311 3.1. Padding 313 Since the SKIPJACK algorithm operates on blocks of 8 octets (and, 314 indeed, so does the ICV algorithm), packets which are of a length 315 which is not a multiple of 8 octets must be padded. This can be 316 injurious to the interpretation of client network-layer protocols 317 being carried over the PPP link, particularly those protocols which 318 do not contain an explicit length field in their protocol headers. 320 In order to avoid this problem the use of self-describing padding is 321 mandated for use with the PPP encapsulation using SKIPJACK. Self- 322 describing padding is defined in RFC1570. Simply put, self- 323 describing padding works like this: 325 1. On the generation side, you always place at least one pad 326 byte, and up to eight - in the case where the packet is already 327 block-aligned. Each pad byte placed has a value equal to its index, 328 from 1 to 8. Once padded the PPP packet is integrity-checked and 329 encrypted and placed in a PPP encryption encapsulation frame, as 330 described in the subsequent sections. 332 2. On the reception side, after the ciphertext is decrypted, 333 and the 8 byte Integrity Check Value field is removed, one looks at 334 the last byte in the remaining data. This is the last byte of the 335 self describing pad field. (The last byte of the self describing pad 336 can be determined by looking for the byte immediately preceding the 8 337 byte ICV, which in turn is the field immediately preceding the HDLC 338 FCS.) This byte indicates the number of bytes of padding to be dis- 339 carded. 341 DRAFT PPP Fortezza Encryption Encapsulation ProtocolNovember 1997 343 3.2. Integrity Check Value calculation 345 The Integrity Check Value is computed in the following manner: 347 The originator computes the 32-bit 1's complement sum of the data 348 field, after it has been padded out to 64-bit block boundaries. The 349 1's complement sum is computed by viewing the data as a series of 350 32-bit big-endian words. The ICV value itself is a 64-bit field. The 351 ones complement sum computed above is placed in the first four bytes 352 and the second four bytes are all zeroes. This ICV value is then 353 appended to the data packet. 355 On the receiving side, after decryption processing, the recipient 356 computes, using the very same algorithm, the entire 64-bit ICV value 357 and then compares it with what has been received. The two values 358 should match. 360 3.3. Encryption 362 The ciphertext is obtained from the plaintext in the following 363 manner: 365 Generally, the SKIPJACK encryption algorithm, being a block cipher, 366 works on packets composed of a multiple of 8 byte blocks. The above 367 padding and Integrity Check Value calculation steps will have pro- 368 duced a data packet that is a multiple of 8 byte blocks. The For- 369 tezza Encryption Encapsulation thus consists of two steps: first, 370 the pre-pending of a per-packet IV value and secondly, the applica- 371 tion of the SKIPJACK algorithm in CBC mode with 64 bit blocks. 373 On the transmit side, the FEEP encryption encapsulation is performed 374 after the Integrity Check Value processing has appended an ICV and 375 before the HDLC or A-HDLC data link protocol processing. Because 376 FEEP utilizes the PPP HDLC or A-HDLC link protocol it is provided 377 with a sequential and mostly reliable link - e.g. HDLC FCS will 378 detect and eliminate corrupted frames.. For this reason we could 379 utilize chaining across multiple packets. I.E., we could obtain the 380 IV value to be used for encrypting the first block of this packet 381 from the ciphertext resulting from the encryption of the last block 382 of the previous packet. 384 However, in the interest of simplifying the processing needed to han- 385 dle a loss of cryptographic synchronization we have elected to 386 include an 8 byte IV value (or "Crypto Synchronization Header" if you 387 will) as the first 8 bytes of the field titled "Ciphertext" in figure 388 2.0-1 above. 390 DRAFT PPP Fortezza Encryption Encapsulation ProtocolNovember 1997 392 What this means is that with this field each packet will automati- 393 cally resync itself. Therefore the loss of one packet due to a com- 394 munications failure will result only in the loss of one packet. 395 Without the Crypto Synchronization Header, the loss of one packet due 396 to communications failure would result in the loss of two packets as 397 the immediately following packet would fail to decrypt properly. The 398 ECP protocol can be utilized to provide crypto resynchronization, but 399 we believe the use of a per packet Crypto Synchronization Header to 400 be the simpler approach. 402 If the async control character map option has been negotiated on the 403 link, the sender applies mapping after the encryption algorithm has 404 been run. 406 There are a lot of details concerning what constitutes the Protocol 407 and Information fields, in the presence or non-presence of Multilink, 408 and whether the ACFC and PFC options have been negotiated, and the 409 type of padding to perform. 411 Regardless of whether ACFC has been negotiated on the link, the 412 sender applies the encryption procedure to only that portion of the 413 packet excluding the address and control field. 415 The plaintext is obtained from the ciphertext in the following 416 manner: 418 The information field of the encapsulating packet is obtained and 419 decrypted using SKIPJACK in CBC mode. Because we are assuming the 420 first 8 bytes constitutes an IV value for the purposes of the CBC 421 mode, we load the first eight bytes in the PPP packets data field 422 into the Skipjack algorithm as IV, and the second 8 bytes as the 423 first data packet. The resulting decrypted PPP packet is handed to 424 Integrity Check Value receive processing. 426 The key to use for these encryption/decryption operations is the one 427 developed during the KEA authentication accomplished during the 428 authentication phase [2]. 430 3.4. MRU considerations and Padding 432 Because of the padding described above, and the additional protocol 433 field and the two bytes of sequence number, it can be seen that the 434 size of the resulting PPP encryption encapsulated frame may be as 435 much as 27 bytes larger than the original, unencapsulated PPP frame. 437 Depending upon the MRU size established during the Link establishment 439 DRAFT PPP Fortezza Encryption Encapsulation ProtocolNovember 1997 441 phase, this expansion could result in the need for fragmentation of a 442 single, original PPP packet into two encryption encapsulated frames. 444 A number of different solutions are available for dealing with this. 446 The simplest solution is to be aware of this problem during Link 447 establishment phase and simply to adjust the value of the MRU that is 448 negotiated with the peer PPP entity to be 27 greater than that being 449 requested by the original PPP link without encryption. That, coupled 450 with the step of reporting the original MRU value to the upper layers 451 as the MTU. 453 Another solution is to make use of the PPP Multi-link procedures 454 which add the overhead of another PPP packet header with additional 455 sequence numbers and "Begin" and "End" bits to signal fragment boun- 456 daries. Given the fact that we only produce, at most, two 457 fragments...as the extra 27 bytes will surely fit in any MRU value 458 negotiated....the Multilink procedure will not actually be that 459 onerous in terms of buffer overhead. 461 For the purposes of this initial recommendation, the former procedure 462 is to be utilized. 464 3.5. Cryptographic synchronization handling 466 We avoid the problem that the loss of a packet due to communications 467 failure will cause the loss of a second packet due to loss of crypto- 468 graphic synchronization through the use of an explicit IV, or "Crypto 469 Synchronization Header" at the beginning of each PPP packet. This 470 approach costs 8 bytes per packet for a savings that is dependent on 471 link quality and is thus hard to quantify. 473 3.6. SKIPJACK mode 475 As PPP is a packet oriented protocol the cryptographic mode selected 476 for SKIPJACK operations is Cipher Block Chaining mode on 64 bits of 477 data. 479 Security Considerations 481 This memo defines a method for securing the exchanging of data frames 482 over a PPP link. 484 DRAFT PPP Fortezza Encryption Encapsulation ProtocolNovember 1997 486 References: 488 [1] Simpson, W. A., 'The Point to Point Protocol 489 (PPP)', July 1994, RFC 1661. 491 [2] Nace, W. A., and Zmuda, J. E. 'PPP EAP KEA Public Key 492 Authentication Protocol', November 21st, 493 1997, draft-ietf-pppext-eapkea-00.txt, work 494 in progress. 496 Acknowledgements: 498 Thanks to Peter Yee and Russ Housley who provided helpful comments on 499 earlier versions of this Memo. Thanks are due to Gerry Meyer for 500 helping me understand his ECP Internet Draft. Thanks also are due to 501 Keith Sklower and Gerry Meyer for their DESE RFC. And thanks to Bill 502 Simpson for the standard PPP spec boilerplate from which I have bor- 503 rowed heavily. 505 Chair's Address: 507 The working group can be contacted via the current 508 chair: 510 Karl Fox 511 Ascend Communications, Inc. 513 Email: karl@ascend.com 515 Author's Address: 517 Questions about this memo can also be directed to: 519 DIRNSA 520 Attn: X22 (W. Nace) 521 9800 Savage Road 522 Fort Meade, MD 20755-6000 523 USA 525 Phone: +1 410 859-4464 526 Email: WANace@missi.ncsc.mil 528 James E. Zmuda 529 SPYRUS 530 2460 N. First Street 531 Suite 100 532 San Jose, CA 95131-1023 533 USA 535 DRAFT PPP Fortezza Encryption Encapsulation ProtocolNovember 1997 537 Phone: +1 408 432-8180 538 Email: jzmuda@spyrus.com