From ipsec-request@ans.net Tue Mar 1 15:33:15 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA16518 (5.65c/IDA-1.4.4 for ); Tue, 1 Mar 1994 10:47:22 -0500 Received: by interlock.ans.net id AA27756 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 1 Mar 1994 10:38:33 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Tue, 1 Mar 1994 10:38:33 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 1 Mar 1994 10:38:33 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 1 Mar 1994 10:38:33 -0500 Message-Id: <9403011533.AA06163@skidrow.lkg.dec.com> To: Phil Karn Cc: iab-retreat@ISI.EDU, mobile-ip@ossi.com, ipsec@ans.net In-Reply-To: Your message of "Mon, 28 Feb 94 14:32:53 PST." <199402282232.OAA01084@servo.qualcomm.com> Date: Tue, 01 Mar 94 10:33:15 -0500 From: "Donald E. Eastlake 3rd (Beast)" X-Mts: smtp Although I was very disappointed by and disapprove of most of the US administration's Feb 4th 1994 "Big Brother" announcements, they did say they plan to legalize temporary export of encryption for personal use. Donald From: Phil Karn To: kent@BBN.COM Cc: pmetzger@lehman.com, iab-retreat@ISI.EDU, mobile-ip@ossi.com, ipsec@ans.net In-Reply-To: <199402282206.AA06971@venera.isi.edu> (message from Steve Kent on Mon, 28 Feb 94 17:02:49 -0500) >... > >My original point remains: bulk encryption is often much easier to >deploy, and gives considerably more "bang for the buck", than >end-to-end authentication. It seems pretty clear to me that had >encrypted IP tunnels been in widespread use, the Internet's recent >passive monitoring attacks would have been much less successful. > >Your other comment about Kerberos with authentication being okay for >export also misses the point. Would you like to come and install >authentication-only Kerberos on *all* of my company's computers so I >can access them securely from overseas without having to violate ITAR >by carrying my encrypted IP tunnel software out of the US? > >Phil Donald From ipsec-request@ans.net Tue Mar 1 05:52:57 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA15811 (5.65c/IDA-1.4.4 for ); Tue, 1 Mar 1994 10:59:32 -0500 Received: by interlock.ans.net id AA27389 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 1 Mar 1994 10:54:04 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Tue, 1 Mar 1994 10:54:04 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 1 Mar 1994 10:54:04 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 1 Mar 1994 10:54:04 -0500 Date: Tue, 1 Mar 94 10:52:57 EST Message-Id: <9403011552.AA25386@tri-flow.ftp.com.ftp.com> To: karn@qualcomm.com Subject: From: stev@tri-flow.ftp.com (stev knowles) Cc: iab-retreat@ISI.EDU, mobile-ip@ossi.com, ipsec@ans.net Sender: stev@tri-flow.ftp.com Repository: tri-flow.ftp.com, [message accepted at Tue Mar 1 10:52:52 1994] Originating-Client: d-cell.ftp.com Content-Length: 248 phil, your note confused me. are you in favor of having privacy and authentication be seperate? the reason i ask is your message left me feeling you were not in the beginning, but that you were when you gave your IETF meeting example. . . . . From ipsec-request@ans.net Tue Mar 1 15:58:25 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA16608 (5.65c/IDA-1.4.4 for ); Tue, 1 Mar 1994 11:23:45 -0500 Received: by interlock.ans.net id AA27171 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 1 Mar 1994 11:18:40 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 1 Mar 1994 11:18:40 -0500 Message-Id: <199403011618.AA15391@interlock.ans.net> To: "Perry E. Metzger" Cc: Phil Karn , iab-retreat@isi.edu, mobile-ip@ossi.com, ipsec@ans.net In-Reply-To: Your message of "Mon, 28 Feb 1994 17:02:49 EST." <199402282206.RAA16535@lehman.com> Subject: swIPe stuff Date: Tue, 01 Mar 94 10:58:25 -0500 From: Steve Kent Perry, The IAB policy on cryptography is consistent with the general thurst of your observation, i.e., we have adopted a stance that calls for the use of cryptography to provide high quality security as applicable throughout the Internet, irrespective of national policies. However, mindful of international (not just U.S.) controls (export and internal use) on crypto, we also suggest using crypto in a focused way. Thus, where crypto for authentication/integrity can achieve security goals and encryoption for confidentiality is not required, we advocate use of crypto in the former fashion. Some countries are more restrictive about what forms of crypto their citizens can easily use within their own country. Not calling for crypto for confidentialtiy where crypto for authentication and integrity will suffice facillitates interoperable, international communication. In terms of integrity checks, my point was that strong checks, e.g., hashes, are really required. This is not what we put in non- security protocols, and so use of encryption without security- oriented integrity checks is dangerous. Use of the integrity checks alone is a good approach for circumstances where confidentiality is not required. As for OFB being a strange case, use of CBC has a different, but analogous set of problems for the last enciphered block. Even a mode like CBC has some subtle vulnerabilities, if used with a weak integrity check like the IP checksum. The best bet is use of a good hash function, either in conjunction with encryption, signed, or with a secret seed quantity. Steve From ipsec-request@ans.net Tue Mar 1 16:04:53 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA21070 (5.65c/IDA-1.4.4 for ); Tue, 1 Mar 1994 11:26:42 -0500 Received: by interlock.ans.net id AA20055 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 1 Mar 1994 11:21:38 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 1 Mar 1994 11:21:38 -0500 Message-Id: <199403011621.AA33361@interlock.ans.net> To: pmetzger@lehman.com Cc: Steve Kent , Phil Karn , iab-retreat@isi.edu, mobile-ip@ossi.com, ipsec@ans.net In-Reply-To: Your message of Mon, 28 Feb 94 18:59:31 -0500. <9402282359.AA10335@andria.lehman.com> Date: Tue, 01 Mar 94 11:04:53 -0500 From: Steve Kent Perry, Your assertion in the first message that encryption is generally as good as authentication, was the assertion I was commenting upon. The point being that, in general, encryption is not an equivalent alternative to cryptographic authentication. The OFB example was just one way of making that point. As for bulk encryoption, rather than end-to-end, that is the general form of what Phil seems to be arguing, i.e., that encryption of traffic between sites is easier than authentication implemented on an end system basis, because of reduced management burdens. While that observation is true, the resulting functionality, is not the same, even if the inter-site encryption is accompanied by authentication at the same granularity. For some contexts this approach could be quite effective, e.g., if one were atte,tping to build a private corporate Internet on top of a public Internet. However, in a more general environment, the wide range of communicating partners makes inter-site encryption less effective (compared to end-to-end authentication). Steve From ipsec-request@ans.net Tue Mar 1 02:25:46 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA19158 (5.65c/IDA-1.4.4 for ); Tue, 1 Mar 1994 13:36:25 -0500 Received: by interlock.ans.net id AA27700 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 1 Mar 1994 13:28:19 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 1 Mar 1994 13:28:19 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 1 Mar 1994 13:28:19 -0500 Message-Id: <199403011826.AA17710@zephyr.isi.edu> To: Steve Kent Cc: "Perry E. Metzger" , Phil Karn , iab-retreat@ISI.EDU, mobile-ip@ossi.com, ipsec@ans.net Reply-To: pvm@isi.edu Subject: Re: swIPe stuff In-Reply-To: Your message of Tue, 01 Mar 1994 10:58:25 -0500. <199403011619.AA00143@venera.isi.edu> Date: Tue, 01 Mar 94 10:25:46 PST From: Paul Mockapetris ...... Not calling for crypto for confidentialtiy > where crypto for authentication and integrity will suffice facillitates > interoperable, international communication. > > In terms of integrity checks, my point was that strong checks, > e.g., hashes, are really required. This is not what we put in non- > security protocols, and so use of encryption without security- > oriented integrity checks is dangerous. Use of the integrity checks > alone is a good approach for circumstances where confidentiality is > not required. Do you contend that remote login is such a case? To add to the list of people "helping" Phil to define his point, a fully-encrypted tunnel rlogin provides an easy-to-grasp level of security. One can then read mail without outside observers. One can then download and upload files without exposure. One can use the tunneled-to firewall to allow further logins with passwords in the clear but no exposure outside the firewall. Integrity, authentication, and the rest are all nice adjuncts, but are aimed at attacks that are active, and hence more detectable. Its hard to avoid the impression that attempts to sell users on various types of security without privacy on technical grounds are really trojan horses for policy issues. paul From ipsec-request@ans.net Tue Mar 1 20:14:42 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA16517 (5.65c/IDA-1.4.4 for ); Tue, 1 Mar 1994 15:31:37 -0500 Received: by interlock.ans.net id AA16557 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 1 Mar 1994 15:19:05 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 1 Mar 1994 15:19:05 -0500 Message-Id: <199403012019.AA25769@interlock.ans.net> To: Paul Mockapetris Cc: "Perry E. Metzger" , Phil Karn , iab-retreat@isi.edu, mobile-ip@ossi.com, ipsec@ans.net Subject: what security do we need? Date: Tue, 01 Mar 94 15:14:42 -0500 From: Steve Kent Paul, >Do you contend that remote login is such a case? To add to the list >of people "helping" Phil to define his point, a fully-encrypted tunnel >rlogin provides an easy-to-grasp level of security. Any procedure that includes rlogin is already suspect in terms of security :-). In part, the question is where does the encryption start and end? If it starts at a firewall from my site and ends at a firewall at your site, then any security breech within either site is capable of capturing passwords that are protected along the path between our sites. If the path is at the end points, then Phil's argument does not apply, because he argued against the administrative overhead of per-host administration of the parameters required for end-to-end authentication, which are essentially the same as those required for end-to-end encryption. >One can then read mail without outside observers. Yes, but who is outside? PEM or other email secuity technology addresses the email reading problem, providing protection even against nosey LAN administrators. >One can then download and upload files without exposure. Yes, and if the files need to be proceted against disclosure encryption is the right answer. But where have those files been? if the provenance of the files is important, a digital signature facility for the files might be the best technique, irrespective of the use of crypto for confidentiality. >One can use the tunneled-to firewall to allow further logins with >passwords in the clear but no exposure outside the firewall. Yes, but opportunities exist for password snatching within the local environment and they would probably be exploited by attackers if we choose to emphasize layer 3 encryption over, lets say, use of S-Key and analogous challange-response schemes. >Integrity, authentication, and the rest are all nice adjuncts, but are >aimed at attacks that are active, and hence more detectable. I disagree, in part. Bind-time authentication is the basis for access control to hosts, net resources, etc. Continuous authentication protects against active attacks. As you note, active attacks are easier to detect, but detection is not the same as prevention, as anyone whose house has been robbed will tell you. >Its hard to avoid the impression that attempts to sell users on >various types of security without privacy on technical grounds are >really trojan horses for policy issues. Come now, Paul, don't turn into a conspiracy theorist. I've been building network layer encryption systems (ones that focused on encryption rather than authentication) for over 15 years. Some worked end-to-end, while others acted at what you would consider to be firewall boundaries. The first ones I built used DES. I think I understand the advantages of each approach, and I am sensitive to the concerns of vendors who want to be able to ship products overseas with minimum hassle. If we take an all-or-nothing approach, by emphasizing encryption over more exportable forms of crypto, then we run a risk of substantial delay if export controls are not loosened, or we encourage people to use weak (or escrowed) crypto algortihms than can be easily exported. Getting layer 3 crypto into operating systems is not a task easily effected by users, in contrast to applications like email that tend to reside outside of OS boundaries. It requires lots of vendor cooperation to cause this to happen. If vendors are concerned about the exportability of products with good encryption ... Steve From ipsec-request@ans.net Tue Mar 1 20:31:38 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA21213 (5.65c/IDA-1.4.4 for ); Tue, 1 Mar 1994 15:43:05 -0500 Received: by interlock.ans.net id AA33372 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 1 Mar 1994 15:32:34 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 1 Mar 1994 15:32:34 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 1 Mar 1994 15:32:34 -0500 Date: Tue, 1 Mar 1994 12:31:38 -0800 From: braden@ISI.EDU (Bob Braden) Message-Id: <199403012031.AA21786@zephyr.isi.edu> To: pmetzger@lehman.com, kent@BBN.COM Subject: Re: swIPe stuff Cc: karn@qualcomm.com, iab-retreat@ISI.EDU, mobile-ip@ossi.com, ipsec@ans.net *> From kent@BBN.COM Tue Mar 1 08:21:08 1994 *> To: "Perry E. Metzger" *> Cc: Phil Karn , iab-retreat@ISI.EDU, mobile-ip@ossi.com, *> ipsec@ans.net *> In-Reply-To: Your message of "Mon, 28 Feb 1994 17:02:49 EST." *> <199402282206.RAA16535@lehman.com> *> Subject: swIPe stuff *> Date: Tue, 01 Mar 94 10:58:25 -0500 *> From: Steve Kent *> Content-Length: 1595 *> X-Lines: 31 *> *> Perry, *> *> The IAB policy on cryptography is consistent with the general *> thurst of your observation, i.e., we have adopted a stance that calls *> for the use of cryptography to provide high quality security as *> applicable throughout the Internet, irrespective of national policies. *> However, mindful of international (not just U.S.) controls (export and *> internal use) on crypto, we also suggest using crypto in a focused *> way. Thus, where crypto for authentication/integrity can achieve *> security goals and encryoption for confidentiality is not required, we *> advocate use of crypto in the former fashion. Some countries are more *> restrictive about what forms of crypto their citizens can easily use *> within their own country. Not calling for crypto for confidentialtiy *> where crypto for authentication and integrity will suffice facillitates *> interoperable, international communication. *> *> In terms of integrity checks, my point was that strong checks, *> e.g., hashes, are really required. This is not what we put in non- *> security protocols, and so use of encryption without security- *> oriented integrity checks is dangerous. Use of the integrity checks *> alone is a good approach for circumstances where confidentiality is Dr. Kent, Good approach to what? *> not required. *> *> As for OFB being a strange case, use of CBC has a different, *> but analogous set of problems for the last enciphered block. Even a *> mode like CBC has some subtle vulnerabilities, if used with a weak *> integrity check like the IP checksum. The best bet is use of a good *> hash function, either in conjunction with encryption, signed, or with *> a secret seed quantity. *> *> Steve *> Sorry, I must have dozed off there somewhere, I have lost track of what the discussion is about. Bob Braden From ipsec-request@ans.net Tue Mar 1 20:38:57 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA03082 (5.65c/IDA-1.4.4 for ); Tue, 1 Mar 1994 15:55:40 -0500 Received: by interlock.ans.net id AA38365 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 1 Mar 1994 15:43:45 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 1 Mar 1994 15:43:45 -0500 Message-Id: <199403012043.AA08409@interlock.ans.net> To: Bob Braden Cc: pmetzger@lehman.com, kent@BBN.COM, karn@qualcomm.com, iab-retreat@isi.edu, mobile-ip@ossi.com, ipsec@ans.net Subject: Re: swIPe stuff In-Reply-To: Your message of Tue, 01 Mar 94 12:31:38 -0800. <199403012031.AA21786@zephyr.isi.edu> Date: Tue, 01 Mar 94 15:38:57 -0500 From: Steve Kent Bob, A good approach to authenticating the identity of users/machines, etc. for access control purposes. Steve From ipsec-request@ans.net Tue Mar 1 22:02:24 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA17308 (5.65c/IDA-1.4.4 for ); Tue, 1 Mar 1994 17:12:11 -0500 Received: by interlock.ans.net id AA23562 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 1 Mar 1994 17:04:09 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Tue, 1 Mar 1994 17:04:09 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Tue, 1 Mar 1994 17:04:09 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 1 Mar 1994 17:04:09 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 1 Mar 1994 17:04:09 -0500 Message-Id: <9403012202.AA15965@andria.lehman.com> To: Steve Kent Cc: pmetzger@lehman.com, Phil Karn , iab-retreat@isi.edu, mobile-ip@ossi.com, ipsec@ans.net In-Reply-To: Your message of "Tue, 01 Mar 1994 11:04:53 EST." <199403011621.LAA26467@lehman.com> Reply-To: pmetzger@lehman.com X-Reposting-Policy: redistribute only with permission Date: Tue, 01 Mar 1994 17:02:24 -0500 From: "Perry E. Metzger" Steve Kent says: > As for bulk encryoption, rather than end-to-end, that is the > general form of what Phil seems to be arguing, i.e., that encryption > of traffic between sites is easier than authentication implemented on > an end system basis, because of reduced management burdens. While > that observation is true, the resulting functionality, is not the > same, even if the inter-site encryption is accompanied by > authentication at the same granularity. For some contexts this > approach could be quite effective, e.g., if one were atte,tping to > build a private corporate Internet on top of a public Internet. > However, in a more general environment, the wide range of > communicating partners makes inter-site encryption less effective > (compared to end-to-end authentication). I see no reason to believe this, and good reason to believe the contrary given good key management protocols. Perry From ipsec-request@ans.net Tue Mar 1 22:09:19 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA07621 (5.65c/IDA-1.4.4 for ); Tue, 1 Mar 1994 17:17:28 -0500 Received: by interlock.ans.net id AA24973 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 1 Mar 1994 17:11:42 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Tue, 1 Mar 1994 17:11:42 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Tue, 1 Mar 1994 17:11:42 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 1 Mar 1994 17:11:42 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 1 Mar 1994 17:11:42 -0500 Message-Id: <9403012209.AA15981@andria.lehman.com> To: pvm@isi.edu Cc: Steve Kent , Phil Karn , iab-retreat@isi.edu, mobile-ip@ossi.com, ipsec@ans.net Subject: Re: swIPe stuff In-Reply-To: Your message of "Tue, 01 Mar 1994 10:25:46 PST." <199403011826.AA17710@zephyr.isi.edu> Reply-To: pmetzger@lehman.com X-Reposting-Policy: redistribute only with permission Date: Tue, 01 Mar 1994 17:09:19 -0500 From: "Perry E. Metzger" Paul Mockapetris says: > Its hard to avoid the impression that attempts to sell users on > various types of security without privacy on technical grounds are > really trojan horses for policy issues. You've said that far better than I possibly could have. I will also point out that time is limited. Firms such as the one that pays me have billions a day riding on the integrity of their internetworks -- I say that without the slightest degree of exageration. Wall Street, to name just one user group, will only wait so long while various groups debate how to please everyone -- the time is very near when one or more of them may develop their own in the absense of a standard and deploy it widely. The costs involved are so trivial to such firms, and the problems being addressed so incredibly important, that it is only a matter of time before this happens if the IETF does not get into gear on a real, end to end encrypted IP security protocol -- and no, authentication is not sufficient when someone could make millions front running your trades. Perry From ipsec-request@ans.net Tue Mar 1 22:22:18 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA07428 (5.65c/IDA-1.4.4 for ); Tue, 1 Mar 1994 17:31:55 -0500 Received: by interlock.ans.net id AA36862 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 1 Mar 1994 17:25:58 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 1 Mar 1994 17:25:58 -0500 Message-Id: <199403012225.AA27898@interlock.ans.net> To: pmetzger@lehman.com Cc: Steve Kent , Phil Karn , iab-retreat@isi.edu, mobile-ip@ossi.com, ipsec@ans.net In-Reply-To: Your message of Tue, 01 Mar 94 17:02:24 -0500. <9403012202.AA15965@andria.lehman.com> Date: Tue, 01 Mar 94 17:22:18 -0500 From: Steve Kent Perry, The "this" in your response has an indefinate antecedent. What part of the cited text do you not believe? Do have any arguments you might like to share to substantiate your opinion? Steve From ipsec-request@ans.net Tue Mar 1 22:43:48 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA07524 (5.65c/IDA-1.4.4 for ); Tue, 1 Mar 1994 17:53:16 -0500 Received: by interlock.ans.net id AA25556 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 1 Mar 1994 17:46:21 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Tue, 1 Mar 1994 17:46:21 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Tue, 1 Mar 1994 17:46:21 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 1 Mar 1994 17:46:21 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 1 Mar 1994 17:46:21 -0500 Message-Id: <9403012243.AA16035@andria.lehman.com> To: Steve Kent Cc: pmetzger@lehman.com, Phil Karn , iab-retreat@isi.edu, mobile-ip@ossi.com, ipsec@ans.net In-Reply-To: Your message of "Tue, 01 Mar 1994 17:22:18 EST." <199403012226.RAA01257@lehman.com> Reply-To: pmetzger@lehman.com X-Reposting-Policy: redistribute only with permission Date: Tue, 01 Mar 1994 17:43:48 -0500 From: "Perry E. Metzger" Steve Kent says: > The "this" in your response has an indefinate antecedent. > What part of the cited text do you not believe? Do have any arguments > you might like to share to substantiate your opinion? Which response, and which "this", are you refering to? Perry From ipsec-request@ans.net Tue Mar 1 12:42:17 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA07530 (5.65c/IDA-1.4.4 for ); Tue, 1 Mar 1994 17:59:50 -0500 Received: by interlock.ans.net id AA29440 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 1 Mar 1994 17:49:06 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 1 Mar 1994 17:49:06 -0500 Message-Id: <199403012249.AA03068@interlock.ans.net> From: smb@research.att.com Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 1 Mar 1994 17:49:06 -0500 To: iab-retreat@isi.edu, mobile-ip@ossi.com, ipsec@ans.net Reply-To: /dev/null@research.att.com Subject: Encryption flamefest Date: Tue, 01 Mar 94 17:42:17 EST The only thing worse than a flamefest is a flamefest addressed to three different mailing lists -- and I happen to be on all of them. Fortunately, I haven't posted anything yet, so I don't get directly- addressed messages, to -- and I've added a bogus Reply-To line to this note, which may encourage folks to think about the proper audience for any responses... --Steve Bellovin From ipsec-request@ans.net Wed Mar 2 10:43:49 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA18971 (5.65c/IDA-1.4.4 for ); Wed, 2 Mar 1994 10:43:49 -0500 Received: by interlock.ans.net id AA20221 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 2 Mar 1994 10:37:53 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Wed, 2 Mar 1994 10:37:53 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 2 Mar 1994 10:37:53 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 2 Mar 1994 10:37:53 -0500 Date: Wed, 02 Mar 94 06:44:13 From: "Housley, Russ" Encoding: 455 Text Message-Id: <9402027626.AA762619453@uu0892.spyrus.com> To: pmetzger@lehman.com, Steve Kent Cc: karn@qualcomm.com, iab-retreat@isi.edu, mobile-ip@ossi.com, ipsec@ans.net Subject: Re: swIPe stuff Perry: You may want to look at the Cipher Block Chaining with Checksum (CBCC) mode that was developed at Xerox PARC. I do not know if there is a paper on this mode, but I do know that the algoritm description is included as part of the XNS Authentication Spec. This mode allows weaker integrity check functions to be used as long as the integrity check value is stored in the final block of ciphertext. Just food for thought... Russ From ipsec-request@ans.net Thu Mar 3 11:37:57 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA19172 (5.65c/IDA-1.4.4 for ); Thu, 3 Mar 1994 11:37:57 -0500 Received: by interlock.ans.net id AA18346 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 3 Mar 1994 11:34:08 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Thu, 3 Mar 1994 11:34:08 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Thu, 3 Mar 1994 11:34:08 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 3 Mar 1994 11:34:08 -0500 Date: Thu, 03 Mar 94 07:52:29 From: "Housley, Russ" Encoding: 1164 Text Message-Id: <9402037627.AA762709949@uu0892.spyrus.com> To: paalh@nta.no Cc: ipsec@ans.net Subject: Re: Comments on IPSEC work Paal: You say: - It is unclear why the author introduces an additional protocol type (the IPPROTO_SWIPE). Many management packages look inside packets. There must be a protocol identifier that warns these packages that they will not be able to parse the contents of the IP datagram. That is, the IP datagram is not carrying TCP or UDP. You say: - The swIPe protocol claims to support a "wide variety" of crypto systems. Well, this wide variety actually excludes all stream ciphers. If you use a stream-cipher, you will have to carry some use-and-discard crypto synchronization per packet, such as a random IV or an encrypted random packet encryption key. There is no room for this in the swIPe header. Why can't you simply prepend the IV to the ciphertext? The ciphertext will be longer than the plaintext, but I do not see this as a problem. Do you? You say: - A good thing about swIPe is that it its header is word aligned. I agree. Many client protocols to IP assume that they are word aligned. This is not true of OSI protocols, so NLSP does not address this issue. Russ From ipsec-request@ans.net Fri Mar 4 14:49:18 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA12529 (5.65c/IDA-1.4.4 for ); Fri, 4 Mar 1994 14:49:18 -0500 Received: by interlock.ans.net id AA41721 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Fri, 4 Mar 1994 14:24:33 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Fri, 4 Mar 1994 14:24:33 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Fri, 4 Mar 1994 14:24:33 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 4 Mar 1994 14:24:33 -0500 Date: Fri, 04 Mar 94 10:24:10 From: "Housley, Russ" Encoding: 2108 Text Message-Id: <9402047628.AA762805450@uu0892.spyrus.com> To: Paal Hoff Cc: ipsec@ans.net Subject: Re: SWIPE Hoff: >> You say: >> - It is unclear why the author introduces an additional protocol >> type (the IPPROTO_SWIPE). >> >> Many management packages look inside packets. There must be a protocol >> identifier that warns these packages that they will not be able to >> parse the contents of the IP datagram. That is, the IP datagram is not >> carrying TCP or UDP. > >If this is the motivation, I see the point. Our "sniffer" is of course >quite confused when it listens to encrypted IP traffic in our lab >installation. I have experienced this problem with other crypto experiments, and this must be solved for the IPSP to be accepted by the general Internet population. Therfore, an IPPROTO_IPSP will be needed! >> You say: >> - The swIPe protocol claims to support a "wide variety" of crypto >> systems. Well, this wide variety actually excludes all stream >> ciphers. If you use a stream-cipher, you will have to carry >> some use-and-discard crypto synchronization per packet, such as >> a random IV or an encrypted random packet encryption key. >> There is no room for this in the swIPe header. >> >> Why can't you simply prepend the IV to the ciphertext? The ciphertext >> will be longer than the plaintext, but I do not see this as a problem. >> Do you? > >I admit that my claim disfavors SWIPE a bit. Surely, I can do what you >describe. But what will be the standard way of doing it? The problem >is not that SWIPE excludes the use of stream-ciphers, but it does not >standardize the method of carrying crypto sync pr packet. I buy your >argument, but if the ambition of SWIPE is to ease interoperability, I >think it should specify this. I do not see it as a problem that the >ciphertext is longer than the plaintext. The lenght of the IV depends on the crypto algorithm that is used. I recommend that the standard be that the IV prepended to the ciphertext. Since the recipient will know which algorithm is being used, the recipient will know how many octets to interpret as the IV. Russ From ipsec-request@ans.net Fri Mar 11 03:04:00 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA03205 (5.65c/IDA-1.4.4 for ); Fri, 11 Mar 1994 14:07:02 -0500 Received: by interlock.ans.net id AA14340 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Fri, 11 Mar 1994 14:04:30 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Fri, 11 Mar 1994 14:04:30 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 11 Mar 1994 14:04:30 -0500 Message-Id: Date: Fri, 11 Mar 94 11:04 PST X-Sender: brian@harry.lloyd.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ipsec@ans.net From: brian@lloyd.com (Brian Lloyd) Subject: IETF meeting I did not see an IPSEC WG meeting scheduled for the upcoming IETF mtg. Did I miss it or are we going to pass this time around? Brian Lloyd, President Lloyd Internetworking brian@lloyd.com 3031 Alhambra Drive (916) 676-1147 - voice Suite 102 (916) 676-3442 - fax Cameron Park, CA 95682 From ipsec-request@ans.net Fri Mar 11 09:24:18 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA17675 (5.65c/IDA-1.4.4 for ); Fri, 11 Mar 1994 18:22:07 -0500 Received: by interlock.ans.net id AA26000 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Fri, 11 Mar 1994 18:20:07 -0500 Received: by interlock.ans.net (Internal Mail Agent-5); Fri, 11 Mar 1994 18:20:07 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Fri, 11 Mar 1994 18:20:07 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Fri, 11 Mar 1994 18:20:07 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Fri, 11 Mar 1994 18:20:07 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 11 Mar 1994 18:20:07 -0500 Message-Id: <00112.2846248271.328@poncho.phx.sectel.mot.com> X-Charset: MACINTOSH To: ipsec@ans.net (ip security mailing list) From: Paul_Lambert@poncho.phx.sectel.mot.com (Paul Lambert) Date: Fri, 11 Mar 1994 16:24:18 MST Subject: Re: IETF meeting Reply to: RE>IETF meeting Brian, We were just scheduled yesterday by Megan for the following slots: >> >> Wed. March 30: 1930-2200 >> >> [GEN] Open IAB Meeting >> [INT] Internet Stream Protocol V2 WG >> [INT] Router Requirements WG >> [MGT] Network Management Area: Open Meeting >> [SEC] IP Security WG - Key Management >> [USV] Distribution and Announcement BOF >> and... >> >> Thu. March 31: 0930-1200 >> >> [INT] Point-to-Point Protocol Extensions WG >> [IPNG] IPNG Requirements BOF >> [MGT] Printer MIB WG >> [OPS] CIDR Deployment WG * >> [RTG] Inter-Domain Multicast Routing WG >> [SEC] IP Security WG - Encapsulation Protocol >> [USV] Network Training Materials WG >> >> *If for any reason you are interested in cidrd it's going to be >> moved for other reasons, but the slot hasn't been determined. >> >> Megan >> Stay tuned, we will have an agenda early next week. Anyone who wants a specific slot on the agenda please drop me a note. Paul From ipsec-request@ans.net Wed Mar 16 05:46:39 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA03264 (5.65c/IDA-1.4.4 for ); Wed, 16 Mar 1994 11:11:15 -0500 Received: by interlock.ans.net id AA26075 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 16 Mar 1994 10:46:27 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 16 Mar 1994 10:46:27 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 16 Mar 1994 10:46:27 -0500 Date: Wed, 16 Mar 94 10:46:39 EST From: Robert Glenn Organization: National Institute of Standards and Technology (NIST) Sub-Organization: Computer Systems Laboratory (CSL) Message-Id: <9403161546.AA13964@sloth.ncsl.nist.gov> To: ipsec@ans.net Subject: IPSP VS IPngSP One of the things this group is chartered to do is to develop an IPv4 security protocol. Recently, the IPng groups seem to be taking more and more of an interest in lower layer security services. Their interest has even resulted in Internet Drafts that propose security solutions independant to what is being developed within the IPSEC Working Group. It seems to me that this lack of coordination needs to be addressed as soon as possible. If it is not addressed soon, and we end up with seperate and distinct security protocols for IPv4 and the various IPng protocols, the result will be at the very least undesirable, and more than likely, costly, confusing, and lead to a much more difficult coordination effort down the road. I am not proposing that this group start dedicating its scarce resources into finding out what is going on in the IPng world. I am suggesting that the IPng groups might be best pointing to the work being done by the IPSEC group for their lower layer security concerns and that this group keep in mind that this will be the case. The IPng liasons should also continue to actively participate in this group, this kind of synergy is good for all concerned. I am further proposing that *when* the IPSEC I-D is written, that the IPng groups be solicited to provide additional text (in whatever is deemed an appropriate form) that shows what (hopefully minor) modifications are needed to the IPSP protocol so that it can provide its security services for the IPng protocols as well as IPv4. Rob G. glenn@osi.ncsl.nist.gov From ipsec-request@ans.net Wed Mar 16 07:11:31 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA16844 (5.65c/IDA-1.4.4 for ); Wed, 16 Mar 1994 12:09:05 -0500 Received: by interlock.ans.net id AA12907 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 16 Mar 1994 12:05:49 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Wed, 16 Mar 1994 12:05:49 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Wed, 16 Mar 1994 12:05:49 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 16 Mar 1994 12:05:49 -0500 Date: Wed, 16 Mar 94 12:11:31 EST From: Robert_Ullmann.LOTUS@CRD.lotus.com Message-Id: <9403161711.AA14233@Mail.Lotus.com> Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 16 Mar 1994 12:05:49 -0500 To: unixml.dnet!"glenn@osi.ncsl.nist.gov"@lotus.com Subject: re IPngSP Hi, There is a *perception* in the IPng process that IPSEC isn't making any progress. (Note that I don't share this perception.) When combined with the strongly expressed requirements from many of the external reviewers that IPng must be "secure" (*) this has led one of the WGs (SIPP) to invent their own. (You should note that SIPP is trying to eat everyone else's lunch too, with new MAC convergence protocols, new variants of routing protocols, DNS inventions, etc. :-) I think IPSEC needs to state *formally* to the appropriate directorates that the question of an NLSP belongs to IPSEC, that IPSEC is prepared to provide it for whatever IPng actually arrives, and that any work in the IPng Area that does more than liase with IPSEC is out-of-order. Certainly CATNIP has no difficulty with using the IPSEC NLSP. (And TUBA will certainly use (an, one of, the?) ISO NLSP.) Best Regards Robert Ullmann CATNIP chair (pro-tem, 29th IETF) (*I presume that in this forum I don't need to discuss the vacuity of the concept of asking that something by "secure" without specifiying whether you mean authentication, access control, confidentiality, non-deniability, etc ... and against what opfor ? :-) From ipsec-request@ans.net Thu Mar 24 18:24:55 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA05656 (5.65c/IDA-1.4.4 for ); Wed, 23 Mar 1994 13:19:08 -0500 Received: by interlock.ans.net id AA03574 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 24 Mar 1994 13:26:17 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 24 Mar 1994 13:26:17 -0500 Message-Id: <199403241826.AA15602@interlock.ans.net> To: Paul Lambert Cc: ipsec@ans.net, solo@BBN.COM Subject: IKMP rough draft Date: Thu, 24 Mar 94 13:24:55 -0500 From: solo@BBN.COM Attached is an initial rough draft for an internet key management protocol. The main goal of this version is to examine the functions and services, the types of exchange, and the types and contents of IKMP PDUs. I haven't addressed specific algorithms and expect that this structure can support a variety of choices (both symmetric and asymmetric). Dave Internet Key Management Protocol 1.0 Introduction The purpose of this draft is to present a first draft for an internet key management protocol (IKMP). This proposal borrows heavily from approaches taken within the SDNS KMP specification. IKMP is invoked when a security protocol/application determines that a key and associated control information is required. For example, in the case of IPSP, a datagram arrives for IPSP processing. IPSP checks its security association database for a match (at least on addresses, possibly on other parameters) and uses a match if found. If not IKMP is invoked to set up a security association that matches the parameters. The basic model for IKMP consists of an initial protocol exchange to create a traffic key accompanied by a family of management PDUs to support attribute negotiation, deleting a security association, error reporting, and security association replacement. IKMP PDUs are exchanged via UDP. This description is oriented around a pairwise association management model. These same tools can be used to manage multicast associations or anycast using the replace security association facility. Robust support for multiparty security associations will require additional management functionality for each party joining in such an association. The PDU format portion of each description currently consists of a list of fields, precise definitions will be developed in subsequent drafts. It is expected that an IKMP PDU consists of initial fixed fields for SAID and PDU type followed by Type/Length/Value (TLV) encoding of the optional elements. 2.0 Initial Setup PDUs 2.1 Establish Security Association This PDU is sent by the initiator of an SA to the peer entity to begin creation of a security association. It contains the SAID (security association identifier) that the initiator will use to reference the security association, an identifier for the key management approach being used, the key management information (including certificate information), and an optional authenticator. Where public key based algorithms are used, or where entity information is contained in public key certificates, certificate validation information may be included in this PDU. Certificate validation information includes the complete certification path along with current CRLs. An entity may include a subset of this information if there is reason to believe that the peer already possesses some of the information (e.g. if they share a common CA). The Key Management (KM) algorithm is assumed to either have been agreed, to be a default, or to have been negotiated previously. PDU CONTENTS: PDU Type My SAID KM Algorithm (Registered value or OID) KM info (variable) 2.2 Security Association Establishment Response This PDU is sent in response to an establish security association PDU. It contains the corresponding key management information, if required, the responder's SAID, and an optional authenticator. If the key management algorithm requires more than two PDUs, multiple SAER PDUs may be exchanged. PDU CONTENTS: PDU Type My SAID Your SAID KM algorithm (registered value or OID) KM information 3.0 SA Management PDUs Security Association Management PDUs are sent to report problems or to control attributes of security association. Services include reporting the receipt of a IPSP PDU with an unrecognized SAID, reporting the deletion of an SA, reporting the presence of an IPSP intermediate system, replacing a security association and negotiation attributes and options for IPSP or IKMP. Management PDUs must be authenticated and may also require confidentiality. This is achieved by either encrypting the PDU contents or by signing the PDU. The signature (i.e., authenticator) may include information needed to validate the digital signature (such as a certification path) if that information is not otherwise present. Encrypting the PDU is the preferred approach when the PDU refers to an existing SA while signed management PDUs may be used for other cases. The attribute negotiation PDU may also be used prior to SA establishment to negotiation the key management algorithm to be used. In this instance the PDU must be signed. 3.1 No Security Association This PDU is used when IPSP receives a PDU with an unrecognized SAID. If authenticated, this PDU is signed. PDU CONTENTS: PDU Type Unrecognized SAID Authenticator 3.2 Delete Security Association This PDU is sent to notify the peer of a security association that one party is terminating the association. The peer is expected to also delete the SA. This PDU should be sent encrypted in the referenced SA. PDU CONTENTS: PDU Type Your SAID Ciphertext { PDU Type Your SAID My SAID ICV } (the encryption function is assumed to prepend any required IV and to perform any necessary padding) 3.3 Peer Discovery This PDU is sent when an intermediate system which performs IPSP processing on behalf of entities behind the IS intercepts an SA PDU intended for one of those entities. This PDU should be authenticated and should, if possible, contain authenticated information confirming that the IS is a valid surrogate for the intended destination. PDU CONTENTS: PDU Type Your SAID My ID Intended Destination Authenticated Delegation Information 3.4 Replace Security Association This PDU is sent when one party to a SA wishes to replace the security association. This may be required to support changing the traffic key, changing a SA attribute, or changing the SAID. This PDU should be sent encrypted in the referenced SA. The request indicates whether to continue to use the existing attributes and key with the new SAID or whether to invoke a new key management operation and/or renegotiate attributes. If the purpose of the new SA is to change the traffic key, the PDU may also contain a new key encrypted with the old key. PDU CONTENTS: PDU Type Your SAID Ciphertext { PDU Type Your SAID My SAID My New SAID New Attribute flag New Key flag New Key Data (optional) ICV } 3.5 Attribute Negotiation This PDU is sent to negotiate parameters and options for a security association. This is the means of determining the specific algorithms and options used by IPSP or by another security protocol/application using IKMP (e.g. encryption algorithm, integrity algorithm, use of labels, use of sequence numbers, protocol format). Negotiation is performed through the exchange of option lists. Each entry contains an option identifier, type, and option value(s). The option identifier is a registered value indicating the option being negotiated (e.g. security protocol ID, encryption algorithm). Options may be of two types: preference lists and choices. Option values are registered values indicating a specific choice for an option identifier (e.g. IPSP version 1, DES-CBC). For preference lists, the sender lists alternative option values in order of preference. The responder must choose one. Examples of a preference list might be encryption or key management algorithms. Choices are characterized as a MANDATORY, PREFERRED, or SUPPORTED capability. These options are compared with the attribute negotiation PDU recipient's corresponding choices. Any Mandatory choice must be used or the security association is terminated. A Preferred choice is used if the recipient supports it. A Supported choice is used if the recipient prefers or mandates it. An option mandated by the recipient which is not present results in a terminated security association. The attribute negotiation PDU may also be used to convey additional authorization information about the entity used by IPSP processing. Such information might include authenticated topology information or authenticated attribute information. If attribute negotiation takes place after SA establishment, the negotiation PDU contents are encrypted. If it is used to negotiate key management algorithms, it is authenticated. Negotiation PDUs contain sequence numbers that are used to detect replay of PDUs and to support acknowledgment/confirmation services. 3.5.1 SA Attribute Negotiation PDU CONTENTS: PDU Type Your SAID Ciphertext { PDU Type Sequence Number Your SAID My SAID Option List Option Identifier, Option Type, Option Value(s) Additional Info ICV } 3.5.2 KM Algorithm Negotiation PDU CONTENTS: PDU Type Your SAID PDU Type Sequence Number Your SAID My SAID Option List Option Identifier, Option Type, Option Value(s) Authenticator 3.6 Commit/Acknowledge This PDU is sent to confirm the last change to a security association. PDU CONTENTS: PDU Type Your SAID Ciphertext { PDU Type Sequence Number Last Received Sequence Number Your SAID My SAID ICV } From ipsec-request@ans.net Thu Mar 24 10:59:47 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA04314 (5.65c/IDA-1.4.4 for ); Thu, 24 Mar 1994 21:30:32 -0500 Received: by interlock.ans.net id AA07949 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 24 Mar 1994 21:23:50 -0500 Received: by interlock.ans.net (Internal Mail Agent-5); Thu, 24 Mar 1994 21:23:50 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Thu, 24 Mar 1994 21:23:50 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Thu, 24 Mar 1994 21:23:50 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Thu, 24 Mar 1994 21:23:50 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 24 Mar 1994 21:23:50 -0500 Message-Id: <00112.2847376800.2742@poncho.phx.sectel.mot.com> X-Charset: MACINTOSH To: ipsec@ans.net (ip security mailing list) From: Paul_Lambert@poncho.phx.sectel.mot.com (Paul Lambert) Date: Thu, 24 Mar 1994 17:59:47 MST Subject: Agenda - IPSEC at 29th IETF Subject: Agenda - IPSEC at 29th IETF Message: There will be two IP Security (IPSEC) WG Meetings at the Twenty-Ninth IETF (March 28 - April 1, 1994). They are scheduled as follows: 1930-2200 Wednesday, March 30, 1994 - Evening Session SEC IP Security WG - Key Management (ipsec) (Paul Lambert/Motorola and Jim Zmuda/Hughes) 0930-1200 Thursday, March 31, 1994 - Morning Session SEC IP Security WG - Encapsulation Protocol (ipsec) (Paul Lambert/Motorola and Jim Zmuda/Hughes) ----------------------------------------------------------------------- IPSEC Agenda Twenty-Ninth IETF (Wednesday March 30 and Thursday March 31, 1994) Wednesday, March 30, 1994 - Evening Session on the Internet Key Management Protocol (IKMP) 19:30 Introductions o Review and Approve Agenda o Minutes of Previous Meeting (Houston) 19:40 Liaisons 19:50 Review of Internet Key Management Goals and Schedule o What is the scope? (IPtng, and other possible applications) o High Level Goals o Milestones and Interoperability Demonstrations 20:20 Review of Internet Key Management Requirements (from Solo) o Symmetric versus Asymmetric Algorithms o Peer-entity Authentication o Option Negotiation (support multiple algorithms, PDU options) o Multicast / Broadcast Considerations o others 20:30 Brief Review of Related Work on Key Management o SDNS KMP, IEEE 802.10, GULS, PEM, X.509, X9.17 o SAMP o TBD (from IBM) 21:00 Review of Preliminary IKMP o Base Functionality o Issues, Next Steps 21:45 Summary o Plans for Prototypes o Action Items 22:00 Adjourn Thursday, March 31, 1994 - Morning Session on IPSP Cryptographic Encapsulation Protocol 9:30 Introductions o Review and Approve Agenda o Approve Minutes of Previous Meeting (Houston) 9:40 Review of Charter and Schedule 9:50 Liaisons 10:00 Brief Review of Existing Implementations o swIPe, SP3, NLSP, ANS, UUNET, DEC, Semaphore o others o Summarize and Discuss Approaches 10:45 Presentation and Discussion on Joint IPSP Proposal o Format o Processing and Algorithms 11:30 Review and Discussion of Issues and Recommendations o Features and Requirements (Host-to-Host, Host-to-Subnet, and Subnet-to-Subnet) o Clear Header Format o Security Transformation (encryption, MAC. etc.) o Protected Header o Labels o Peek-Through o Interaction with IP clients (including IP/IPSP/IP) o Fragmentation o Multicast / Broadcast o Interaction with SNMP o Others 11:50 Summary o Next Meeting o Review Action Items o Update Schedule 12:00 Adjourn From ipsec-request@ans.net Fri Mar 25 19:50:31 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA13004 (5.65c/IDA-1.4.4 for ); Fri, 25 Mar 1994 14:55:10 -0500 Received: by interlock.ans.net id AA13913 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Fri, 25 Mar 1994 14:49:46 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Fri, 25 Mar 1994 14:49:46 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Fri, 25 Mar 1994 14:49:46 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 25 Mar 1994 14:49:46 -0500 Date: Fri, 25 Mar 1994 14:50:31 -0500 (EST) From: glenn@osi.ncsl.nist.gov (Robert Glenn) Subject: Re: Agenda - IPSEC at 29th IETF To: Paul_Lambert@poncho.phx.sectel.mot.com Cc: ipsec@ans.net Message-Id: <9403251950.AA02438@osi.ncsl.nist.gov> Content-Transfer-Encoding: 7BIT Paul, On the agenda you have "Presentation and Discussion on Joint IPSP Proposal". What particular proposal is going to be discussed? What does the word Joint refer to? Rob G. glenn@osi.ncsl.nist.gov From ipsec-request@ans.net Thu Mar 31 11:25:46 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA05665 (5.65c/IDA-1.4.4 for ); Thu, 31 Mar 1994 06:29:15 -0500 Received: by interlock.ans.net id AA07492 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 31 Mar 1994 06:25:57 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Thu, 31 Mar 1994 06:25:57 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Thu, 31 Mar 1994 06:25:57 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 31 Mar 1994 06:25:57 -0500 Message-Id: <9403311125.AA01325@skidrow.lkg.dec.com> To: IP Secrity WG Cc: dee@lkg.dec.com Subject: My current thoughts on IPSEC Date: Thu, 31 Mar 94 06:25:46 -0500 From: "Donald E. Eastlake 3rd (Beast)" X-Mts: smtp See below --------------------------------------------------------------------------- Donald E. Eastlake, III DTN: 226-6577(w) dee@lkg.dec.com 550 King St, LKG2-1/BB3 1-508-486-6577(w) dee@ranger.enet.dec.com Littleton, MA 01460 USA 1-508-486-7417(fax) 1-508-287-4877(h) INTERNET-DRAFT PIPS: Practical IP Security 31 March 1994 Expires 30 September 1994 PIPS: Practical IP Security ----- --------- -- -------- Donald E. Eastlake 3rd Status of This Document This draft, file name draft-ietf-ipsec-pips-00.txt, is intended to be become a standards track RFC. Distribution of this document is unlimited. Comments should be sent to the IP Security Working Group mailing list or to the author. This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months. Internet-Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet- Drafts as reference material or to cite them other than as a ``working draft'' or ``work in progress.'' To learn the current status of any Internet-Draft, please check the 1id-abstracts.txt listing contained in the Internet-Drafts Shadow Directories on ds.internic.net, nic.nordu.net, ftp.isi.edu, or munnari.oz.au. Abstract [to be written] Donald E. Eastlake 3rd [Page 1] INTERNET-DRAFT PIPS Table of Contents [Table of Contents gets moved here from the end] Donald E. Eastlake 3rd [Page 2] INTERNET-DRAFT PIPS 1. Introduction [To be written] 2. Overview of the Protocol PIPS provides a wide variety of security services for datagram, multicast, and connection oriented traffic. Donald E. Eastlake 3rd [Page 3] INTERNET-DRAFT PIPS 3. Packet Format Below is a simplified diagram of the PIPS packet format with optional fields omitted. After a brief description and discussion of this simplified format, the full diagram is given followed by detailed specifications. SIMPLIFIED DIAGRAM 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IP packet header with PIPS protocol specified | / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Black Flags | Security Association ID / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ * | Red Flags | Orig. Proto. | / * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / * / data part of original IP Packet / * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Authentication Tail | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ * = portion optionally encrypted PIPS works by replacing the protocol field in the header of the IP packet to be secured with the PIPS protocol number and then encapsulating the replaced original protocol number and the data portion of the original IP packet in a security envelope. The value of the PIPS protocol type is xxx. The original data is optionally compressed and prefixed by the original protocol and some flags (which include a flag indicating whether compression is in effect) and the resulting byte sequence is optionally encrypted. This possibly encrypted byte sequence is then prefixed by a 24 bit Security Association ID (SAID) and some additional flags (which include an indication of whether encryption is in effect). The final packet is produced by calculating a digital signature across the PIPS packet data portion thus far and selected fields from the new IP packet header and appending this digital signature (authentication tail) to the packet. Authentication is applied last, as opposed to inside the encryption, (1) to minimize the effort required by software implementations of PIPS to reject bogus packets, and (2) to allow the creation of "filter walls" that can screen packets enterning a nework area to Donald E. Eastlake 3rd [Page 4] INTERNET-DRAFT PIPS allow only certain types of authorized packets without giving filter wall computers access to the encrypted message body. [The SAID field could be made variable length despite the additional complexity this entails to accommodate the seeming irreconcilable requirements by different populations of PIPS users. Those using slower radio or serial links have argued for a one byte SAID. Others who want to use cryptographic hardware and have the SAID be the session key encyrpted under a host key need 64 bits or more. See the receiver specified opaque quantity option as another way to meet this later requirement.] A flag indicating whether or not encryption is in effect in included in the Black Flags field so that in cases where only authentication is in effect routers, statistics gathering software, etc., can look inside the PIPS packet and use the original protocol or things like TCP header fields. DETAILED DIAGRAM 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IP packet header with PIPS protocol specified | / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Black Flags | Security Association ID / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (Time Stamp) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / (Black Options) / * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ * | Red Flags | Orig. Proto. | (true src &/or dst address(s))/ * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ * / (Red Options) / * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ * / data part of original IP Packet / * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Authentication Tail | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ * = optionally encrypted portion Most fields in this detailed diagram are described below. 3.1 Black Flag Bits Bit 0 is the control bit. If it is clear, this is a data packet. If it is set, this is a control or error packet and the Donald E. Eastlake 3rd [Page 5] INTERNET-DRAFT PIPS "original protocol" field is actually an operation or error code. Bit 1 is the error bit. It is meaningless if bit zero is zero. If bit zero is a one, it indicates the packet is an error packet instead of a control packet. Bit 2 indicates that a 32 bit time stamp is present after the SAID. Bit 3 is the encryption bit. If it is on, the area marked by asterisks at the right edge in the above diagram is encrypted. Bit 4 is the black options bit. If on, the black options area is non-null. Bit 5 is reserved and must be zero. Bits 6-7 are a two bit field which indicates the SAID type. 00 indicates a global SAID, 01 indicates a dictated SAID, 10 indicates a negotiated SAID, and 11 is reserved. 3.2 Security Association IDentifiers Security Association IDentifiers come in three varieties: global, dictated, and negotiated. In all cases, an SAID can be used by a recipient to tell what cryptographic algorithms are in use and what the keys are or how to find this information, as well as what compression algorithms are available. 3.2.1 Global Security Association IDentifiers Global SAIDs are used for the most simple and fundamental case of secure datagrams without explicit call setup. Such datagrams can be either multicast or unicast. The Global SAIDs are defined by a standards action and must mean the same thing to all recipients. Global SAID zero is illegal. Global SAIDs 1 and 2 are defined below. 3.2.1.1 Global SAID One This SAID permits an authenticated and optionally confidential packet to be sent across the Internet with no explicit set up. The encryption and authentication algorithms are the default RSA datagram algorithms as described in section 4. The compression algorithm, if used, is the default. The keys used are the private key for the Donald E. Eastlake 3rd [Page 6] INTERNET-DRAFT PIPS source id and the public key for the destination id. Low level implementations of PIPS (see Section 9) can use only the default IP address source and destination identities (see Section 3.5.2). 3.2.1.2 Global SAID Two Global SAID 2 is used when there is complete prior arrangement between the parties requiring no parameters or negotiation. The encryption, authentication, and compression algorithms are as so arranged. The keying material must be pre-configured at both machines or could have been arrived at in some way outside of PIPS. 3.2.2 Dictated Security Association IDentifiers A dictated SAID is established by a transmitting entity. The SAID is relative to the originating IP address, ie, the SAID number is allocated by the transmitting host. This is typically used for transmission to a multicast group where the class of receivers is dynamic. See section 6 on control messages in relation to this type of SAID. 3.2.3 Negotiated Security Association IDentifiers Negotiated SAIDs can be used only in the special case of secure unicast connections. The exchanged SAID is relative to the destination IP address, ie, the SAID is allocated by the receiving host. Thus this type of SAID can not be used if the destination is a multicast group. Such connections are set up and torn down via PIPS control messages. They are called negotiated because the source and destination generally have to agree on the algorithms and keys involved. See Section 6 on PIPS control message in connection with this tpe of SAID. Such connections are two way and the SAID in each PIPS packet is one assigned by and meaningful to the recipient of the packet, 3.3 Time Stamp Optionally a 32 bit plain text time stamp can be included in the PIPS packet. Its presence is indicated by a black flag bit. The quantity Donald E. Eastlake 3rd [Page 7] INTERNET-DRAFT PIPS is the number of second since the beginning of 1994 until the time the packet was assembled. The time stamp is not encrypted because there isn't anything secret about it (it's the "current" time) and so that it can be used in authenticating packets without/before looking inside the encyption. The Time Stamp is included in the authentication calculation. 3.4 Red Flag Bits The bits in the red flags byte are defined as follows: Bits 0-3 are reserved for future use and must be zero. Bit 4 indicates that data compression is in effect. See section 5. Bit 5 indicates that the source IP address is not the true origin of the packet (eg, the original packet was encapsulated in PIPS along the way, possibly at a firewall router). If it is on, the red flags and original protocol bytes are immediately followed by the true four byte source IP address. Bit 6 indicates that the destination IP address is not the true destination of the encapsulated packet (ie, the original packet was encapsulated in PIPS and then address to some intermediate machine, possibly a firewall router, before the true destination). If it is a one, the true four byte destination IP address appears either immediately after the red flags and original protocol bytes or after the true source address if bit 5 is also a one. Bit 7 indicates that the red options area is non-null. 3.5 Black / Red Options Options can appear at two places in the PIPS format: the black options area and the red options area. The only difference in the two areas is that red options will be encrypted if encryption is used. In the absence of encryption, it is better to combine the options in one area to decrease bytes wasted on area formating overhead. The presence of either options area is indicated by a bit in the black and red flags bytes respectively so that no bytes need be used up if either or both areas is unnecessary. Although there are a wide variety of options to handle various complexities, a Level One or Level Two implementation (see section 9) of PIPS need not implement options at all and can respond to any PIPS Donald E. Eastlake 3rd [Page 8] INTERNET-DRAFT PIPS packet having any options with an "unimplemented" error. Each options is indicated by a one byte code followed by a length (except for the two special codes 80 and 81 which are not followed by any length field or data) and then zero or more bytes of data. The option codes are the same for the black and red options areas. As shown below, the most significant bit of the option code indicates that understanding of the option is mandatory. As soon as an option of this type is encountered which the receiver does not understand, option processing may halt and an error packet must be sent back unless the packet being received is itself an error packet. 0 1 2 3 4 5 6 7 8 ... 15/23 +---+---+---+---+---+---+---+---+-+-+-+-/-+-+-+-+ | M - option code | length | +---+---+---+---+---+---+---+---+-+-+-+-/-+-+-+-+ M = comprehension mandatory The length has the following format: 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | 0 | 0 - 127 | or +---+---+---+---+---+---+---+---+ 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ | 1 | 0 - 32767 | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 3.5.1 Option Codes The following subsections define the assigned option codes and list the reserved and illegal option codes. 3.5.1.1 Mandatory Comprehension Option Codes The current options for which comprehension is mandatory are described below. Each paragraph begins with the option code in hexadecimal. 80 - End of options. This code indicates the end of the particular options area. It is NOT followed by a length code. 81 - No-op. This code is followed by no additional associated Donald E. Eastlake 3rd [Page 9] INTERNET-DRAFT PIPS bytes and does nothing. It can be used as a one byte pad for alignment or other purposes. It is NOT followed by a length code. (Option code 01 can be used for variable length padding.) 82 - Mandatory labels. Data sensitivity and handling labels. See section 3.5.4. 83 - Authentication algorithms list. See section 3.5.3. 84 - Encryption algorithms list. See section 3.5.3. 85 - Source identity. See section 3.5.2. 86 - Destination identity. See section 3.5.2. 87 - Receiver specified opaque quatity. 3.5.1.2 Permissive Comprehension Option Codes The current options for which comprehension is optional are described below. Each paragraph begins with the option code in hexadecimal. 01 - Padding. This code provides a variable length (minimum size 2 bytes (0x0100), maximum size 32,770 bytes (0x01FFFF...)) padding field. Use option code 81 for a single byte pad. 02 - Permissive labels. Data sensitivity and handling labels. See section 3.5.4. 03 - Compression algorithms list. See section 7. 3.5.1.3 Illegal Option Codes The option codes consisting of all zero and all one bits (hex 00 and FF) are illegal and will not be assigned. 3.5.1.4 Reserved Option Codes The following ranges of option codes are reserved for future allocation by the IANA: [everything that's left] Donald E. Eastlake 3rd [Page 10] INTERNET-DRAFT PIPS 3.5.2 Source and Destination Identities The source identity option indicates the authenticated entity originating the encapsulated packet. The destination identity option indicates the entity for which the packet is destined and optionally encrypted. These options may occur only once in a PIPS packet. There are several types of identities described below. In the absence of source or destination identity options, the source or destination identities are the DNS names corresponding to the source and destination IP addresses. Thus if the PIPS packet has a source address of x.y.z.w and there is no source identity option, the packet is treated as if there were a DNS host name source identity of w.z.y.x.in-addr.arpa. Note that the destination IP address may be a multicast address. While there are a variety of identity types, not all need be implemented, depending of the level of implementation desired (see section 9). Furthermore, depending on security policy, the identities need be processed only enough to extract or retrieve and, in some cases, authenticate the relevant public key. 00 - Illegal. 01 - DNS entity. Followed by one or more zone signed DNS Resource Records. [See draft-ietf-dnssec-secext-*.txt] The owner name of the first RR present is the DNS name of the source / destination identity. The RRs present must include a signed key for that entity. Additional signed RSA RRs are allowed to provide a certificate chain to a zone more likely to be known to the recipient of the PIPS packet; however, size constraints may limit how may RRs can be included. Usual DNS name abbreviation by pointer may be done inside the data area of this option. 02 - DNS host name. Followed by a fully qualified DNS name. The identity is that corresponding to the IP host having that name. For example nic.ddn.mil. In general, this type makes it necessary to retrieve the identity's public key from the DNS. It may be preferable to use the DNS entity type above. 03 - DNS account name. Followed by a fully qualified DNS name. The identity is that corresponding to the account named by the first part of the DNS name at the host corresponding to the remainder of the DNS name. For example dee.skidrow.lkg.dec.com which corresponds to the user dee@skidrow.lkg.dec.com. In general, this type makes it necessary to retrieve the identity's public key from the DNS. It may be preferable to use the DNS entity type above. 04 - RSA key owner. Followed by three bytes of unsigned exponent and then an unsigned count byte and the count byte number of Donald E. Eastlake 3rd [Page 11] INTERNET-DRAFT PIPS bytes of modulus. This data is the public version of an RSA key and asserts only that the source/destination identity is whatever posesses the corresponding private key. This type is included specifically to provide for anonymous identities that are not part of any hierarchy. In addition, the special case of a modulus length of zero indicates the publicly anonymous and unconfirmable null identity. 05 - OSI entity. Followed by the BER encoding of the ASN.1 for either a DN or an X.509 certificate or a sequence of such certificates. The DN or the DN in the first certificate is the name of the source/destination entity. Multiple certificates are allowed to provide a chain of authentication to a high level entity that may be more easy to contact or confirm. However, space restrictions may make it difficult to include more than one certificate. Provision of just a DN will generally require retrieval of the public key from an X.500 directory or other database containing X.509 certificates. 06 through FE - reserved for future allocation by the IANA. FF - illegal. 3.5.3 Algorithm Lists Algorithm list options consist of a sequence of OIDs preceeded by an unsigned count byte giving the sequence length. Each of the three types of option lists, encryption, authentication, and compression, may occur only once in a PIPS packet. During the set up of a negotiated SAID, the two parties must agree on what encryption algorithm and authentication algorithm will be used and what data compression algorithms will be available. The initial Open control packet can contain a list of encryption and/or a list of authentication algorithms that the opener would find acceptable. In the Open acknowledge control packet, the other party must then specify which single algorithm is to be used. In the announcement of a dictated SAID with an Open control packet, the sender may specify a non-default encryption and/or authentication algorithm by including the appropriate list option with a single algorithm secified. Because compression is optional in each packet and can be selected among the available algorithms on a per packet basis by the sender, a set of compression algorithms can be established. For a negotiated SAID, the sender of the initial Open control packet may specify a list of compression algorithms they want to be able to Donald E. Eastlake 3rd [Page 12] INTERNET-DRAFT PIPS use. The Open acknowledgement control packet then specifies the subset of those algorithms that the receiver is also willing to use. (This list in the open acknowledge can not be longer than that in the original open which can be no longer than 255 algorithms.) It defines the numbering of the available algorithms for use in the compressed data prefix byte. For a dictated SAID, the sender of the Open control packet may dictate the set of compression algorithms it may use; however, it must be certain any algorithm it uses is available to any receiver it would like to understand compressed data. In the absence of any algorithm list, the default algorithm is presumed. 3.5.4 Labels [this section needs work] Donald E. Eastlake 3rd [Page 13] INTERNET-DRAFT PIPS 4. Cryptographic Algorithms The default datagram algorithms given in 4.1 below must be included in all PIPS implementations. The default negotiated/dictated algorithms in section 4.2 must be included in all level two or higher PIPS implementations. The supplemental algorithms given in section 4.3 must be included in all Level Three or higher implementations. There is no explicit provision in the PIPS formats for padding of input to or IVP prefixing of output from encrytion algorithms. This is all considered part of the encryption algorithm which may produce a longer output than its input. 4.1 Default Datagram Algorithms The default encryption algorithm is similar to PKCS#1 using the public key of the destination identity. The data is divided into byte sequences that are six or more bytes shorter than the public key. Each such piece is then encoded as follows: output = ( 02 | salt* | 00 | data ) ** e (mod n) where "| is concatenation, 02 and 00 are bytes of that hex value, and "salt" is at least 3 non-zero bytes of non-repeating data. (For example, an implementation could maintain a 3 byte or larger counter with values where any byte of the count was zero supressed and use this as the salt. This counter would be incremented for each PIPS packet sent. For additional padding, as might be required on the last piece of the data, the counter bytes could be repeated as necessary to make enough salt.) The OID for the default datagram encrytion algorithm is xxx. The default authentication algorithm is to calculate the MD5 hash of the pseudo header defined above and the PIPS data area (including possibly encrypted data) before the authentication tail and then to digitally sign this value as per PKCS#1. That is authentication tail = ( 01 | FF* | 00 | hash ) ** e (mod n) The OID for the default datagram authentication algorithm is xxx. 4.2 Default Negotiated / Dictated Algorithms The default encryption algorithm uses MD5 for key generation. MD5 produces a 128 bit block by hashing the bottom 128 bits of the shared Donald E. Eastlake 3rd [Page 14] INTERNET-DRAFT PIPS key, the IP source and destination addresses, and IP packet ID, the portion of the PIPS packet before the encrypted portion begins, and a 12 bit quantity which is a sequence count of the up to 4K 128 bit blocks it would take to cover 64K bytes of data. As many such 128 bit blocks as necessary are computed and concatenated. The resulting bit stream is masked to the exact length of the data to be encypted and xor'ed with it. Advantages of this type of encryption are that it does not expand the data at all and that it may be possible to pre-calculate the encryption for the next packet before the packet is available to send. This results in better latency on packet transmission. WARNING: It is essential that the hashed quantity be different for every different packet sent. If the IP packet ID is used to obtain this, there must be extremely high confidence that it will change for each different packet and it will be necessary to re-key if more than 64K packets are sent. As an alternative, a black padding option can be included that is a PIPS packet count. If two different messages are ever sent with the same key generation, it may result in easy to decode data. The OID for this encryption algorithm is xxx. The default authentication algorithm for negotiated / deictated SAIDs is to calculate and MD5 message digest over a secret key and most of the packet. The 128 bit of MD5 output are then appended to the message as the authentication tail field. The quantity hashed consists of the top 128 bits of the shared key, the pseudo header defined above, and all of the PIPS packet before the authentication tail including the possibly encrypted portion. The OID for this authentication algorithm is xxx. 4.3 Supplemental Algorithms [A few additional algorithms can be specified here. All Level three or higher implementations will be required to include them. The only things which seem like they might be worth while are DES, Triple DES, and IDEA for encryption, and SHS for authentication.] Donald E. Eastlake 3rd [Page 15] INTERNET-DRAFT PIPS 5. Compression Data compression is an important feature of the PIPS protocol. 5.1 Body Data Compression Many encryption and essentially all digital signature techniques increase the size of the data encrypted or authenticated. This can lead to packet fragmentation and other significant inefficiencies which can be partially avoided with compression. Compression must be done before encryption because compression depends on the redundancy in most data. After encryption, the data appears to be random and is essentially incompressible. In some cases, data can be very redundant with large areas of equal bytes or the like. Without encryption, such data may be highly compressed by low level end-to-end software, modem logic, or the like. Without a means to compress before encryption, encryption leads to a massive loss in efficiency. Most popular compression algorithms are designed to compress long sequences of bytes, such as large data files, or indefinitely long data streams through a modem. For PIPS we need compression algorithms that will help on a packet by packet basis. A basic compression algorithm is decribed below. Facilities are provided to use alternative algorithms between cooperating end points. Compression algorithms are almost entirely orthogonal to encryption, authentication, integrity, etc., algorithms. As a result, we indicate the algorithm in use for a particular packet by the first byte of data if the compression bit is on in the red flags. 5.2 Basic Compression Algorithm The basic PIPS compression algorithm works as follows: (1) Pick a flag byte to indicate the occurence of a compression encoding. The should be a byte not used anywhere in the data of the packet to be compressed or, if all 256 byte values are used, it should be the value of one of the values used most rarely. (2) Output a zero prefix byte to indicate that the basic compression algorithm is in use followed by the flag byte determined in 1. (3) Scan the input data where possible replacing sequences with the form 1 or form 2 abbreviations shown below. Donald E. Eastlake 3rd [Page 16] INTERNET-DRAFT PIPS (3.1) Form 1 is indicated by a zero most significant bit in the byte following the flag byte as follows: +-----------+----------+ | flag byte | 0xxyyyyy | +-----------+----------+ xx and yyyyy are unsigned integer fields of 2 and 5 bits length. A two byte Form 1 sequence indicates the repetition of the x+3 source bytes starting y+x+2 bytes back in the source stream. y=0 is special and indicates that the two byte sequence encodes a literal occurence of the flag byte (in this case the value of x is ignored). (3.2) Form 2 is indicated by a most significant bit of one in the byte following the flag byte as follows: +-----------+----------+----------+ | flag byte | 1zzzwwww | wwwwwwww | +-----------+----------+----------+ zzz and wwwwwwwwwwww are unsigned integer fields of 3 and 12 bits length with the most significant part of w in the byte immediately after the flag byte and the low order part in the next byte. A three byte Form 2 sequence indicates the repetition of the z+4 source bytes starting w+z+4 bytes back in the source stream. Due to the requirement to include a two byte (zero and flag) prefix and the encoding of a source occurence of the flag byte as two bytes in the output, the basic compression algorithm will not compress some input sequencess. In such cases, it should not be used and, unless other compression is available, the source sequence should be sent as is and the compression bit should be off in the red flags. 5.3 Header Compression [There will be cases of host communication primarily via PIPS packets over leased lines or the like where bandwidth or response time is at a premium. To maximize performance under such circumstances, a compression algorithm similar to the Van Jacobsen TCP/IP header compression needs to be defined for PIPS.] Donald E. Eastlake 3rd [Page 17] INTERNET-DRAFT PIPS 6. PIPS Control/ Error Packets PIPS control and error messages are indicated by the control bit in the Black Flags being a one. The error bit in the Black Flags bit is zero for control packets and a one for error packets. The normal PIPS SAID value and type and the encrypted black flag refer to the encryption / authentication of the control or error packet itself. Control packets are generally used to set up and tear down negotiated or dictated SAIDs. Error packets are only issued in response to the receipt of an apparently erroneous PIPS packet and include a possibly truncated and decrypted copy of that packet. Other possible "error" conditions are indicated by control messages. 6.1 Control Message Formats For control packets, the "original protocol" byte is actually an operation code. If anything in the control packet itself is sensitive, it should be sent encyrpted. If no appropriate connection (one with the appropriate destination identity and destination IP address and security) exists, sensitive control packets should be sent as Global SAID 1 PIPS packets. The format of the data portion of control packets is as follows: 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 3 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 2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | flags | Security Association IDentifier (SAID) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | keying material length | / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + / keying material / / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The control packet flags are defined as follows: Bits 0-5 are reserved and must be zero. Bits 6-7 are the SAID type. 00 indicates a global SAID which is illegal because no operations are applicable to such SAIDs. 01 indicates a dictated SAID. 10 indicates a negotiated SAID. 11 is reserved. Donald E. Eastlake 3rd [Page 18] INTERNET-DRAFT PIPS 6.2 Key Exchange For a dictated SAID being established, the keying material is as sent in the Open message. It must be long enough for the cryptographic algorithms used and a minimum of 196 bits is recommended. For a negotiated SAID being established, the ultimate keying material is set via Diffie-Hellman key exchange. The Open contains the quantities public-x, g, and n from the following equation: public-x = g ** secret-x (mod n) where n is a large prime (1000 or more bits is recommended), (n-1)/2 is also prime, and g is a primitive route of n. g, secret-x, and n are all chosen by the party opening the negotiated connection and are each represented as an unsigned once byte count of bytes followed by the number. The corresponding Open Acknowledge will contain public-y from the following equation: public-y = g ** secret-y (mod n) where g and n are as provided in the Open and secret y was chosen by the party acknowledging the Open. The Opener then calculates shared = public-y ** secret-x (mod n) and the Acknowledger calculates shared = public-x ** secret-y (mod n) and the keying information used is the shared secret quantity "shared" with its top 32 bits and bottom 32 bits discarded. The resulting quantity must be lareg enough for the cryptographic algorithms used. At least 196 bits is recommended. 6.3 Operation Codes The valid PIPS operation codes which can occur in the "original protocol" field are as follows: [this section needs more work] 00 - Illegal. 01 - Open. This command attempts to establish a dictated or negotiated SAID. 02 - Open Acknowledge. Donald E. Eastlake 3rd [Page 19] INTERNET-DRAFT PIPS 03 - Close. 04 - Close Acknowledge. 05 - Inquire. Used, for example, by someone entering a multicast group as a receiver to inquire of a transmitter as to the dicatated key and algorithms. 06 - Inquire Response. 07-FD - Reserved FE - Private code. This code will never be defined by the PIPS protocol. It is available for private use. Such use should be avoided if there is any way to achieve the desired effect within the defined PIPS control operations. FF - Illegal. [The above probably needs a simple state diagram or two.] 6.4 Error Packet Formats Within an error packet, the "original protocol" byte is actually an error code. The data portion of the packet is not an encapsulated IP packet data area but rather is structured as shown below. To avoid various possibilities of compromise, the error packet resulting from an encrypted PIPS packet MUST always be encrypted. If no other possibilities are available, it should be sent as a global SAID 1 datagram. If an appropriate connection oriented SAID is available (one with a destination ID the same as the apparent origin ID of the erroneous packet at the same IP address as the IP source of the erroenous packet and appropirate security and source ID), it can be sent on that connection. (If the error concerns an SAID, that can be extracted from the erroneous PIPS packet by tghe receiver from the error packet.) 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 3 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 2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | sub-error code| starting bit | starting byte | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | error flags | ending bit | ending byte | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |length of erroneous packet data| / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + / erroneous PIPS packet / Donald E. Eastlake 3rd [Page 20] INTERNET-DRAFT PIPS / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The erroneous PIPS packet is essentially as it was when the error was detected. The starting and ending byte and bit numbers specify a field within the erroneous PIPS packet. If the field is actualy a field of one or more whole bytes, the staring bit number will be 0 and the ending bit number will be 7. Note: this may point to a location within the encrypted portion of the original PIPS packet, such as a red option. It may also be necessary to truncate the erroneous packet in which case bytes are dropped from its end even if the error field was within them (almost certainly a bad authentication tail). The error flags are defined as follows: Bit 0 - Encrypted. If the erroneous PIPS packet packet claims to be encrypted and was not yet decrypted when the error was found, this bit will be a one. Bit 1 - Compressed. If it had been determined that the PIPS packet claimed to be compressed and was not yet decompressed when the error was found, this bit will be a one. Bits 2-6 - Reserved. Bit 7 - Truncated. Indicates that the erroneous PIPS packet had to be truncated to fit into the error packet. 6.5 Error Codes The valid PIPS error codes which can occur in the "original protocol" field are as follows: 00 - Illegal code. 01 - Illegal field value. 02 - Bad Time. Time stamp field is bad. Sub-error 0 means packet too old. Sub-error 1 means packet seems to be from the future. 03 - Unimplemented. Value specifies something that could be implemented but is not in the implementation issuing the error packet. 04 - Unknown. Field value is something that could be bound in real time like an SAID but appear not to be. Donald E. Eastlake 3rd [Page 21] INTERNET-DRAFT PIPS 05 - Duplicate. An option which is only permitted to appear once in a packet appears twice. Field pointed to is any occurence of the option code in the erroneous packet. 06 - Bogus. Sub-error 0 means authentication check failed. Sub- error 1 means that decrypting failed due to apparent garbled data as indicated by the decryption algorithm. Sub-error 2 means that decompressing failed to to apparent garbled data as indicated by the decompression algorithm. 07 - Insecure. Indicates a packet which violates any reasonable security policy. 08-FE - Reserved. FF - Illegal code. Donald E. Eastlake 3rd [Page 22] INTERNET-DRAFT PIPS 7. Initial Communications and New ICMP Error Code There are several strategies that can be adopted by a host source entity that desires security when starting to communicate with a remote entity. Basicly you can start by sending PIPS packets, by sending non-PIPS packets, or both. Sending both and changing to just using PIPS if you get PIPS responses is a possible strategy, though somewhat wasteful. A problem with simply sending PIPS and seeing if it is rejected is that many implementations of IP erroneously fail to return a protocol- unreachable ICMP error on receiving a packet or a protocol they do not implement. Thus the packets may fall into a black hole and the sending host will have to have an arbitrarily time out. If the desired secure communications are based on DNS keys, as will most commonly be the case, and the DNS entries show that security for the destination entity is "mandatory", just sending PIPS packets is reasonable. If you just send unsecured packets and the destination has a policy of only engaging in secure communications, some means is necessary to indicate this. A new type of "unreachable" ICMP error code needs to be assigned to indicate that the packet was rejected because it was not secured with the PIPS protocol and the recipient will only communicate with the sender using PIPS. Once the use of PIPS is established by receipt of this ICMP, much more detailed PIPS negotiation and errors can be used to settle security details. Donald E. Eastlake 3rd [Page 23] INTERNET-DRAFT PIPS 8. Decoding a PIPS Packet This section describes, step by step, the decoding of an incoming packet by PIPS. NOTE: in all cases where these instructions say to return an error control message, you should NOT do this if the erroneous packet is itself an error. This can easily be determined by checking if both the control and error bits are on in the Black Flags byte. You should also NOT do this if the destination address that delivered it to you is a multicast or broadcast address. (1) Look at the Black Flags. If any must-be-zero bits are non-zero, return an Illegal error packet. (2) If the time stamp flag is on and you have a policy with respect to stale packets, check the time. If it's bad, drop the packet and send a Bad Time error packet back. (3) If the black options flag is on and options are not implemented, return an Unimplemented error packet. If the flag is on and options are implemented, parse the black options returning an Illegal or Unimplemented error if any illegal or unimplemented non-permissive options are found or a Duplicate error if any options that may only occur once are found more than once. Record the values for valid implemented options. (4) If this is a data packet, go to 5. If it is a control packet, go to 6. If it is an error packet, go to 7. (5) DATA Packet Check the SAID type and value. If the value is zero, return an Illegal error. If the type is global and the value is greater than two or is equal to two with no prior arrangement with the source, return an Unimplemented error. If the type is negotiated and the SAID is unknown to you, return an Unknown error. If the type is dictated and the SAID is unknown then you can return an Unknown error (only if unicast) or unicast an Inquire control message to the source (even if the destination was multicast) to try to learn about the SAID. If the SAID type is reserved, return an Unimplemented error. (5.1) At this point you have a superficially valid data packet and enought information to check the authentication tail. If authentication fails, return a Bogus error. (5.2) If the encryption flag is on, decrypt the data portion of the packet using the algorithm and key you have. If the decryption algorithm indicates the data is garbled, return an Bogus error. (5.3) Look at the Red Flags. If any must-be-zero bits are non-zero, Donald E. Eastlake 3rd [Page 24] INTERNET-DRAFT PIPS return an Illegal error packet. (5.4) If the red options flag is on and options are not implemented, return an Unimplemented error packet. If the flag is on and options are implemented, parse the red options returning an Illegal or Unimplemented error if any illegal or unimplemented non-permissive options are found or a Duplicate error if any options that may only occur once are found more than once (including duplication in the black options). Record the values for valid implemented options. (5.5) If the data is compressed, either de-compress it or return an appropriate Illegal or Unimplemented error. If the decompression algorithm indicates that the data is garbled, return a Bogus error. (5.6) At this point, you are essentially done. Depending on local implementation, you should be able to fully recontruct the encapsulated IP packet by taking the incoming packet header, replacing the PIPS protocol number with the original protocol, replacing the source and destination IP addresses with the true source and destination IP addressee if necessary, and affixing the plain text data. (6) CONTROL Packet xxx (7) ERROR Packet If the error is Illegal, Duplicate, Bogus, or Unsecure, it indicates a real error condition, although this could be due to packet corruption on the network or a bug in the source of the error PIPS packet as well as a bug in the recipient of the error packet. Within reason, such errors should be logged. If the error is Bad Time, you may be out of synchronization with the other end or it may just have very tight timing requirmeents. This is likely to be a persistent error. An Unimplemented error may indicated the need, if permitted by your security poicy, to fall back to a a lower level of PIPS capabilities. ... Unknown Donald E. Eastlake 3rd [Page 25] INTERNET-DRAFT PIPS 9. Levels of Implementation PIPS is a rich protocol containing many features and options. But it is only necessary to implement a limited subset to get many of its advantages. Four levels of implementation are defined below but even the minimum level provides substantial authentication and confidentiality. Note that the descriptions below give only the minimum necessary to qualify for each level. Most real implementations will include additional features beyond the level they qualify at. In addition, it should be noted that the requirement for certain capabilities does not imply any obligation on any party to adopt security policies which would actualy make use of such capabilities. 9.1 Level One Implementation A level one implementation (PIPS-1) must include global SAID 1, the default (IP address) source and destination identities, the default datagram encryption and authentication algorithms, and the default compression algorithm. It must also allow the time stamp option but need not do anything with received time stamps. It must implement the true source and true destination red flags. The implementation must have access to or include a resolver that can securely retrieve keys from the DNS. However, a PIPS-1 implementation need not include any key exchange or connection oriented logic and need not understand or even be able to parse options. WARNING: Level one implementations are impractical under most circumstances without special cryptographic hardware. Without such hardware, the default encryption and authentication algorithms impose an excessive computational burden. Nevertheless, there may be special circumstances where software implementations of PIPS-1 may be useful such as authentication of router ICMP re-direct datagrams. Even a lowly level one implementation provides (1) authentication that the source of an encapsulated IP packet is someone currently authorized to speak for the source IP address, (2) assurance that the packet has not been tampered with in transit, and (3) optional protection against observation of the packet content by anyone not currently authorized to hear for the destination IP address (which may be a multicast address). However, PIPS-1 provides no inherent protection against replay attacks. Unless the packet being encapsulated contains time stamp information or is replay insensitive, the PIPS time stamp field should be included and checked. Donald E. Eastlake 3rd [Page 26] INTERNET-DRAFT PIPS 9.2 Level Two Implementation A level two implemetation augments PIPS-1 by adding dictated and negotiated SAIDs and the default connection oriented encryption and authentication algorithms. There is still no need to understand or parse options or implement any but the default algorithms. The connection oriented cryptographic algorithms are much less computation intensive than the datagram cryptographic algorithms making software implementation more practical. PIPS-2, through the authenticated cryptographic establishment of a random shared key, provides the additional security that even later compromise of both hosts involved will not compromise the messages sent over the connection as long as the shared key has been purged. Furthermore, the existence of a uniquely keyed temporary connection reduces the risk of replay attacks, in the absence of time stamps, to the duration of the connection. A PIPS-2 implementation should provide the capability, when appropriate, to fall back to pure datagram mode when speaking securely with a PIPS-1 implementation. 9.3 Level Three Implementation Level three implementation adds the ability to parse options and requires the implementation of (1) the DNS oriented source/destination identity options, (2) the key owner source/destination identity options, and (3) the encryption and authentication algorithm list options and recognition in these lists and implementation of all the default and supplemental encryption and authentication algorithms defined in this document. For example, this permits connection oriented secure traffic using the RSA/MD5 authentication algorithm so that each packet could be independently authenticated without looking inside any encyrption. A PIPS-3 implementation should provide the capability, when appropriate, to fall back to level two or level one capabilities when speaking securely with lower level implementations. 9.4 Level Four Implementation Level four implementation adds the high level OSI oriented source and destination identity options. This permits a wider range of source and destination identities and better integration with X.500 directories. A PIPS-4 implementation should provide the capability, when appropriate, Donald E. Eastlake 3rd [Page 27] INTERNET-DRAFT PIPS to fall back to lower level capabilities when speaking securely with lower level implementations. Donald E. Eastlake 3rd [Page 28] INTERNET-DRAFT PIPS 10. Abbreviations ASN.1 - OSI Abstract Syntax Notation. BER - OSI Basic Encoding Rules. DN - OSI Distinguished Name. DNS - Internet Domain Name System. IANA - Internet Assigned Numbers Authority. IP - Internet Protocol. OID - OSI Object IDentifier. PIPS - Practical IP Security protocol. RR - DNS Resource Record. SAID - Security Association IDentifier. X.500 - An OSI Directory System. 11. Security Considerations The entirety of this document concerns a network level protocol to provide packet integrity, authentication, and confidentiality for IP protocol verison 4. References [PKCS1] - PKCS #1: RSA Encryption Standard, RSA Data Security, Inc., 3 June 1991, Version 1.4. [RFC1305] - Network Time Protocol (v3), D. Mills, April 9 1992 [SHS] - NIST FIPS PUB 180, Secure Hash Standard, National Institute of Science and Technology, U.S. Department of Commerce, April 1993. Donald E. Eastlake 3rd [Page 29] INTERNET-DRAFT PIPS Author's Address Donald E. Eastlake 3rd Digital Equipment Corporation 550 King Street, LKG2-1/BB3 Littleton, MA 01460 Telephone: +1 508 486 6577(w) +1 508 287 4877(h) EMail: dee@lkg.dec.com Expiration and File Name This draft expires 30 September 1994. Its file name is draft-ietf-ipsec-pips-00.txt. Donald E. Eastlake 3rd [Page 30] INTERNET-DRAFT PIPS Status of This Document....................................1 Abstract...................................................1 Acknowledgements...........................................1 Table of Contents..........................................2 1. Introduction............................................3 2. Overview of the Protocol...............................3 3. Packet Format...........................................4 3.1 Black Flag Bits........................................5 3.2 Security Association IDentifiers.......................6 3.2.1 Global Security Association IDentifiers..............6 3.2.1.1 Global SAID One....................................6 3.2.1.2 Global SAID Two....................................7 3.2.2 Dictated Security Association IDentifiers............7 3.2.3 Negotiated Security Association IDentifiers..........7 3.3 Time Stamp.............................................7 3.4 Red Flag Bits..........................................8 3.5 Black / Red Options....................................8 3.5.1 Option Codes.........................................9 3.5.1.1 Mandatory Comprehension Option Codes...............9 3.5.1.2 Permissive Comprehension Option Codes.............10 3.5.1.3 Illegal Option Codes..............................10 3.5.1.4 Reserved Option Codes.............................10 3.5.2 Source and Destination Identities...................11 3.5.3 Algorithm Lists.....................................12 3.5.4 Labels..............................................13 4. Cryptographic Algorithms...............................14 4.1 Default Datagram Algorithms...........................14 4.2 Default Negotiated / Dictated Algorithms..............14 4.3 Supplemental Algorithms...............................15 5. Compression............................................16 5.1 Body Data Compression.................................16 5.2 Basic Compression Algorithm...........................16 5.3 Header Compression....................................17 6. PIPS Control/ Error Packets............................18 6.1 Control Message Formats...............................18 6.2 Key Exchange..........................................19 6.3 Operation Codes.......................................19 6.4 Error Packet Formats..................................20 6.5 Error Codes...........................................21 7. Initial Communications and New ICMP Error Code.........23 8. Decoding a PIPS Packet.................................24 Donald E. Eastlake 3rd [Page 31] INTERNET-DRAFT PIPS 9. Levels of Implementation...............................26 9.1 Level One Implementation..............................26 9.2 Level Two Implementation..............................27 9.3 Level Three Implementation............................27 9.4 Level Four Implementation.............................27 10. Abbreviations.........................................29 11. Security Considerations...............................29 References................................................29 Author's Address..........................................30 Expiration and File Name..................................30 Donald E. Eastlake 3rd [Page 32]