From owner-ipsec Mon Sep 1 17:43:09 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA29142 for ipsec-outgoing; Mon, 1 Sep 1997 17:34:50 -0400 (EDT) From: Tim Bass (IETF) Message-Id: <199709012142.RAA20419@linux.silkroad.com> Subject: IANA and SA Attribute Registration (ISAKMP) To: ipsec@tis.com Date: Mon, 1 Sep 1997 17:42:35 -0400 (EDT) X-Mailer: ELM [version 2.4 PL24 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk The ISAKMP draft (July 26, 1997) discusses that IANA will be the central authority for registering and managing SA attributes, referencing STD 2, Assigned Numbers, October 1994. i am assuming (perhaps incorrectly) SA attributes such as: -Key Establishment Method -Key Exchange Authentication Method -Etc. Etc. ... have been identified, defined, and numbers assigned by IANA.. However, i've missed finding this information in the drafts, etc. Is there a matrix which defines the SA attributes and assigned numbers? Thanks, Tim From owner-ipsec Tue Sep 2 11:00:56 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA05117 for ipsec-outgoing; Tue, 2 Sep 1997 11:00:20 -0400 (EDT) From: aha@apollo.hp.com Message-Id: <199709021507.LAA19118@relay.rv.tis.com> Date: Tue, 2 Sep 1997 11:09:10 -0400 To: ietf@linux.silkroad.com Cc: ipsec@tis.com In-Reply-To: <199709012142.RAA20419@linux.silkroad.com> (ietf@linux.silkroad.com) Subject: Re: IANA and SA Attribute Registration (ISAKMP) Sender: owner-ipsec@ex.tis.com Precedence: bulk "The resolution of ISAKMP with Oakley" has the ISAKMP security attribute classes and class values in Appendix A. "The Internet IP Security Domain of Interpretation for ISAKMP" has the IPSEC security attribute classes and classes in Section 4.5. Anne H. Anderson, aha@apollo.hp.com, 508/436-5707, HP TN 436-5707 Internet Technology Lab, Hewlett-Packard Company, Chelmsford, MA From owner-ipsec Tue Sep 2 11:01:00 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA05111 for ipsec-outgoing; Tue, 2 Sep 1997 10:58:51 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <97Aug28.224704edt.11650@janus.tor.securecomputing.com> References: kent's message of "Thu, 28 Aug 1997 20:39:06 -0400". Your message of "Mon, 25 Aug 1997 17:24:19 CDT." Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 2 Sep 1997 11:05:12 -0400 To: "C. Harald Koch" From: Stephen Kent Subject: Re: A few observations about the replay issue Cc: Daniel Harkins , ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Harald, >We've gone to a lot of trouble to include sequence numbers and replay >protection into the protocol specs. I should *expect* AR to be turned on >given its emphasis in the new specs. > >So, If the sender rolls its sequence number, and the remote end starts >rejecting packets, the sender has an *excellent* idea why. > If we knew the receiver were rejecting the packets, this would not be an issue. However, the sender may know only that the packets are not being received, without knowing why. Steve From owner-ipsec Thu Sep 4 14:23:35 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA22326 for ipsec-outgoing; Thu, 4 Sep 1997 14:16:52 -0400 (EDT) Date: Thu, 4 Sep 1997 14:25:47 -0400 Message-Id: <199709041825.OAA03760@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: ipsec@tis.com Subject: Vendors who are implementing IPSEC, step forward.... Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi there, I'm starting to get reporters who are pestering me for interviews; one of the questions which they are asking is "which companies are implementing IPSEC"? In the spirit of fairness, I'd appreciate if people from those vendors who are willing to have their names on the list of "companies who are planning to implement IPSEC", send me e-mail. I could make some inferences based on who's active on the ipsec mailing list, which is after all public, but it seems fairer to ask people to self-nominate themselves for this list, so that I don't miss anyone or appear to be playing favorites with respect to marketing/pushing certain companies or their products more than others. Of course, if you'd rather not be listed, that's fine too! - Ted From owner-ipsec Fri Sep 5 04:32:27 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id EAA26760 for ipsec-outgoing; Fri, 5 Sep 1997 04:30:47 -0400 (EDT) To: "Theodore Y. Ts'o" Cc: ipsec@tis.com Subject: Re: Vendors who are implementing IPSEC, step forward.... References: <199709041825.OAA03760@dcl.MIT.EDU> From: Lars Albertsson Date: 05 Sep 1997 10:39:56 +0200 In-Reply-To: "Theodore Y. Ts'o"'s message of Thu, 4 Sep 1997 14:25:47 -0400 Message-ID: Lines: 14 X-Mailer: Gnus v5.3/Emacs 19.34 Sender: owner-ipsec@ex.tis.com Precedence: bulk > Hi there, > > I'm starting to get reporters who are pestering me for > interviews; one of the questions which they are asking is "which > companies are implementing IPSEC"? In the spirit of fairness, I'd > appreciate if people from those vendors who are willing to have their > names on the list of "companies who are planning to implement IPSEC", > send me e-mail. We are implementing IPSEC in HP-UX on behalf of HP. /Lalle, SICS From owner-ipsec Fri Sep 5 07:30:17 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA27731 for ipsec-outgoing; Fri, 5 Sep 1997 07:28:49 -0400 (EDT) Date: Fri, 5 Sep 1997 13:53:07 +0300 (EET DST) From: Kalle Kaukonen To: "Theodore Y. Ts'o" cc: ipsec@tis.com, "Michael C. Richardson" Subject: Re: Vendors who are implementing IPSEC, step forward.... In-Reply-To: <199709041825.OAA03760@dcl.MIT.EDU> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk On Thu, 4 Sep 1997, Theodore Y. Ts'o wrote: > > Hi there, > > I'm starting to get reporters who are pestering me for > interviews; one of the questions which they are asking is "which > companies are implementing IPSEC"? In the spirit of fairness, I'd > appreciate if people from those vendors who are willing to have their > names on the list of "companies who are planning to implement IPSEC", > send me e-mail. 2 companies that are implementing IPSEC (and now having an early beta, in 3 weeks supposed to have a beta): Data Fellows, Ltd. http://www.datafellows.com/ SSH Communications Security, Ltd. http://www.ssh.fi/ Best Regards, Kalle Kaukonen * kalle@ssh.fi * SSH Communications Security, Ltd. From owner-ipsec Fri Sep 5 08:31:19 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA28303 for ipsec-outgoing; Fri, 5 Sep 1997 08:30:16 -0400 (EDT) Message-ID: From: Greg Carter To: "'anx-sec@dot.netrex.net'" Cc: "'isakmp-oakley@cisco.com'" , "'ipsec@tis.com'" Subject: RE: IPsec and Oakley test items Date: Fri, 5 Sep 1997 08:35:40 -0400 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk > Informational exchanges are protected by SKEYID_e and SKEYID_a. Section >5.6 doesn't mention how an IV is generated to use with encryption nor does >it mention where 'M-ID' in the HASH definition came from. The intent is that >this is similar to a Quick Mode initiation. A unique message id for this >single message is chosen and it is used to generate an IV ala Quick Mode. >Once this message is sent all the state associated with it-- the IV, the >message id, plus whatever else your implementation chooses to generate-- >is deleted. This is how it should be done. Hi Dan, I a little confused now. For Info exchange (an example - a notify of a failed QUICK_MODE) associated with a quick mode what M-ID do we use? The M-ID associated with the quick mode (what we had previously done) or generate a new unique ID. Is the generation of a unique ID only for 'independent' Informational exchanges (assuming an ISAKMP SA has been setup), I hope so... Thanks Bye. ---- Greg Carter, Entrust Technologies greg.carter@entrust.com Get FREE 128-bit FIPS-140-1 Validated Crypto for the desktop http://www.entrust.com/solo.htm > From owner-ipsec Fri Sep 5 08:40:23 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA28388 for ipsec-outgoing; Fri, 5 Sep 1997 08:38:47 -0400 (EDT) Message-ID: <34100183.8A8C4A7F@newoak.com> Date: Fri, 05 Sep 1997 08:56:35 -0400 From: smamros@newoak.com (Shawn Mamros) X-Mailer: Mozilla 4.0 [en] (WinNT; U) MIME-Version: 1.0 To: ipsec@tis.com, isakmp-oakley@cisco.com CC: smamros@newoak.com Subject: ISAKMP/Oakley resolution draft question X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk My apologies for repeating a question I had asked about a month ago, but given the noise level on the list at the time, I can understand how it got lost in the shuffle... In the latest (-04) version of the ISAKMP/Oakley resolution draft, the last message of Aggressive Mode (regardless of the authentication method) is always unencrypted. This seems to counter the base ISAKMP (-08) draft, where the last message of Aggressive Mode is encrypted. But there is some text in section 5 of the resolution draft (at the top of page 7) which seems to justify the lack of encryption. Is this correct? If so, then how does one calculate the IV required for the first Quick Mode message after using Aggressive Mode, given that there will be no CBC output block from phase 1 (see appendix B)? Thanks in advance... -Shawn Mamros E-mail to: smamros@newoak.com From owner-ipsec Fri Sep 5 09:29:16 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA28720 for ipsec-outgoing; Fri, 5 Sep 1997 09:27:48 -0400 (EDT) X-Mailer: SuperTCP Suite for Windows Version 3.0.2 (Mailer Version 1.02) Message-ID: <34100BB7-00000001@rock101> From: john@frontiertech.com MIME-Version: 1.0 Content-Type: Text/Plain; Charset=US-ASCII Date: Fri, 05 Sep 1997 08:40:06 -0500 Subject: Re: Vendors who are implementing IPSEC, step forward.... To: "Theodore Y. Ts'o" Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk > >Hi there, > > I'm starting to get reporters who are pestering me for >interviews; one of the questions which they are asking is "which >companies are implementing IPSEC"? In the spirit of fairness, I'd >appreciate if people from those vendors who are willing to have their >names on the list of "companies who are planning to implement IPSEC", >send me e-mail. > > I could make some inferences based on who's active on the ipsec >mailing list, which is after all public, but it seems fairer to ask >people to self-nominate themselves for this list, so that I don't miss >anyone or appear to be playing favorites with respect to >marketing/pushing certain companies or their products more than others. I appreciate your request. We are not very active because as yet we are a little behind. Frontier is a Microsoft Windows TCP/IP company. We have been doing stacks, and tcp/ip applications for 15 years (SuperTCP, SuperNFS, SuperX, SuperTCP Suite). Most of what we develop lately is OEM oriented, so we are not all that visible. We started developing IPsec rather late, and have manual key management ready (but why make any anouncements about that), and expect to have ISAKMP ready on Win95, NT 3.51, and NT 4.0. I am more than willing to receive some press, but as I point out because we are alittle behind, we have not yet appeared in the interoperability tables. I have more information (marketing, spec sheets), but don't believe that you want to be bombarded with that. Thanks for your willingness to pass the information along. > > Of course, if you'd rather not be listed, that's fine too! > > - Ted %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% John F. Moehrke Director of Engineering Frontier Technologies Corp 10201 N. Port Washington Rd. Mequon, WI 53092 VOICE: (414) 241-4555 x215 FAX: (414) 241-7084 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% From owner-ipsec Fri Sep 5 09:36:01 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA28793 for ipsec-outgoing; Fri, 5 Sep 1997 09:33:51 -0400 (EDT) Message-ID: From: Greg Carter To: "'ipsec@tis.com'" , "'isakmp-oakley@cisco.com'" , "'smamros@newoak.com'" Subject: RE: ISAKMP/Oakley resolution draft question Date: Fri, 5 Sep 1997 09:38:29 -0400 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk >Is this correct? If so, then how does one calculate the IV required >for the first Quick Mode message after using Aggressive Mode, given >that there will be no CBC output block from phase 1 (see appendix B)? I can't comment on whether it is correct or not, but here is what I do: I initialize the buffer which is supposed to be the last CBC block with N bytes, where N is the Block size, of the phase one calculated IV (using the method described in appendix B, 5th or 6th paragraph). Then my Quick Mode IV generation treats it as though it were the last CBC block. Since both sides know the value everything works out. Bye. ---- Greg Carter, Entrust Technologies greg.carter@entrust.com Get FREE 128-bit FIPS-140-1 Validated Crypto for the desktop http://www.entrust.com/solo.htm > From owner-ipsec Fri Sep 5 12:10:23 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA29754 for ipsec-outgoing; Fri, 5 Sep 1997 12:08:51 -0400 (EDT) Message-Id: <199709051618.JAA22079@dharkins-ss20> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: Greg Carter Cc: "'anx-sec@dot.netrex.net'" , "'isakmp-oakley@cisco.com'" , "'ipsec@tis.com'" Subject: Re: IPsec and Oakley test items In-Reply-To: Your message of "Fri, 05 Sep 1997 08:35:40 EDT." Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 05 Sep 1997 09:18:08 -0700 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk Greg, Yes, the M-ID is only for the informational exchange. If the notify is a result of a failed Quick Mode the M-ID of the informational exchange will not be that of the failed Quick Mode; they are different. And once the message has been sent the unique M-ID (only for the Info exchange) is thrown away. Dan. Greg Carter responding to me: > > Informational exchanges are protected by SKEYID_e and SKEYID_a. Section > >5.6 doesn't mention how an IV is generated to use with encryption nor does > >it mention where 'M-ID' in the HASH definition came from. The intent is that > >this is similar to a Quick Mode initiation. A unique message id for this > >single message is chosen and it is used to generate an IV ala Quick Mode. > >Once this message is sent all the state associated with it-- the IV, the > >message id, plus whatever else your implementation chooses to generate-- > >is deleted. This is how it should be done. > > Hi Dan, > > I a little confused now. For Info exchange (an example - a notify of a > failed QUICK_MODE) associated with a quick mode what M-ID do we use? > The M-ID associated with the quick mode (what we had previously done) or > generate a new unique ID. Is the generation of a unique ID only for > 'independent' Informational exchanges (assuming an ISAKMP SA has been > setup), I hope so... From owner-ipsec Fri Sep 5 12:31:15 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA29855 for ipsec-outgoing; Fri, 5 Sep 1997 12:30:51 -0400 (EDT) Message-Id: <199709051640.JAA22096@dharkins-ss20> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: Greg Carter Cc: "'ipsec@tis.com'" , "'isakmp-oakley@cisco.com'" , "'smamros@newoak.com'" Subject: Re: ISAKMP/Oakley resolution draft question In-Reply-To: Your message of "Fri, 05 Sep 1997 09:38:29 EDT." Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 05 Sep 1997 09:40:05 -0700 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk Shawn, Good point. I guess I never ran into that because my implementation sends the last Aggressive Mode message encrypted (i.e. under the protection of the ISAKMP SA) which, I guess, is technically in violation of the spec. I'll clean this up. The reason the messages are shown as being in the clear is because the parties can delay generation of the shared secret until the exchange is finished if they choose to do so. I surely didn't mean to imply that they must do so. What Greg suggests is correct. The phase 2 IV is computed-- in part-- from the phase 1 IV. If the phase 1 IV has never been used (if in Aggressive Mode the last message is sent unencrypted) then that's just what's used. If the phase 1 IV has been used then it will end up just being the last CBC block processed. In either case it's still the "phase 1 IV". It seems to me that the responder should be able to handle either. If it chooses to postpone exponentiation but the initiator didn't and sent the message encrypted then it must exponentiate to process the final message. If it chooses to exponentiate but the initiator did not and sent the last message in the clear the responder shouldn't treat this as an error-- as it should if a Quick Mode message was sent unencrypted. If there are no objections to such a clarification I'll make it. An alternative would be to just mandate that the last message be encrypted but that would negate the "feature" of being able to delay exponentiation if you so choose. sorry for the delay in answering you, Dan. > >In the latest (-04) version of the ISAKMP/Oakley resolution draft, > >the last message of Aggressive Mode (regardless of the authentication > >method) is always unencrypted. This seems to counter the base > >ISAKMP (-08) draft, where the last message of Aggressive Mode is > >encrypted. But there is some text in section 5 of the resolution > >draft (at the top of page 7) which seems to justify the lack of > >encryption. > > > >Is this correct? If so, then how does one calculate the IV required > >for the first Quick Mode message after using Aggressive Mode, given > >that there will be no CBC output block from phase 1 (see appendix B)? > > I can't comment on whether it is correct or not, but here is what I do: > > I initialize the buffer which is supposed to be the last CBC block with > N bytes, where N is the Block size, of the phase one calculated IV > (using the method described in appendix B, 5th or 6th paragraph). Then > my Quick Mode IV generation treats it as though it were the last CBC > block. Since both sides know the value everything works out. From owner-ipsec Fri Sep 5 13:38:34 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA00383 for ipsec-outgoing; Fri, 5 Sep 1997 13:37:22 -0400 (EDT) Message-ID: From: Greg Carter To: "'Daniel Harkins'" Cc: "'anx-sec@dot.netrex.net'" , "'ipsec@tis.com'" Subject: RE: IPsec and Oakley test items Date: Fri, 5 Sep 1997 13:39:58 -0400 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi Dan, Below are a few relevant sections from the latest ISAKMP (unchanged from previous versions). I think it is clear that a Notification that is concerned with a Quick Mode should use the same M-ID as that of the Quick Mode. And that it is acceptable to identify in progress Quick Modes by that M-ID (along with the cookies). Using SPI alone to match up in progress Quick Modes is cumbersome, especially for exchanges which involve multiple SPIs. If I can key off the M-ID its much easier to single out the failed negotiation. Regardless, there is discrepancy between ISAKMP and your proposed additions to ISAKMP/Oakley. You can probably figure out which one I want. Bye. Section 2.4 Identifying Security Associations ... In the fifth line (5) of the table, the initiator and responder use the Message ID field in the ISAKMP Header to keep track of the in-progress protocol negotiation. This is only applicable for a phase 2 exchange and the value SHOULD be 0 for a phase 1 exchange because the combined cook- ies identify the ISAKMP SA. Section 3.14 Notification Payload ... Notification which occurs during, or is concerned with, a Phase 2 nego- tiation is identified by the Initiator and Responder cookie pair in the ISAKMP Header and the Message ID and SPI associated with the current nego- tiation. One example for this type of notification is to indicate why a proposal was rejected. ---- Greg Carter, Entrust Technologies greg.carter@entrust.com Get FREE 128-bit FIPS-140-1 Validated Crypto for the desktop http://www.entrust.com/solo.htm >---------- >From: Daniel Harkins[SMTP:dharkins@cisco.com] >Sent: Friday, September 05, 1997 12:18 PM >To: Greg Carter >Cc: 'anx-sec@dot.netrex.net'; 'isakmp-oakley@cisco.com'; 'ipsec@tis.com' >Subject: Re: IPsec and Oakley test items > > Greg, > > Yes, the M-ID is only for the informational exchange. If the notify is >a result of a failed Quick Mode the M-ID of the informational exchange >will not be that of the failed Quick Mode; they are different. And once >the message has been sent the unique M-ID (only for the Info exchange) is >thrown away. > > From owner-ipsec Fri Sep 5 14:12:44 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA00581 for ipsec-outgoing; Fri, 5 Sep 1997 14:12:21 -0400 (EDT) Date: Fri, 5 Sep 1997 11:12:16 -0700 (PDT) From: Wan-Yen Hsu Message-Id: <199709051812.LAA01807@hpindlm.cup.hp.com> To: ipsec@tis.com Subject: Re: Vendors who are implementing IPSEC, step forward... Cc: wanyen@hpindlm.cup.hp.com Mime-Version: 1.0 Content-Type: text/plain; charset=X-roman8 Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi, > I'm starting to get reporters who are pestering me for >interviews; one of the questions which they are asking is "which >companies are implementing IPSEC"? In the spirit of fairness, I'd >appreciate if people from those vendors who are willing to have their >names on the list of "companies who are planning to implement IPSEC", >send me e-mail. > I could make some inferences based on who's active on the ipsec >mailing list, which is after all public, but it seems fairer to ask >people to self-nominate themselves for this list, so that I don't miss >anyone or appear to be playing favorites with respect to >marketing/pushing certain companies or their products more than others. > Of course, if you'd rather not be listed, that's fine too! HP is implementing IPSEC and ISAKMP. We plan to participate ANX's September IPSEC workshop. Regards, Wan-yen Hsu HP From owner-ipsec Fri Sep 5 14:32:22 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA00642 for ipsec-outgoing; Fri, 5 Sep 1997 14:28:52 -0400 (EDT) Message-Id: <199709051838.LAA22225@dharkins-ss20> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: Greg Carter Cc: "'anx-sec@dot.netrex.net'" , "'ipsec@tis.com'" Subject: Re: IPsec and Oakley test items In-Reply-To: Your message of "Fri, 05 Sep 1997 13:39:58 EDT." Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 05 Sep 1997 11:38:05 -0700 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk Greg, There's already a discrepancy between ISAKMP/Oakley and the base ISAKMP spec on this subject: note there's no hash in the exchange in section 4.8 in the base ISAKMP draft (also unchanged from previous versions). It has to be so because the base ISAKMP spec doesn't spell out a specific key exchange and doesn't deal with SKEYID_foo or message encryption and authentication. But my intent is not to add gratuitous changes to increase the discrepancies between the drafts. I really have a reason. Informational exchanges are unidirectional and one does not set a retransmition timer when sending them. If you use the M-ID of the phase 2 exchange which (for whatever reason) caused the notify message in the first place to "identify" the corresponding state you're maintaining then you also have to use the IV from that same phase 2 exchange. Now, if that notify gets lost in the ether your IVs are out-of-sync and the next message will decrypt wrong, which will probably cause you to generate another notify, which will be encrypted with an out-of-sync IV and cause a decryption failure by the other party who will respond with a notify which you will be unable to decrypt.... until you both throw up your hands and give up. On the other hand, if the exchanges are decoupled (they've got different exchange identifiers too, so the informational exchange really is different than a Quick Mode exchange) packet loss will not result in complete chaos. In fact, the other party who never received your notify would probably retransmit the original problematic offer and you'd send another notify (which odds are, he'd get) which he could properly handle. I could also argue that this is not a discrepancy with the base ISAKMP spec. The M-ID and SPI would still identify the correct state as dictated by section 2.4. It's just that the M-ID and SPI would be in the body of the notify message as the ISAKMP header and SA payload to which the notify refers. The ISAKMP header of the Informational Exchange would be unique to the Informational Exchange. Dan. > Below are a few relevant sections from the latest ISAKMP (unchanged from > previous versions). I think it is clear that a Notification that is > concerned with a Quick Mode should use the same M-ID as that of the > Quick Mode. And that it is acceptable to identify in progress Quick > Modes by that M-ID (along with the cookies). > > Using SPI alone to match up in progress Quick Modes is cumbersome, > especially for exchanges which involve multiple SPIs. If I can key off > the M-ID its much easier to single out the failed negotiation. > > Regardless, there is discrepancy between ISAKMP and your proposed > additions to ISAKMP/Oakley. You can probably figure out which one I > want. From owner-ipsec Fri Sep 5 15:33:41 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA01159 for ipsec-outgoing; Fri, 5 Sep 1997 15:32:26 -0400 (EDT) Message-ID: <34106103.19E0@cylan.com> Date: Fri, 05 Sep 1997 12:44:53 -0700 From: Saroop Mathur X-Mailer: Mozilla 3.01Gold (Win95; I) MIME-Version: 1.0 To: "Theodore Y. Ts'o" CC: ipsec@tis.com Subject: Re: Vendors who are implementing IPSEC, step forward.... References: <199709041825.OAA03760@dcl.MIT.EDU> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk CyLAN Technologies licenses IPSEC and ISAKMP/Oakley toolkits for embedded systems. - Saroop Mathur Theodore Y. Ts'o wrote: > > Hi there, > > I'm starting to get reporters who are pestering me for > interviews; one of the questions which they are asking is "which > companies are implementing IPSEC"? In the spirit of fairness, I'd > appreciate if people from those vendors who are willing to have their > names on the list of "companies who are planning to implement IPSEC", > send me e-mail. > > I could make some inferences based on who's active on the ipsec > mailing list, which is after all public, but it seems fairer to ask > people to self-nominate themselves for this list, so that I don't miss > anyone or appear to be playing favorites with respect to > marketing/pushing certain companies or their products more than others. > > Of course, if you'd rather not be listed, that's fine too! > > - Ted From owner-ipsec Fri Sep 5 19:09:47 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA02471 for ipsec-outgoing; Fri, 5 Sep 1997 19:08:28 -0400 (EDT) Date: Fri, 5 Sep 1997 19:17:53 -0400 Message-Id: <199709052317.TAA09169@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: ipsec@tis.com Subject: Initial cut at web page of companies implementing IPSEC Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi there, I've put together an initial cut of a web page containing a list of companies who claim to be implementing IPSEC. If you've submitted information, please take a look at it and make sure it is accurate. If you would like to have a contact, or a product listed, please send me mail with the updates. URL's to product-specific pages will also be accepted. I'm doing this mainly as a service to those companies who have been working so hard on IPSEC, and for myself since I've had several reporters ask me which companies are working on IPSEC. It doesn't replace the implementation survey, which is a bit more comprensive and aimed at the "techie" crowd; in contrast, this list has marketing contacts on it.... :-) Take a look at the list; it's impressively large, and I'm sure it's not complete: http://web.mit.edu/tytso/www/ipsec/companies.html - Ted P.S. If you sent me submissions late today (Friday), they may not have made it onto the list; I'll get to them after the weekend. From owner-ipsec Mon Sep 8 10:27:44 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA18113 for ipsec-outgoing; Mon, 8 Sep 1997 10:19:55 -0400 (EDT) Date: Mon, 8 Sep 97 10:31:39 EDT From: wdm@epoch.ncsc.mil (W. Douglas Maughan) Message-Id: <9709081431.AA00577@dolphin.ncsc.mil> To: ipsec@tis.com Subject: ISAKMP v08 comments Sender: owner-ipsec@ex.tis.com Precedence: bulk All, As a reminder, I would like all comments on ISAKMP-08 by the end of the week. I would like to have a new draft out by the 20th so it can go forward to the IESG. I will include the items I presented at Munich which were all interoperability issues. They are listed here: * Text to clarify that Data Attributes fields contained in Transform payloads are not aligned on 4-octet boundaries. If they don't align then subsequent payloads will not be aligned and any padding will be added at the end of the message as described in ISAKMP-08 section 3. * Text to clarify the use of IVs with respect to Informational Exchanges, i.e. independence from IVs of other on-going communication. * Removal of # Cert Types and # Cert Auths fields from the Certificate Request payload. This will eliminate parsing problems for multiple certificates and authorities or non-existent authorities (e.g. PGP) and multiple Certificate Request payloads can be chained together to accomplish the same thing more efficiently. * Adding an additional bit in the ISAKMP Header Flags field for Authentication Only Information Exchange. This bit is intended for use with the Informational Exchange with a Notify payload and will allow passing information with integrity checking, but no encryption (e.g. "emergency mode"). NOTE: The current I-D calls for all Informational Exchanges to be sent under protection of an ISAKMP SA. This is a slight modification to that policy. Thanks, Doug Maughan From owner-ipsec Mon Sep 8 12:52:22 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA19236 for ipsec-outgoing; Mon, 8 Sep 1997 12:49:25 -0400 (EDT) Date: Mon, 8 Sep 1997 12:58:18 -0400 (EDT) From: Dave Mason Message-Id: <199709081658.MAA17280@rubicon.rv.tis.com> To: anx-sec@dot.netrex.net, ipsec@tis.com Subject: Re: IPsec and Oakley test items Sender: owner-ipsec@ex.tis.com Precedence: bulk > I could also argue that this is not a discrepancy with the base ISAKMP >spec. The M-ID and SPI would still identify the correct state as dictated >by section 2.4. It's just that the M-ID and SPI would be in the body of >the notify message as the ISAKMP header and SA payload to which the notify >refers. The ISAKMP header of the Informational Exchange would be unique >to the Informational Exchange. Are there any plans in specifying "the additional Notification Data" for particular error notifications? Is the data always the message (in its entirety) that caused the error? -dave From owner-ipsec Mon Sep 8 16:08:15 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA20774 for ipsec-outgoing; Mon, 8 Sep 1997 16:07:02 -0400 (EDT) Date: Mon, 8 Sep 1997 13:15:43 -0700 Message-Id: <199709082015.NAA14785@gump.eng.ascend.com> From: Karl Fox To: Derrell Piper Cc: ipsec@tis.com Subject: ID: draft-ietf-ipsec-ipsec-doi-03.txt In-Reply-To: <199707312305.TAA26362@portal.ex.tis.com> References: <199707312305.TAA26362@portal.ex.tis.com> Reply-To: Karl Fox Organization: Ascend Communications Sender: owner-ipsec@ex.tis.com Precedence: bulk Why was the section entitled "IPSEC Security Parameter Index (SPI) Encoding" removed from this draft? Is the information moving somewhere else? If so, will the ISAKMP draft be updated to point to the new place rather than to the DOI? Derrell Piper writes: > > > > > > > Network Working Group Derrell Piper > INTERNET-DRAFT cisco Systems > draft-ietf-ipsec-ipsec-doi-03.txt July 31, 1997 > > > The Internet IP Security Domain of Interpretation for ISAKMP > ... -- Karl Fox, servant of God, employee of Ascend Communications 655 Metro Place South, Suite 370, Dublin, Ohio 43017 +1 614 760 4041 From owner-ipsec Mon Sep 8 16:14:38 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA20848 for ipsec-outgoing; Mon, 8 Sep 1997 16:14:33 -0400 (EDT) Date: Mon, 8 Sep 97 16:26:23 EDT From: wdm@epoch.ncsc.mil (W. Douglas Maughan) Message-Id: <9709082026.AA00886@dolphin.ncsc.mil> To: ipsec@tis.com Subject: ISAKMP Munich Presentation Sender: owner-ipsec@ex.tis.com Precedence: bulk All, As is usually the case when mentioning those who have provided help, I inadvertently left off one of the more important contributors to ISAKMP from my slide in Munich. Often those with whom you work very closely are the ones overlooked. I wanted to publicly apologize to Elfed Weaver of the UK Defense Evaluation and Research Agency (DERA) and give him the recognition he justly deserves. Elfed has been working very closely with us (NSA and Cisco) on the development of ISAKMP and ISAKMP/Oakley. He has provided many valuable comments from implementation experience. SORRY ELFED!!! Cheers, Doug Maughan From owner-ipsec Mon Sep 8 16:35:09 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA20999 for ipsec-outgoing; Mon, 8 Sep 1997 16:34:02 -0400 (EDT) Message-Id: <199709082042.NAA07265@pita.cisco.com> To: Karl Fox Cc: ipsec@tis.com Subject: Re: ID: draft-ietf-ipsec-ipsec-doi-03.txt In-reply-to: Your message of "Mon, 08 Sep 1997 13:15:43 PDT." <199709082015.NAA14785@gump.eng.ascend.com> Date: Mon, 08 Sep 1997 13:42:47 -0700 From: Derrell Piper Sender: owner-ipsec@ex.tis.com Precedence: bulk Karl, The current version of ISAKMP has a generalized variable length SPI, so a particular encoding format for the IPSEC DOI is no longer required. Derrell From owner-ipsec Mon Sep 8 16:46:59 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA21097 for ipsec-outgoing; Mon, 8 Sep 1997 16:46:36 -0400 (EDT) Date: Mon, 8 Sep 1997 13:55:28 -0700 Message-Id: <199709082055.NAA15034@gump.eng.ascend.com> From: Karl Fox To: Derrell Piper Cc: ipsec@tis.com Subject: Re: ID: draft-ietf-ipsec-ipsec-doi-03.txt In-Reply-To: <199709082042.NAA07265@pita.cisco.com> References: <199709082015.NAA14785@gump.eng.ascend.com> <199709082042.NAA07265@pita.cisco.com> Reply-To: Karl Fox Organization: Ascend Communications Sender: owner-ipsec@ex.tis.com Precedence: bulk Derrell Piper writes: > Karl, > > The current version of ISAKMP has a generalized variable length SPI, so a > particular encoding format for the IPSEC DOI is no longer required. Ok, that makes sense. But since AH and ESP use 32-bit SPIs, does that then mean that we're changing the ISAKMP bits on the wire? If not, then presumably we still need to pad the 32-bit SPIs into a 64-bit field in the ISAKMP Proposal payload. Where, then, do I go to find out how to do this SPI padding? > Derrell -- Karl Fox, servant of God, employee of Ascend Communications 655 Metro Place South, Suite 370, Dublin, Ohio 43017 +1 614 760 4041 From owner-ipsec Mon Sep 8 16:55:44 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA21165 for ipsec-outgoing; Mon, 8 Sep 1997 16:55:35 -0400 (EDT) Date: Mon, 8 Sep 1997 14:04:31 -0700 Message-Id: <199709082104.OAA15064@gump.eng.ascend.com> From: Karl Fox To: ipsec@tis.com Subject: Slicing and dicing Reply-To: Karl Fox Organization: Ascend Communications Sender: owner-ipsec@ex.tis.com Precedence: bulk Appendix B of draft -04 of the resolution document says The key for DES-CBC is derived from the first eight (8) non-weak and non-semi-weak (see Appendix A) bytes of SKEYID_e. If the bytes 1-8 are a weak or semi-weak key, do we then go on to bytes 2-9 (I hope not!) or bytes 9-16? The same appendix later says The key for 3DES-CBC is the first twenty-four (24) bytes of a key derived in the aforementioned pseudo-random function feedback method. 3DES-CBC is an encrypt-decrypt-encrypt operation using the first, middle, and last eight (8) bytes of the entire 3DES-CBC key. This means that no weak key test may be done for 3DES-CBC. Was this the intent? -- Karl Fox, servant of God, employee of Ascend Communications 655 Metro Place South, Suite 370, Dublin, Ohio 43017 +1 614 760 4041 From owner-ipsec Mon Sep 8 16:56:09 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA21179 for ipsec-outgoing; Mon, 8 Sep 1997 16:56:05 -0400 (EDT) Date: Mon, 8 Sep 1997 17:04:30 -0400 (EDT) From: Dave Mason Message-Id: <199709082104.RAA05697@rubicon.rv.tis.com> To: piper@cisco.com Cc: ipsec@tis.com Subject: Re: ID: draft-ietf-ipsec-ipsec-doi-03.txt Sender: owner-ipsec@ex.tis.com Precedence: bulk >> Network Working Group Derrell Piper >> INTERNET-DRAFT cisco Systems >> draft-ietf-ipsec-ipsec-doi-03.txt July 31, 1997 >> >> >> The Internet IP Security Domain of Interpretation for ISAKMP >> Where do we find doi-03? It doesn't seem to be at ds.internic.net. -dave From owner-ipsec Mon Sep 8 17:10:29 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA21261 for ipsec-outgoing; Mon, 8 Sep 1997 17:09:38 -0400 (EDT) Message-Id: <3.0.3.32.19970908171145.00773740@pop3.pn.com> X-PGP-Key: X-Sender: rodney@pop3.pn.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Mon, 08 Sep 1997 17:11:45 -0400 To: ipsec@tis.com From: Rodney Thayer Subject: Slicing and dicing Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk A weak key test for 3des was listed in the 3des explicit-iv draft. It is my understanding that if bytes 1..8 yield a weak key that you toss that 'slice' and go on, so it would use bytes 9..16. >Date: Mon, 8 Sep 1997 14:04:31 -0700 >From: Karl Fox >To: ipsec@tis.com >Subject: Slicing and dicing >Reply-To: Karl Fox >Organization: Ascend Communications >Sender: owner-ipsec@ex.tis.com > >Appendix B of draft -04 of the resolution document says > > The key for DES-CBC is derived from the first eight (8) non-weak and > non-semi-weak (see Appendix A) bytes of SKEYID_e. > >If the bytes 1-8 are a weak or semi-weak key, do we then go on to >bytes 2-9 (I hope not!) or bytes 9-16? > >The same appendix later says > > The key for 3DES-CBC is the first twenty-four (24) bytes of a key > derived in the aforementioned pseudo-random function feedback method. > 3DES-CBC is an encrypt-decrypt-encrypt operation using the first, > middle, and last eight (8) bytes of the entire 3DES-CBC key. > >This means that no weak key test may be done for 3DES-CBC. Was this >the intent? >-- >Karl Fox, servant of God, employee of Ascend Communications >655 Metro Place South, Suite 370, Dublin, Ohio 43017 +1 614 760 4041 > > > From owner-ipsec Mon Sep 8 17:28:55 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA21384 for ipsec-outgoing; Mon, 8 Sep 1997 17:28:37 -0400 (EDT) Message-Id: <199709082138.OAA17029@itech.terisa.com> To: ipsec@tis.com Subject: Certification/Endpoint Identification Date: Mon, 08 Sep 1997 14:39:00 -0700 From: EKR Sender: owner-ipsec@ex.tis.com Precedence: bulk I don't want this to turn into a naming problem, but I think we're going to need to describe some canonical rules to map IPSEC DOI style names (as represented in the Identification payload) to certificates. There are two issues here: 1. Being able to identify which certificate in the certificate payloads is the end entity certificate and which are supporting certificates (i.e. other parts of the cert chain such as CAs) This is an interoperability condition. 2. Being able to verify that the certificate which the end-entity claims is his matches the identity that the end-entity claims to have. This is a security condition. I'm separating these because it's easy to imagine satisfying (1) while not satisfying (2). E.g. the first certificate payload is the end-entity. The obvious thing here is just to use the subjectAltName field. So, for instance, we might have the following text in the IPSEC DOI: The Identification payload SHOULD be checked against the subjectAltName field of the end-entity certificate. The following table describes the correspondence between Identification types and subjectAltName types ID_IPV4_ADDR ipAddress ID_FQDN dNSName ID_USER_FQDN rfc822Name ID_IPV4_ADDR_SUBNET ???? ID_IPV6_ADDR ???? ID_IPV6_ADDR_SUBNET ???? ID_IPV4_ADDR_RANGE ???? ID_IPV6_ADDR_RANGE ???? Unfortunately, there don't seem to be correspondences in PKIX Part I for wildcarding of the ipAddress name, so I'm not sure how to deal with those. But I think this is generally the right approach to follow. Mainly, though, it's important that the drafts say something concrete about this topic. -Ekr [Eric Rescorla Terisa Systems, Inc.] "Put it in the top slot." From owner-ipsec Mon Sep 8 17:39:22 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA21454 for ipsec-outgoing; Mon, 8 Sep 1997 17:39:06 -0400 (EDT) Date: Mon, 8 Sep 1997 17:47:31 -0400 (EDT) From: Dave Mason Message-Id: <199709082147.RAA07082@rubicon.rv.tis.com> To: ipsec@tis.com Subject: Re: Slicing and dicing Sender: owner-ipsec@ex.tis.com Precedence: bulk >It is my understanding that if bytes 1..8 yield a weak key that you toss >that 'slice' and go on, so it would use bytes 9..16. My take is to try bytes 2..9 if 1..8 are weak (I inherited some code that does it that way). I guess the text needs to be more specific. -dave From owner-ipsec Mon Sep 8 17:49:19 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA21519 for ipsec-outgoing; Mon, 8 Sep 1997 17:49:09 -0400 (EDT) Date: Mon, 8 Sep 1997 14:57:36 -0700 Message-Id: <199709082157.OAA15383@gump.eng.ascend.com> From: Karl Fox To: Rodney Thayer Cc: ipsec@tis.com Subject: Slicing and dicing In-Reply-To: <3.0.3.32.19970908171145.00773740@pop3.pn.com> References: <3.0.3.32.19970908171145.00773740@pop3.pn.com> Reply-To: Karl Fox Organization: Ascend Communications Sender: owner-ipsec@ex.tis.com Precedence: bulk Rodney Thayer writes: > A weak key test for 3des was listed in the 3des explicit-iv draft. Thanks for the pointer. Actually, it says 3.1 Weak Keys DES has 64 known weak keys, including so-called semi-weak keys and possibly-weak keys [Schneier95, pp 280-282]. The likelihood of picking one at random is negligible. For DES-EDE3, there is no known need to reject weak or complementation keys. Any weakness is obviated by the other keys. However, if the first two independent 64-bit keys are equal (k1 == k2), then the 3DES operation is simply the same as DES. Implementers MUST reject keys that exhibit this property. I assume that the second paragraph then *proscribes* weak key tests for automated key material derivation. So I see there's no need to test for weak keys in 3DES, but am now concerned that although we compare for k1==k2, why is it we don't test for k2==k3? And although we do these tests on the SKEYID_d keymat, we don't for SKEYID_e. Why not? Is my memory going bad, or didn't we agree that ISAKMP encryption and authentication transforms would match AH/ESP transforms? If so, wouldn't this also then apply to the derivation of keying material? > It is my understanding that if bytes 1..8 yield a weak key that you toss > that 'slice' and go on, so it would use bytes 9..16. Thank you, that's what I was hoping for. I'd like to suggest that the document be changed to say so. -- Karl Fox, servant of God, employee of Ascend Communications 655 Metro Place South, Suite 370, Dublin, Ohio 43017 +1 614 760 4041 From owner-ipsec Mon Sep 8 17:56:14 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA21575 for ipsec-outgoing; Mon, 8 Sep 1997 17:56:09 -0400 (EDT) Date: Mon, 8 Sep 1997 15:04:45 -0700 Message-Id: <199709082204.PAA15434@gump.eng.ascend.com> From: Karl Fox To: ipsec@tis.com Subject: Slicing and dicing In-Reply-To: <199709082104.OAA15064@gump.eng.ascend.com> References: <199709082104.OAA15064@gump.eng.ascend.com> Reply-To: Karl Fox Organization: Ascend Communications Sender: owner-ipsec@ex.tis.com Precedence: bulk While I'm on the subject of key material derivation, draft-ietf-ipsec-ciph-des-expiv-00.txt talks about comparisons with possibly-weak keys, while isakmp-oakley-04 only mentions weak and semi-weak keys. They should be consistent. Even better, they should both point to a single place where an appropriate technique is described. Also, draft-ietf-ipsec-ciph-des-expiv-00.txt says that [some document] describes the general mechanism to derive keying material for the ESP transform. The derivation of the key from some amount of keying material does not differ between the manually- and automatically-keyed security associations. Does anybody know when this document will be available? What else should we use to find out what to use for the ANX testing, the reference implementation? Is that what everybody else does? -- Karl Fox, servant of God, employee of Ascend Communications 655 Metro Place South, Suite 370, Dublin, Ohio 43017 +1 614 760 4041 From owner-ipsec Mon Sep 8 21:17:20 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id VAA22660 for ipsec-outgoing; Mon, 8 Sep 1997 21:14:38 -0400 (EDT) Date: Tue, 9 Sep 97 00:59:00 GMT Daylight Time From: Ran Atkinson Subject: Re: Certification/Endpoint Identification To: EKR , ipsec@tis.com X-Mailer: Chameleon ATX 6.0, Standards Based IntraNet Solutions, NetManage Inc. X-Priority: 3 (Normal) References: <199709082138.OAA17029@itech.terisa.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk --- On Mon, 08 Sep 1997 14:39:00 -0700 EKR wrote: > I don't want this to turn into a naming problem, but I think > we're going to need to describe some canonical rules to map > IPSEC DOI style names (as represented in the Identification > payload) to certificates. Please consider that not all of the identities were designed with X.509 in mind -- several of them were quite explicitly designed to work well with signed KEY records from Secure DNS. Details below. > So, for instance, we might have the following text in the > IPSEC DOI: The IPsec DOI is probably the wrong place to put it since your proposed new text (below) is very X.509-centric and the IPsec DOI should be _neutral_ with respect to which certificate/signed-key technology is used. Note also that X.509/PKIX is not yet a standards-track RFC, while Secure DNS is a Proposed Standard (RFC-2065). This seems pretty germane since we're working in the IETF. > The Identification payload SHOULD be checked against the > subjectAltName field of the end-entity certificate. The > following table describes the correspondence between > Identification types and subjectAltName types > > ID_IPV4_ADDR ipAddress OR use a KEY record bound to a DNS A record. > ID_FQDN dNSName OR use a KEY record bound to a FQDN in the DNS. > ID_USER_FQDN rfc822Name OR use a KEY record bound to a DNS MB record. > ID_IPV6_ADDR ???? OR use a KEY record bound to a DNS AAAA record. > Unfortunately, there don't seem to be correspondences in > PKIX Part I for wildcarding of the ipAddress name, so I'm > not sure how to deal with those. But I think this is generally > the right approach to follow. Mainly, though, it's important > that the drafts say something concrete about this topic. Perhaps there should be a separate (very short) draft on (bidirectionally) mapping X.509/PKIX certificates into the IPsec DOI context. That could reasonably be a PKIX WG item or an IPsec WG item. However, given that some of us plan to use Secure DNS to distribute the signed keys and don't plan to use X.509, please don't put text into the IPsec DOI that is X.509-centric. Thanks, Ran rja@inet.org From owner-ipsec Mon Sep 8 22:19:07 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id WAA22967 for ipsec-outgoing; Mon, 8 Sep 1997 22:17:42 -0400 (EDT) Message-Id: <199709090227.TAA18569@itech.terisa.com> To: Ran Atkinson cc: ipsec@tis.com Subject: Re: Certification/Endpoint Identification In-reply-to: Your message of "Tue, 09 Sep 1997 00:59:00 EST." Date: Mon, 08 Sep 1997 19:28:05 -0700 From: EKR Sender: owner-ipsec@ex.tis.com Precedence: bulk Ran, You're right, I was only thinking of X.509 when I wrote my message. Actually the scope of the problem is a lot worse than I had originally thought: draft-ietf-ipsec-isakmp-08.txt lists the following certificate types: __________Certificate_Type___________Value___ NONE 0 PKCS #7 wrapped X.509 certificate 1 PGP Certificate 2 DNS Signed Key 3 X.509 Certificate - Signature 4 X.509 Certificate - Key Exchange 5 Kerberos Tokens 6 Certificate Revocation List (CRL) 7 Authority Revocation List (ARL) 8 SPKI Certificate 9 RESERVED 10- 255 Now, we can ignore PKCS#7 certs (cause they're just a wrapper for X.509), CRLs and ARLs, but all the other certificate types (with the possible exception of SPKI certificates) do in fact bind keying material to Identity and they all have their own representations of Identity. For each of these, we need to describe how to map these to the Identification payloads listed in the DOI. This can be done either in the DOI draft or (as you suggest) in separate drafts. You write: [...snip....] > > The Identification payload SHOULD be checked against the > > subjectAltName field of the end-entity certificate. The > > following table describes the correspondence between > > Identification types and subjectAltName types > > > > ID_IPV4_ADDR ipAddress > > OR use a KEY record bound to a DNS A record. > > > ID_FQDN dNSName > OR use a KEY record bound to a FQDN in the DNS. > > > ID_USER_FQDN rfc822Name > OR use a KEY record bound to a DNS MB record. > > > ID_IPV6_ADDR ???? > OR use a KEY record bound to a DNS AAAA record. This is fine as far as it goes, but it omits all the wildcarded types, which are really my main concern: ID_IPV4_ADDR_SUBNET ???? ID_IPV6_ADDR_SUBNET ???? ID_IPV4_ADDR_RANGE ???? ID_IPV6_ADDR_RANGE ???? I suppose that we could simply list Identification<->Name mapping rules for each certificate type (loosely considering Secure DNS KEY RRs as being certificates) and prohibit use of any Identification payloads/Certificate combinations where the names couldn't be mapped (e.g. if one decided not to map the wildcarded types) but we should at least do that, I would think. -Ekr [Eric Rescorla Terisa Systems, Inc.] "Put it in the top slot." From owner-ipsec Tue Sep 9 04:36:26 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id EAA24838 for ipsec-outgoing; Tue, 9 Sep 1997 04:35:05 -0400 (EDT) Date: Tue, 9 Sep 1997 04:43:36 -0400 (EDT) From: Dave Mason Message-Id: <199709090843.EAA14539@rubicon.rv.tis.com> To: ipsec@tis.com Subject: Re: Slicing and dicing Sender: owner-ipsec@ex.tis.com Precedence: bulk >I'd suggest a clarification be added to the draft stating that bytes >9-16 should be used in the event that bytes 1-8 are weak. And that in the very unlikely event that 9-16 are also weak? The draft needs to cover this situation also, however unlikely. -dave From owner-ipsec Tue Sep 9 07:16:21 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA25743 for ipsec-outgoing; Tue, 9 Sep 1997 07:15:08 -0400 (EDT) X-Sender: smith@mailhost.sctc.com Message-Id: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 8 Sep 1997 17:26:26 -0600 To: "Theodore Y. Ts'o" From: Rick Smith Subject: Re: Vendors who are implementing IPSEC, step forward.... Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Ted, > I'm starting to get reporters who are pestering me for >interviews; one of the questions which they are asking is "which >companies are implementing IPSEC"? In the spirit of fairness, I'd >appreciate if people from those vendors who are willing to have their >names on the list of "companies who are planning to implement IPSEC", >send me e-mail. Secure Computing has two firewall products that use IPSEC: Sidewinder and the Border Firewall Server. We also arranged with FTP Software to produce a PC based IPSEC "client" that could connect to our firewalls. I don't know what the client's status is today, though. Also, I spend a third of my recently published book, "Internet Cryptography," describing IPSEC and its use for non-cryppies. Rick. smith@securecomputing.com Secure Computing Corporation "Internet Cryptography" now in bookstores http://www.visi.com/crypto/ From owner-ipsec Tue Sep 9 07:18:24 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA25804 for ipsec-outgoing; Tue, 9 Sep 1997 07:18:08 -0400 (EDT) Date: Mon, 8 Sep 1997 23:14:16 -0400 (EDT) Message-Id: <199709090314.XAA04865@carp.morningstar.com> From: Ben Rogers To: ipsec@tis.com Subject: More inadequacies in draft-ietf-ipsec-ipsec-doi-03.txt... Reply-To: ben@Ascend.COM (Ben Rogers) Sender: owner-ipsec@ex.tis.com Precedence: bulk >From draft-ietf-ipsec-isakmp-08.txt: 2.1 ISAKMP Terminology ... Security Parameter Index (SPI) An identifier for a Security Assocation, relative to some security protocol. Each security protocol has its own ``SPI-space''. A (security protocol, SPI) pair may uniquely identify an SA. The uniqueness of the SPI is implementation dependent, but could be based per system, per protocol, or other options. Depending on the DOI, additional information (e.g. host address) may be necessary to identify an SA. The DOI will also determine which SPIs (i.e. initiator's or re- sponder's) are sent during communication. Curiously the DOI does not define this. Has anyone been able to produce interoperable code without using the reference implementation? ben From owner-ipsec Tue Sep 9 10:22:04 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA27335 for ipsec-outgoing; Tue, 9 Sep 1997 10:19:17 -0400 (EDT) Message-Id: <3.0.3.32.19970909100506.007576a0@pop3.pn.com> X-PGP-Key: X-Sender: rodney@pop3.pn.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Tue, 09 Sep 1997 10:05:06 -0400 To: ipsec@tis.com From: Rodney Thayer Subject: More inadequacies in draft-ietf-ipsec-ipsec-doi-03.txt... Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk There is an implementation survey which, among other things, discusss geneology of ISAKMP implementations. Based on conversations with several vendors, I don't think everyone is using the reference implementation as a base. The site we had arranged to use for the survey is no longer available, I am working with the WG chairs to find another site. >Date: Mon, 8 Sep 1997 23:14:16 -0400 (EDT) >From: Ben Rogers >To: ipsec@tis.com >Subject: More inadequacies in draft-ietf-ipsec-ipsec-doi-03.txt... >Reply-To: ben@Ascend.COM (Ben Rogers) >Sender: owner-ipsec@ex.tis.com > > >>From draft-ietf-ipsec-isakmp-08.txt: > > 2.1 ISAKMP Terminology > > ... > > Security Parameter Index (SPI) An identifier for a Security Assocation, > relative to some security protocol. Each security protocol has its own > ``SPI-space''. A (security protocol, SPI) pair may uniquely identify an > SA. The uniqueness of the SPI is implementation dependent, but could be > based per system, per protocol, or other options. Depending on the DOI, > additional information (e.g. host address) may be necessary to identify > an SA. The DOI will also determine which SPIs (i.e. initiator's or re- > sponder's) are sent during communication. > >Curiously the DOI does not define this. > >Has anyone been able to produce interoperable code without using the >reference implementation? > > >ben > > > > > From owner-ipsec Tue Sep 9 10:22:06 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA27334 for ipsec-outgoing; Tue, 9 Sep 1997 10:19:14 -0400 (EDT) Date: Tue, 9 Sep 1997 10:28:07 -0400 (EDT) From: Dave Mason Message-Id: <199709091428.KAA23411@rubicon.rv.tis.com> To: ipsec@tis.com Subject: Second Oakley Group Sender: owner-ipsec@ex.tis.com Precedence: bulk The resolution doc (v04 section 5.7.2) defines a Second Oakley Group that MUST be supported and states that it is assigned id 2. This assigned id should be reflected in appendix A under the Attribute Assigned Numbers (it should probably be specified in the doi-v03 also). -dave From owner-ipsec Tue Sep 9 10:50:35 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA27565 for ipsec-outgoing; Tue, 9 Sep 1997 10:48:42 -0400 (EDT) To: IETF-Announce@ietf.org cc: ipsec@tis.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-simpson-photuris-16.txt Date: Tue, 09 Sep 1997 09:46:33 -0400 Message-ID: <9709090946.aa06025@ietf.org> Sender: owner-ipsec@ex.tis.com Precedence: bulk --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. Title : Photuris: Session Key Management Protocol Author(s) : P. Karn, W. Simpson Filename : draft-simpson-photuris-16.txt Pages : 74 Date : 03-Sep-97 Photuris is a session-key management protocol intended for use with the IP Security Protocols (AH and ESP). This document defines the basic protocol mechanisms. Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-simpson-photuris-16.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-simpson-photuris-16.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-simpson-photuris-16.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970903163008.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-simpson-photuris-16.txt --OtherAccess Content-Type: Message/External-body; name="draft-simpson-photuris-16.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970903163008.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec Tue Sep 9 12:12:42 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA28153 for ipsec-outgoing; Tue, 9 Sep 1997 12:11:46 -0400 (EDT) Message-Id: <3.0.3.32.19970909115849.0070d248@pop3.pn.com> X-PGP-Key: X-Sender: rodney@pop3.pn.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Tue, 09 Sep 1997 11:58:49 -0400 To: ipsec@tis.com From: Rodney Thayer Subject: Slicing and dicing Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk I believe that during the most recent round of draft writing we discovered that several people were discussing and/or documenting DES Weak keys. I suspect we failed to resolve that. I think the simples resolution I heard was to suggest that in the future all documents point at Schneier's book for the weak and semi-weak key list. >Date: Mon, 8 Sep 1997 15:04:45 -0700 >From: Karl Fox >To: ipsec@tis.com >Subject: Slicing and dicing >Reply-To: Karl Fox >Organization: Ascend Communications >Sender: owner-anx-sec@dot.netrex.net >Reply-To: anx-sec@dot.netrex.net > >While I'm on the subject of key material derivation, >draft-ietf-ipsec-ciph-des-expiv-00.txt talks about comparisons with >possibly-weak keys, while isakmp-oakley-04 only mentions weak and >semi-weak keys. They should be consistent. Even better, they should >both point to a single place where an appropriate technique is >described. > >Also, draft-ietf-ipsec-ciph-des-expiv-00.txt says that > > [some document] describes the general mechanism to derive keying > material for the ESP transform. The derivation of the key from some > amount of keying material does not differ between the manually- and > automatically-keyed security associations. > >Does anybody know when this document will be available? What else >should we use to find out what to use for the ANX testing, the >reference implementation? > >Is that what everybody else does? >-- >Karl Fox, servant of God, employee of Ascend Communications >655 Metro Place South, Suite 370, Dublin, Ohio 43017 +1 614 760 4041 > > > From owner-ipsec Tue Sep 9 14:04:46 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA28830 for ipsec-outgoing; Tue, 9 Sep 1997 14:02:49 -0400 (EDT) Date: Tue, 9 Sep 1997 11:11:29 -0700 Message-Id: <199709091811.LAA20489@gump.eng.ascend.com> From: Karl Fox To: Rodney Thayer Cc: ipsec@tis.com Subject: Slicing and dicing In-Reply-To: <3.0.3.32.19970909115849.0070d248@pop3.pn.com> References: <3.0.3.32.19970909115849.0070d248@pop3.pn.com> Reply-To: Karl Fox Organization: Ascend Communications Sender: owner-ipsec@ex.tis.com Precedence: bulk Rodney Thayer writes: > I believe that during the most recent round of draft writing we discovered > that several people were discussing and/or documenting DES Weak keys. I > suspect we failed to resolve that. I think the simples resolution I heard > was to suggest that in the future all documents point at Schneier's book > for the weak and semi-weak key list. I'd prefer that the list be included in the document (preferably in a *single* document), partly because the table of possibly-weak keys in my copy of Schneier's book (2nd edition, 1st printing) contains an error. The tables in draft-ietf-ipsec-ciph-des-derived-00.txt and draft-ietf-ipsec-ciph-des-expiv-00.txt are right. I don't know if Schneier's book has been corrected in later printings (if there are any). I've reported the error to him twice with only an automated errata list (not containing the table error) as reply, but it may be fixed now--others I've spoken to have found it, too. > >Date: Mon, 8 Sep 1997 15:04:45 -0700 > >From: Karl Fox > >To: ipsec@tis.com > >Subject: Slicing and dicing > >Reply-To: Karl Fox > >Organization: Ascend Communications > >Sender: owner-anx-sec@dot.netrex.net > >Reply-To: anx-sec@dot.netrex.net > > > >While I'm on the subject of key material derivation, > >draft-ietf-ipsec-ciph-des-expiv-00.txt talks about comparisons with > >possibly-weak keys, while isakmp-oakley-04 only mentions weak and > >semi-weak keys. They should be consistent. Even better, they should > >both point to a single place where an appropriate technique is > >described. > > > >Also, draft-ietf-ipsec-ciph-des-expiv-00.txt says that > > > > [some document] describes the general mechanism to derive keying > > material for the ESP transform. The derivation of the key from some > > amount of keying material does not differ between the manually- and > > automatically-keyed security associations. > > > >Does anybody know when this document will be available? What else > >should we use to find out what to use for the ANX testing, the > >reference implementation? > > > >Is that what everybody else does? > >-- > >Karl Fox, servant of God, employee of Ascend Communications > >655 Metro Place South, Suite 370, Dublin, Ohio 43017 +1 614 760 4041 > > > > > > -- Karl Fox, servant of God, employee of Ascend Communications 655 Metro Place South, Suite 370, Dublin, Ohio 43017 +1 614 760 4041 From owner-ipsec Tue Sep 9 16:10:30 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA29568 for ipsec-outgoing; Tue, 9 Sep 1997 16:08:49 -0400 (EDT) Date: Tue, 9 Sep 1997 16:17:34 -0400 (EDT) From: Dave Mason Message-Id: <199709092017.QAA17933@rubicon.rv.tis.com> To: ipsec@tis.com Subject: Re: Slicing and dicing Sender: owner-ipsec@ex.tis.com Precedence: bulk >I'd prefer that the list be included in the document (preferably in a >*single* document), partly because the table of possibly-weak keys in >my copy of Schneier's book (2nd edition, 1st printing) contains an >error. The tables in draft-ietf-ipsec-ciph-des-derived-00.txt and >draft-ietf-ipsec-ciph-des-expiv-00.txt are right. I don't know if >Schneier's book has been corrected in later printings (if there are >any). I've reported the error to him twice with only an automated >errata list (not containing the table error) as reply, but it may be >fixed now--others I've spoken to have found it, too. Although the authors have probably already notice this, it should be noted that the weak keys listed in Appendix A of the resolution doc, oakley-04, don't match the above docs and don't include the possibly-weak keys. -dave From owner-ipsec Wed Sep 10 07:45:51 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA04541 for ipsec-outgoing; Wed, 10 Sep 1997 07:43:49 -0400 (EDT) Mime-Version: 1.0 Date: Tue, 9 Sep 1997 19:47:47 -0700 Message-ID: <00009BC4.@aiag.org> From: kschohl@aiag.org (karl schohl) Subject: Re[2]: Vendors who are implementing IPSEC, step forward.... To: Rick Smith , "Theodore Y. Ts'o" Cc: ipsec@tis.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Sender: owner-ipsec@ex.tis.com Precedence: bulk I think that it would be in the vendors' best interest to wait until after the interoperability workshop and determine if and when a common press-release can be put together. We could decide this lon the 24th or 25th. A pre-released list worked last time, wherein a magazine stated "vendors a,b,c...z met at Lawrence Tech in Southfield, Michigan to test IPSec..." and this was just a simple paragraph, but we had only 15 vendors at the time. This list is quite extensive now, Moskowitz is receiving additions all the time, and we will miss someone so unless we are PR people, we should wait for a coordinated effort. The AiAG's Public Relations firm could help to coordinate this. Each company could then use this information to refine their own (release), if they so desired. Interop is coming, so the a lot of bull is going to fly. A reporter starts out with "who is participating" and then come the real questions and then enough for a half-baked, half-informed article. Karl E. Schohl ANX Business Manager AiAG From owner-ipsec Wed Sep 10 09:33:37 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA05276 for ipsec-outgoing; Wed, 10 Sep 1997 09:30:56 -0400 (EDT) Message-Id: <3.0.3.32.19970910093719.0076d728@pop3.pn.com> X-PGP-Key: X-Sender: rodney@pop3.pn.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Wed, 10 Sep 1997 09:37:19 -0400 To: ipsec@tis.com From: Rodney Thayer Subject: DES key list? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk ISAKMP-OAKLEY specifies DES Weak and Semi-Weak keys (the list on page 281, 5th printing, 2nd edition of Schneier. The list of keys in the draft and the list of keys in the book are the same, I believe. The ESP DES drafts listed Weak, Semi-Weak, and 'Possibly' weak keys. It's the POSSIBLY WEAK list that has an error in Schneier, even in the 5th printing. I have some questions on this. 1. where's the source of this Possibly Weak list, that people are using in telling us that Schneier is wrong? 2. Should we or should we not worry about the Possibly Weak list? ISAKMP-Oakley presumably didn't think it was necessary. Simpson (who did the DES Implicit IV draft, which pre-dates the Explicit IV draft) thought it was necessary? Could someone explain the logic of this, either way? If we don't need the Possibly Weak list, we can just make all three docs point at Schneier, "and of course you should consult the current literature for any changes in this". >Date: Tue, 9 Sep 1997 11:11:29 -0700 >From: Karl Fox >To: Rodney Thayer >Cc: ipsec@tis.com >Subject: Slicing and dicing >Reply-To: Karl Fox >Organization: Ascend Communications > >Rodney Thayer writes: >> I believe that during the most recent round of draft writing we discovered >> that several people were discussing and/or documenting DES Weak keys. I >> suspect we failed to resolve that. I think the simples resolution I heard >> was to suggest that in the future all documents point at Schneier's book >> for the weak and semi-weak key list. > >I'd prefer that the list be included in the document (preferably in a >*single* document), partly because the table of possibly-weak keys in >my copy of Schneier's book (2nd edition, 1st printing) contains an >error. The tables in draft-ietf-ipsec-ciph-des-derived-00.txt and >draft-ietf-ipsec-ciph-des-expiv-00.txt are right. I don't know if >Schneier's book has been corrected in later printings (if there are >any). I've reported the error to him twice with only an automated >errata list (not containing the table error) as reply, but it may be >fixed now--others I've spoken to have found it, too. > >> >Date: Mon, 8 Sep 1997 15:04:45 -0700 >> >From: Karl Fox >> >To: ipsec@tis.com >> >Subject: Slicing and dicing >> >Reply-To: Karl Fox >> >Organization: Ascend Communications >> >Sender: owner-anx-sec@dot.netrex.net >> >Reply-To: anx-sec@dot.netrex.net >> > >> >While I'm on the subject of key material derivation, >> >draft-ietf-ipsec-ciph-des-expiv-00.txt talks about comparisons with >> >possibly-weak keys, while isakmp-oakley-04 only mentions weak and >> >semi-weak keys. They should be consistent. Even better, they should >> >both point to a single place where an appropriate technique is >> >described. >> > >> >Also, draft-ietf-ipsec-ciph-des-expiv-00.txt says that >> > >> > [some document] describes the general mechanism to derive keying >> > material for the ESP transform. The derivation of the key from some >> > amount of keying material does not differ between the manually- and >> > automatically-keyed security associations. >> > >> >Does anybody know when this document will be available? What else >> >should we use to find out what to use for the ANX testing, the >> >reference implementation? >> > >> >Is that what everybody else does? >> >-- >> >Karl Fox, servant of God, employee of Ascend Communications >> >655 Metro Place South, Suite 370, Dublin, Ohio 43017 +1 614 760 4041 >> > >> > >> > >-- >Karl Fox, servant of God, employee of Ascend Communications >655 Metro Place South, Suite 370, Dublin, Ohio 43017 +1 614 760 4041 > > > From owner-ipsec Wed Sep 10 10:01:55 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA05542 for ipsec-outgoing; Wed, 10 Sep 1997 10:01:26 -0400 (EDT) Message-Id: <199709101414.KAA15328@istari.sandelman.ottawa.on.ca> To: ipsec@tis.com Subject: Re: DES key list? In-reply-to: Your message of "Wed, 10 Sep 1997 09:37:19 EDT." <3.0.3.32.19970910093719.0076d728@pop3.pn.com> Date: Wed, 10 Sep 1997 10:14:11 -0400 From: "Michael C. Richardson" Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Rodney" == Rodney Thayer writes: Rodney> If we don't need the Possibly Weak list, we can just make Rodney> all three docs point at Schneier, "and of course you Rodney> should consult the current literature for any changes in Rodney> this". Couldn't we just publish an informational RFC with all the possibilities listed, and point at *that*? Maybe one of the cryptographers will author it and provide a couple of paragraphs on why each set of keys is considered weak. This is clearly cryptography, not network protocol design, so let the experts argue over this document rather than doing it here. :!mcr!: | Network security programming, currently Michael Richardson | on contract with DataFellows F-Secure IPSec WWW: mcr@sandelman.ottawa.on.ca. PGP key available. -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQB1AwUBNBarL6ZpLyXYhL+BAQFppgL9EQAk8QBxIQTlBZFsQHFGr6gYgICUK6+Z 57W4yw962tnorGLchTYZVRmo1R5eaLAwmCFax7K4LWE4zuHsLWqWBi0+/9jkTdMu 0s3qKUMeW2onCrwhe92uzWIBz8vyQ9/V =o6Yh -----END PGP SIGNATURE----- From owner-ipsec Wed Sep 10 10:06:35 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA05577 for ipsec-outgoing; Wed, 10 Sep 1997 10:06:25 -0400 (EDT) Date: Wed, 10 Sep 97 14:04:47 GMT Daylight Time From: Ran Atkinson Subject: Re: DES key list? To: IPsec WG X-Mailer: Chameleon ATX 6.0, Standards Based IntraNet Solutions, NetManage Inc. X-Priority: 3 (Normal) References: <3.0.3.32.19970910093719.0076d728@pop3.pn.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk I believe the canonical DES weak/semi-weak key list is listed in one of the FIPS on DES. It might be best all around if someone could locate the correct FIPS, verify the list in the I-D against that list, and then cite the FIPS as the source of ground truth. It might be the case that someone at NIST could help with this, since NIST used to be NBS and hence is the author-of-record for those documents. All IMHO. Ran From owner-ipsec Wed Sep 10 10:32:16 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA05798 for ipsec-outgoing; Wed, 10 Sep 1997 10:30:01 -0400 (EDT) Message-Id: <199709101437.KAA09123@postal.research.att.com> To: "Michael C. Richardson" cc: ipsec@tis.com Subject: Re: DES key list? Date: Wed, 10 Sep 1997 10:37:17 -0400 From: Steven Bellovin Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Rodney" == Rodney Thayer writes: Rodney> If we don't need the Possibly Weak list, we can just make Rodney> all three docs point at Schneier, "and of course you Rodney> should consult the current literature for any changes in Rodney> this". Couldn't we just publish an informational RFC with all the possibilities listed, and point at *that*? Maybe one of the cryptographers will author it and provide a couple of paragraphs on why each set of keys is considered weak. This is clearly cryptography, not network protocol design, so let the experts argue over this document rather than doing it here. We need to cite *one* source for the data, so that each side knows what the other will do with the keying material. I confess that I'm not worried about the possibility of a weak key being chosen at random. Even if one is, so what? The problem with a weak key is that double-encryption with it yields the original plaintext. We're not double-encrypting in general; if there are two independent layers of encryption, the odds on hitting a weak key in both is about 1 in 2^108. I'll take my chances... If you want, I think Ran is right -- cite FIPS-74 (a reference I have gives that as the proper document; I haven't checked). It's at http://csrc.ncsl.nist.gov/fips/, but that document appears to be only in WordPerfect form... From owner-ipsec Wed Sep 10 12:54:06 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA06850 for ipsec-outgoing; Wed, 10 Sep 1997 12:50:27 -0400 (EDT) Date: Wed, 10 Sep 1997 13:01:02 -0400 Message-Id: <199709101701.NAA19832@brill.shiva.com> From: John Shriver To: rja@inet.org CC: ipsec@tis.com In-reply-to: (message from Ran Atkinson on Wed, 10 Sep 97 14:04:47 GMT Daylight Time) Subject: Re: DES key list? Sender: owner-ipsec@ex.tis.com Precedence: bulk http://www.itl.nist.gov/div897/pubs/fip74.htm (FIPS 74) gives the DES Weak keys and DES Semiweak Key Pairs. It does not give the DES Possibly Weak Keys. From owner-ipsec Wed Sep 10 13:59:51 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA07383 for ipsec-outgoing; Wed, 10 Sep 1997 13:58:27 -0400 (EDT) Message-Id: <3.0.32.19970910105541.009b08a0@192.43.161.2> X-Sender: jburke@192.43.161.2 X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Wed, 10 Sep 1997 10:55:42 -0700 To: ipsec@tis.com From: John Burke Subject: SPI and its length in the ISAKMP Proposal Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk A piddly, I don't know if anyone will have trouble on this point but someone might: I don't see where any specific SPI length is required in the Proposal Payload of the Phase I ISAKMP negotiation. It is prescribed that its value should be zero, in the ISAKMP draft ver-08, "2.4 Identifying Security Associations". This suggests to me that everyone is obliged to accept any SPI length in a Phase I Proposal payload; it is even arguable a SPI length of zero is acceptable here. Or an odd number, like 1, but that would be really wierd. I know that in specification of the Notify and Delete payloads it is prescribed that the SPI is the cookie pair; but I would say nothing says this applies to the Proposal case. If everyone is producing size 16 now then it would be reasonable for everyone to agree it should be so, and for that clarification to appear in a later draft. Our implementation is going to send SPI length 16 in these Proposals, but will accept all lengths. - John Burke From owner-ipsec Wed Sep 10 14:05:17 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA07451 for ipsec-outgoing; Wed, 10 Sep 1997 14:04:58 -0400 (EDT) Date: Wed, 10 Sep 1997 14:14:05 -0400 Message-Id: <199709101814.OAA23887@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: kschohl@aiag.org Cc: Rick Smith , "Theodore Y. Ts'o" , ipsec@tis.com In-Reply-To: karl schohl's message of Tue, 9 Sep 1997 19:47:47 -0700, <00009BC4.@aiag.org> Subject: Re: Re[2]: Vendors who are implementing IPSEC, step forward.... Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: owner-ipsec@ex.tis.com Precedence: bulk Date: Tue, 9 Sep 1997 19:47:47 -0700 From: kschohl@aiag.org (karl schohl) I think that it would be in the vendors' best interest to wait until after the interoperability workshop and determine if and when a common press-release can be put together. We could decide this lon the 24th or 25th. A pre-released list worked last time, wherein a magazine stated "vendors a,b,c...z met at Lawrence Tech in Southfield, Michigan to test IPSec..." and this was just a simple paragraph, but we had only 15 vendors at the time. This list is quite extensive now, Moskowitz is receiving additions all the time, and we will miss someone so unless we are PR people, we should wait for a coordinated effort. The AiAG's Public Relations firm could help to coordinate this. Each company could then use this information to refine their own (release), if they so desired. Well, I've already given the URL to one reporter who was asking questions about who was implementing. If someone would like to put together a web page with the results of the AiAG, I will happily put a link to it. I currently have a link to a web page listing the companies which have signed up for the AiAG workshop in Ottawa, since that's public information (according to Bob Moscowitz, who gave me the information). If afterwards someone else puts together a really spiffy web page that has the results of the interop testing, I'll happily link my page off to theirs instead. - Ted From owner-ipsec Wed Sep 10 14:16:23 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA07516 for ipsec-outgoing; Wed, 10 Sep 1997 14:15:59 -0400 (EDT) Message-Id: <199709101825.OAA02966@thunk.ch.apollo.hp.com> X-Authentication-Warning: thunk.ch.apollo.hp.com: sommerfeld owned process doing -bs To: Steven Bellovin Cc: "Michael C. Richardson" , ipsec@tis.com Subject: Re: DES key list? In-Reply-To: smb's message of Wed, 10 Sep 1997 10:37:17 -0400. <199709101437.KAA09123@postal.research.att.com> Date: Wed, 10 Sep 1997 14:24:59 -0400 From: Bill Sommerfeld Sender: owner-ipsec@ex.tis.com Precedence: bulk > I confess that I'm not worried about the possibility of a weak key being > chosen at random. Indeed, from a pure software engineering perspective, I'm more concerned about the reliability of code for weak key avoidance which *could*, but probably won't ever be run in production. How the heck are you going to tweak implementations such that you can actually *test* the interoperability of the recovery-from-weak-key code paths?? - Bill From owner-ipsec Wed Sep 10 14:45:48 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA07709 for ipsec-outgoing; Wed, 10 Sep 1997 14:45:14 -0400 (EDT) Date: Wed, 10 Sep 1997 14:53:23 -0400 Message-Id: <199709101853.OAA23904@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: Steven Bellovin Cc: "Michael C. Richardson" , ipsec@tis.com In-Reply-To: Steven Bellovin's message of Wed, 10 Sep 1997 10:37:17 -0400, <199709101437.KAA09123@postal.research.att.com> Subject: Re: DES key list? Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: owner-ipsec@ex.tis.com Precedence: bulk Date: Wed, 10 Sep 1997 10:37:17 -0400 From: Steven Bellovin I confess that I'm not worried about the possibility of a weak key being chosen at random. Even if one is, so what? The problem with a weak key is that double-encryption with it yields the original plaintext. We're not double-encrypting in general; if there are two independent layers of encryption, the odds on hitting a weak key in both is about 1 in 2^108. I'll take my chances... It's even better than that. Given that we're using CBC, you'd have to doubly encrypt with the same IV, and the odds that they would be the same make the probability of lossage even lower. It's really not clear this is worth us worrying about it... - Ted From owner-ipsec Wed Sep 10 14:49:34 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA07750 for ipsec-outgoing; Wed, 10 Sep 1997 14:49:29 -0400 (EDT) Date: Wed, 10 Sep 1997 14:58:22 -0400 (EDT) From: Dave Mason Message-Id: <199709101858.OAA20844@rubicon.rv.tis.com> To: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk >ISAKMP-OAKLEY specifies DES Weak and Semi-Weak keys (the list on page 281, >5th printing, 2nd edition of Schneier. The list of keys in the draft and >the list of keys in the book are the same, I believe. Note that the following weak keys are different between these two sources: resolution Schneier 2nd edition 1F1F 1F1F E0E0 E0E0 1F1F 1F1F 0E0E 0E0E (E0 vs 0E) E0E0 E0E0 1F1F 1F1F E0E0 E0E0 F1F1 F1F1 (1F vs F1) I would guess that the resolution doc (v04) is in error. >The ESP DES drafts listed Weak, Semi-Weak, and 'Possibly' weak keys. It's >the POSSIBLY WEAK list that has an error in Schneier, even in the 5th >printing. I have some questions on this. Note that the esp des drafts match Schneier 2nd edition in the weak keys but differ in one of the semi-weak keys: Schneier 2nd edition esp des drafts E01F E01F F10E F10E E0F1 E0F1 F10E F10E (2nd and 4th bytes) >From the pattern of all the other semiweak key pairs (bytes swapped within halfword compared with its key pair), I would have to say that the esp des drafts are in error. The key pair is 1FE0 1FE0 0EF1 0EF1. The esp des drafts differ with Schneier 2nd edition in the following possibly weak keys: Schneier 2nd edition esp des drafts fe01 e01f fe01 f10e fe01 e01f fe01 f1e0 (8th byte) 1ffe e001 0efe f001 1ffe e001 0efe f101 (7th byte) I would guess that Schneier is correct on the first key (from the pattern of the other possibly weak keys near it - splitting the key in half, two bytes remain the same in the first half and second half, and the remaing two bytes map E0 <-> F1 and 1F <-> 0E). I would guess that the esp des drafts are correct on the second one (the byte with F0 has incorrect parity). WARNING: I'm just guessing on the above. Can someone who would know for sure please inform this list as to what is correct. Thanks. -dave From owner-ipsec Wed Sep 10 15:09:47 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA07873 for ipsec-outgoing; Wed, 10 Sep 1997 15:08:29 -0400 (EDT) Message-Id: <3.0.3.32.19970910151112.00768198@pop3.pn.com> X-PGP-Key: X-Sender: rodney@pop3.pn.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Wed, 10 Sep 1997 15:11:12 -0400 To: "Theodore Y. Ts'o" From: Rodney Thayer Subject: Re: DES key list? Cc: ipsec@tis.com In-Reply-To: <199709101853.OAA23904@dcl.MIT.EDU> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk It's my impression that Bruce Schneier has the same opinion. I suggest we pull the text from all three places. At 02:53 PM 9/10/97 -0400, you wrote: > Date: Wed, 10 Sep 1997 10:37:17 -0400 > From: Steven Bellovin > > I confess that I'm not worried about the possibility of a weak key being > chosen at random. Even if one is, so what? The problem with a weak key > is that double-encryption with it yields the original plaintext. We're > not double-encrypting in general; if there are two independent layers of > encryption, the odds on hitting a weak key in both is about 1 in 2^108. > I'll take my chances... > >It's even better than that. Given that we're using CBC, you'd have to >doubly encrypt with the same IV, and the odds that they would be the >same make the probability of lossage even lower. > >It's really not clear this is worth us worrying about it... > > - Ted > > From owner-ipsec Wed Sep 10 15:31:36 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA08129 for ipsec-outgoing; Wed, 10 Sep 1997 15:31:29 -0400 (EDT) Date: Wed, 10 Sep 1997 15:40:43 -0400 Message-Id: <199709101940.PAA24106@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: Rodney Thayer Cc: "Theodore Y. Ts'o" , ipsec@tis.com In-Reply-To: Rodney Thayer's message of Sat, 06 Sep 1997 12:11:08 -0400, <3.0.3.32.19970906121108.006f3f00@pop3.pn.com> Subject: Re: Vendors who are implementing IPSEC, step forward.... Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: owner-ipsec@ex.tis.com Precedence: bulk Date: Sat, 06 Sep 1997 12:11:08 -0400 From: Rodney Thayer Attached is a tar file with the survey in it. If you untar this into a web site, the files reference each other. 'results.html' is the main file, I suggest we link to that. The March 1997 IPSEC Implementation results are now available off of: http://web.mit.edu/tytso/www/ipsec This page will contain random IPSEC resources that I find or make available, while we try to set up a IPSEC wg web page. - Ted From owner-ipsec Wed Sep 10 15:34:02 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA08170 for ipsec-outgoing; Wed, 10 Sep 1997 15:33:57 -0400 (EDT) Date: Wed, 10 Sep 1997 15:42:27 -0400 (EDT) From: Dave Mason Message-Id: <199709101942.PAA23228@rubicon.rv.tis.com> To: ipsec@tis.com Subject: Re: DES key list? Sender: owner-ipsec@ex.tis.com Precedence: bulk >It's my impression that Bruce Schneier has the same opinion. I suggest we >pull the text from all three places. I also vote to skip the weak key check. If I'm not mistaken, if we generate a new key every single minute, we'll only run into a "weak/semiweak/possibly weak" key about once every billion years. -dave From owner-ipsec Thu Sep 11 09:33:27 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA00353 for ipsec-outgoing; Thu, 11 Sep 1997 09:24:19 -0400 (EDT) Date: Thu, 11 Sep 1997 09:09:18 -0400 (EDT) From: Dave Mason Message-Id: <199709111309.JAA03481@rubicon.rv.tis.com> To: ipsec@tis.com Subject: Re: IPsec and Oakley test items Sender: owner-ipsec@ex.tis.com Precedence: bulk >>Do we want doi-02, or doi-03? I know the -03 isn't in the ID directories >>yet, but it was published on the mailing list some time ago, and contains >>some important clarifications. > >03. I took my list from the charter and thus missed this change. Is it possible that doi-03 can be placed in the ID directories? -dave From owner-ipsec Thu Sep 11 09:33:29 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA00336 for ipsec-outgoing; Thu, 11 Sep 1997 09:24:16 -0400 (EDT) Message-Id: <199709111323.GAA26498@dharkins-ss20> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: ben@Ascend.COM (Ben Rogers) Cc: ipsec@tis.com Subject: Re: More inadequacies in draft-ietf-ipsec-ipsec-doi-03.txt... In-Reply-To: Your message of "Mon, 08 Sep 1997 23:14:16 EDT." <199709090314.XAA04865@carp.morningstar.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 11 Sep 1997 06:23:36 -0700 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk > Has anyone been able to produce interoperable code without using the > reference implementation? Ahh, errr, well... PAY NO ATTENTION TO THE MAN BEHIND THE CURTAIN! Dan. From owner-ipsec Thu Sep 11 10:16:17 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA00921 for ipsec-outgoing; Thu, 11 Sep 1997 10:15:59 -0400 (EDT) To: IETF-Announce@ietf.org From: Internet-Drafts@ietf.org cc: ipsec@tis.com Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-mcdonald-pf-key-v2-04.txt Date: Thu, 11 Sep 1997 10:10:41 -0400 Message-ID: <9709111010.aa07973@ietf.org> Sender: owner-ipsec@ex.tis.com Precedence: bulk --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. Title : PF_KEY Key Management API, Version 2 Author(s) : D. McDonald, B. Phan, C. Metz Filename : draft-mcdonald-pf-key-v2-04.txt Pages : 67 Date : 10-Sep-97 A generic key management API that can be used not only for IP Security [Atk95a] [Atk95b] [Atk95c] but also for other network security services is presented in this document. Version 1 of this API was implemented inside 4.4-Lite BSD as part of the U. S. Naval Research Laboratory's freely distributable and usable IPv6 and IPsec implementation[AMPMC96]. It is documented here for the benefit of others who might also adopt and use the API, thus providing increased portability of key management applications (e.g. a manual keying application, an ISAKMP daemon, a GKMP daemon [HM97a,HM97b], a Photuris daemon, or a SKIP certificate discovery protocol daemon). Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-mcdonald-pf-key-v2-04.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-mcdonald-pf-key-v2-04.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-mcdonald-pf-key-v2-04.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970910160007.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-mcdonald-pf-key-v2-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-mcdonald-pf-key-v2-04.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970910160007.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec Thu Sep 11 10:32:27 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA01012 for ipsec-outgoing; Thu, 11 Sep 1997 10:31:02 -0400 (EDT) Message-Id: <199709111440.HAA26591@dharkins-ss20> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: John Burke Cc: ipsec@tis.com Subject: Re: SPI and its length in the ISAKMP Proposal In-Reply-To: Your message of "Wed, 10 Sep 1997 10:55:42 PDT." <3.0.32.19970910105541.009b08a0@192.43.161.2> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 11 Sep 1997 07:40:34 -0700 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk John, You're right there is no required SPI length for phase 1 negotiation because (as you also note) the ISAKMP SA is identified by the cookies. I send a SPI length of zero (and don't send a SPI). I also accept a SPI length of anything and skip over the passed SPI. So I guess I'd accept a SPI length of 1 in phase 1 since I really don't care. (If debugging is on I'll report that a phase 1 SPI was passed but that's about all). Since ver-08 of the draft prescribes its value to zero then I guess zero is correct. I'm not really sure where you got the idea that everyone is doing a SPI size of 16. For IPSec negotiations it's 8. If you pass me 16 bytes of SPI for phase 2 I'll reject it. Dan. > A piddly, I don't know if anyone will have trouble on this point but > someone might: > > I don't see where any specific SPI length is required in the Proposal > Payload of the Phase I ISAKMP negotiation. It is prescribed that its value > should be zero, in the ISAKMP draft ver-08, "2.4 Identifying Security > Associations". > > This suggests to me that everyone is obliged to accept any SPI length in a > Phase I Proposal payload; it is even arguable a SPI length of zero is > acceptable here. Or an odd number, like 1, but that would be really wierd. > > I know that in specification of the Notify and Delete payloads it is > prescribed that the SPI is the cookie pair; but I would say nothing says > this applies to the Proposal case. > > If everyone is producing size 16 now then it would be reasonable for > everyone to agree it should be so, and for that clarification to appear in > a later draft. > > Our implementation is going to send SPI length 16 in these Proposals, but > will accept all lengths. From owner-ipsec Thu Sep 11 16:17:12 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA01045 for ipsec-outgoing; Thu, 11 Sep 1997 16:06:41 -0400 (EDT) Message-ID: From: Greg Carter To: "'ben@Ascend.COM'" , "'Daniel Harkins'" Cc: "'ipsec@tis.com'" Subject: RE: More inadequacies in draft-ietf-ipsec-ipsec-doi-03.txt... Date: Thu, 11 Sep 1997 16:10:50 -0400 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk I am not sure at what Dan is getting at (my cube doesn't even have curtains :) ), but yes definitely. ---- Greg Carter, Entrust Technologies greg.carter@entrust.com Get FREE 128-bit FIPS-140-1 Validated Crypto for the desktop http://www.entrust.com/solo.htm >---------- >From: Daniel Harkins[SMTP:dharkins@cisco.com] >Sent: Thursday, September 11, 1997 9:23 AM >To: ben@Ascend.COM >Cc: ipsec@tis.com >Subject: Re: More inadequacies in draft-ietf-ipsec-ipsec-doi-03.txt... > >> Has anyone been able to produce interoperable code without using the >> reference implementation? > >Ahh, errr, well... PAY NO ATTENTION TO THE MAN BEHIND THE CURTAIN! > > Dan. > > From owner-ipsec Thu Sep 11 16:49:34 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA01357 for ipsec-outgoing; Thu, 11 Sep 1997 16:47:35 -0400 (EDT) Date: Thu, 11 Sep 1997 16:47:35 -0400 (EDT) Message-Id: <199709112047.QAA01357@portal.ex.tis.com> From: Ben Rogers To: ipsec@tis.com, isakmp-oakley@cisco.com Subject: Re: Ordering of payloads In-Reply-To: <199709111639.JAA26732@dharkins-ss20> References: <199709111621.MAA05631@carp.morningstar.com> <199709111639.JAA26732@dharkins-ss20> Reply-To: ben@Ascend.COM (Ben Rogers) Sender: owner-ipsec@ex.tis.com Precedence: bulk Daniel Harkins writes: > Ben, > > > Any reason we don't mandate that the SA be the first payload for > > aggressive mode exchanges? Until we parse the SA payload, we have no > > idea what to do with any of the others in that packet. It seems that we > > are making the packet needlessly difficult to parse if the SA payload > > can be anywhere in the packet. > > I can't think of a reason. Is this a suggestion? You might want to run > this by the ipsec list as well if it is. Basically I don't see a problem > mandating that the 1st payload of the 1st message of a phase 1 exchange > be a SA payload. Yes, it was intended as a suggestion. Anyone have any problems with making the mandate which Dan states above? ben From owner-ipsec Thu Sep 11 17:51:54 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA01738 for ipsec-outgoing; Thu, 11 Sep 1997 17:49:34 -0400 (EDT) Message-ID: <0171F2F8F9E5D011A4D10060B03CFB44917E@scc-server3.semaphorecom.com> From: CJ Gibson To: "'Greg Carter'" , "'ben@Ascend.COM'" , "'Daniel Harkins'" Cc: "'ipsec@tis.com'" Subject: RE: More inadequacies in draft-ietf-ipsec-ipsec-doi-03.txt... Date: Thu, 11 Sep 1997 15:05:18 -0700 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1457.3) Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk Dan, is the curtain green? -----Original Message----- From: Greg Carter [SMTP:greg.carter@entrust.com] Sent: Thursday, September 11, 1997 1:11 PM To: 'ben@Ascend.COM'; 'Daniel Harkins' Cc: 'ipsec@tis.com' Subject: RE: More inadequacies in draft-ietf-ipsec-ipsec-doi-03.txt... I am not sure at what Dan is getting at (my cube doesn't even have curtains :) ), but yes definitely. ---- Greg Carter, Entrust Technologies greg.carter@entrust.com Get FREE 128-bit FIPS-140-1 Validated Crypto for the desktop http://www.entrust.com/solo.htm >---------- >From: Daniel Harkins[SMTP:dharkins@cisco.com] >Sent: Thursday, September 11, 1997 9:23 AM >To: ben@Ascend.COM >Cc: ipsec@tis.com >Subject: Re: More inadequacies in draft-ietf-ipsec-ipsec-doi-03.txt... > >> Has anyone been able to produce interoperable code without using the >> reference implementation? > >Ahh, errr, well... PAY NO ATTENTION TO THE MAN BEHIND THE CURTAIN! > > Dan. > > From owner-ipsec Thu Sep 11 22:16:50 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id WAA03112 for ipsec-outgoing; Thu, 11 Sep 1997 22:15:36 -0400 (EDT) Date: Fri, 12 Sep 1997 05:24:59 +0300 (EET DST) Message-Id: <199709120224.FAA18901@pilari.ssh.fi> From: Tero Kivinen To: ben@Ascend.COM (Ben Rogers) Cc: ipsec@tis.com, isakmp-oakley@cisco.com Subject: Re: Ordering of payloads In-Reply-To: <199709112047.QAA01357@portal.ex.tis.com> References: <199709111621.MAA05631@carp.morningstar.com> <199709111639.JAA26732@dharkins-ss20> <199709112047.QAA01357@portal.ex.tis.com> Organization: SSH Communications Security Oy Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="iso-8859-1" X-Edit-Time: 30 min Sender: owner-ipsec@ex.tis.com Precedence: bulk Ben Rogers writes: > Daniel Harkins writes: > > > Any reason we don't mandate that the SA be the first payload for > > > aggressive mode exchanges? Until we parse the SA payload, we have no > > > idea what to do with any of the others in that packet. It seems that we > > > are making the packet needlessly difficult to parse if the SA payload > > > can be anywhere in the packet. > > I can't think of a reason. Is this a suggestion? You might want to run > > this by the ipsec list as well if it is. Basically I don't see a problem > > mandating that the 1st payload of the 1st message of a phase 1 exchange > > be a SA payload. > Yes, it was intended as a suggestion. Anyone have any problems with > making the mandate which Dan states above? I don't think it will make much difference if the SA payload first or not. If one argues that it would be easier, then one might just say that every packet must be exactly the order given in draft, because that would make things even more easy... The only difference in the first packet in the aggressive mode is that the public key encryption authentication have extra optional HASH(1) payload and the ID and Ni payloads are encrypted with public key encryption. At least my implementation always divides the packet completely to separate payloads before doing anything else, so finding the SA payload anywhere from the packet is just as easy as it would be to find it from the beginning of packet. BTW there are some problems with the public key encryption authentication in aggressive mode. Firstly there cannot be any other authentication methods in sa proposals when using public key encryption authentication method, because otherwise the responder doesn't know if the ID and Ni payloads are encrypted or not. Because the initial packets of signature and pre-shared keys have identical information, you could have initiators proposal that offers both signature and pre-shared keys authentication and then let the responder select the authentication method. The another problem is that there is no negotiated hash algorithm, before the responder sends his SA payload back and negotiates one. Unfortunately the draft says the HASH(1) payload that identifies the public key used, uses the negotiated hash algorithm. This means that the initiator have to guess a hash algorithm the responder support and use that when sending hash of the certificate used in the public key encryption authentication. If the responder doesn't support it, it just drops your negotiation and hopefully sends you ATTRIBUTES-NOT-SUPPORTED notification back, so you can retry with other hash function. If initiator adds more than one hash algorithm in its SA proposal then the responder doesn't know which of them was used to calculate the hash (the first hash algorithm from the SA proposal?). In the revised encryption method the problem is even harder, because there we need common symmetric cipher before it is negotiated. If the initiator doesn't know anything about the responder he have to try to loop all cipher and hash algorithms one by one and try each combination until the negotiation succeeds. It can only try one cipher algorithm and hash algorithm at time, because othervise it has no knowledge which one of the algorithms (cipher or hash) was unsuppored by responder. -- kivinen@iki.fi Work : +358-9-4354 3205 Magnus Enckellin kuja 9 K 19, 02610, Espoo Home : +358-9-502 1573 From owner-ipsec Fri Sep 12 02:25:29 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id CAA04212 for ipsec-outgoing; Fri, 12 Sep 1997 02:24:05 -0400 (EDT) Message-Id: Date: Thu, 11 Sep 1997 22:40:23 -0700 (PDT) From: Phil Karn To: karl@Ascend.COM CC: rodney@sabletech.com, ipsec@tis.com, karn@qualcomm.com In-reply-to: <199709091811.LAA20489@gump.eng.ascend.com> (message from Karl Fox on Tue, 9 Sep 1997 11:11:29 -0700) Subject: Re: Slicing and dicing Sender: owner-ipsec@ex.tis.com Precedence: bulk How likely are we to generate a weak key by random accident? Is it worth worrying about? Phil From owner-ipsec Fri Sep 12 05:44:26 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id FAA05419 for ipsec-outgoing; Fri, 12 Sep 1997 05:43:05 -0400 (EDT) Message-Id: <1.5.4.32.19970901212207.006961a0@cale.checkpoint.com> X-Sender: roy@cale.checkpoint.com X-Mailer: Windows Eudora Light Version 1.5.4 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 02 Sep 1997 00:22:07 +0300 To: Daniel Harkins From: Roy Shamir Subject: Re: More inadequacies in draft-ietf-ipsec-ipsec-doi-03.txt... Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk I second Greg. We've never looked at the reference implementation. Roy At 06:23 AM 9/11/97 -0700, you wrote: >> Has anyone been able to produce interoperable code without using the >> reference implementation? > >Ahh, errr, well... PAY NO ATTENTION TO THE MAN BEHIND THE CURTAIN! > > Dan. > > > From owner-ipsec Fri Sep 12 08:05:52 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA06486 for ipsec-outgoing; Fri, 12 Sep 1997 08:04:35 -0400 (EDT) Message-ID: From: Greg Carter To: "'Tero Kivinen'" Cc: "'ipsec@tis.com'" Subject: RE: Ordering of payloads Date: Fri, 12 Sep 1997 08:07:28 -0400 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi Tero, My understanding of Aggressive mode was that most of the problems you describe are actually features of that particular mode. It becomes useful in situations where there doesn't need to be any 'real' negotiation of ISKAMP SAs. For example an IT person in a corporate environment may find it desirable to have all the clients configured to use one and only one ISAKMP SA type. If they are only going to negotiate this one type (say DES/MD5/Shared Secret) use aggressive and speed up the connect time. On the original subject... I agree with Tero, given the fact you have to flip through the packet for a sanity check anyways, you have an opportunity to figure out where everything is. Added on top of that the fact that the other payloads can come in any order (but in a specific group sequence) there is no added complexity in finding the SA payload and processing it in the order you require. ISAKMP also states that some optional payloads must be accepted at any point in the exchange (not that I would ever stick anything before the SA). But specifying it must be first doesn't really bother me either :) Bye ---- Greg Carter, Entrust Technologies greg.carter@entrust.com Get FREE 128-bit FIPS-140-1 Validated Crypto for the desktop http://www.entrust.com/solo.htm >---------- >From: Tero Kivinen[SMTP:kivinen@ssh.fi] >Sent: Thursday, September 11, 1997 10:24 PM >To: ben@ascend.com >Cc: ipsec@tis.com; isakmp-oakley@cisco.com >Subject: Re: Ordering of payloads > >... >BTW there are some problems with the public key encryption >authentication in aggressive mode. Firstly there cannot be any other >authentication methods in sa proposals when using public key >encryption authentication method, because otherwise the responder >doesn't know if the ID and Ni payloads are encrypted or not. > >Because the initial packets of signature and pre-shared keys have >identical information, you could have initiators proposal that offers >both signature and pre-shared keys authentication and then let the >responder select the authentication method. > >The another problem is that there is no negotiated hash algorithm, >before the responder sends his SA payload back and negotiates one. >Unfortunately the draft says the HASH(1) payload that identifies the >public key used, uses the negotiated hash algorithm. > >This means that the initiator have to guess a hash algorithm the >responder support and use that when sending hash of the certificate >used in the public key encryption authentication. If the responder >doesn't support it, it just drops your negotiation and hopefully sends >you ATTRIBUTES-NOT-SUPPORTED notification back, so you can retry with >other hash function. > >If initiator adds more than one hash algorithm in its SA proposal then >the responder doesn't know which of them was used to calculate the >hash (the first hash algorithm from the SA proposal?). > >In the revised encryption method the problem is even harder, because >there we need common symmetric cipher before it is negotiated. If the >initiator doesn't know anything about the responder he have to try >to loop all cipher and hash algorithms one by one and try each >combination until the negotiation succeeds. > >It can only try one cipher algorithm and hash algorithm at time, >because othervise it has no knowledge which one of the algorithms >(cipher or hash) was unsuppored by responder. >-- >kivinen@iki.fi Work : +358-9-4354 3205 >Magnus Enckellin kuja 9 K 19, 02610, Espoo Home : +358-9-502 1573 > From owner-ipsec Fri Sep 12 08:40:12 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA06670 for ipsec-outgoing; Fri, 12 Sep 1997 08:40:05 -0400 (EDT) Date: Fri, 12 Sep 1997 05:48:40 -0700 Message-Id: <199709121248.FAA08785@gump.eng.ascend.com> From: Karl Fox To: Phil Karn Cc: rodney@sabletech.com, ipsec@tis.com Subject: Re: Slicing and dicing In-Reply-To: References: <199709091811.LAA20489@gump.eng.ascend.com> Reply-To: Karl Fox Organization: Ascend Communications Sender: owner-ipsec@ex.tis.com Precedence: bulk Phil Karn writes: > How likely are we to generate a weak key by random accident? Is it > worth worrying about? Probably not. I'd just like to see the documents agree. -- Karl Fox, servant of God, employee of Ascend Communications 655 Metro Place South, Suite 370, Dublin, Ohio 43017 +1 614 760 4041 From owner-ipsec Fri Sep 12 12:29:33 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA07976 for ipsec-outgoing; Fri, 12 Sep 1997 12:26:36 -0400 (EDT) Date: Fri, 12 Sep 1997 12:35:56 -0400 Message-Id: <199709121635.MAA05295@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: Phil Karn Cc: karl@Ascend.COM, rodney@sabletech.com, ipsec@tis.com, karn@qualcomm.com In-Reply-To: Phil Karn's message of Thu, 11 Sep 1997 22:40:23 -0700 (PDT), Subject: Re: Slicing and dicing Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: owner-ipsec@ex.tis.com Precedence: bulk Date: Thu, 11 Sep 1997 22:40:23 -0700 (PDT) From: Phil Karn How likely are we to generate a weak key by random accident? Is it worth worrying about? Well, there are 4 weak keys, and 16 semi-weak keys, out of possible 2**56 keys. So the probability of picking one of these weak keys is (20 * 2**-56). Now, the property of having a weak or semi-weak key K is that there is exactly one key (in the case of the weak key, itself), K', such that encrypting with K and then encrypting with K' results in the original plaintext. Given that we are using CBC mode, the random IV also must be the same. Note that this is also only a problem if we some how end up re-encrypting the encrypted packet again, such as in applications where you might be using two layers of ESP for some reason. In those cases, the probability of trouble would be (20 * 2**-56 * 2**-56 * 20**-64), or (20 * 2**-176), or 2 * 10**-52. - Ted From owner-ipsec Fri Sep 12 12:50:40 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA08109 for ipsec-outgoing; Fri, 12 Sep 1997 12:50:06 -0400 (EDT) Date: Fri, 12 Sep 97 09:56:27 PDT From: jim@mentat.com (Jim Gillogly) Message-Id: <9709121656.AA16604@mentat.com> To: karn@qualcomm.com, tytso@MIT.EDU Subject: Re: Slicing and dicing Cc: karl@Ascend.COM, rodney@sabletech.com, ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Phil Karn sez: > How likely are we to generate a weak key by random accident? Is it > worth worrying about? Ted T'so responds: ... > Note that this is also only a problem if we some how end up > re-encrypting the encrypted packet again, such as in applications where > you might be using two layers of ESP for some reason. In those cases, > the probability of trouble would be (20 * 2**-56 * 2**-56 * 20**-64), or > (20 * 2**-176), or 2 * 10**-52. Putting this in perspective, there are about pi * 10^7 seconds per year, so if everybody on earth (10^10, in round numbers) were changing keys 10^10 times per second, somebody would expose a stream once in 10^25 years. I think I can live with that. Jim Gillogly From owner-ipsec Fri Sep 12 13:21:49 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA08346 for ipsec-outgoing; Fri, 12 Sep 1997 13:21:38 -0400 (EDT) From: Cheryl Madson Message-Id: <199709121730.KAA07488@trix.cisco.com> Subject: Re: Slicing and dicing To: tytso@MIT.EDU (Theodore Y. Ts'o) Date: Fri, 12 Sep 1997 10:30:03 -0700 (PDT) Cc: karn@qualcomm.com, karl@Ascend.COM, rodney@sabletech.com, ipsec@tis.com In-Reply-To: <199709121635.MAA05295@dcl.MIT.EDU> from "Theodore Y. Ts'o" at Sep 12, 97 12:35:56 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk I'm willing to change my DES draft to remove the weak key checking altogether. I could probably add text similar to what Ted provided into the security considerations section, so later readers will know that we thought about this. I was already planning for an editorial update to happen sometime soon (I have a couple of other wordsmithing changes in the pipe). - C > > Date: Thu, 11 Sep 1997 22:40:23 -0700 (PDT) > From: Phil Karn > > How likely are we to generate a weak key by random accident? Is it > worth worrying about? > > Well, there are 4 weak keys, and 16 semi-weak keys, out of possible > 2**56 keys. So the probability of picking one of these weak keys is > (20 * 2**-56). > > Now, the property of having a weak or semi-weak key K is that there is > exactly one key (in the case of the weak key, itself), K', such that > encrypting with K and then encrypting with K' results in the original > plaintext. Given that we are using CBC mode, the random IV also must be > the same. > > Note that this is also only a problem if we some how end up > re-encrypting the encrypted packet again, such as in applications where > you might be using two layers of ESP for some reason. In those cases, > the probability of trouble would be (20 * 2**-56 * 2**-56 * 20**-64), or > (20 * 2**-176), or 2 * 10**-52. > > - Ted > > From owner-ipsec Fri Sep 12 13:35:05 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA08473 for ipsec-outgoing; Fri, 12 Sep 1997 13:34:15 -0400 (EDT) Message-Id: <199709121747.NAA26920@istari.sandelman.ottawa.on.ca> To: ipsec@tis.com Subject: Re: Slicing and dicing In-reply-to: Your message of "Fri, 12 Sep 1997 12:35:56 EDT." <199709121635.MAA05295@dcl.MIT.EDU> Date: Fri, 12 Sep 1997 13:47:35 -0400 From: "Michael C. Richardson" Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Theodore" == Theodore Y Ts'o writes: Theodore> Note that this is also only a problem if we some how end Theodore> up re-encrypting the encrypted packet again, such as in Theodore> applications where you might be using two layers of ESP Theodore> for some reason. In those cases, the probability of Theodore> trouble would be (20 * 2**-56 * 2**-56 * 20**-64), or Theodore> (20 * 2**-176), or 2 * 10**-52. Given this, I'd say forget about handling it. The world isn't just DES, though. The question about what to do with weak keys in general. Are weak keys in other algorithms equally improbable? Given the difficulty in even test code to replace the weak keys with other keys, I'd prefer to simply fail the SA, and cause ISAKMP to start over again. I think even my vic-20 can afford to do this once every (86400/300 * 365)/(2* 10**-52) years. :!mcr!: | Network security programming, currently Michael Richardson | on contract with DataFellows F-Secure IPSec WWW: mcr@sandelman.ottawa.on.ca. PGP key available. -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQB1AwUBNBmAM6ZpLyXYhL+BAQEfsAMArWAdndda2GYJ+qe4wOJfGInM/EszpzZC mjJ9PHROrHWjZGGFXZusAjPv1rZsy27LR2reN4/7F7adg4DdV7ryCJ0p9ItoxTXF Q5xmlzSASTZnnc9tbyqUe/PUeIRFwPTZ =ec8l -----END PGP SIGNATURE----- From owner-ipsec Fri Sep 12 14:19:58 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA08860 for ipsec-outgoing; Fri, 12 Sep 1997 14:19:39 -0400 (EDT) From: Dan.McDonald@Eng.Sun.Com (Dan McDonald) Message-Id: <199709121828.LAA13256@kebe.eng.sun.com> Subject: Re: Slicing and dicing To: mcr@sandelman.ottawa.on.ca (Michael C. Richardson) Date: Fri, 12 Sep 1997 11:28:35 -0700 (PDT) Cc: ipsec@tis.com In-Reply-To: <199709121747.NAA26920@istari.sandelman.ottawa.on.ca> from "Michael C. Richardson" at Sep 12, 97 01:47:35 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk > Given this, I'd say forget about handling it. Quick question, do you mean key mgmt. failing? If so, I agree, and you state the perfect reasons why below... > The world isn't just DES, though. The question about what to do with weak > keys in general. Are weak keys in other algorithms equally improbable? I dunno about other algorithms, but you can't discount that possibility. > Given the difficulty in even test code to replace the weak keys with > other keys, I'd prefer to simply fail the SA, and cause ISAKMP to start > over again. I think even my vic-20 can afford to do this once every > (86400/300 * 365)/(2* 10**-52) years. Pardon the small plug, but PF_KEY has, since its inception, and at the insistence of the many, REQUIRED to return errors when an algorithm's key is deemed weak. This means either SADB_ADD, or SADB_UPDATE will fail miserably when/if a weak key is fed down. I agree with Michael, in that the SA should fail, and ISAKMP should kick-in again. Just my $0.02. Dan From owner-ipsec Fri Sep 12 14:37:29 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA09031 for ipsec-outgoing; Fri, 12 Sep 1997 14:36:09 -0400 (EDT) Message-Id: <3.0.32.19970912114639.00905470@192.43.161.2> X-Sender: jburke@192.43.161.2 X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Fri, 12 Sep 1997 11:46:39 -0700 To: ipsec@tis.com From: John Burke Subject: RE: Ordering of payloads Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk Maybe we want to consider this a little more? Greg C. was a "real programmer" here and apparently handled payload ordering and the SA in the most robust way. Just to state clearly what this requires: 1. Sanity check: discover what payloads are present and assure no malformations. While doing this remember where payloads are, particularly the SA load. 2. Payload handling: A. If an SA Payload was present, go to its location first, decode it, select and validate, and set all relevant parameters in your SA block. B. Once you have done that, suck in all other parameters. You can go through these in any order, saving their values in your SA (BUT NOTE that for ID's in Quick Mode their order of arrival must be used to separate IDi, IDr). C. Finally take the actions required for the message, e.g. key derivations and formation of a response. Now I wonder how many of the existing implementations support order-free handling of the SA load as I describe above? Sure if the early ISAKMP specs had said explicitly that payloads can appear in any order maybe everyone would have been scared into doing it; but did they? The point here is, do we agree at this time that we should require everyone to do the handling I describe? I.E. find the SA first and do it before passing over the other loads? We actually did not implement this way (nor as I remember did the reference implementation for ISAKMP v-06). But where do others stand, A. for the upcoming interoperation tests and B. later for the final ISAKMP draft? I see nothing wrong with the SA load being singled out as having to be (not "first" but) ordered per the diagrams, while other loads can be in any order; I feel the procedure described above is enough to point out why it is different. Certain Hash loads are already singled out in this manner. The only kind of argument I could see is, if someone has implementation reasons why it would help to be able to put SA in a different position. This is not to make a big deal of this, just to ask people to think before acting, and to mention what we would like. We'll do whatever people agree on. - John Burke At 08:07 AM 9/12/97 -0400, Greg Carter wrote: >Hi Tero, [ ... ] >On the original subject... >I agree with Tero, given the fact you have to flip through the packet >for a sanity check anyways, you have an opportunity to figure out where >everything is. Added on top of that the fact that the other payloads >can come in any order (but in a specific group sequence) there is no >added complexity in finding the SA payload and processing it in the >order you require. ISAKMP also states that some optional payloads must >be accepted at any point in the exchange (not that I would ever stick >anything before the SA). > >But specifying it must be first doesn't really bother me either :) > >Bye >---- >Greg Carter, Entrust Technologies >greg.carter@entrust.com >Get FREE 128-bit FIPS-140-1 Validated Crypto for the desktop >http://www.entrust.com/solo.htm Tero Kivinen wrote: > I don't think it will make much difference if the SA payload first or > not. If one argues that it would be easier, then one might just say > that every packet must be exactly the order given in draft, because > that would make things even more easy... From owner-ipsec Fri Sep 12 15:13:27 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA09348 for ipsec-outgoing; Fri, 12 Sep 1997 15:13:15 -0400 (EDT) From: Cheryl Madson Message-Id: <199709121921.MAA12951@trix.cisco.com> Subject: Re: Slicing and dicing To: Dan.McDonald@Eng.Sun.Com (Dan McDonald) Date: Fri, 12 Sep 1997 12:21:56 -0700 (PDT) Cc: mcr@sandelman.ottawa.on.ca, ipsec@tis.com In-Reply-To: <199709121828.LAA13256@kebe.eng.sun.com> from "Dan McDonald" at Sep 12, 97 11:28:35 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk We've managed to come full circle. The initial proposal was to fail the SA and kick ISAKMP to establish a new one. Then various re-hashing strategies came about, so we woudn't have to take on the overhead of asking for a new SA. Then it was taking the next "hunk" of keymat (either change your pointer offset by one byte or 8 bytes and try again). Now back to failing the SA. I also didn't catch *what* would be the definitive reference for listing weak/semi-weak/possibly-weak keys, since some folks claim that Schneier is in error. Saying that we MUST check and reject weak keys only makes sense if we all use the same list. If said weak key list were available in reasonably-obtainable documentation, I could be reconvinced to keep the weak key check. I did interpret the recent comments to be along the line of "even worrying about using a weak key for DES isn't worth it, given the varying IVs". Still, I do agree that a general strategy should be developed to handle such a case, so that future cipher writers won't have to invent this. My own druthers in that case would be to simply kill the SA and ask for a new one. Why? Putting on my writer hat again: it's behavior that can be applied regardless of the algorithm in question. We can simply state in some general document that this is what should be done. [I wasn't excited about the "simply move one byte over and try again" approach, as it ends up being fairly algorithm-dependent, and would require lots of explanation in both the cipher document and any "general" document. Step back and envision writing the next cipher draft which had weak key checks: you'd get to analyze what the "correct" offset to move over would be.] So, (1) we should develop a general strategy which would be applicable to any algorithm with weak key checks in the context of AH/ESP, (2) we should decide if we even care in the case of DES, and (3) if so, *what* is the definitive list of weak keys. But, let's *decide* and be done with it. - C > > > Given this, I'd say forget about handling it. > > Quick question, do you mean key mgmt. failing? If so, I agree, and you state > the perfect reasons why below... > > > The world isn't just DES, though. The question about what to do with weak > > keys in general. Are weak keys in other algorithms equally improbable? > > I dunno about other algorithms, but you can't discount that possibility. > > > Given the difficulty in even test code to replace the weak keys with > > other keys, I'd prefer to simply fail the SA, and cause ISAKMP to start > > over again. I think even my vic-20 can afford to do this once every > > (86400/300 * 365)/(2* 10**-52) years. > > Pardon the small plug, but PF_KEY has, since its inception, and at the > insistence of the many, REQUIRED to return errors when an algorithm's key is > deemed weak. This means either SADB_ADD, or SADB_UPDATE will fail miserably > when/if a weak key is fed down. > > I agree with Michael, in that the SA should fail, and ISAKMP should kick-in > again. > > Just my $0.02. > > Dan > From owner-ipsec Fri Sep 12 15:25:55 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA09490 for ipsec-outgoing; Fri, 12 Sep 1997 15:25:40 -0400 (EDT) Message-Id: <199709121939.PAA27376@istari.sandelman.ottawa.on.ca> To: ipsec@tis.com Subject: Weak DES keys In-reply-to: Your message of "Fri, 12 Sep 1997 11:28:35 PDT." <199709121828.LAA13256@kebe.eng.sun.com> Date: Fri, 12 Sep 1997 15:39:04 -0400 From: "Michael C. Richardson" Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Dan" == Dan McDonald writes: >> Given this, I'd say forget about handling it. Dan> Quick question, do you mean key mgmt. failing? If so, I Dan> agree, and you state the perfect reasons why below... There are, I think, two places that we use a DES key. In the ISAKMP SA, and in the ESP key. (Would we care about weak keys if using a DES based MAC?) >> The world isn't just DES, though. The question about what to do >> with weak keys in general. Are weak keys in other algorithms >> equally improbable? Dan> I dunno about other algorithms, but you can't discount that Dan> possibility. If we are just talking about DES for the ISAKMP SA, then I'd say don't even check for weak keys. Dan> Pardon the small plug, but PF_KEY has, since its inception, Dan> and at the insistence of the many, REQUIRED to return errors Dan> when an algorithm's key is deemed weak. This means either Dan> SADB_ADD, or SADB_UPDATE will fail miserably when/if a weak Dan> key is fed down. Plug appropriate. If we return fail, then I'd say that we just pretend we never did anything and try again. That works, is algorithm independant, and removes all weak key checks from the key manager. We are, btw, implementing it, but since at least a couple versions of our engine is user space based, we are pushing PF_KEY packets through Unix domain stream sockets, or NT named pipes, or Mac i-don't-know-but-somebody-does. I haven't read your latest draft to see if that mode of operation was documented. :!mcr!: | Network security programming, currently Michael Richardson | on contract with DataFellows F-Secure IPSec WWW: mcr@sandelman.ottawa.on.ca. PGP key available. -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQB1AwUBNBmaOaZpLyXYhL+BAQHP+AL/VqYnKgYRSiUnThJjsLe2E1J38rm+at+h BoL/u2GLyydKzB+0saQ0V50ceEhtqFBTo2xwR4NhzpT5HqE03BT6Ov5fq2/Ov2Ye h/rBUlogBFWW1Kp84WnUWyU3AnecCAOH =aYw+ -----END PGP SIGNATURE----- From owner-ipsec Fri Sep 12 15:28:34 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA09509 for ipsec-outgoing; Fri, 12 Sep 1997 15:28:09 -0400 (EDT) Message-Id: <199709121937.MAA28053@dharkins-ss20> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: ben@Ascend.COM (Ben Rogers) Cc: Roy Shamir , ipsec@tis.com Subject: Re: More inadequacies in draft-ietf-ipsec-ipsec-doi-03.txt... In-Reply-To: Your message of "Fri, 12 Sep 1997 15:24:50 EDT." <199709121924.PAA28356@carp.morningstar.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 12 Sep 1997 12:37:41 -0700 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk We? Is that the royal, the medical, or the law enforcement "we"? If you have any constructive suggestions then out with them. Point out the self-contradictions, or how you view it as inadequate, suggest replacement text and then "we" can get these drafts out. I'm all in favor of pouring the concrete. Sooner the better. Dan. > Well, looks like I'll be joining the minority in doing so... > > What I really _meant_ to ask is whether anyone was able to make an > implementation without assistance apart from the drafts (reference > implementation was the first thought -- mailing list is the second). > And, its not really a valid question, because I'm almost certain that > the answer is going to be 'no'. If we're trying to get these drafts > ready in any reasonable amount of time, something really needs to be > done now to eliminate the inadequacies and self-contradictions within > them. From owner-ipsec Fri Sep 12 15:57:23 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA09708 for ipsec-outgoing; Fri, 12 Sep 1997 15:55:22 -0400 (EDT) Date: Fri, 12 Sep 1997 13:03:32 -0700 Message-Id: <199709122003.NAA11338@gump.eng.ascend.com> From: Karl Fox To: Cheryl Madson Cc: Dan.McDonald@Eng.Sun.Com (Dan McDonald), mcr@sandelman.ottawa.on.ca, ipsec@tis.com Subject: Re: Slicing and dicing In-Reply-To: <199709121921.MAA12951@trix.cisco.com> References: <199709121828.LAA13256@kebe.eng.sun.com> <199709121921.MAA12951@trix.cisco.com> Reply-To: Karl Fox Organization: Ascend Communications Sender: owner-ipsec@ex.tis.com Precedence: bulk Cheryl Madson writes: > I also didn't catch *what* would be the definitive reference > for listing weak/semi-weak/possibly-weak keys, since some folks > claim that Schneier is in error. Summarizing the statements made to this list (I'll not comment on whether or not that might be authoritative), Schneier is correct in every entry except the one with an "F0" byte, which simply has the wrong parity. -- Karl Fox, servant of God, employee of Ascend Communications 655 Metro Place South, Suite 370, Dublin, Ohio 43017 +1 614 760 4041 From owner-ipsec Fri Sep 12 15:58:58 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA09721 for ipsec-outgoing; Fri, 12 Sep 1997 15:57:09 -0400 (EDT) Date: Fri, 12 Sep 1997 15:24:50 -0400 (EDT) Message-Id: <199709121924.PAA28356@carp.morningstar.com> From: Ben Rogers To: Roy Shamir Cc: Daniel Harkins , ipsec@tis.com Subject: Re: More inadequacies in draft-ietf-ipsec-ipsec-doi-03.txt... In-Reply-To: <1.5.4.32.19970901212207.006961a0@cale.checkpoint.com> References: <1.5.4.32.19970901212207.006961a0@cale.checkpoint.com> Reply-To: ben@Ascend.COM (Ben Rogers) Sender: owner-ipsec@ex.tis.com Precedence: bulk Well, looks like I'll be joining the minority in doing so... What I really _meant_ to ask is whether anyone was able to make an implementation without assistance apart from the drafts (reference implementation was the first thought -- mailing list is the second). And, its not really a valid question, because I'm almost certain that the answer is going to be 'no'. If we're trying to get these drafts ready in any reasonable amount of time, something really needs to be done now to eliminate the inadequacies and self-contradictions within them. ben Roy Shamir writes: > I second Greg. We've never looked at the reference implementation. > > Roy > > At 06:23 AM 9/11/97 -0700, you wrote: > >> Has anyone been able to produce interoperable code without using the > >> reference implementation? > > > >Ahh, errr, well... PAY NO ATTENTION TO THE MAN BEHIND THE CURTAIN! > > > > Dan. > > > > > > > From owner-ipsec Fri Sep 12 15:59:03 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA09745 for ipsec-outgoing; Fri, 12 Sep 1997 15:57:39 -0400 (EDT) Date: Fri, 12 Sep 1997 15:46:13 -0400 (EDT) Message-Id: <199709121946.PAA02588@carp.morningstar.com> From: Ben Rogers To: John Burke Cc: ipsec@tis.com Subject: RE: Ordering of payloads In-Reply-To: <3.0.32.19970912114639.00905470@192.43.161.2> References: <3.0.32.19970912114639.00905470@192.43.161.2> Reply-To: ben@Ascend.COM (Ben Rogers) Sender: owner-ipsec@ex.tis.com Precedence: bulk John Burke writes: > The point here is, do we agree at this time that we should require everyone > to do the handling I describe? I.E. find the SA first and do it before > passing over the other loads? We actually did not implement this way (nor > as I remember did the reference implementation for ISAKMP v-06). But where > do others stand, A. for the upcoming interoperation tests and B. later for > the final ISAKMP draft? 'twould be nice to have all the code space in the world to work in... Some of us are extremely restricted as to how much code space we are allowed to use. (If I remember the numbers right, on some of our boxes, the entire router load needs to fit into less space than Entrust's ISAKMP implementation takes.) So, anything that helps us to reduce the amount of completely unnecessary processing would be really helpful. I'm trying to get my brain around the reason it is helpful to allow payloads to be in any order, but I am fairly certain we don't lose any functionality by requiring that the SA payload in phase I exchanges be before any other payloads whose interpretation depend on our SA negotiation. I'm wondering if the WG hasn't been overcome by a bad case of creeping featuritis... :) ben From owner-ipsec Fri Sep 12 16:00:33 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA09776 for ipsec-outgoing; Fri, 12 Sep 1997 15:59:09 -0400 (EDT) Date: Fri, 12 Sep 1997 13:07:57 -0700 Message-Id: <199709122007.NAA11363@gump.eng.ascend.com> From: Karl Fox To: "Michael C. Richardson" Cc: ipsec@tis.com Subject: Weak DES keys In-Reply-To: <199709121939.PAA27376@istari.sandelman.ottawa.on.ca> References: <199709121828.LAA13256@kebe.eng.sun.com> <199709121939.PAA27376@istari.sandelman.ottawa.on.ca> Reply-To: Karl Fox Organization: Ascend Communications Sender: owner-ipsec@ex.tis.com Precedence: bulk Michael C. Richardson writes: > If we return fail, then I'd say that we just > pretend we never did anything and try again. That works, is algorithm > independant, and removes all weak key checks from the key manager. Another nice thing about this approach is that not only is it hard to get wrong, even those who do get it wrong will still interoperate. -- Karl Fox, servant of God, employee of Ascend Communications 655 Metro Place South, Suite 370, Dublin, Ohio 43017 +1 614 760 4041 From owner-ipsec Fri Sep 12 16:01:39 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA09787 for ipsec-outgoing; Fri, 12 Sep 1997 16:00:10 -0400 (EDT) Date: Fri, 12 Sep 1997 16:06:20 -0400 (EDT) Message-Id: <199709122006.QAA02651@carp.morningstar.com> From: Ben Rogers To: isakmp-oakley@cisco.com, ipsec@tis.com Subject: Encryption + expansion of ISAKMP packets/payloads Reply-To: ben@Ascend.COM (Ben Rogers) Sender: owner-ipsec@ex.tis.com Precedence: bulk draft-ietf-ipsec-isakmp-08.txt (3.1) states: o Length (4 octets) - Length of total message (header + payloads) in octets. Encryption can expand the size of an ISAKMP message. This issue is addressed in [IPDOI] and [IO-Res]. As far as I can tell, this is not addressed in the DOI or resolution documents. Moreover, why isn't it addressed in the ISAKMP document, where it seems like it belongs? ben From owner-ipsec Fri Sep 12 16:02:35 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA09815 for ipsec-outgoing; Fri, 12 Sep 1997 16:01:11 -0400 (EDT) From: Cheryl Madson Message-Id: <199709122010.NAA14943@trix.cisco.com> Subject: Can the drafts which missed the Munich cutoff get reposted? To: ipsec@tis.com Date: Fri, 12 Sep 1997 13:10:31 -0700 (PDT) Cc: cmadson@cisco.com (Cheryl Madson) X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk It's almost been a month since the Munich meeting, and the drafts still aren't in the I-D directory. [I've heard that if a draft misses the cutoff, that it needs to be resubmitted to Cynthia after the meeting.] Trying to reconstruct the list in my head the list of drafts I think are missing: doi-03 arch-01 ? Bob and Naganand's VPN draft I thought there were more, but I can't recall the others (I think Rodney may have a longer list?). I can't tell other people to look at drafts that aren't posted anywhere... Thx - C From owner-ipsec Fri Sep 12 16:22:55 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA09928 for ipsec-outgoing; Fri, 12 Sep 1997 16:18:40 -0400 (EDT) Message-ID: From: Greg Carter To: "'Michael C. Richardson'" Cc: "'ipsec@tis.com'" Subject: weak keys was: RE: Slicing and dicing Date: Fri, 12 Sep 1997 16:19:42 -0400 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk > The world isn't just DES, though. The question about what to do with >weak keys in general. Are weak keys in other algorithms equally >improbable? CAST128 has no known weak keys. ---- Greg Carter, Entrust Technologies greg.carter@entrust.com Get FREE FIPS-140-1 Validated Crypto for the desktop http://www.entrust.com/solo.htm > From owner-ipsec Fri Sep 12 16:25:17 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA09987 for ipsec-outgoing; Fri, 12 Sep 1997 16:23:11 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <199709121921.MAA12951@trix.cisco.com> References: <199709121828.LAA13256@kebe.eng.sun.com> from "Dan McDonald" at Sep 12, 97 11:28:35 am Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 12 Sep 1997 16:31:27 -0400 To: Cheryl Madson From: Stephen Kent Subject: Re: Slicing and dicing Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Cheryl, I have mixed feelings about this issue. Some weeks ago I observed in an e-mail exchange with Ted that the issue of weak, semi-weak, etc. keys in DES seemed overblown to me, in the context of CBC mode. Ted did an excellent job of providing a quantitative analysis that makes the point better than my qualitative discussion with him. However, the analysis is algorithm and mode dependent. That suggests that ISAKMP ought to include a generic facility for a symmetric algorithm to reject candidate keying material, for instances where this may be a problem. That said, I agree with your observation that moving on to another chunk of the key bits is probably not a good idea, and just giving up and trying a new exchange seems preferable, especially since any useful algorithm will probably have a very, very small likelihood of rejecting keys for whatever reason. That defers the question of what to do for DES in CBC mode to the algorithm document itself. Based on the current discussion, it looks like people are willing to just punt on this case, but I would likle to see a requirement in ISAKMP to support the generic rejection facility. Is it reasonable to provide an error indication to the other end indicating the reason for the rejection, just in case implementations don't agree on the rejection (or at least for audit trail purposes)? Steve From owner-ipsec Fri Sep 12 16:54:49 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA10208 for ipsec-outgoing; Fri, 12 Sep 1997 16:52:42 -0400 (EDT) Message-Id: <199709122101.OAA28163@dharkins-ss20> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: ben@Ascend.COM (Ben Rogers) Cc: isakmp-oakley@cisco.com, ipsec@tis.com Subject: Re: Encryption + expansion of ISAKMP packets/payloads In-Reply-To: Your message of "Fri, 12 Sep 1997 16:06:20 EDT." <199709122006.QAA02651@carp.morningstar.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 12 Sep 1997 14:01:20 -0700 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk Appendix B of ISAKMP/Oakley. Paragraphs beginning "In phase...." > draft-ietf-ipsec-isakmp-08.txt (3.1) states: > > o Length (4 octets) - Length of total message (header + payloads) in > octets. Encryption can expand the size of an ISAKMP message. This > issue is addressed in [IPDOI] and [IO-Res]. > > As far as I can tell, this is not addressed in the DOI or resolution > documents. Moreover, why isn't it addressed in the ISAKMP document, > where it seems like it belongs? From owner-ipsec Fri Sep 12 17:21:37 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA10381 for ipsec-outgoing; Fri, 12 Sep 1997 17:19:43 -0400 (EDT) Date: Fri, 12 Sep 1997 17:28:18 -0400 Message-Id: <199709122128.RAA05863@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: Stephen Kent Cc: Cheryl Madson , ipsec@tis.com In-Reply-To: Stephen Kent's message of Fri, 12 Sep 1997 16:31:27 -0400, Subject: Re: Slicing and dicing Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: owner-ipsec@ex.tis.com Precedence: bulk I should I have acknowledged that it was Steve that pointed out to me that the issue of weak and semi-weak keys really wasn't a big issue in DES-CBC; my apologies for not pointing this out. I agree with Steve's suggestion that ISAKMP have a generic facility for rejecting keying material if it is deemed to be insecure for some reason. It would seem to me that this would simply be a matter of defining a new ISAKMP Notify Message Error Type: WEAK-KEY-REJECTED 27 ... and then adding some text in the various encryption algorithm documents stating that under some circumstances weak keys need to be rejected using this ISAKMP error. Given that weak keys are algorithm-specific, it would seem that this text would have to go in the encryption algorithm documents. Would this satisfy folks? BTW, I'd suggest not including the weak and semi-weak keys, and I'd suggest NOT referencing Schneier; instead, I'd suggest referencing the original FIPS documents, since that's much more authoratative, and they *are* easily available on the web. - Ted From owner-ipsec Fri Sep 12 18:38:02 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA10794 for ipsec-outgoing; Fri, 12 Sep 1997 18:35:42 -0400 (EDT) Message-ID: From: Greg Carter To: "'John Burke'" , "'ben@Ascend.COM'" Cc: "'ipsec@tis.com'" Subject: RE: Ordering of payloads Date: Fri, 12 Sep 1997 18:38:57 -0400 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi Ben, To be fair, our ISAKMP implementation also includes a full LDAP client, full crypto kernel inc PKCS#11, healthy ASN lib, Cert lib, PKIX client etc. etc.. The point being its not just ISAKMP, in fact my ISAKMP has little impact on the overall size of the lib. It hasn't been tuned for low mem/virtual memoryless systems. My liberal coding practices aside... Also the payload order code isn't useless, if you want to handle optional payloads which can arrive anywhere then like it or not you are going to have to remember payload positions, otherwise your logic for processing hdr->nextpayload is going to be fun. I tried to do it the simple way and hope to god everybody else sent me payloads in a reasonable order. But the code got wacky trying to handle optional payloads. Maybe you will have better luck. Again I have no problem with saying SA must be first. I was trying to point out the consequences if your code can not handle payloads arriving in order other than those shown in ISAKMP/Oakley and the effect optional payloads will have on those diagrams. Bye. ---- Greg "Code Bloat" Carter, Entrust Technologies greg.carter@entrust.com Get FREE FIPS-140-1 Validated Crypto for the desktop http://www.entrust.com/solo.htm >---------- >From: Ben Rogers[SMTP:ben@Ascend.COM] >Sent: Friday, September 12, 1997 3:46 PM >To: John Burke >Cc: ipsec@tis.com >Subject: RE: Ordering of payloads > >John Burke writes: > >> The point here is, do we agree at this time that we should require everyone >> to do the handling I describe? I.E. find the SA first and do it before >> passing over the other loads? We actually did not implement this way (nor >> as I remember did the reference implementation for ISAKMP v-06). But where >> do others stand, A. for the upcoming interoperation tests and B. later for >> the final ISAKMP draft? > >'twould be nice to have all the code space in the world to work in... > >Some of us are extremely restricted as to how much code space we are >allowed to use. (If I remember the numbers right, on some of our boxes, >the entire router load needs to fit into less space than Entrust's >ISAKMP implementation takes.) So, anything that helps us to reduce the >amount of completely unnecessary processing would be really helpful. > >I'm trying to get my brain around the reason it is helpful to allow >payloads to be in any order, but I am fairly certain we don't lose any >functionality by requiring that the SA payload in phase I exchanges be >before any other payloads whose interpretation depend on our SA >negotiation. > >I'm wondering if the WG hasn't been overcome by a bad case of creeping >featuritis... :) > > >ben > > > > From owner-ipsec Fri Sep 12 18:42:04 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA10827 for ipsec-outgoing; Fri, 12 Sep 1997 18:40:40 -0400 (EDT) Message-Id: <199709122250.PAA28343@dharkins-ss20> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: Stephen Kent Cc: Cheryl Madson , ipsec@tis.com Subject: Re: Slicing and dicing In-Reply-To: Your message of "Fri, 12 Sep 1997 16:31:27 EDT." Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 12 Sep 1997 15:50:31 -0700 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk Steve, If a negotiated algorithm has a weak key and the check is not done then there will be no rejection and hence no need for ISAKMP to support this sort of notification. If the check is done then both sides will arrive at the same conclusion and throw the thing away. Again, no need for such a notification. If we decide to make things really ugly and allow a side to just decide to do a weak key check (did someone say "replay"?) then it can use a DELETE message to inform the other party that it didn't really like that SA and not to use it. (This can be used for other generic and probably more likely situations such as a malloc failing that results in the inability of KM to add the SA). Hence, there is no need for this. Of course, ISAKMP is sufficiently general that you can do this sort of thing in your implementation by using a private use notify number. That's the whole point. It is possible, though, to add a new notify type and it's even possible to add a new negotiable attribute to say whether you do weak key checks and also to add another payload in which you can specify the weak keys you check (with an algorithm field and a number of keys field). That way each side will have all the information on hand in case a weak key is found. But that is featureitis, a form of protocol cancer. This whole discussion is evident of the problem of the IPSec WG. A question is raised about confusing language in a draft-- do you check bytes 1-8 or 8-15 if bytes 0-7 are weak-- which then morphs into a discussion about whether a popular book is wrong which morphs into statistical analysis of how often weak keys are found which morphs into adding another feature into a protocol! We should all be ashamed. (And that's not neither the royal, medical, nor law enfocement "we". I'm taking a heaping helping of blame). Dan. > That defers the question of what to do for DES in CBC mode to the > algorithm document itself. Based on the current discussion, it looks like > people are willing to just punt on this case, but I would likle to see a > requirement in ISAKMP to support the generic rejection facility. Is it > reasonable to provide an error indication to the other end indicating the > reason for the rejection, just in case implementations don't agree on the > rejection (or at least for audit trail purposes)? From owner-ipsec Fri Sep 12 18:59:38 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA10935 for ipsec-outgoing; Fri, 12 Sep 1997 18:58:10 -0400 (EDT) Message-Id: <199709122307.QAA18748@pita.cisco.com> To: Cheryl Madson cc: ipsec@tis.com Subject: Re: Can the drafts which missed the Munich cutoff get reposted? In-reply-to: Your message of "Fri, 12 Sep 1997 13:10:31 PDT." <199709122010.NAA14943@trix.cisco.com> Date: Fri, 12 Sep 1997 16:07:54 -0700 From: Derrell Piper Sender: owner-ipsec@ex.tis.com Precedence: bulk Yup, the DOI needs to be resubmitted. I will do so next week. There were a couple of changes from Munich that I wanted to incorporate, but I haven't had time since the meeting. Sad, but true. Derrell From owner-ipsec Fri Sep 12 20:59:55 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id UAA11449 for ipsec-outgoing; Fri, 12 Sep 1997 20:57:41 -0400 (EDT) Date: Sat, 13 Sep 97 00:55:35 GMT Daylight Time From: Ran Atkinson Subject: Re: Slicing and dicing To: ipsec@tis.com X-Mailer: Chameleon ATX 6.0, Standards Based IntraNet Solutions, NetManage Inc. X-Priority: 3 (Normal) References: <199709121921.MAA12951@trix.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk I'm with Dan and Cheryl (and sundry others). An implementation should check for weak/semi-weak keys. If it encounters a problem, just kill the SA and get a new one. This is nicely general for all algorithms. Ran rja@inet.org From owner-ipsec Mon Sep 15 07:58:00 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA25565 for ipsec-outgoing; Mon, 15 Sep 1997 07:30:11 -0400 (EDT) Date: Mon, 15 Sep 1997 02:41:43 -0400 (EDT) Message-Id: <199709150641.CAA05540@carp.morningstar.com> From: Ben Rogers To: ipsec@tis.com, isakmp-oakley@cisco.com Subject: Which comes first? Reply-To: ben@Ascend.COM (Ben Rogers) Sender: owner-ipsec@ex.tis.com Precedence: bulk When I negotiate an ESP SA with DES encryption and an MD5 HMAC, I obviously need 64 + 128 = 196 bits of keying material from Oakley. I can't seem to find a reference as to which 64 bits are used for the DES key and which for the MD5 key. Can anyone give me a pointer? Thanks, ben From owner-ipsec Mon Sep 15 09:54:44 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA26653 for ipsec-outgoing; Mon, 15 Sep 1997 09:45:12 -0400 (EDT) Message-ID: From: Roy Pereira To: "'ben@ascend.com'" , "'ipsec@tis.com'" , "'isakmp-oakley@cisco.com'" Subject: RE: Which comes first? Date: Mon, 15 Sep 1997 10:12:47 -0400 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk The cipher key alsways gets the first number of bits, where represents the number of bits for its key. This is stated in other ESP cipher algorithm documents, but it also should be stated in the main ESP document as well. On Monday, September 15, 1997 2:42 AM, Ben Rogers [SMTP:ben@ascend.com] wrote: > > When I negotiate an ESP SA with DES encryption and an MD5 HMAC, I > obviously need 64 + 128 = 196 bits of keying material from Oakley. I > can't seem to find a reference as to which 64 bits are used for the DES > key and which for the MD5 key. > > Can anyone give me a pointer? > > > Thanks, > > ben > From owner-ipsec Mon Sep 15 17:24:56 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA29691 for ipsec-outgoing; Mon, 15 Sep 1997 17:23:21 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <199709122010.NAA14943@trix.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 15 Sep 1997 17:27:46 -0400 To: Cheryl Madson From: Stephen Kent Subject: Re: Can the drafts which missed the Munich cutoff get reposted? Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Cheryl, The arch doc was distribuetd to the list on 7/30, but it did not get posted to the I-D directory. We have held off posting that version, pedning changes discussed at the Munich meeting. I'll be gald to send a copy of the 7/30 version to anyone who requires it, but it is under going significant changes. Steve From owner-ipsec Tue Sep 16 03:40:13 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id DAA02536 for ipsec-outgoing; Tue, 16 Sep 1997 03:38:27 -0400 (EDT) Message-Id: <199709160752.DAA25000@relay.hq.tis.com> Date: Tue, 16 Sep 97 3:39:05 EDT From: Karen Seo To: rpereira@TimeStep.com, ben@Ascend.COM, ipsec@tis.com cc: kseo@bbn.com Subject: Re: Which comes first? Sender: owner-ipsec@ex.tis.com Precedence: bulk Folks [From discussion between Roy Pereira and Ben Rogers...] >>The cipher key alsways gets the first number of bits, where >>represents the number of bits for its key. >> >>This is stated in other ESP cipher algorithm documents, but it also >>should be stated in the main ESP document as well. How does the text below sound? Thanks, Karen ============================================================================== Please note that in response to comments received on the currently posted draft, we've re-organized the Processing section to make the inbound and outbound sections more parallel to each other, consolidate the algorithms text, etc. The not-yet-posted Processing section looks like: 3. Encapsulating Security Protocol Processing........................7 3.1 ESP Header Location..........................................7 3.2 Algorithms..................................................10 3.2.1 Encryption Algorithms..................................10 3.2.2 Authentication Algorithms..............................10 3.3 Outbound Packet Processing..................................10 3.3.1 Security Association Lookup............................11 3.3.2 Packet Encryption......................................11 3.3.3 Sequence Number Generation.............................11 3.3.4 Integrity Check Value Calculation......................12 3.3.5 Fragmentation..........................................12 3.4 Inbound Packet Processing...................................12 3.4.1 Reassembly.............................................12 3.4.2 Security Association Lookup............................13 3.4.3 Sequence Number Verification...........................13 3.4.4 Integrity Check Value Verification.....................14 3.4.5 Packet Decryption......................................15 We propose to add the following text to section 3.2 before 3.2.1 and 3.2.2: "If both encryption and authentication services are selected, then the encryption key is taken from the first (left-most, high-order) bits and the authentication key is taken from the remaining bits. The number of bits for each is defined in the relevant transforms." From owner-ipsec Tue Sep 16 07:19:46 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA03754 for ipsec-outgoing; Tue, 16 Sep 1997 07:17:56 -0400 (EDT) Date: Tue, 16 Sep 1997 01:58:01 -0400 (EDT) Message-Id: <199709160558.BAA00898@carp.morningstar.com> From: Ben Rogers To: ipsec@tis.com, isakmp-oakley@cisco.com Subject: 3DES-CBC-MAC Reply-To: ben@Ascend.COM (Ben Rogers) Sender: owner-ipsec@ex.tis.com Precedence: bulk IO-RES seems to assume we have a knowledge of 3DES-CBC-MAC, but doesn't provide a reference for the used implementation. Some of the other drafts reference Schneier (IMO an unacceptable reference for an internet draft) for DES-CBC-MAC. However, we don't really have a well defined method to create padding bits if the last block does not end on an 8 byte boundary. Am I missing some reference in the docs? Otherwise can someone please explain to the list what is typically done here, and append that to the IO-RES draft? ben From owner-ipsec Tue Sep 16 16:55:14 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA08207 for ipsec-outgoing; Tue, 16 Sep 1997 16:49:32 -0400 (EDT) Message-Id: <2.2.32.19970916205714.006cee98@pita.cisco.com> X-Sender: shacham@pita.cisco.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 16 Sep 1997 13:57:14 -0700 To: ipsec@tis.com From: Avram Shacham Subject: draft-ietf-ippcp-protocol-01.txt Sender: owner-ipsec@ex.tis.com Precedence: bulk As the IP Payload Compression Protocol WG is a spin-off of IPSec, the attached draft may be of interest to this WG. The document reflects the resolutions of the IPPCP WG meeting in IETF 39 on August 13, 1997. To keep the separation of the WGs, please forward your comments to the IPPCP WG at ippcp@external.cisco.com Cheers, avram ==== I-D start === INTERNET-DRAFT A. Shacham, Cisco IP Payload Compression Protocol Working Group R. Monsour, Hi/fn Expires in six months R. Pereira, TimeStep M. Thomas, AltaVista Internet September 1997 IP Payload Compression Protocol (IPComp) Status of this Memo 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 and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as ``work in progress.'' To view the entire list of current Internet-Drafts, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Distribution of this memo is unlimited. Abstract This document describes a protocol intended to provide lossless compression for Internet Protocol datagrams in an Internet environment. 1. Introduction IP payload compression is a protocol to reduce the size of IP datagrams. This protocol will increase the overall communication performance between a pair of communicating hosts/gateways ("nodes") by compressing the datagrams, provided the nodes have sufficient computation power, through either CPU capacity or a compression coprocessor, and the communication is over slow or congested links. IP payload compression is especially useful when encryption is applied to IP datagrams, causing the data to be random in nature, rendering compression at lower protocol layers (e.g., PPP Compression Control Protocol [RFC-1962]) ineffective. This document defines the IP payload compression protocol (IPComp), the IPComp packet structure, the IPComp Association (IPCA), and several methods to negotiate the IPCA. Other documents shall specify how a specific compression algorithm can be used with the IP payload compression protocol. Shacham, Monsour, Pereira, Thomas [Page 1] INTERNET DRAFT IPComp September 1997 1.1. Specification of Requirements The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC-2119]. 2. Compression Process The compression processing of IP datagrams has two phases: compressing of outbound IP datagrams ("compression") and decompressing of inbound datagrams ("decompression"). The compression processing MUST be lossless, ensuring that the IP datagram, after being compressed and decompressed, is identical to the original IP datagram. Each IP datagram is compressed and decompressed by itself without any relation to other datagrams ("stateless compression"), as IP datagrams may arrive out of order or not arrive at all. Each compressed IP datagram encapsulates a single IP datagram. Processing of inbound IP datagrams MUST support both compressed and non-compressed IP datagrams, in order to meet the non-expansion policy requirements, as defined in section 2.2. The compression of outbound IP datagrams MUST be done before any IP security processing, such as encryption and authentication, and before any fragmentation of the IP datagram. In addition, in IP version 6 [RFC-1883], the compression of outbound IP datagrams MUST be done before the addition of either a Hop-by-Hop Options header or a Routing Header, since both carry information that must be examined and processed by possibly every node along a packet's delivery path, and therefore MUST be sent in the original form. Similarly, the decompression of inbound IP datagrams MUST be done after the reassembly of the IP datagrams, and after the completion of all IP security processing, such as authentication and decryption. 2.1. Compressed Payload The compression is applied to a single array of octets, which are contiguous in the IP datagram. This array of octets always ends at the last octet of the IP packet payload. Note: a contiguous array of octets in the IP datagram may be not contiguous in physical memory. In IP version 4 [RFC-0791], the compression is applied to the upper layer protocol (ULP) payload of the IP datagram. No portion of the IP header or the IP header options is compressed. Shacham, Monsour, Pereira, Thomas [Page 2] INTERNET DRAFT IPComp September 1997 In the IPv6 context, IPComp is viewed as an end-to-end payload, and therefore MUST apply after hop-by-hop, routing, and fragmentation extension headers. The compression is applied starting at the first IP Header Option field which does not carry information that must be examined and processed by nodes along a packet's delivery path, if such IP Header Option field exists, and continues to the ULP payload of the IP datagram. The size of a compressed payload MUST be in whole octet units. As defined in section 3, an IPComp header is inserted immediately preceding the compressed payload. The original IP header is modified to indicate the usage of the IPComp protocol and the reduced size of the IP datagram. The original content of the Next Header field is stored in the IPComp header. The decompression is applied to a single contiguous array of octets in the IP datagram. The start of the array of octets immediately follows the IPComp header and ends at the last octet of the IP payload. If the decompression process is successfully completed, the IP header is modified to indicate the size of the decompressed IP datagram, and the original next header as stored in the IPComp header. The IPComp header is removed from the IP datagram and the decompressed payload immediately follows the IP header. 2.2. Non-Expansion Policy If the size of a compressed IP datagram, including the IP header, the IPComp header as defined in section 3, and the compressed payload, is not smaller than the size of the original IP datagram, the IP datagram MUST be sent in the original non-compressed form. To clarify: If an IP datagram is sent non-compressed, no IPComp header is added to the datagram. This policy ensures saving the decompression processing cycles and avoiding incurring IP datagram fragmentation when the expanded datagram is larger than MTU. Small IP datagrams are likely to expand as a result of compression. Therefore, a numeric threshold SHOULD be applied before compression, where IP datagrams of size smaller than the threshold are sent in the original form without attempting compression. The numeric threshold is implementation dependent. An IP datagram with payload that has been previously compressed tends not to compress any further. The previously compressed payload may be the result of external processes, such as compression applied by an upper layer in the communication stack, or by an off-line compression utility. An adaptive algorithm SHOULD be implemented to avoid the performance hit. For example, if the compression of i consecutive IP datagrams of an IPCA fails, the next k IP datagrams are sent without attempting compression. If the next j datagrams are also failing to compress, the next k+n datagrams are sent without attempting compression. Once a datagram is compressed successfully, the normal process of IPComp restarts. The adaptive algorithm including all the related thresholds is implementation dependent. Shacham, Monsour, Pereira, Thomas [Page 3] INTERNET DRAFT IPComp September 1997 During the processing of the payload, the compression algorithm MAY periodically apply a test to determine the compressibility of the processed data, similar to the requirements of [V42BIS]. The nature of the test is implementation dependent. Once the compression algorithm detects that the data is non-compressible, the algorithm SHOULD stop processing the data, and the payload is sent in the original non-compressed form. 3. Compressed IP Datagram Header Structure A compressed IP datagram is encapsulated by modifying the IP header and inserting an IPComp header immediately preceding the compressed payload. This section defines the IP header modifications both in IPv4 and IPv6, and the structure of the IPComp header. 3.1. IPv4 Header Modifications The following IPv4 header fields are set: Total Length The length of the entire encapsulated IP datagram, including the IP header, the IPComp header and the compressed payload. Protocol The Protocol field is set to 108, IPComp Datagram, [RFC-1700]. All other IPv4 header fields are kept unchanged, including any header options. 3.2. IPv6 Header Modifications The following IPv6 header fields are set: Payload Length The length of the compressed IP payload. Next Header The Next Header field is set to 108, IPComp Datagram, [RFC-1700]. All other IPv6 header fields are kept unchanged, including any non-compressed header options. The IPComp header is placed in an IPv6 packet using the same rules as the IPv6 Fragment Header. However if an IPv6 packet contains both an IPv6 Fragment Header and an IPComp header, the IPv6 Fragment Header MUST preceed the IPComp header in the packet. Shacham, Monsour, Pereira, Thomas [Page 4] INTERNET DRAFT IPComp September 1997 3.3. IPComp Header Structure The four octet header has the following structure: 0 1 2 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header | Flags | Compression Parameter Index | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Next Header 8-bit selector. Stores the IPv4 Protocol field or the IPv6 Next Header field of the original IP header. Flags 8-bit field. Reserved for future use. Must be set to zero. Compression Parameter Index (CPI) 16-bit index. The CPI is stored in network order. The values 0-63 are defined by IANA and are used for manual setup, which requires no additional information. The values 64-61439 are negotiated between the two nodes in definition of an IPComp Association, as defined in section 4. The values 61440-65535 are for private use among mutually consenting parties. 4. IPComp Association (IPCA) Negotiation To utilize the IPComp protocol, two nodes MUST first establish an IPComp Association (IPCA) between them. The IPCA includes all required information for the operation of IPComp, including the Compression Parameter Index (CPI), the mode of operation, the compression algorithm to be used, and any required parameter for the selected compression algorithm. The IPComp mode of operation is either a node-to-node policy where IPComp is applied to every IP packet between the nodes, or an ULP session based policy where only selected ULP sessions between the nodes are using IPComp. For each IPCA, a different compression algorithm may be negotiated in each direction, or only one direction may be compressed. The default is "no IPComp compression". The IPCA is established by dynamic negotiations or by static configuration. The dynamic negotiations SHOULD use the Internet Security Association and Key Management Protocol [ISAKMP], where IPSec is present. The dynamic negotiations MAY be implemented through a different protocol. Shacham, Monsour, Pereira, Thomas [Page 5] INTERNET DRAFT IPComp September 1997 4.1. Use of ISAKMP For IPComp in the context of IP Security, ISAKMP provides the necessary mechanisms to establish IPCA. IPComp Association is negotiated by the initiator using a Proposal Payload, which would include one or more Transform Payloads. The Proposal Payload would specify a compression protocol in the protocol id field and each Transform Payload would contain the specific compression method(s) being offered to the responder. In the Internet IP Security Domain of Interpretation (DOI) [SECDOI], IPComp is negotiated as the Protocol ID PROTO_IPCOMP. The compression algorithm is negotiated as one of the defined IPCOMP Transform Identifiers. 4.2. Use of Non-ISAKMP Protocol The dynamic negotiations MAY be implemented through a protocol other than ISAKMP. Such protocol is beyond the scope of this document. 4.3. Static Configuration Nodes may establish IPComp Associations using static configuration. For this method, a limited number of Compression Parameters Indexes (CPIs) is designated to represent a list of specific compression methods. 5. Security Considerations IP payload compression potentially reduces the security of the Internet, similar to the effects of IP encapsulation [RFC-2003]. For example, IPComp makes it difficult for border routers to filter datagrams based on header fields. In particular, the original value of the Protocol field in the IP header is not located in its normal positions within the datagram, and any transport header fields within the datagram, such as port numbers, are neither located in their normal positions within the datagram nor presented in their original values after compression. A filtering border router can filter the datagram only if it shares the IPComp Association used for the compression. To allow this sort of compression in environments in which all packets need to be filtered (or at least accounted for), a mechanism must be in place for the receiving node to securely communicate the IPComp Association to the border router. This might, more rarely, also apply to the IPComp Association used for outgoing datagrams. When IPComp is used in the context of IPSec, it is not believed to have an effect on the underlying security functionality provide by the IPSec protocol; i.e., the use of compression is not known to degrade or alter the nature of the underlying security architecture or the encryption technologies used to implement it. Shacham, Monsour, Pereira, Thomas [Page 6] INTERNET DRAFT IPComp September 1997 6. References [RFC-0791] Postel, J., Editor, "Internet Protocol", STD 5, RFC 791, September 1981. [RFC-1700] Reynolds, J., Postel, J., "Assigned Numbers", RFC 1700, October 1994. [RFC-1883] Deering, S., Hinden, R., "Internet Protocol, Version 6 (IPv6) Specification", RFC 1883, April 1996. [RFC-1962] Rand, D., "The PPP Compression Control Protocol (CCP)", RFC 1962, June 1996. [RFC-2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996. [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [ISAKMP] Maughan, D., Schertler, M., Schneider, M., and Turner, J., "Internet Security Association and Key Management Protocol (ISAKMP)", Internet-Draft: draft-ietf-ipsec-isakmp-08.txt, Work in Progress, July 1997. [SECDOI] Piper, D., "The Internet IP Security Domain of Interpretation for ISAKMP", Internet-Draft: draft-ietf-ipsec-ipsec-doi-02.txt, Work in Progress, February 1997. [V42BIS] CCITT, "Data Compression Procedures for Data Circuit Terminating Equipment (DCE) Using Error Correction Procedures", Recommendation V.42 bis, January 1990. Authors' Information Abraham Shacham Cisco Systems 101 Cooper Street Santa Cruz, California 95060 United States of America Email: shacham@cisco.com Robert Monsour Hi/fn Inc. 2105 Hamilton Avenue, Suite 230 San Jose, California 95125 United States of America Email: rmonsour@hifn.com Shacham, Monsour, Pereira, Thomas [Page 7] INTERNET DRAFT IPComp September 1997 Roy Pereira TimeStep Corporation 362 Terry Fox Drive Kanata, Ontario K2K 2P5 Canada Email: rpereira@timestep.com Matt Thomas AltaVista Internet Software 30 Porter Road Littleton, Massachusetts 01460 United States of America Email: matt.thomas@altavista-software.com Working Group The IP Payload Compression Protocol (IPPCP) working group can be contacted through its chair: Naganand Dorswamy Bay Networks Email: naganand@baynetworks.com Shacham, Monsour, Pereira, Thomas Expires in six months [Page 8] === I-D end === From owner-ipsec Tue Sep 16 20:09:45 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id UAA09411 for ipsec-outgoing; Tue, 16 Sep 1997 20:08:33 -0400 (EDT) Date: Tue, 16 Sep 1997 20:18:19 -0400 Message-Id: <199709170018.UAA15793@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: Karen Seo Cc: rpereira@TimeStep.com, ben@Ascend.COM, ipsec@tis.com, kseo@bbn.com In-Reply-To: Karen Seo's message of Tue, 16 Sep 97 3:39:05 EDT, <199709160752.DAA25000@relay.hq.tis.com> Subject: Re: Which comes first? Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: owner-ipsec@ex.tis.com Precedence: bulk Date: Tue, 16 Sep 97 3:39:05 EDT From: Karen Seo "If both encryption and authentication services are selected, then the encryption key is taken from the first (left-most, high-order) bits and the authentication key is taken from the remaining bits. The number of bits for each is defined in the relevant transforms." This looks fine to me. Is it what most people have been implementing? I would have assumed so.... - Ted From owner-ipsec Wed Sep 17 04:51:29 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id EAA11937 for ipsec-outgoing; Wed, 17 Sep 1997 04:49:04 -0400 (EDT) Message-ID: <341F9CF5.15FB7483@teil.soft.net> Date: Wed, 17 Sep 1997 09:03:49 +0000 From: "Suren Arockia S." X-Mailer: Mozilla 3.0Gold (X11; U; BSD/OS 3.0 i386) MIME-Version: 1.0 To: ipsec@tis.com Subject: Daemon Recovery References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk I have a problem for which I donot have a proper solution. After a complete negotiation between two ISAKMP peers (A and B), the peer B crashes. When B recovers, ip packets from A reach B with SPI values strange to B. Can someone suggest a method to stop A from sending packets using OLD SPI values. Suren. -- ------------------------------------------------------------------------------ Arockia S. Suren, Specialist, Tata Elxsi India Ltd. email: suren@teil.soft.net / Ph: 91-80-8452015 ------------------------------------------------------------------------------ From owner-ipsec Wed Sep 17 11:53:35 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA15058 for ipsec-outgoing; Wed, 17 Sep 1997 11:51:08 -0400 (EDT) Date: Wed, 17 Sep 97 08:57:58 PDT From: marc@mentat.com (Marc Hasson) Message-Id: <9709171557.AA20523@mentat.com> To: kseo@bbn.com, tytso@MIT.EDU Subject: Re: Which comes first? Cc: rpereira@TimeStep.com, ben@Ascend.COM, ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk > Date: Tue, 16 Sep 97 3:39:05 EDT > From: Karen Seo > > "If both encryption and authentication services are selected, > then the encryption key is taken from the first (left-most, > high-order) bits and the authentication key is taken from the > remaining bits. The number of bits for each is defined in the > relevant transforms." > > This looks fine to me. Is it what most people have been implementing? > I would have assumed so.... > > - Ted Well, its not what any PF_KEYv2 person is implementing or has implemented at the kernel level where the authentication and encryption keys are passed down in one message that clearly delineates the auth and encrypt keys for the one ESP session. The above text is fine in itself but I don't understand why this would need to go into the ESP document which is a *auth/encrypt protocol* specification (not a keying interface one) based on a set of transforms which, in turn, specify keying material lengths of the individual algorithms that can be used with ESP. Its an implementation issue how the keys get to this ESP specification or code. The original question, as I understood it, from Ben came up in the context of Key Management and so this becomes an issue of how "Key Management vs. the ESP code" needed to split the full blob of keying material from an ISAKMP/OAKLEY context into the auth/encrypt portions. If we had a different KM algorithm that negotiated independent blobs of material for authentication and encryption then this issue may not even arise in some implementations, the bits for each function may be clearly delineated early on. Or if there's a manual key system that independently specifies the MD5 and DES keys for a statically allocated SPI splitting is again a moot point for ESP. Its clear. Implementations of a KM and ESP should have the flexibility of either one devying up a full blob of keying material into separate authentication and encryption segment. We just need to agree on whats needed for interoperation. I would suggest Karen's text go into any key management related document where a single blob of keying material is being passed around so that the end entities can understand how to divide it up amongst multiple algorithms. After all, these KM protocols did negotiate the specific algorithms being used so this seems like a good place to mention how to split the keys. Or, if people really feel this must go into ESP, the above text should be pre-qualified with a "those ESP implementations receiving a single injection of keying material from KM for both auth/encrypt services divide it up as follows." -- Marc -- From owner-ipsec Wed Sep 17 12:20:20 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA15304 for ipsec-outgoing; Wed, 17 Sep 1997 12:18:09 -0400 (EDT) Message-Id: <199709171626.JAA28335@pita.cisco.com> From: "Michael Reilly" To: "Marc Hasson" , , Cc: , , Subject: Re: Which comes first? Date: Wed, 17 Sep 1997 09:24:58 -0700 X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1160 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Marc Hanson wrote: >>Well, its not what any PF_KEYv2 person is implementing or has implemented .. Actually it is what some of us "PF_KEYv2 people" have implemented. The key daemon will supply exactly what is asked for. The kernel asks for 192 bits of encryption key and 0 bits of authentication key and gets just that. Of course if the kernel wanted to ask for 64 bits for ESP and 128 for the HMAC and KNEW a priori that the key daemon understood the ESP transform in use it could do so. Since the key daemon shouldn't have to know anything about the transform in use the kernel can decide how to cut up the keying material and ask for all the bits at once. PF_KEY doesn't preclude this. michael From owner-ipsec Wed Sep 17 13:05:22 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA15671 for ipsec-outgoing; Wed, 17 Sep 1997 13:04:11 -0400 (EDT) Message-Id: <199709171713.KAA04846@dharkins-ss20> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: marc@mentat.com (Marc Hasson) Cc: kseo@bbn.com, tytso@MIT.EDU, rpereira@TimeStep.com, ben@Ascend.COM, ipsec@tis.com Subject: Re: Which comes first? In-Reply-To: Your message of "Wed, 17 Sep 1997 08:57:58 PDT." <9709171557.AA20523@mentat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 17 Sep 1997 10:13:37 -0700 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk Marc, > > "If both encryption and authentication services are selected, > > then the encryption key is taken from the first (left-most, > > high-order) bits and the authentication key is taken from the > > remaining bits. The number of bits for each is defined in the > > relevant transforms." > > > > This looks fine to me. Is it what most people have been implementing? > > I would have assumed so.... > > > > - Ted > >Well, its not what any PF_KEYv2 person is implementing or has implemented >at the kernel level where the authentication and encryption keys are >passed down in one message that clearly delineates the auth and encrypt >keys for the one ESP session. Well since PF_KEYv2 is not an IPSec draft and the authors of PF_KEYv2 chose to define their own monolithic, one-dimensional number space instead of using IPSec-approved DOI values (and including a DOI-type field in the sadb_sa struct to multiplex things like IPSec and RIPv2 in exactly the same manner that ISAKMP can) and since they chose to impose unnecessary restrictions on the behavior of ISAKMP/Oakley I'd like to know why PF_KEYv2 implementations (still haven't seen one yet) should have _any_ impact on IPSec documents. > The above text is fine in itself but I don't understand why this would > need to go into the ESP document which is a *auth/encrypt protocol* > specification (not a keying interface one) based on a set of transforms > which, in turn, specify keying material lengths of the individual > algorithms that can be used with ESP. Its an implementation issue how > the keys get to this ESP specification or code. The original question, > as I understood it, from Ben came up in the context of Key Management > and so this becomes an issue of how "Key Management vs. the ESP code" > needed to split the full blob of keying material from an ISAKMP/OAKLEY > context into the auth/encrypt portions. If you're talking about where to slice-and-dice I can honestly tell you that mine is the One True Religion and yours is heretical. If you're talking about where the text should go then since ESP does both auth and encrypt it would make sense to inform the implementor right there about what goes first without having to context switch to another document-- it's hard enough jumping from document to document as it is. Nothing in that text suggests that slicing-and-dicing must be done in any particular place. It merely states that when slicing-and-dicing to take the encryption key first. If a PF_KEYv2 implementation (or I should say a KM protocol that has been hacked into PF_KEYv2) does not do this then it won't interoperate with non-PF_KEYv2 (i.e. every single one out there already) implementations. Yes, Ted, this is what all interoperable implementations have been doing. Dan. From owner-ipsec Wed Sep 17 13:15:48 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA15742 for ipsec-outgoing; Wed, 17 Sep 1997 13:15:42 -0400 (EDT) Date: Wed, 17 Sep 97 10:23:57 PDT From: marc@mentat.com (Marc Hasson) Message-Id: <9709171723.AA20938@mentat.com> To: michaelr@cisco.com Subject: Re: Which comes first? Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Michael, > >>Well, its not what any PF_KEYv2 person is implementing or has implemented > .. > > Actually it is what some of us "PF_KEYv2 people" have implemented. The key > daemon will supply exactly what is asked for. The kernel asks for 192 bits > of encryption key and 0 bits of authentication key and gets just that. Of > course if the kernel wanted to ask for 64 bits for ESP and 128 for the HMAC > and KNEW a priori that the key daemon understood the ESP transform in use > it could do so. > > Since the key daemon shouldn't have to know anything about the transform in > use the kernel can decide how to cut up the keying material and ask for all > the bits at once. PF_KEY doesn't preclude this. Fine. I guess you can use PF_KEYv2 that way, if you wish. Its a question for another forum to work out PF_KEYv2 inter-vendor portability or API issues, if thats ever appropriate as the work developes. (Personally I always interpreted "encrypt" or "auth" in PF_KEYv2 to refer to the encryption algorithm or authentication algorithms, not ESP vs. AH.) Thanks for the tidbit, I shouldn't have presumed how different folks made use of the PF_KEYv2 specification and should merely have said that the PF_KEYv2 specification had separate delineation of authentication vs. encryption keying material for passing down keying material. And its certainly possible that other non-PF_KEY implementations have only that separation. Given this, would you (or anyone) have any trouble with my last suggestion on Karen's text: > ... Or, if people really feel this must go > into ESP, the above text should be pre-qualified with a "those ESP > implementations receiving a single injection of keying material from > KM for both auth/encrypt services divide it up as follows." -- Marc -- From owner-ipsec Wed Sep 17 13:27:00 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA15845 for ipsec-outgoing; Wed, 17 Sep 1997 13:26:43 -0400 (EDT) Date: Wed, 17 Sep 1997 10:10:39 -0700 (PDT) Message-Id: <199709171710.KAA02697@boonmark-pc.juniper.net> From: Pasvorn Boonmark MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Suren Arockia S." Cc: ipsec@tis.com Subject: Daemon Recovery In-Reply-To: <341F9CF5.15FB7483@teil.soft.net> References: <341F9CF5.15FB7483@teil.soft.net> X-Mailer: VM 6.22 under 19.15 XEmacs Lucid Sender: owner-ipsec@ex.tis.com Precedence: bulk Suren Arockia S. writes: > I have a problem for which I donot have a proper solution. > After a complete negotiation between two ISAKMP peers (A and B), > the peer B crashes. When B recovers, ip packets from A reach > B with SPI values strange to B. Can someone suggest a method > to stop A from sending packets using OLD SPI values. > This would be the same as receiving INVALID SPI (page 59.) It basically said that what you want to do depended up on your security policy. Another thought is the use of SA error notification, but I'm not sure. I think someone would have comment on that. > Suren. > -- > ------------------------------------------------------------------------------ > Arockia S. Suren, > Specialist, Tata Elxsi India Ltd. > email: suren@teil.soft.net / Ph: 91-80-8452015 > ------------------------------------------------------------------------------ From owner-ipsec Wed Sep 17 13:41:48 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA15947 for ipsec-outgoing; Wed, 17 Sep 1997 13:41:42 -0400 (EDT) Message-ID: From: Roy Pereira To: "'Pasvorn Boonmark'" , "'Suren Arockia S.'" Cc: "'ipsec@tis.com'" Subject: RE: Daemon Recovery Date: Wed, 17 Sep 1997 14:05:58 -0400 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Doing anything very intensive could cause your implementation to be vulnerable to 'denial of service' attacks because an attacker can send out ESP headers with bogus SPIs very quickly. On Wednesday, September 17, 1997 1:11 PM, Pasvorn Boonmark [SMTP:boonmark@juniper.net] wrote: > Suren Arockia S. writes: > > I have a problem for which I donot have a proper solution. > > After a complete negotiation between two ISAKMP peers (A and B), > > the peer B crashes. When B recovers, ip packets from A reach > > B with SPI values strange to B. Can someone suggest a method > > to stop A from sending packets using OLD SPI values. > > > > This would be the same as receiving INVALID SPI (page 59.) It > basically said that what you want to do depended up on your security > policy. > > Another thought is the use of SA error notification, but I'm not > sure. I think someone would have comment on that. > > > Suren. > > -- > > > ----------------------------------------------------------------------------- - > > Arockia S. Suren, > > Specialist, Tata Elxsi India Ltd. > > email: suren@teil.soft.net / Ph: 91-80-8452015 > > > ----------------------------------------------------------------------------- - > > From owner-ipsec Wed Sep 17 13:52:01 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA16057 for ipsec-outgoing; Wed, 17 Sep 1997 13:51:42 -0400 (EDT) Date: Wed, 17 Sep 1997 14:01:13 -0400 Message-Id: <199709171801.OAA16412@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: "Suren Arockia S." Cc: ipsec@tis.com In-Reply-To: suren@teil.soft.net's message of Wed, 17 Sep 1997 09:03:49 +0000, <341F9CF5.15FB7483@teil.soft.net> Subject: Re: Daemon Recovery Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: owner-ipsec@ex.tis.com Precedence: bulk Date: Wed, 17 Sep 1997 09:03:49 +0000 From: "Suren Arockia S." I have a problem for which I donot have a proper solution. After a complete negotiation between two ISAKMP peers (A and B), the peer B crashes. When B recovers, ip packets from A reach B with SPI values strange to B. Can someone suggest a method to stop A from sending packets using OLD SPI values. Bill Simpson has proposed an unsecured ICMP message which tells host B that a particular SPI is invalid. Unfortunately, there are some obvious and severe denial of service attacks one could accomplish with this tack. I could imagine either requiring that the ICMP message be secured in an existing SPI from the same host. A better solution might be to include in the ISAKMP negotiations a notification that at the successful conclusion of this SPI negotiation, all other SPI's for the same host should be discarded. What do other people think? - Ted From owner-ipsec Wed Sep 17 14:06:37 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA16206 for ipsec-outgoing; Wed, 17 Sep 1997 14:05:44 -0400 (EDT) Message-Id: <199709171815.OAA04122@thunk.ch.apollo.hp.com> X-Authentication-Warning: thunk.ch.apollo.hp.com: sommerfeld owned process doing -bs To: "Theodore Y. Ts'o" Cc: "Suren Arockia S." , ipsec@tis.com Subject: Re: Daemon Recovery In-Reply-To: tytso's message of Wed, 17 Sep 1997 14:01:13 -0400. <199709171801.OAA16412@dcl.MIT.EDU> Date: Wed, 17 Sep 1997 14:15:11 -0400 From: Bill Sommerfeld Sender: owner-ipsec@ex.tis.com Precedence: bulk > A better solution might be to include in the ISAKMP negotiations a > notification that at the successful conclusion of this SPI > negotiation, all other SPI's for the same host should be discarded. This is a somewhat larger hammer than necessary, and I have this funny feeling (which I can't really justify yet) that there are some gotchas with this approach in the presence of packet reordering and the like.. Here's an alternate solution: Upon receipt of a message to a "bad" SPI, the system should attempt to negotiate a new SPI-pair with the sender; only one negotiation should be attempted at a time. If it fails, there should be a "hold-down" period (of seconds to minutes) during which no negotiation is initiated. Once this negotiation succeeds, it can be used to secure ICMP messages informing the sender that the SPI it was sending to isn't there any more. - Bill From owner-ipsec Wed Sep 17 14:11:19 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA16249 for ipsec-outgoing; Wed, 17 Sep 1997 14:11:14 -0400 (EDT) Message-Id: <199709171820.LAA04959@dharkins-ss20> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: "Theodore Y. Ts'o" Cc: "Suren Arockia S." , ipsec@tis.com Subject: Re: Daemon Recovery In-Reply-To: Your message of "Wed, 17 Sep 1997 14:01:13 EDT." <199709171801.OAA16412@dcl.MIT.EDU> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 17 Sep 1997 11:20:50 -0700 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk Ted, > I have a problem for which I donot have a proper solution. > After a complete negotiation between two ISAKMP peers (A and B), > the peer B crashes. When B recovers, ip packets from A reach > B with SPI values strange to B. Can someone suggest a method > to stop A from sending packets using OLD SPI values. > > Bill Simpson has proposed an unsecured ICMP message which tells host B > that a particular SPI is invalid. Unfortunately, there are some obvious > and severe denial of service attacks one could accomplish with this > tack. > > I could imagine either requiring that the ICMP message be secured in an > existing SPI from the same host. A better solution might be to include > in the ISAKMP negotiations a notification that at the successful > conclusion of this SPI negotiation, all other SPI's for the same host > should be discarded. What do other people think? I'm not sure that would fix the problem. Peer A doesn't know peer B crashed so it doesn't try to negotiate again. As far as A is concerned everything is hunky-dory. B, on the other hand, silently drops the packets per the spec. I've been worrying about this for a while but for a different reason. If one of the peers is doing Virtual Router Redundancy Protocol and the failover happens this same situation can occur. To A it looks like nothing happened. Same IP address, same everything, just all of a sudden everything IPSec-wise stopped working. I was toying with the idea of an ISAKMP keep-alive message as a way to solve this. Periodically the peers could just remind each other of their continued viability and prove they still have the SKEYID state. If after some period of time a keep-alive was not received, the peer (A in the example) could begin negotiation with the other peer (B in the example) and then do as you suggest: throw away the old SPIs and start using the new ones. Any other potential solutions? Dan. From owner-ipsec Wed Sep 17 14:30:04 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA16345 for ipsec-outgoing; Wed, 17 Sep 1997 14:29:44 -0400 (EDT) Posted-Date: Wed, 17 Sep 1997 14:38:55 -0400 (EDT) Message-Id: <342024BD.794BDF32@baynetworks.com> Date: Wed, 17 Sep 1997 14:43:10 -0400 From: Naganand Doraswamy X-Mailer: Mozilla 3.01Gold (X11; I; SunOS 4.1.4 sun4m) Mime-Version: 1.0 To: Daniel Harkins Cc: "Theodore Y. Ts'o" , "Suren Arockia S." , ipsec@tis.com Subject: Re: Daemon Recovery References: <199709171820.LAA04959@dharkins-ss20> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Daniel Harkins wrote: > > I'm not sure that would fix the problem. Peer A doesn't know peer B crashed > so it doesn't try to negotiate again. As far as A is concerned everything is > hunky-dory. B, on the other hand, silently drops the packets per the spec. > > I've been worrying about this for a while but for a different reason. > If one of the peers is doing Virtual Router Redundancy Protocol and the > failover happens this same situation can occur. To A it looks like nothing > happened. Same IP address, same everything, just all of a sudden everything > IPSec-wise stopped working. I was toying with the idea of an ISAKMP keep-alive > message as a way to solve this. Periodically the peers could just remind each > other of their continued viability and prove they still have the SKEYID state. > If after some period of time a keep-alive was not received, the peer (A in the > example) could begin negotiation with the other peer (B in the example) and > then do as you suggest: throw away the old SPIs and start using the new ones. > > Any other potential solutions? > The problem is when A does not receive a keep alive message from B, it could start an ISAKMP negotiation and B could still be down at this point. I think it is better that when B receives a secure packet and doesnt have an SA, it negotiates a new SA. The only problem is SA explosion on A. If the SA's have large lifetime, then old SA established between A and B will not be deleted until the timeout. We can avoid this problem by notifying that this is the first SA establishment after a reboot so that A can purge all the SA's associated with B. -- --Naganand --------------------------------------------------------------- Naganand Doraswamy (508)916-1323 (O) Bay Architecture Lab (508)670-8153 (F) Bay Networks, Inc. 3 Federal St, BL3-04 Billerica, MA 01821 From owner-ipsec Wed Sep 17 14:37:24 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA16391 for ipsec-outgoing; Wed, 17 Sep 1997 14:37:14 -0400 (EDT) Date: Wed, 17 Sep 97 11:45:07 PDT From: marc@mentat.com (Marc Hasson) Message-Id: <9709171845.AA21422@mentat.com> To: dharkins@cisco.com Subject: Re: Which comes first? Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Dan, > Well since PF_KEYv2 is not an IPSec draft and the authors of PF_KEYv2 chose > to define their own monolithic, one-dimensional number space instead of > using IPSec-approved DOI values (and including a DOI-type field in the > sadb_sa struct to multiplex things like IPSec and RIPv2 in exactly the same > manner that ISAKMP can) and since they chose to impose unnecessary > restrictions on the behavior of ISAKMP/Oakley I'd like to know why PF_KEYv2 > implementations (still haven't seen one yet) should have _any_ impact on > IPSec documents. Agreed that PF_KEYv2 is not a working group item and that its particulars should not be discussed here until it is, or (more likely since this group is supposed to wind down) in some other group. I only wanted to point out that implementations of ESP may not take a single blob of keying material from KM, even if the effect "on the wire" is that way from your viewpoint. I was just using PF_KEYv2 as an example and didn't mean to start a discussion about it in particular, it could have been any implementation. Sorry. (As far as PF_KEYv2 implementations, I have one and would be all-too-happy to build PF_KEYv2-using code against it. I can't show you the kernel source, thats proprietary. From Michael's note it appears that he can show you an example PF_KEYv2 implementation and he works at your company. :-) BTW, I too would like to see some mods to PF_KEYv2 to fit other IPSEC stuff better.) > If you're talking about where to slice-and-dice I can honestly tell you > that mine is the One True Religion and yours is heretical. If you're > talking about where the text should go then since ESP does both auth and > encrypt it would make sense to inform the implementor right there about > what goes first without having to context switch to another document-- it's > hard enough jumping from document to document as it is. Nothing in that text > suggests that slicing-and-dicing must be done in any particular place. It I was concerned primarily about the text location and implementation flexibility. Putting the text into the ESP doc is acceptable to me, I can see where its handy for informing the implementor and I fully desire your interpretation in the last sentence above. I take it that you don't have any objection to my "single injection of keying material" qualification to make that interpretation clearer to me and probably others? Other text could clarify it as well, perhaps better. > > Yes, Ted, this is what all interoperable implementations have been doing. If "interoperable" excludes manual keying as I suspect you mean, then I can't disagree with my current implementation and testing experience. And I can't speak for others. However, I have interoperated ESP via manual keying, injecting separate MD5 & DES keys, with an ANX-active vendor who could do both manual keying and ISAKMP/Oakley. And I'll have an opportunity to do more next week at the ANX IPSEC workshop. And I expect to have ISAKMP/OAKLEY using my implementation be interoperable as well in the near future. Since we're specifying protocols, not interfaces, I don't see anything wrong with leaving implementation flexibility to those parties coding both their own ISAKMP and ESP implementations (where they *can* slice/dice wherever they want to) rather than saying (paraphrased, which was *my* interpretation of Karen's text) "an ESP implementation will split auth/encrypt keys from keying material in this manner since ESP always gets material in a single blob". If my clarification request is heresy, so be it... -- Marc -- From owner-ipsec Wed Sep 17 14:46:23 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA16447 for ipsec-outgoing; Wed, 17 Sep 1997 14:46:08 -0400 (EDT) From: Dan.McDonald@Eng.Sun.Com (Dan McDonald) Message-Id: <199709171854.LAA24409@kebe.eng.sun.com> Subject: Re: Which comes first? To: ipsec@tis.com Date: Wed, 17 Sep 1997 11:54:50 -0700 (PDT) In-Reply-To: <199709171713.KAA04846@dharkins-ss20> from "Daniel Harkins" at Sep 17, 97 10:13:37 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk First off... What PF_KEYv2 does is orthogonal w.r.t. the original question. I like Karen's text, and where I think she puts is is where it will do the most good. I'll trust her judgement on this. Now on to something else... > Well since PF_KEYv2 is not an IPSec draft Because it's not just for IPsec. > and the authors of PF_KEYv2 chose to define their own monolithic, > one-dimensional number space instead of using IPSec-approved DOI values > (and including a DOI-type field in the sadb_sa struct to multiplex things > like IPSec and RIPv2 in exactly the same manner that ISAKMP can) Not every protocol will have a DOI, and not KM scheme will have the same concept of DOI. > and since they chose to impose unnecessary restrictions on the behavior of > ISAKMP/Oakley I'd like to know why PF_KEYv2 implementations (still haven't > seen one yet) should have _any_ impact on IPSec documents. The first bit notwithstanding, PF_KEYv2 imps. should not have any impact on IPsec documents. If it does, there's a bug somewhere. They are orthogonal problems, which is why we, the authors, chose to keep it out of the ipsec group. My bottom line is that PF_KEYv2 takes its keys separately. The order in which you derive said keys (which WAS the original question) is irrelevant. And snipped text Dan brings up is a question of WHERE that derivation takes place, not HOW. Dan McD. From owner-ipsec Wed Sep 17 15:21:56 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA16642 for ipsec-outgoing; Wed, 17 Sep 1997 15:21:14 -0400 (EDT) Date: Wed, 17 Sep 1997 15:30:47 -0400 Message-Id: <199709171930.PAA03291@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: marc@mentat.com Cc: kseo@bbn.com, rpereira@TimeStep.com, ben@Ascend.COM, ipsec@tis.com In-Reply-To: Marc Hasson's message of Wed, 17 Sep 97 08:57:58 PDT, <9709171557.AA20523@mentat.com> Subject: Re: Which comes first? Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: owner-ipsec@ex.tis.com Precedence: bulk Marc, At some level it doesn't matter where the text (about how to divvy up the keying material for ESP) goes, as long as it goes *somewhere*. Likewise, what we are specifying is solely a protocol matter, and implementations are free to use whatever implementation strategy they want, so long as the resulting protocol is interoperable. I had thought that was clear; it tends to be a general ground rule for the IETF. From the point of view of ISAKMP, it provides a single blob of keying material, no matter what the underying transform (ESP or AH or whatever). So architecturally, it seems to be cleaner ***CONCEPTUALLY*** to make the outpt of ISAKMP always be a single blob of keying materal, and that it is up to the consumers of that keying material to divide it up as they see fit. For ESP, it might divide it up into two parts; for some other ISAKMP client in the future, it might divide it up into three or four parts. Your point of view is that ESP might be used for manual keying, and in manual keying, some implementations may have chosen to have two separate inputs for the encryption and message digest algorithms. This may certainly be true. But this is an implementation detail, and we are not specifying an interface definition in these documents. So this information could go into the ESP documents, or it could go into the ISAKMP document. What's not acceptable is that we continue to bicker endlessly about where it goes. Let's put it somewhere, and move on. At the end of the day, it doesn't affect the bits on the wire. - Ted From owner-ipsec Wed Sep 17 15:37:02 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA16759 for ipsec-outgoing; Wed, 17 Sep 1997 15:36:45 -0400 (EDT) Date: Wed, 17 Sep 1997 15:43:04 -0400 Message-Id: <199709171943.PAA04971@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: Bill Sommerfeld Cc: "Theodore Y. Ts'o" , "Suren Arockia S." , ipsec@tis.com In-Reply-To: Bill Sommerfeld's message of Wed, 17 Sep 1997 14:15:11 -0400, <199709171815.OAA04122@thunk.ch.apollo.hp.com> Subject: Re: Daemon Recovery Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: owner-ipsec@ex.tis.com Precedence: bulk X-Authentication-Warning: thunk.ch.apollo.hp.com: sommerfeld owned process doing -bs Cc: "Suren Arockia S." , ipsec@tis.com Date: Wed, 17 Sep 1997 14:15:11 -0400 From: Bill Sommerfeld > A better solution might be to include in the ISAKMP negotiations a > notification that at the successful conclusion of this SPI > negotiation, all other SPI's for the same host should be discarded. This is a somewhat larger hammer than necessary, and I have this funny feeling (which I can't really justify yet) that there are some gotchas with this approach in the presence of packet reordering and the like.. Well, I'm assuming that if the host that has just crashed has lost all of its keying information from before the crash (i.e., it wasn't storing its keys in some form of non-volatile storage), it should inform the other side that it shouldn't bother with trying to use any of the previous SPI's, since they're simply going to be dropped on receipt anyway. Here's an alternate solution: Upon receipt of a message to a "bad" SPI, the system should attempt to negotiate a new SPI-pair with the sender; only one negotiation should be attempted at a time. If it fails, there should be a "hold-down" period (of seconds to minutes) during which no negotiation is initiated. Once this negotiation succeeds, it can be used to secure ICMP messages informing the sender that the SPI it was sending to isn't there any more. Yes, we'd need to do something like this as well (and I think I was kinda assuming that something like this was going to happen). My original proposal was an optional thing that which the just-rebooted machine could send which meant, "I just rebooted; this is the first and only SPI for which I have keying information ---- you can forget all of your other (older) SPI's." - Ted From owner-ipsec Wed Sep 17 15:40:49 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA16779 for ipsec-outgoing; Wed, 17 Sep 1997 15:40:44 -0400 (EDT) Date: Wed, 17 Sep 1997 15:49:30 -0400 (EDT) From: Dave Mason Message-Id: <199709171949.PAA21460@rubicon.rv.tis.com> To: dharkins@cisco.com, naganand@BayNetworks.COM Cc: ipsec@tis.com, suren@teil.soft.net, tytso@MIT.EDU Subject: Re: Daemon Recovery Sender: owner-ipsec@ex.tis.com Precedence: bulk Naganand Doraswamy wrote: >The problem is when A does not receive a keep alive message from B, it >could start an ISAKMP negotiation and B could still be down at this >point. I think it is better that when B receives a secure packet and >doesnt have an SA, it negotiates a new SA. The only problem is SA >explosion on A. If the SA's have large lifetime, then old SA established >between A and B will not be deleted until the timeout. We can avoid this >problem by notifying that this is the first SA establishment after a >reboot so that A can purge all the SA's associated with B. By notifying do you mean a notify message? Would this be included as a payload in the main/aggressive mode exchange or subsequently sent in an informational exchange? Are you proposing a new notify message status type, e.g. FIRST_XCHNG, which might be used anytime a system is negotiating an ISAKMP SA when no others exist with the ISAKMP peer (SAs can disappear at times other than reboot)? Sounds like one possible solution. Perhaps one of the ISAKMP header flag bits could be used for this purpose (simpler but requires 12.5% of a limited resource - 1 bit of the flag octet). I have another question for the group - If the Phase I SA lifetime expires before a Phase II lifetime is the Phase II SA deleted along wiht the Phase I SA? If the answer is no, the proposal above might best be limited to reboots. -dave From owner-ipsec Wed Sep 17 15:43:25 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA16820 for ipsec-outgoing; Wed, 17 Sep 1997 15:43:15 -0400 (EDT) Message-Id: <199709171958.PAA00808@istari.sandelman.ottawa.on.ca> To: ipsec@tis.com Subject: Re: Daemon Recovery In-reply-to: Your message of "Wed, 17 Sep 1997 14:15:11 EDT." <199709171815.OAA04122@thunk.ch.apollo.hp.com> Date: Wed, 17 Sep 1997 15:58:17 -0400 From: "Michael C. Richardson" Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Bill" == Bill Sommerfeld writes: Bill> This is a somewhat larger hammer than necessary, and I have Bill> this funny feeling (which I can't really justify yet) that Bill> there are some gotchas with this approach in the presence of Bill> packet reordering and the like.. Agreed. The response should be to kick key/policy management. Key/policy management would only do something if policy allowed. Bill> Upon receipt of a message to a "bad" SPI, the system should Bill> attempt to negotiate a new SPI-pair with the sender; only Bill> one negotiation should be attempted at a time. If it fails, Bill> there should be a "hold-down" period (of seconds to minutes) You need a hold down period even if you succeed during which you refuse to negotiate new SAs. Consider the case of opportunistic (FreeSWAN) encryptors. Their policy always allows an SA to be formed. You can now shut them down. Bill> during which no negotiation is initiated. Once this Bill> negotiation succeeds, it can be used to secure ICMP messages Bill> informing the sender that the SPI it was sending to isn't Bill> there any more. I would like to suggest that an SA that can be used for this purpose should be marked with some attribute. I exepect that VPN group will have to make a series of policy profiles. A major issue will be under what circumstances traffic that is not for the end-nodes will be allowed to enter and exit the tunnel. :!mcr!: | Network security programming, currently Michael Richardson | on contract with DataFellows F-Secure IPSec WWW: mcr@sandelman.ottawa.on.ca. PGP key available. Winner of the 1997 O.C.D.L.D.L.P. award. -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQB1AwUBNCA2V6ZpLyXYhL+BAQF+2QL+NmgS0+P1ZfwhFqcGvcLQErG/8vO1Aq8w 5BJscWoS1taJifkbU3edBz29U943M8uSkA3Rde+tB2BZwJz/NqIO+T9HEDca7Ez4 yFNiwRDL+EzetQFV1uQojLrLbuV4scCb =ppwd -----END PGP SIGNATURE----- From owner-ipsec Wed Sep 17 16:06:39 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA16930 for ipsec-outgoing; Wed, 17 Sep 1997 16:06:16 -0400 (EDT) Message-Id: <199709172006.NAA03570@pita.cisco.com> To: "Theodore Y. Ts'o" cc: Bill Sommerfeld , "Suren Arockia S." , ipsec@tis.com Subject: Re: Daemon Recovery In-reply-to: Your message of "Wed, 17 Sep 1997 15:43:04 EDT." <199709171943.PAA04971@dcl.MIT.EDU> Date: Wed, 17 Sep 1997 13:06:33 -0700 From: Derrell Piper Sender: owner-ipsec@ex.tis.com Precedence: bulk Ted, I like the idea of a host sending an informational message when it reboots. >Yes, we'd need to do something like this as well (and I think I was >kinda assuming that something like this was going to happen). My >original proposal was an optional thing that which the just-rebooted >machine could send which meant, "I just rebooted; this is the first and >only SPI for which I have keying information ---- you can forget all of >your other (older) SPI's." This would be fairly easy: designate a new Notify Status message (REBOOTED) and add text to say that after a host reboots, after establishing the first SA with any particular host, an ISAKMP Informational Exchange SHOULD be sent under the new ISAKMP SA which indicates that the other side should purge all associations with the rebooted host. This would mean that a host would always send one of these out the first time it establishes an SA with any system. However, the recipient doesn't have to do anything with the message if they didn't want to. Derrell From owner-ipsec Wed Sep 17 16:12:26 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA16974 for ipsec-outgoing; Wed, 17 Sep 1997 16:12:16 -0400 (EDT) Message-Id: <199709172021.QAA04171@thunk.ch.apollo.hp.com> X-Authentication-Warning: thunk.ch.apollo.hp.com: sommerfeld owned process doing -bs To: Derrell Piper Cc: "Theodore Y. Ts'o" , "Suren Arockia S." , ipsec@tis.com Subject: Re: Daemon Recovery In-Reply-To: piper's message of Wed, 17 Sep 1997 13:06:33 -0700. <199709172006.NAA03570@pita.cisco.com> Date: Wed, 17 Sep 1997 16:21:27 -0400 From: Bill Sommerfeld Sender: owner-ipsec@ex.tis.com Precedence: bulk Here's another concept which will allow for easier cleanup with less risk of trouble in the presence of message reordering.. Include a "boot time" attribute in the isakmp negotiation. (as a footnote, this is a trick found in a number of other stateful protocols, including the Rx RPC protocol used by AFS, the Apollo NCS/DCE RPC protocol, and probably a few others). The "boot time" is a value, monotonically increasing over all time, chosen by each party in the protocol; you attach a boot time to each SA. Your boot time should change any time you completely empty the SA table (e.g., at reboot..). When a peer notices a negotiation with a new boot time, it knows it can flush all SA's which have an older boot time.. - Bill From owner-ipsec Wed Sep 17 16:42:52 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA17125 for ipsec-outgoing; Wed, 17 Sep 1997 16:41:46 -0400 (EDT) Message-Id: <3.0.3.32.19970917165015.030bacb8@ranier.altavista-software.com> X-Sender: altapop@ranier.altavista-software.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Wed, 17 Sep 1997 16:50:15 -0400 To: Derrell Piper From: Matt Thomas Subject: Re: Daemon Recovery Cc: ipsec@tis.com In-Reply-To: <199709172006.NAA03570@pita.cisco.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 01:06 PM 9/17/97 -0700, Derrell Piper wrote: >This would be fairly easy: designate a new Notify Status message (REBOOTED) >and add text to say that after a host reboots, after establishing the first >SA with any particular host, an ISAKMP Informational Exchange SHOULD be >sent under the new ISAKMP SA which indicates that the other side should >purge all associations with the rebooted host. This would mean that a host >would always send one of these out the first time it establishes an SA with >any system. However, the recipient doesn't have to do anything with the >message if they didn't want to. Be careful. If your ISAKMP daemon dies and restarts AND your IPSEC SAs are kept elsewhere (kernel, another daemon, whatever) you only want to the remote ISAKMP daemon to forget about ISAKMP SAs. It should leave the IPSEC SAs alone. The messages (I'd call it RESTART) should send include the DOI for which the SAs should be forgotten. Multiple RESTART notification payloads can be included if more than one DOI needs to flushed. -- Matt Thomas Internet: matt.thomas@altavista-software.com Internet Locksmith WWW URL: AltaVista Internet Software Disclaimer: This message reflects my own Littleton, MA warped views, etc. From owner-ipsec Wed Sep 17 16:46:41 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA17152 for ipsec-outgoing; Wed, 17 Sep 1997 16:45:16 -0400 (EDT) Message-Id: <199709172054.NAA04672@pita.cisco.com> To: Matt Thomas cc: ipsec@tis.com Subject: Re: Daemon Recovery In-reply-to: Your message of "Wed, 17 Sep 1997 16:50:15 EDT." <3.0.3.32.19970917165015.030bacb8@ranier.altavista-software.com> Date: Wed, 17 Sep 1997 13:54:58 -0700 From: Derrell Piper Sender: owner-ipsec@ex.tis.com Precedence: bulk Matt, >Be careful. If your ISAKMP daemon dies and restarts AND your IPSEC SAs >are kept elsewhere (kernel, another daemon, whatever) you only want to >the remote ISAKMP daemon to forget about ISAKMP SAs. It should leave >the IPSEC SAs alone. Oh yeah, agreed. >The messages (I'd call it RESTART) should send include the DOI for which >the SAs should be forgotten. Multiple RESTART notification payloads can >be included if more than one DOI needs to flushed. The DOI is included in the Notification Payload. If you wanted to flush more than one DOI, you could include more than one Notification Payload in a single informational exchange. Assuming we went this route... Derrell From owner-ipsec Wed Sep 17 17:36:51 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA17511 for ipsec-outgoing; Wed, 17 Sep 1997 17:34:16 -0400 (EDT) Date: Thu, 18 Sep 1997 00:51:42 +0300 (EET DST) From: Helger Lipmaa X-Sender: helger@keeks To: ipsec@tis.com Subject: Re: Daemon Recovery In-Reply-To: <199709171943.PAA04971@dcl.MIT.EDU> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk On Wed, 17 Sep 1997, Theodore Y. Ts'o wrote: > Here's an alternate solution: > > Upon receipt of a message to a "bad" SPI, the system should attempt to > negotiate a new SPI-pair with the sender; only one negotiation should > be attempted at a time. If it fails, there should be a "hold-down" > period (of seconds to minutes) during which no negotiation is > initiated. Once this negotiation succeeds, it can be used to secure > ICMP messages informing the sender that the SPI it was sending to > isn't there any more. > > Yes, we'd need to do something like this as well (and I think I was > kinda assuming that something like this was going to happen). My > original proposal was an optional thing that which the just-rebooted > machine could send which meant, "I just rebooted; this is the first and > only SPI for which I have keying information ---- you can forget all of > your other (older) SPI's." This is actually what we have done in our IPSEC implementation. Our intention wasn't to be 100% compatible, we just needed to get a _working_ system out as soon as possible. Although our solution is fully compatible in IP level (ESP/AH, draft-cipher-*, etc) but we have dropped ISAKMP/Oakley for good, using a proprietary, efficient and provably secure protocol instead. Best, Helger From owner-ipsec Thu Sep 18 07:40:49 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA21645 for ipsec-outgoing; Thu, 18 Sep 1997 07:37:46 -0400 (EDT) Date: Wed, 17 Sep 1997 14:02:26 -0700 (PDT) Message-Id: <199709172102.OAA03196@boonmark-pc.juniper.net> From: Pasvorn Boonmark MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Daniel Harkins Cc: "Theodore Y. Ts'o" , "Suren Arockia S." , ipsec@tis.com Subject: Re: Daemon Recovery In-Reply-To: <199709171820.LAA04959@dharkins-ss20> References: <199709171801.OAA16412@dcl.MIT.EDU> <199709171820.LAA04959@dharkins-ss20> X-Mailer: VM 6.22 under 19.15 XEmacs Lucid Sender: owner-ipsec@ex.tis.com Precedence: bulk Daniel Harkins writes: > Ted, > > > I have a problem for which I donot have a proper solution. > > After a complete negotiation between two ISAKMP peers (A and B), > > the peer B crashes. When B recovers, ip packets from A reach > > B with SPI values strange to B. Can someone suggest a method > > to stop A from sending packets using OLD SPI values. > > > > Bill Simpson has proposed an unsecured ICMP message which tells host B > > that a particular SPI is invalid. Unfortunately, there are some obvious > > and severe denial of service attacks one could accomplish with this > > tack. > > > > I could imagine either requiring that the ICMP message be secured in an > > existing SPI from the same host. A better solution might be to include > > in the ISAKMP negotiations a notification that at the successful > > conclusion of this SPI negotiation, all other SPI's for the same host > > should be discarded. What do other people think? > > I'm not sure that would fix the problem. Peer A doesn't know peer B crashed > so it doesn't try to negotiate again. As far as A is concerned everything is > hunky-dory. B, on the other hand, silently drops the packets per the spec. > > I've been worrying about this for a while but for a different reason. > If one of the peers is doing Virtual Router Redundancy Protocol and the > failover happens this same situation can occur. To A it looks like nothing > happened. Same IP address, same everything, just all of a sudden everything > IPSec-wise stopped working. I was toying with the idea of an ISAKMP keep-alive > message as a way to solve this. Periodically the peers could just remind each > other of their continued viability and prove they still have the SKEYID state. > If after some period of time a keep-alive was not received, the peer (A in the > example) could begin negotiation with the other peer (B in the example) and > then do as you suggest: throw away the old SPIs and start using the new ones. > > Any other potential solutions? > > Dan. > The keep-alive might not be a bad idea. This way A and B always knows each other state. It should also prevent another situation which another node, C, trying to attack B by sending packets with bogus SPI to B with A's address. In this case, A and B know that they both have good SKEYID state, so the packet that B received must be corrupted and B could send ICMP error message back to A, if B selected to do so to notify A of the potential problem. The action should also be rate-limited to minimize possibility of denial of service attack. Ok, I admitted, I throw the above ideas together into a mixer, but it might work. -Pasvorn From owner-ipsec Thu Sep 18 09:31:30 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA22437 for ipsec-outgoing; Thu, 18 Sep 1997 09:30:28 -0400 (EDT) Message-ID: From: Greg Carter To: "'anx-sec@dot.netrex.net'" Cc: "'dharkins@cisco.com'" , "'ipsec@tis.com'" Subject: RE: comments on Oakley test items Date: Thu, 18 Sep 1997 09:35:32 -0400 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk > I could also argue that this is not a discrepancy with the base ISAKMP >spec. The M-ID and SPI would still identify the correct state as dictated >by section 2.4. It's just that the M-ID and SPI would be in the body of >the notify message as the ISAKMP header and SA payload to which the notify >refers. The ISAKMP header of the Informational Exchange would be unique >to the Informational Exchange. Hi Dan, I can't find where it says to include the M-ID/SPI in the body of the notify message, nor where it says to include the ISAKMP header. ISAKMP states the data portion of a notify message is DOI specific, DOIv3 doesn't specify any thing special, so I would assume nothing. I agree that ISAKMP-Cookies, Protocol-ID, and SPI (so the data available during notify parse) is enough to find a bad Quick Mode BUT if and only if each side gets past the SA parse since you need to send back the other sides SPIs. There are a few cases where I will reject before I get to a deep parse of the SA payload, bad hash, invalid payload, no SA payload, who knows, etc... Can we have the DOI define the notification data to include the M-ID. Its in the clear (so it wont get screwed by IV/crypto mix ups) and relates to the whole Quick Mode (where as SPIs - multiple SAs per quick mode, AND and ORing). Sorry, don't want to harp on this, but specifying the M-ID leaves nothing to be desired and covers 100% of the error conditions, where as the current solution relies on a successful parse of the SA payload which seems rather optimistic. Bye. ---- Greg Carter, Entrust Technologies greg.carter@entrust.com Get FREE FIPS-140-1 Validated Crypto for the desktop http://www.entrust.com/solo.htm > From owner-ipsec Thu Sep 18 11:45:44 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA23542 for ipsec-outgoing; Thu, 18 Sep 1997 11:44:22 -0400 (EDT) Date: Thu, 18 Sep 1997 17:43:28 +0100 From: goode@nc3a.nato.int (Rob Goode) Message-Id: <199709181643.RAA14464@comsun21.nc3a.nato.int> To: ipsec@tis.com Subject: News on Pending US (Encryption) Legislation X-Sun-Charset: US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk Will this have any effect on IPSEC? Cheers, Rob Goode goode@nc3a.nato.int ----- Begin Included Message ----- ==================================================================== To: coastwatch (COAST Mailing list) Subject: Special Notice: News on Pending US Legislation The last week has produced some incredible events in the U.S. House of Representatives as regards cryptography. Enclosed is a story about one such event that may soon result in U.S. law. If you do business in the U.S. or live in the U.S. and expect to use computer systems and networks, this issue should be of major concern to you. Most mainstream media seems to be avoiding this issue, perhaps because it is difficult to present to the lay reader. Thus, you may not have heard about this. We think you should. The implications are huge for our security and privacy, and for the ability to conduct unhindered research and education on information security issues in the U.S. I will not editorialize on this issue here. However, I urge you to seek out information on what is happening and convey your opinions, whatever they may be, to your elected representatives (if you are in the US). You should act soon, as there may be little time before a final bill is crafted to go to the floor of the House. >---------- Forwarded message ---------- >Date: Thu, 11 Sep 1997 23:37:39 -0700 (PDT) >From: Declan McCullagh >To: fight-censorship-announce@vorlon.mit.edu >Subject: House panel votes behind closed doors to build in Big Brother > >Software that protects your privacy is a controlled substance that may no >longer be sold, a Congressional committee decided today. > >Meeting behind closed doors this morning, the House Intelligence committee >voted to replace a generally pro-encryption bill with an entirely >rewritten draft that builds in Big Brother into all future encryption >products. (The Senate appears to be moving in a similar direction.) > >The new SAFE bill -- titled in a wonderfully Orwellian manner the >"Security and Freedom through Encryption" act even though it provides >neither -- includes these provisions: > >SELLING CRYPTO: Selling unapproved encryption products (that do not >include "immediate access to plaintext") becomes a federal crime, >immediately after this bill becomes law. Five years in jail plus >fines. Distributing, importing, or manufacturing such products >after January 31, 2000 is another crime. > >NETWORK PROVIDERS: Anyone offering scrambled "network service" >including encrypted web servers or even "ssh" would be required to >build in a backdoor for the government by January 31, 2000. This >backdoor must provide for "immediate decryption or access to >plaintext of the data." > >TECHNICAL STANDARDS: The Attorney General will publish technical >requirements for such backdoors in network service and encryption >products, within five months after the president signs this bill. > >LEGAL TO USE CRYPTO: "After January 31, 2000, it shall not be >unlawful to use any encryption product purchased or in use prior to >such date." > >GOVERNMENT POWERS: If prosecutors think you may be selling, >importing, or distributing non-backdoor'd crypto or are "about" to >do so, they can sue. "Upon the filing of the complaint seeking >injunctive relief by the Attorney General, the court shall >automatically issue a temporary restraining order against the party >being sued." Also, there are provisions for holding secret >hearings, and "public disclosure of the proceedings shall be >treated as contempt of court." You can request an advisory opinion >from the government to see if the program you're about to publish >violates the law. > >ACCESS TO PLAINTEXT: Courts can issue orders, ex parte, granting >police access to your encrypted data. But all the government has to >do to get one is to provide "a factual basis establishing the >relevance of the plaintext" to an investigation. They don't have to >demonstrate probable cause, which is currently required for a >search warrant. More interestingly, this explicitly gives the FISA >court jurisdiction (yes, the secret court that has never denied a >request for a wiretap). If they decode your messages, they'll tell >you within 90 days. > >GOVERNMENT PURCHASING: Federal government computer purchases must >use a key escrow "immediate decryption" backdoor after 1998. Same >with networks "purchased directly with Federal funds to provide the >security service of data confidentially." Such products can be >labeled "authorized for sale to U.S. government" > >ENCRYPTION EXPORTS: The Defense & Commerce departments will control >exports of crypto. Software "without regard to strength" can be >exported if it includes a key escrow backdoor and is first >submitted to the government. Export decisions aren't subject to >judicial review, and the "president may by executive order waive >any provision of this act" if he thinks it's a threat to national >security. Within 15 days, he must send a classified briefing to >Congress. > >ADVISORY PANEL: Creates the Encryption Industry and Information >Security Board, with seven members from Justice, State, FBI, CIA, >White House, and six from the industry. > >INTERNATIONAL: The president can negotiate international agreements >and perhaps punish noncompliant governments. Can you say "trade >sancation?" > >(Other provisions barring the use of crypto in a crime and >some forms of cryptanalysis are also in the bill.) > >Next the Commerce Committee will vote on SAFE, and a former FBI >agent-turned-Congressman is vowing to ensure that similar language to this >is included. (The committees are voting on the bill in parallel, and a >four-person team of Congressmen is working to forge a compromise before >Commerce votes.) Then the heads of the five committees that have rewritten >the legislation will sit down and work out another compromise. If it's >acceptable to the House Rules committee -- and if the FBI/NSA get what >they want it will be -- the bill can move to the floor for a vote. > >That's why the encryption outlook in Congress is abysmal. Crypto-advocates >have lost, and lost miserably. A month ago, the debate was about export >controls. Now the battle is over how strict the //domestic// controls will >be. It's sad, really, that so many millions of lobbyist-dollars were not >only wasted, but used to advance legislation that has been morphed into a >truly awful proposal. > >I wrote more about this at: > > http://cgi.pathfinder.com/netly/opinion/0,1042,1385,00.html > >-Declan > ------- End of Forwarded Message From owner-ipsec Thu Sep 18 13:30:29 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA24184 for ipsec-outgoing; Thu, 18 Sep 1997 13:27:02 -0400 (EDT) Message-Id: <199709181736.NAA27519@jekyll.piermont.com> X-Authentication-Warning: jekyll.piermont.com: [[UNIX: localhost]] didn't use HELO protocol To: goode@nc3a.nato.int (Rob Goode) cc: ipsec@tis.com Subject: Re: News on Pending US (Encryption) Legislation In-reply-to: Your message of "Thu, 18 Sep 1997 17:43:28 BST." <199709181643.RAA14464@comsun21.nc3a.nato.int> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Thu, 18 Sep 1997 13:36:13 -0400 From: "Perry E. Metzger" Sender: owner-ipsec@ex.tis.com Precedence: bulk Rob Goode writes: > Will this have any effect on IPSEC? First the laws have to pass, which is doubtful. Perry From owner-ipsec Fri Sep 19 08:40:26 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA00144 for ipsec-outgoing; Fri, 19 Sep 1997 08:34:11 -0400 (EDT) Message-Id: <3.0.3.32.19970919084246.00997560@dilbert.is.chrysler.com> Reply-To: rgm3@chrysler.com X-Sender: rgm3@dilbert.is.chrysler.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Fri, 19 Sep 1997 08:42:46 -0400 To: ipsec@tis.com From: Robert Moskowitz Subject: Wrap up for the IPsec drafts Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk Ted and I want to start last call on a set of documents that the IESG will promote. Our first step is to group the drafts that are related to this group and then finish up the key drafts. So in this light the key drafts are: draft-ietf-ipsec-arch-sec-01.txt (We are waiting to see 02) draft-ietf-ipsec-isakmp-08.txt draft-ietf-ipsec-oakley-02.txt draft-ietf-ipsec-isakmp-oakley-05.txt (in progress will contain enc-mode) draft-ietf-ipsec-ipsec-doi-03.txt (questions on readiness) draft-ietf-ipsec-doc-roadmap-01.txt draft-ietf-ipsec-esp-v2-00.txt draft-ietf-ipsec-auth-header-01.txt draft-ietf-ipsec-auth-hmac-md5-96-00.txt draft-ietf-ipsec-auth-hmac-sha196-00.txt draft-ietf-ipsec-ciph-des-expiv-00.txt ipsec-oakley-02.txt and perhaps ipsec-doc-roadmap-01.txt will most likely be informational, all the rest are standards track. We need everyone to review these and comment on their readiness. PLEASE include the draft name in the subject for everyone's benefit. Those that receive no major comments by 9/26/97 will start wg last call on the 9/29/97. We need to get ALL of these through wg last call before sending on to the IESG! The 3 drafts with notes attached are already not considered ready for last call by the chairs. We request the editors of these documents to submit updated versions, based on wg concensus in the next week. ---------------------------------------------------------- The following documents are still considered wg documents, but will follow the above group to the IESG. We do not want to overload them with reading and slow down approval on the core documents. Note that since the working group consensus was explicit IVs only, this list does not include any proposals that use derived, or 'implicit' IVs. If I did not get this list right in this regard, let me know! draft-ietf-ipsec-ciph-3des-expiv-00.txt draft-ietf-ipsec-ciph-des-xex-00.txt draft-ietf-ipsec-ciph-rc5-cbc-00.txt draft-ietf-ipsec-ciph-cast128-cbc-00.txt draft-ietf-ipsec-ciph-arcfour-00.txt (author reports new ver soon) draft-ietf-ipsec-ciph-blowfish-cbc-00.txt draft-ietf-ipsec-ciph-idea-cbc-00.txt Somehow, it seems that we need to develop applicablity statements for all of these algorithms, suggestions anyone? The following drafts, for various reasons are dead: draft-ietf-ipsec-vpn-00.txt old vpn, watch for wg BOF draft-ietf-ipsec-revised-enc-mode-01.txt roll into isakmp-oakley-05 draft-ietf-ipsec-new-esp-00.txt old esp drop draft-ietf-ipsec-ah-hmac-sha-04.txt old ah drop draft-ietf-ipsec-ah-hmac-sha-1-96-00.txt old ah drop draft-ietf-ipsec-ah-hmac-md5-96-00.txt old ah drop The following draft will be moved to IPsecond: draft-ietf-ipsec-inline-isakmp-01.txt The following drafts are released to their authors for independent Informational RFC publication AFTER the main IPsec drafts are issued as RFCs. The justification for this is either there was no wg concensus on their value to the IPsec specification, or they use protocol designs (for example, derived IV) rejected by wg concensus. draft-ietf-ipsec-cbc-00.txt draft-ietf-ipsec-ciph-des-derived-00.txt draft-ietf-ipsec-ciph-des3-00.txt draft-ietf-ipsec-ciph-desx-00.txt draft-ietf-ipsec-ciph-cast-div-00.txt Thank you all. Theodore T'so and Robert Moskowitz Robert Moskowitz Chrysler Corporation (810) 758-8212 From owner-ipsec Fri Sep 19 10:02:22 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA00794 for ipsec-outgoing; Fri, 19 Sep 1997 09:59:12 -0400 (EDT) Date: Fri, 19 Sep 1997 09:59:27 -0400 (EDT) Message-Id: <199709191359.JAA17166@carp.morningstar.com> From: Ben Rogers To: rgm3@chrysler.com Cc: ipsec@tis.com Subject: Wrap up for the IPsec drafts In-Reply-To: <3.0.3.32.19970919084246.00997560@dilbert.is.chrysler.com> References: <3.0.3.32.19970919084246.00997560@dilbert.is.chrysler.com> Reply-To: ben@Ascend.COM (Ben Rogers) Sender: owner-ipsec@ex.tis.com Precedence: bulk Robert Moskowitz writes: > ipsec-oakley-02.txt and perhaps ipsec-doc-roadmap-01.txt will most likely > be informational, all the rest are standards track. > > We need everyone to review these and comment on their readiness. PLEASE > include the draft name in the subject for everyone's benefit. > > Those that receive no major comments by 9/26/97 will start wg last call on > the 9/29/97. We need to get ALL of these through wg last call before > sending on to the IESG! The 3 drafts with notes attached are already not > considered ready for last call by the chairs. We request the editors of > these documents to submit updated versions, based on wg concensus in the > next week. I'm a bit concerned about even thinking about last call on a document (namely draft-ietf-ipsec-isakmp-oakley-05.txt) which is still in progress, and which has been rumored to contain a significant rewrite. I would also like to express concern about having the drop-dead date so close to the ANX bakeoff. I have major comments on both the isakmp-oakley and the doi drafts, which I feel are no where near ready. However, I won't have the time until after I return from Ottowa to arrange and format these comments nicely in order to present them to the group. ben From owner-ipsec Fri Sep 19 10:14:29 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA00903 for ipsec-outgoing; Fri, 19 Sep 1997 10:14:15 -0400 (EDT) Message-Id: <3.0.3.32.19970919102242.00ac3b70@dilbert.is.chrysler.com> Reply-To: rgm3@chrysler.com X-Sender: rgm3@dilbert.is.chrysler.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Fri, 19 Sep 1997 10:22:42 -0400 To: ben@Ascend.COM (Ben Rogers) From: Robert Moskowitz Subject: Re: Wrap up for the IPsec drafts Cc: ipsec@tis.com In-Reply-To: <199709191359.JAA17166@carp.morningstar.com> References: <3.0.3.32.19970919084246.00997560@dilbert.is.chrysler.com> <3.0.3.32.19970919084246.00997560@dilbert.is.chrysler.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 09:59 AM 9/19/97 -0400, Ben Rogers wrote: > >I'm a bit concerned about even thinking about last call on a document >(namely draft-ietf-ipsec-isakmp-oakley-05.txt) which is still in >progress, and which has been rumored to contain a significant rewrite. Well again I may be writing too fast, too much on my agenda. I am doing this in a meeting between my comments. I tagged 3 drafts in this group, all of which have some issues. These do not have the last call deadline, but I wanted to get everyone to see them in a group. We need the new draft from S. Kent, there is a new isakmp-oakley in the works (see below), and there has been enough conversation on the DOI to warrent holding off on it for a few weeks. As far as isakmp-oakley-05, my understanding is it will incorporate items for oakley and revised-enc-mode. These are not significant changes. >I would also like to express concern about having the drop-dead date so >close to the ANX bakeoff. I have major comments on both the >isakmp-oakley and the doi drafts, which I feel are no where near ready. If a number of people feel that we will learn a lot more about these drafts, I can slip a week for comments that will delay last call. Remember, though, that last call is the move by the work group to get everyone to give the docs a final read-over. Of course comments will come during the last call that may well result in document changes. What I am looking for is are there major debates needed on any of these that should delay the last call discussions? >However, I won't have the time until after I return from Ottowa to >arrange and format these comments nicely in order to present them to the >group. These are welcomed even during last call. I may repeat something our previous co-chair, Ran, frequently stated: Comments in the form of re-written sections are the most effective, as it is clearer what the commenter means, and more likely to be made. Robert Moskowitz Chrysler Corporation (810) 758-8212 From owner-ipsec Fri Sep 19 10:30:30 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA01005 for ipsec-outgoing; Fri, 19 Sep 1997 10:30:14 -0400 (EDT) Date: Fri, 19 Sep 1997 07:39:01 -0700 Message-Id: <199709191439.HAA15819@gump.eng.ascend.com> From: Karl Fox To: rgm3@chrysler.com Cc: ipsec@tis.com Subject: Wrap up for the IPsec drafts In-Reply-To: <3.0.3.32.19970919084246.00997560@dilbert.is.chrysler.com> References: <3.0.3.32.19970919084246.00997560@dilbert.is.chrysler.com> Reply-To: Karl Fox Organization: Ascend Communications Sender: owner-ipsec@ex.tis.com Precedence: bulk Robert Moskowitz writes: > We need everyone to review these and comment on their readiness. PLEASE > include the draft name in the subject for everyone's benefit. > > Those that receive no major comments by 9/26/97 will start wg last call on > the 9/29/97. Could you please push this back by a week, or at least until the middle of the following week? If not, it makes comment by some of us going to Ottawa very difficult, arguably the most interested subset of the WG. I'm sure we'll also discover new issues during the testing. -- Karl Fox, servant of God, employee of Ascend Communications 655 Metro Place South, Suite 370, Dublin, Ohio 43017 +1 614 760 4041 From owner-ipsec Fri Sep 19 10:37:25 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA01049 for ipsec-outgoing; Fri, 19 Sep 1997 10:36:45 -0400 (EDT) Date: Fri, 19 Sep 1997 10:45:32 -0400 (EDT) From: Dave Mason Message-Id: <199709191445.KAA24939@rubicon.rv.tis.com> To: ipsec@tis.com Subject: Re: Wrap up for the IPsec drafts Sender: owner-ipsec@ex.tis.com Precedence: bulk Ben Rogers writes: >I would also like to express concern about having the drop-dead date so >close to the ANX bakeoff. I have major comments on both the The bakeoff might also reveal parts that need better clarification and/or specification. -dave From owner-ipsec Fri Sep 19 11:06:44 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA01291 for ipsec-outgoing; Fri, 19 Sep 1997 11:05:45 -0400 (EDT) X-Sender: fred@stilton.cisco.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 19 Sep 1997 07:54:35 -0700 To: ipsec@tis.com From: Fred Baker Subject: Costs of Mandatory Key Recovery Sender: owner-ipsec@ex.tis.com Precedence: bulk If you could email any hard numbers as to expected costs to Don Heath , it would be helpful. >>Date: Wed, 17 Sep 1997 10:55:55 -0400 >>From: Philip Webre >>To: heath@isoc.org >>Subject: Costs of Mandatory Key Recovery >>Content-Disposition: inline >> >>As I explained over the telephone, we are trying to estimate >>the private sector costs associated with mandatory key >>recovery in the US. Thursday the House Intelligence >>Committees passed an amended version of HR 695 that >>would mandate immediate key recovery in all encryption >>products sold, imported or distributed in the US after >>January 31, 2000. It further imposes this requirement >>on Internet service providers who provide encryption >>services when presented by a warrant from a duly authorized >>law enforcement official. >> >>We expect that within an organization like a corporate >>LAN, key recovery can be mandated in a straight forward >>manner. But since the relationship between an ISP >>and its client is more distant, very different mechanisms >>and cost structure would surface. I would be very >>interested in any information you could provide regarding >>the costs associated with such a mandate. >> >>Address: >>Philip Webre >>Congressional Budget Office >>Natural Resources and Commerce Division >>495 Ford House Office Bldg. >>Washington, D.C. 20515 >>Fax Number: 202-226-0207 >>Voice: 202-226-2940 >>Internet: Philipw@CBO.GOV > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= "Planning is bringing the future into the present so that you can do something about it now." Alan Lakein From owner-ipsec Fri Sep 19 12:16:28 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA01864 for ipsec-outgoing; Fri, 19 Sep 1997 12:14:51 -0400 (EDT) Message-ID: From: Roy Pereira To: "'rgm3@chrysler.com'" , "'ipsec@tis.com'" Subject: RE: Wrap up for the IPsec drafts Date: Fri, 19 Sep 1997 12:37:40 -0400 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk > draft-ietf-ipsec-ciph-des-xex-00.txt Where can I find this document? It is not on "internic.net". From owner-ipsec Fri Sep 19 12:23:03 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA01947 for ipsec-outgoing; Fri, 19 Sep 1997 12:22:49 -0400 (EDT) Message-Id: <3.0.3.32.19970919122739.00a692c0@dilbert.is.chrysler.com> Reply-To: rgm3@chrysler.com X-Sender: rgm3@dilbert.is.chrysler.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Fri, 19 Sep 1997 12:27:39 -0400 To: Roy Pereira , "'ipsec@tis.com'" From: Robert Moskowitz Subject: RE: Wrap up for the IPsec drafts In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 12:37 PM 9/19/97 -0400, Roy Pereira wrote: >> draft-ietf-ipsec-ciph-des-xex-00.txt > >Where can I find this document? It is not on "internic.net". > ARGH!!! This was in an earlier version of this note and got pasted back in. Drop it, it does not exist.... Robert Moskowitz Chrysler Corporation (810) 758-8212 From owner-ipsec Fri Sep 19 12:43:51 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA02096 for ipsec-outgoing; Fri, 19 Sep 1997 12:43:20 -0400 (EDT) Message-ID: From: Roy Pereira To: "'rgm3@chrysler.com'" , "'ipsec@tis.com'" Subject: RE: Wrap up for the IPsec drafts Date: Fri, 19 Sep 1997 13:07:02 -0400 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk I would like to see a DES-X ESP draft thougth. The one that exists uses derived IV, thus it is in-appropriate. Perhaps the author can redo it using explicit IV ? On Friday, September 19, 1997 12:28 PM, Robert Moskowitz [SMTP:rgm3@chrysler.com] wrote: > At 12:37 PM 9/19/97 -0400, Roy Pereira wrote: > >> draft-ietf-ipsec-ciph-des-xex-00.txt > > > >Where can I find this document? It is not on "internic.net". > > > ARGH!!! > > This was in an earlier version of this note and got pasted back in. Drop > it, it does not exist.... > > > Robert Moskowitz > Chrysler Corporation > (810) 758-8212 From owner-ipsec Fri Sep 19 12:58:26 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA02169 for ipsec-outgoing; Fri, 19 Sep 1997 12:58:21 -0400 (EDT) Message-Id: <3.0.3.32.19970919130451.035313b0@dilbert.is.chrysler.com> Reply-To: rgm3@chrysler.com X-Sender: rgm3@dilbert.is.chrysler.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Fri, 19 Sep 1997 13:04:51 -0400 To: Roy Pereira , "'ipsec@tis.com'" From: Robert Moskowitz Subject: RE: Wrap up for the IPsec drafts In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 01:07 PM 9/19/97 -0400, Roy Pereira wrote: Ask him directly. If an explicit DES-X transform draft shows up, it will get the same treatment (imho) as the other misc explicit IV drafts. >I would like to see a DES-X ESP draft thougth. The one that exists uses >derived IV, thus it is in-appropriate. Perhaps the author can redo it >using explicit IV ? > > >On Friday, September 19, 1997 12:28 PM, Robert Moskowitz >[SMTP:rgm3@chrysler.com] wrote: >> At 12:37 PM 9/19/97 -0400, Roy Pereira wrote: >> >> draft-ietf-ipsec-ciph-des-xex-00.txt >> > >> >Where can I find this document? It is not on "internic.net". >> > >> ARGH!!! >> >> This was in an earlier version of this note and got pasted back in. Drop >> it, it does not exist.... >> >> >> Robert Moskowitz >> Chrysler Corporation >> (810) 758-8212 > > Robert Moskowitz Chrysler Corporation (810) 758-8212 From owner-ipsec Fri Sep 19 16:45:16 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA03505 for ipsec-outgoing; Fri, 19 Sep 1997 16:43:25 -0400 (EDT) From: Dan.McDonald@Eng.Sun.Com (Dan McDonald) Message-Id: <199709192052.NAA28212@kebe.eng.sun.com> Subject: Re: Wrap up for the IPsec drafts To: rgm3@chrysler.com Date: Fri, 19 Sep 1997 13:52:18 -0700 (PDT) Cc: ipsec@tis.com In-Reply-To: <3.0.3.32.19970919084246.00997560@dilbert.is.chrysler.com> from "Robert Moskowitz" at Sep 19, 97 08:42:46 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk > Ted and I want to start last call on a set of documents that the IESG will > promote. Our first step is to group the drafts that are related to this > group and then finish up the key drafts. So in this light the key drafts > are: > > draft-ietf-ipsec-arch-sec-01.txt (We are waiting to see 02) This full version is not on the ds.internic.net site. Will 02 be? > draft-ietf-ipsec-ipsec-doi-03.txt (questions on readiness) This revision, while posted to the list, isn't on the ds.internic.net site either. > draft-ietf-ipsec-auth-hmac-md5-96-00.txt This revision is not on the site either. > draft-ietf-ipsec-auth-hmac-sha196-00.txt And while I've got this one up, lemme ask the naive question that probably has been answered during ANX testing. For ESP, do I use the truncated 96-bit HMAC results to place at the end of my ESP datagram? Or do I used the full result? In either case, both of the ipsec-auth documents need to make clear how the auth algorithm in question is used in AH (where 96-bit trunc is useful) and in ESP (where it is probably a don't-care). Thanks, Dan From owner-ipsec Fri Sep 19 16:50:40 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA03518 for ipsec-outgoing; Fri, 19 Sep 1997 16:50:24 -0400 (EDT) Date: Fri, 19 Sep 1997 17:00:23 -0400 Message-Id: <199709192100.RAA05861@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: Roy Pereira Cc: "'rgm3@chrysler.com'" , "'ipsec@tis.com'" In-Reply-To: Roy Pereira's message of Fri, 19 Sep 1997 13:07:02 -0400, Subject: Re: Wrap up for the IPsec drafts Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: owner-ipsec@ex.tis.com Precedence: bulk From: Roy Pereira Date: Fri, 19 Sep 1997 13:07:02 -0400 I would like to see a DES-X ESP draft thougth. The one that exists uses derived IV, thus it is in-appropriate. Perhaps the author can redo it using explicit IV ? Speaking personally, I'd rather not include a document for every single cryptographic algorithm under the sun, just for completeness sake. If there's a constituency that's really going to use DES-X, that's fine. But otherwise, Yet Another Crypto Draft is merely going to confuse people. In fact, we probably have too many crypto algorithms already. Do we have folks who are planning to implement and use all of them? - Ted From owner-ipsec Fri Sep 19 17:04:10 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA03616 for ipsec-outgoing; Fri, 19 Sep 1997 17:03:54 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <199709192052.NAA28212@kebe.eng.sun.com> References: <3.0.3.32.19970919084246.00997560@dilbert.is.chrysler.com> from "Robert Moskowitz" at Sep 19, 97 08:42:46 am Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 19 Sep 1997 17:07:41 -0400 To: Dan.McDonald@Eng.Sun.Com (Dan McDonald) From: Stephen Kent Subject: Re: Wrap up for the IPsec drafts Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Dan, The ESP spec also calls for a 96-bit truncated hash, just for consistency with AH. The same sort of alignment concerns montiavte it, though not so strongly as in the case of AH, as you noted. Steve From owner-ipsec Fri Sep 19 17:33:35 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA03785 for ipsec-outgoing; Fri, 19 Sep 1997 17:33:25 -0400 (EDT) Date: Fri, 19 Sep 1997 17:42:59 -0400 Message-Id: <199709192142.RAA05880@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: ipsec@tis.com Subject: [Theodore Y. Ts'o: Re: Daemon Recovery] Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: owner-ipsec@ex.tis.com Precedence: bulk Charlie gave me permission to forward his e-mail to me to the list; below is his obersvations, followed by my reply. It seems pretty obvious, but given that our previous conversation had talked about "host", and we hadn't really thought about the user-oriented keying, it seems appropriate to remind ourselves that host-based keying might not be all there is. - Ted ------- Forwarded Message Date: Wed, 17 Sep 1997 23:15:36 -0400 From: "Theodore Y. Ts'o" To: Charles Lynn Cc: "Theodore Y. Ts'o" In-Reply-To: Charles Lynn's message of Wed, 17 Sep 97 17:00:18 EDT, <9709172100.AA26988@MIT.EDU> Subject: Re: Daemon Recovery Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Date: Wed, 17 Sep 97 17:00:18 EDT From: Charles Lynn > A better solution might be to include in the ISAKMP negotiations a > notification that at the successful conclusion of this SPI > negotiation, all other SPI's for the same host should be discarded. > What do other people think? Does this mean that if I setup a new SPI, I can wipe yours out? Sounds like DOS. You bring up a good point; in the case of user-based keying, life becomes much more difficult. I think most folks were assuming that the keys in use were host (TCB) based, not user-based --- or at the very least, unprivileged users would not have access to the keying material. I'd think the right thing to do is to specify that when you finish negotiating an SPI, you can invalidate all previous SPI's corresponding to the same public key which was used to establish the new SPI. This would work for either host or user based keying. - Ted P.S. May I forward your observation, and my response, to the ipsec list? ------- End Forwarded Message From owner-ipsec Fri Sep 19 21:32:12 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id VAA04838 for ipsec-outgoing; Fri, 19 Sep 1997 21:30:24 -0400 (EDT) Date: Sat, 20 Sep 97 01:24:13 GMT Daylight Time From: Ran Atkinson Subject: Re: [Theodore Y. Ts'o: Re: Daemon Recovery] To: ipsec@tis.com X-Mailer: Chameleon ATX 6.0, Standards Based IntraNet Solutions, NetManage Inc. X-Priority: 3 (Normal) References: <199709192142.RAA05880@dcl.MIT.EDU> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk --- On Fri, 19 Sep 1997 17:42:59 -0400 "Theodore Y. Ts'o" wrote: > It seems pretty obvious, but given that our previous conversation had > talked about "host", and we hadn't really thought about the > user-oriented keying, it seems appropriate to remind ourselves that > host-based keying might not be all there is. Yes. And thank you very much for remembering and reminding us all of that. > You bring up a good point; in the case of user-based keying, life > becomes much more difficult. I think most folks were assuming that the > keys in use were host (TCB) based, not user-based --- or at the very > least, unprivileged users would not have access to the keying material. Unprivileged users ought not have access to keying material. This ought to be noted very specifically somewhere in {ARCH, ESP/AH}. Vaguely I think that this once lived in the Security Considerations text of the current RFCs, but I haven't verified that just now. Unfortunately, Windows/DOS/MacOS do not have the concept of an unprivileged user [Sommerfeld]. > I'd think the right thing to do is to specify that when you finish > negotiating an SPI, you can invalidate all previous SPI's corresponding > to the same public key which was used to establish the new SPI. This > would work for either host or user based keying. If you'd change "to the same public key which was" into text more like "to the same identity which was", then I think I'd be a little happier. I don't think an implementation is required to retain the "public key" in the SA state, whereas implementations are supposed to retain the "identity" information in the SA state. While I think that "identity" will frequently be identical to "IP address" in many operational situations, its important to design/implement for the general case where "identity" might be something else, such as" FQDN USER_FQDN SUBNET ... Ran rja@inet.org From owner-ipsec Sat Sep 20 17:05:51 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA09680 for ipsec-outgoing; Sat, 20 Sep 1997 16:55:23 -0400 (EDT) Date: Sun, 21 Sep 1997 00:13:22 +0300 (EET DST) From: Helger Lipmaa X-Sender: helger@keeks To: ipsec@tis.com Subject: draft-...-cipher-* In-Reply-To: <199709192100.RAA05861@dcl.MIT.EDU> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk On Fri, 19 Sep 1997, Theodore Y. Ts'o wrote: > Speaking personally, I'd rather not include a document for every single > cryptographic algorithm under the sun, just for completeness sake. Same here. I think that it would be a much better idea to compose one draft for all (or most) block ciphers that would give a general framework on using them in ESP. Parts of this document ought to go like that: ... This document gives implementers general instructions for using any standard block cipher algorithm in CBC mode to secure ESP. For information about concrete ciphers (key sizes, block sizes, performance, patents) see "Handbook of Applied Cryptography". The warnings about weaknesses of concrete ciphers given there (weak keys, minimal number of rounds) given there MUST be followed. Implementers SHOULD also be aware of the newest attacks available in the cryptographical literature. /* I consider [Schneier] to be a unsuitable reference for RFC's. HAC is much better, but not complete (and partly out-of-date). The best reference (imho) available is by Lars Knudsen at http://www.esat.kuleuven.ac.be/~knudsen/bc and is continously changing. Maybe IPSEC WG should contact Lars and ask him to collaborate by adding some IPSEC specific info to this page (e.g., by emphasing for dumb implementers the ciphers and parameters that are considered to be long term secure atm). */ ... ... ESP Payload Most block ciphers in CBC mode require an initialization vector of $b/8$ octets for use with ESP, where $b$ is the block size in bits [Kent97]. The IV MUST precede the data to be encrypted in the packet and must be $b$ octets in length. The IV SHOULD be chosen at random. Common practice is to use random data for the first IV and the last $b/8$ of encrypted data from an encryption process as the IV for the next encryption process. ... XXX Block Size and Padding Block size of cipher algorithm in bits is denoted by $b$. /* Some overall requirements on $b$, e.g. $32|b$ */ Padding is used to align the payload type and pad length octets as specified in [Kent97]. Padding must be sufficient to align the data to be encrypted to an $b/8$ octet ($b$ bit) boundary. ... XXX Some concrete ciphers While writing the draft, IPSEC WG encouraged using of the next ciphers with following parameters. Name | block size | key size | rounds | --------+------------+----------+--------+ DES | 64 | 56 | 16 | ... One should be aware that new attacks are discovered continously, therefore implementers MUST consult the updated information [Knudsen?] once in a while. ... Actually, I think that most implementers are currently doing exactly what I've written here: x one needs general framework how to implement ESP with _any_ block cipher x data given in drafts gets older with every day; things like 'performance' or 'best attack currently known' shouldn't be there at all. For example, in draft-ietf-ipsec-ciph-idea-cbc-00.txt it is written: Normal eight round IDEA is approximately twice as fast [word 'as' missing] DES on 386 and 486 processors. However on a Pentium, both eight round IDEA and 56 bit key, 16 round DES require about the same number of clock cycles per byte encrypted. If you check the page by Knudsen, you get different figures. Best, Helger From owner-ipsec Sat Sep 20 17:21:13 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA09774 for ipsec-outgoing; Sat, 20 Sep 1997 17:18:23 -0400 (EDT) Message-ID: From: Roy Pereira To: "'Helger Lipmaa'" , "'ipsec@tis.com'" Subject: draft-ipsec-cipher-generic.txt (was: draft-...cipher-*) Date: Sat, 20 Sep 1997 17:47:42 -0400 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk I had written such a draft and submitted it before the second last ANX tests to the ANX mailing list, but most peole thought it would be better to have a separate draft for each algorithm. Now that we have a more unified ESP model, it might be worth while to do a generic/multi-algorithm ESP algorithm draft. What do people think? On Saturday, September 20, 1997 5:13 PM, Helger Lipmaa [SMTP:helger@ioc.ee] wrote: > On Fri, 19 Sep 1997, Theodore Y. Ts'o wrote: > > > Speaking personally, I'd rather not include a document for every single > > cryptographic algorithm under the sun, just for completeness sake. > > Same here. I think that it would be a much better idea to compose one > draft for all (or most) block ciphers that would give a general framework > on using them in ESP. > > Parts of this document ought to go like that: > > ... > > This document gives implementers general instructions for using > any standard block cipher algorithm in CBC mode to secure ESP. > > For information about concrete ciphers (key sizes, block sizes, > performance, patents) see "Handbook of Applied Cryptography". The > warnings about weaknesses of concrete ciphers given there (weak keys, > minimal number of rounds) given there MUST be followed. > > Implementers SHOULD also be aware of the newest attacks available in > the cryptographical literature. > > /* I consider [Schneier] to be a unsuitable reference for RFC's. > HAC is much better, but not complete (and partly out-of-date). > The best reference (imho) available is by Lars Knudsen at > http://www.esat.kuleuven.ac.be/~knudsen/bc and is continously > changing. Maybe IPSEC WG should contact Lars and ask him to > collaborate by adding some IPSEC specific info to this page > (e.g., by emphasing for dumb implementers the ciphers and parameters > that are considered to be long term secure atm). > */ > > ... > > ... ESP Payload > > Most block ciphers in CBC mode require an initialization vector of > $b/8$ octets for use with ESP, where $b$ is the block size in > bits [Kent97]. The IV MUST precede the data to be encrypted in the > packet and must be $b$ octets in length. The IV SHOULD be chosen at > random. Common practice is to use random data for the first IV and the > last $b/8$ of encrypted data from an encryption process as the IV for > the next encryption process. > > ... > > XXX Block Size and Padding > > Block size of cipher algorithm in bits is denoted by $b$. /* Some > overall requirements on $b$, e.g. $32|b$ */ > > Padding is used to align the payload type and pad length octets as > specified in [Kent97]. Padding must be sufficient to align the > data to be encrypted to an $b/8$ octet ($b$ bit) boundary. > > ... > > XXX Some concrete ciphers > > While writing the draft, IPSEC WG encouraged using of the next > ciphers with following parameters. > > Name | block size | key size | rounds | > --------+------------+----------+--------+ > DES | 64 | 56 | 16 | > ... > > One should be aware that new attacks are discovered continously, > therefore implementers MUST consult the updated information [Knudsen?] > once in a while. > > ... > > Actually, I think that most implementers are currently doing exactly what > I've written here: > > x one needs general framework how to implement ESP with _any_ block > cipher > x data given in drafts gets older with every day; things like > 'performance' or 'best attack currently known' shouldn't be there at > all. For example, in draft-ietf-ipsec-ciph-idea-cbc-00.txt it is > written: > > Normal eight round IDEA is approximately twice as fast [word 'as' > missing] DES on 386 and 486 processors. However on a Pentium, both > eight round IDEA and 56 bit key, 16 round DES require about the same > number of clock cycles per byte encrypted. > > If you check the page by Knudsen, you get different figures. > > Best, > Helger > From owner-ipsec Sun Sep 21 21:07:17 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id VAA16245 for ipsec-outgoing; Sun, 21 Sep 1997 21:00:55 -0400 (EDT) From: Dan.McDonald@Eng.Sun.Com (Dan McDonald) Message-Id: <199709220109.SAA00251@kebe.eng.sun.com> Subject: Comments on ipsec-arch-sec-01.txt To: kent@bbn.com Date: Sun, 21 Sep 1997 18:09:52 -0700 (PDT) Cc: danmcd@jurassic.eng.Sun.COM (Dan McDonald), ipsec@tis.com X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk The following bullets are comments on the 01 revision of the IPsec Architecture document. Some of this I stated at or before Munich. With Bob and Ted's push to advance these documents, I wanted to make sure I spoke my peace. * It is my opinion that, while there are processing differences between transport and tunnel modes of IPsec, to explicitly distinguish them as an SA attribute is wrong. They should be "Selectors" in your abstraction of the Security Policy Database. I may wish to use a pair of SAs for both tunnel mode and transport mode simultaneously. The differences between tunnel and transport mode are important, but they should be indicated with respect to processing and policy decision making, rather than be an explicit SA attribute. * While I'm on the subject of tunnel mode and policy, I'd like to show an example of why it is so important to get policy enforcment correct. This may seems obvious to some, but a naive implementation may not correctly handle this case. Furthermore, I recall this being in earlier version of the IPsec architecture. Consider the security gateway example... ---- SG =======(The Internet)======== SG' --- It is important to note that SG may accept legitimate SA establishment requests from parties other than SG'. If this is so, it is CRUCIAL that SG take care that a malicious party M doesn't use its legitimate SAs to tunnel forged packets from a.b.d.X to a.b.c.Y. A naive SG implementation may say "Oh, it was decrypted, of COURSE I can forward the inner packet" regardless of WHICH PEER SG sent it. * In section 4.3, there's a sentence that reads: ... SAs that comprise a bundle need may terminate... "need may" was probably a typo. * You may wish to site GKMP as work in progress for multicast key distribution in section 4.7. * In section 5.2 (Inbound IPsec processing), you have reassembly at the END of the steps, rather than at the beginning. * For section 6 (ICMP processing), the question is do you trust the sender of an ICMP packet? If the router that sends the ICMP packet first does a full-blown ISAKMP initiation sequence, I suppose you can trust that it came from that router. A discussion of ICMP trust, and the "advisory" role of ICMP probably is needed. * BTW, if a bump-in-the-stack implementation of IPsec attempts to apply different IPsec algorithms based on the ports is sniffs, it is difficult to apply Path MTU adjustments. * In performance issues, the initial ISAKMP (or Photuris, etc.) processing overhead will be felt in the first packet, and is analogous to ARP resolution or IPv6 Neighbor Discovery. The question is, will the exchange cause a TCP to retransmit the SYN before the exchange is done? (I wish the ANX sessions talked about this.) * My aforementioned example is probably a good candidate for "Security Considerations". Hope this helps, Dan From owner-ipsec Sun Sep 21 22:39:01 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id WAA16705 for ipsec-outgoing; Sun, 21 Sep 1997 22:37:53 -0400 (EDT) Message-ID: <3425DC34.2781@cs.umass.edu> Date: Sun, 21 Sep 1997 22:47:16 -0400 From: Lewis McCarthy Organization: UMass-Amherst Theoretical Computer Science Group, X-Mailer: Mozilla 3.01Gold (X11; U; OSF1 V3.2 alpha) MIME-Version: 1.0 To: IP Security List CC: Steve Kent , Dan McDonald Subject: Re: Comments on ipsec-arch-sec-01.txt References: <199709220109.SAA00251@kebe.eng.sun.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Dan McDonald writes: > The following bullets are comments on the 01 revision of the IPsec > Architecture document. Some of this I stated at or before Munich. As a reminder to others, a copy of draft-ietf-ipsec-arch-sec-01 can be found in the July 30 list archives at in Message-Id: <199707311309.JAA22086@portal.ex.tis.com> [...much elided...] > * You may wish to site GKMP as work in progress for multicast key > distribution in section 4.7. Actually the GKMP documents became Experimental RFCs (2093 & 2094) in July, so they're no longer work in progress in the I-D sense. -Lewis From owner-ipsec Mon Sep 22 10:26:44 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA21204 for ipsec-outgoing; Mon, 22 Sep 1997 10:24:23 -0400 (EDT) Date: Mon, 22 Sep 97 10:19:21 EDT From: wdm@epoch.ncsc.mil (W. Douglas Maughan) Message-Id: <9709221419.AA01158@dolphin.ncsc.mil> To: ipsec@tis.com, dharkins@cisco.com, jburke@cylink.com Subject: Re: BAD_ID_RANGE Notification per Oakley Sender: owner-ipsec@ex.tis.com Precedence: bulk Dan / John, > Oakley ver-04 still contains this text (in 5.4 Phase 2 - Quick Mode, a > couple of paragraphs from the end, immediately before the description of > negotiating multiple SA's): > > [ .. ]If an ID range > (see Appendix A of [Pip96]) is not acceptable (for example, the > specified subnet is too large) a BAD_ID_RANGE notify message followed > by an acceptible ID range, in an ID payload, MUST be sent. > > Someone pointed out on the list a while ago that the provisions for > notification of bad address are no longer in the ISAKMP spec. Is this > "MUST" in Oakley meant to stand or should we expect it to go away? Was this ever resolved? Do I need to add an additional Notify Message Error Type to the ISAKMP draft? Or is there an existing Error Type that can be used for this message? Doug Maughan From owner-ipsec Mon Sep 22 13:39:08 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA22914 for ipsec-outgoing; Mon, 22 Sep 1997 13:37:55 -0400 (EDT) Date: Mon, 22 Sep 97 13:32:55 EDT From: wdm@epoch.ncsc.mil (W. Douglas Maughan) Message-Id: <9709221732.AA01228@dolphin.ncsc.mil> To: greg.carter@entrust.com Subject: RE: comments on Oakley test items Cc: anx-sec@dot.netrex.net, dharkins@cisco.com, ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Greg, > > I could also argue that this is not a discrepancy with the base ISAKMP > >spec. The M-ID and SPI would still identify the correct state as dictated > >by section 2.4. It's just that the M-ID and SPI would be in the body of > >the notify message as the ISAKMP header and SA payload to which the notify > >refers. The ISAKMP header of the Informational Exchange would be unique > >to the Informational Exchange. > > Hi Dan, > I can't find where it says to include the M-ID/SPI in the body of the > notify message, nor where it says to include the ISAKMP header. ISAKMP > states the data portion of a notify message is DOI specific, DOIv3 > doesn't specify any thing special, so I would assume nothing. > > I agree that ISAKMP-Cookies, Protocol-ID, and SPI (so the data available > during notify parse) is enough to find a bad Quick Mode BUT if and only > if each side gets past the SA parse since you need to send back the > other sides SPIs. > > There are a few cases where I will reject before I get to a deep parse > of the SA payload, bad hash, invalid payload, no SA payload, who knows, > etc... > > Can we have the DOI define the notification data to include the M-ID. > Its in the clear (so it wont get screwed by IV/crypto mix ups) and > relates to the whole Quick Mode (where as SPIs - multiple SAs per quick > mode, AND and ORing). > > Sorry, don't want to harp on this, but specifying the M-ID leaves > nothing to be desired and covers 100% of the error conditions, where as > the current solution relies on a successful parse of the SA payload > which seems rather optimistic. > I realize this has been a discussion between you and Dan, but I thought I'd stick my nose in. Section 4.8 of ISAKMP-08 shows the values included in an Informational Exchange (notify or delete). This includes an ISAKMP Header (containing the M-ID) and the Notify Payload, described in section 3.15. This payload includes DOI, P-ID, and SPI. The data portion of the message is DOI specific (and you're right that DOIv3 doesn't have anything extra). The Message Type field gives the details of the message. Maybe I'm missing your point, but what isn't there that you need? Is there something that needs to be added to the ISAKMP draft or is it needed in the DOI draft? Doug Maughan From owner-ipsec Mon Sep 22 15:50:52 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA23989 for ipsec-outgoing; Mon, 22 Sep 1997 15:49:25 -0400 (EDT) Message-ID: <28347281A2B5CF119AB000805FD4186603D73BA4@RED-77-MSG.dns.microsoft.com> From: Paul Leach To: ipsec@tis.com, "'Ran Atkinson'" Subject: RE: [Theodore Y. Ts'o: Re: Daemon Recovery] Date: Mon, 22 Sep 1997 12:59:09 -0700 X-Priority: 3 X-Mailer: Internet Mail Service (5.0.1459.27) Sender: owner-ipsec@ex.tis.com Precedence: bulk > ---------- > From: Ran Atkinson[SMTP:rja@inet.org] > Sent: Friday, September 19, 1997 6:24 PM > To: ipsec@tis.com > Subject: Re: [Theodore Y. Ts'o: Re: Daemon Recovery] > > > > > You bring up a good point; in the case of user-based keying, life > > becomes much more difficult. I think most folks were assuming that > the > > keys in use were host (TCB) based, not user-based --- or at the very > > least, unprivileged users would not have access to the keying > material. > > Unprivileged users ought not have access to keying material. This > ought > to be noted very specifically somewhere in {ARCH, ESP/AH}. Vaguely I > think that this once lived in the Security Considerations text of the > current RFCs, but I haven't verified that just now. Unfortunately, > Windows/DOS/MacOS do not have the concept of an unprivileged user > [Sommerfeld]. > It is most important that unprivileged users don't have access to other users' keying material -- on the above systems, which are single user, that's still true. Perhaps also worth noting is that with host-based keying, the identity being trusted (in the absence of tamper-proof hardware) is the administrator -- which in the case of the above operating systems, is also the user. I.e, on those systems, nothing prevents the user from moving the host's key to another host. Finally, Windows NT does have a notion of unprivileged user (which I mention solely because the reference to "Windows" above is potentially ambiguous). Paul From owner-ipsec Mon Sep 22 16:00:35 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA24038 for ipsec-outgoing; Mon, 22 Sep 1997 16:00:27 -0400 (EDT) Date: Mon, 22 Sep 97 15:55:34 EDT From: wdm@epoch.ncsc.mil (W. Douglas Maughan) Message-Id: <9709221955.AA01290@dolphin.ncsc.mil> To: jburke@cylink.com, ben@Ascend.COM, dharkins@cisco.com Subject: RE: Ordering of payloads Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Ben / John / Dan, > John Burke writes: > > > The point here is, do we agree at this time that we should require everyone > > to do the handling I describe? I.E. find the SA first and do it before > > passing over the other loads? We actually did not implement this way (nor > > as I remember did the reference implementation for ISAKMP v-06). But where > > do others stand, A. for the upcoming interoperation tests and B. later for > > the final ISAKMP draft? > > 'twould be nice to have all the code space in the world to work in... > > Some of us are extremely restricted as to how much code space we are > allowed to use. (If I remember the numbers right, on some of our boxes, > the entire router load needs to fit into less space than Entrust's > ISAKMP implementation takes.) So, anything that helps us to reduce the > amount of completely unnecessary processing would be really helpful. > > I'm trying to get my brain around the reason it is helpful to allow > payloads to be in any order, but I am fairly certain we don't lose any > functionality by requiring that the SA payload in phase I exchanges be > before any other payloads whose interpretation depend on our SA > negotiation. > > I'm wondering if the WG hasn't been overcome by a bad case of creeping > featuritis... :) I've been following this discussion for the past week and want to come to some resolution on this point. I'm trying to get a new version of the draft out by the end of this week. I agree that this may be a case of featuritis, but if it makes for more interoperable implementations, then maybe it's worth it. Is there concensus about this issue? Should I modify the ISAKMP draft to specify that the SA payload MUST be the first payload of the first message of a Phase 1 exchange? or do we want to just let people implement it how they want? Thoughts, anyone?? Thanks, Doug Maughan From owner-ipsec Mon Sep 22 23:52:29 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id XAA26526 for ipsec-outgoing; Mon, 22 Sep 1997 23:47:26 -0400 (EDT) X-Sender: kent@po1.bbn.com (Unverified) Message-Id: In-Reply-To: <199709220109.SAA00251@kebe.eng.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 22 Sep 1997 21:15:24 -0500 To: Dan.McDonald@Eng.Sun.Com (Dan McDonald) From: Stephen Kent Subject: Re: Comments on ipsec-arch-sec-01.txt Cc: Dan.McDonald@Eng.Sun.Com (Dan McDonald), ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Dan, >* It is my opinion that, while there are processing differences between >transport and tunnel modes of IPsec, to explicitly distinguish them as an SA >attribute is wrong. They should be "Selectors" in your abstraction of the >Security Policy Database. I may wish to use a pair of SAs for both tunnel >mode and transport mode simultaneously. The differences between tunnel and >transport mode are important, but they should be indicated with respect to >processing and policy decision making, rather than be an explicit SA >attribute. We agree that tunnel vs. transport mode needs to be in the SPD. Depedning on the context of the IPsec implementation, I think it will be necessary to specify that as an SA attribute, but I'm willing to remove it there is agreement among implementors that not all implementations will need this attribute. >* While I'm on the subject of tunnel mode and policy, I'd like to show an >example of why it is so important to get policy enforcment correct. This may >seems obvious to some, but a naive implementation may not correctly handle >this case. Furthermore, I recall this being in earlier version of the IPsec >architecture. Consider the security gateway example... > > ---- SG =======(The Internet)======== SG' --- > >It is important to note that SG may accept legitimate SA establishment >requests from parties other than SG'. If this is so, it is CRUCIAL that SG >take care that a malicious party M doesn't use its legitimate SAs to tunnel >forged packets from a.b.d.X to a.b.c.Y. A naive SG implementation may say >"Oh, it was decrypted, of COURSE I can forward the inner packet" regardless >of WHICH PEER SG sent it. I too pushed for checking incoming IP source addresses against SA parameters long ago, for precisely this reason, but somehow it didn't make it into the I-D. I'll correct that omission. >* You may wish to site GKMP as work in progress for multicast key >distribution in section 4.7. In paring down the Arch Doc, we'll just make passing mention of this, and defer the problem for now. >* In section 5.2 (Inbound IPsec processing), you have reassembly at the END >of the steps, rather than at the beginning. We'll go back and fix it. >* For section 6 (ICMP processing), the question is do you trust the sender of >an ICMP packet? If the router that sends the ICMP packet first does a >full-blown ISAKMP initiation sequence, I suppose you can trust that it came >from that router. A discussion of ICMP trust, and the "advisory" role of >ICMP probably is needed. We may defer most of the ICMP issue, or make a simple statement about the "do you trust the source" problem. >* BTW, if a bump-in-the-stack implementation of IPsec attempts to apply >different IPsec algorithms based on the ports is sniffs, it is difficult to >apply Path MTU adjustments. Yes, it is, but I've been asked to not rule out BITS implementations that take extraodrinary measures to compensate. >* In performance issues, the initial ISAKMP (or Photuris, etc.) processing >overhead will be felt in the first packet, and is analogous to ARP resolution >or IPv6 Neighbor Discovery. The question is, will the exchange cause a TCP >to retransmit the SYN before the exchange is done? (I wish the ANX sessions >talked about this.) Good point. >* My aforementioned example is probably a good candidate for "Security >Considerations". Which example? Steve From owner-ipsec Tue Sep 23 09:08:19 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA29788 for ipsec-outgoing; Tue, 23 Sep 1997 09:06:00 -0400 (EDT) Date: Tue, 23 Sep 97 12:57:26 GMT Daylight Time From: Ran Atkinson Subject: Re: Comments on ipsec-arch-sec-01.txt To: ipsec@tis.com X-Mailer: Chameleon ATX 6.0, Standards Based IntraNet Solutions, NetManage Inc. X-Priority: 3 (Normal) References: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk --- On Mon, 22 Sep 1997 21:15:24 -0500 Stephen Kent wrote: > >* It is my opinion that, while there are processing differences between > >transport and tunnel modes of IPsec, to explicitly distinguish them as an SA > >attribute is wrong. They should be "Selectors" in your abstraction of the > >Security Policy Database. I may wish to use a pair of SAs for both tunnel > >mode and transport mode simultaneously. The differences between tunnel and > >transport mode are important, but they should be indicated with respect to > >processing and policy decision making, rather than be an explicit SA > >attribute. > > We agree that tunnel vs. transport mode needs to be in the SPD. Depedning > on the context of the IPsec implementation, I think it will be necessary to > specify that as an SA attribute, but I'm willing to remove it there is > agreement among implementors that not all implementations will need this > attribute. Requiring that the tunnel/transport-mode distinction be part of the SA will break several existing implementations that my employer is using. It also goes against the grain of not changing the specification in a way that makes existing conforming implementations non-conforming. I would also request that it be deleted as a mandatory or recommended SA attribute. > >* For section 6 (ICMP processing), the question is do you trust the sender of > >an ICMP packet? If the router that sends the ICMP packet first does a > >full-blown ISAKMP initiation sequence, I suppose you can trust that it came > >from that router. A discussion of ICMP trust, and the "advisory" role of > >ICMP probably is needed. > > We may defer most of the ICMP issue, or make a simple statement about the > "do you trust the source" problem. I consider it valuable to note the serious problems with unauthenticated ICMP messages. If these aren't noted, some well-intentioned but naive implementer might actually code up Simpson's proposed ICMP extensions, thereby creating a security problem for that implementation. By at least clearly noting the issues, a naive implementer can become informed. > >* BTW, if a bump-in-the-stack implementation of IPsec attempts to apply > >different IPsec algorithms based on the ports is sniffs, it is difficult to > >apply Path MTU adjustments. > > Yes, it is, but I've been asked to not rule out BITS implementations that > take extraodrinary measures to compensate. Perhaps its useful to note in more detail how much extraordinary effort is required to get a BITS approach to work properly. I suspect that most of the BITS implementations won't go far enough to really make things work properly. Personally, I don't believe that the BITS approach is necessary given that various vendors have already shipped stacks for Windows that include IPsec and Microsoft has IPsec code being written for its stacks. The historic justification for the BITS approach was Microsoft systems. From owner-ipsec Tue Sep 23 09:40:27 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA00035 for ipsec-outgoing; Tue, 23 Sep 1997 09:40:05 -0400 (EDT) Message-Id: <199709231349.GAA28157@pita.cisco.com> To: Ran Atkinson cc: ipsec@tis.com Subject: Re: Comments on ipsec-arch-sec-01.txt In-reply-to: Your message of "Tue, 23 Sep 1997 12:57:26 EST." Date: Tue, 23 Sep 1997 06:49:44 -0700 From: Derrell Piper Sender: owner-ipsec@ex.tis.com Precedence: bulk > Requiring that the tunnel/transport-mode distinction be part of the SA > will break several existing implementations that my employer is using. > It also goes against the grain of not changing the specification in a way > that makes existing conforming implementations non-conforming. I would > also request that it be deleted as a mandatory or recommended SA attribute. Many of the interoperable ISAKMP/Oakley implementations here at the ANX are using the encapsulation mode attribute to negotiate tunnel/transport mode. Though not mandated by the current IPSEC DOI, most of us have implemented this attribute and find it quite useful to know a priori whether we're negotiating transport or tunnel mode. You'll note that the DOI does *not* mandate this attribute precisely because you (and others) raised objections to doing so way back when. However there are many of us who find this attribute useful and I doubt there is concensus to remove it from the DOI. Derrell From owner-ipsec Tue Sep 23 10:01:44 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA00252 for ipsec-outgoing; Tue, 23 Sep 1997 10:01:33 -0400 (EDT) To: IETF-Announce@ietf.org Cc: ipsec@tis.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-ipsec-doi-04.txt Date: Tue, 23 Sep 1997 09:41:44 -0400 Message-ID: <9709230941.aa06485@ietf.org> Sender: owner-ipsec@ex.tis.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : The Internet IP Security Domain of Interpretation for ISAKMP Author(s) : D. Piper Filename : draft-ietf-ipsec-ipsec-doi-04.txt Pages : 25 Date : 1997-09-22 The Internet Security Association and Key Management Protocol (ISAKMP) defines a framework for security association management and cryptographic key establishment for the Internet. This framework consists of defined exchanges and processing guidelines that occur within a given Domain of Interpretation (DOI). This document details the Internet IP Security DOI, which is defined to cover the IP security protocols that use ISAKMP to negotiate their security associations. For a description of how the IPSEC DOI fits into the overall IP Security Documentation framework, please see [ROADMAP]. For a list of changes since the previous version of the IPSEC DOI, please see Section 5. Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-ipsec-doi-04.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-ipsec-doi-04.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-ipsec-doi-04.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970922105259.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-ipsec-doi-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-ipsec-doi-04.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970922105259.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec Tue Sep 23 10:16:08 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA00404 for ipsec-outgoing; Tue, 23 Sep 1997 10:15:04 -0400 (EDT) Date: Tue, 23 Sep 1997 09:23:30 -0500 Message-Id: <199709231423.JAA24678@beavis.smallworks.com> From: Jim Thompson To: rja@inet.org CC: ipsec@tis.com In-reply-to: (message from Ran Atkinson on Tue, 23 Sep 97 12:57:26 GMT Daylight Time) Subject: Re: Comments on ipsec-arch-sec-01.txt Sender: owner-ipsec@ex.tis.com Precedence: bulk > > Yes, it is, but I've been asked to not rule out BITS implementations that > > take extraodrinary measures to compensate. > > Perhaps its useful to note in more detail how much extraordinary effort is > required to get a BITS approach to work properly. I suspect that most of > the BITS implementations won't go far enough to really make things work > properly. > > Personally, I don't believe that the BITS approach is necessary given that > various vendors have already shipped stacks for Windows that include IPsec > and Microsoft has IPsec code being written for its stacks. The historic > justification for the BITS approach was Microsoft systems. Microsoft, Sun, HP, ... If you seek to eliminate BITS implementations, then you will likely 'lock-out' several IPSEC vendors. (Anyone who doesn't have access to the source for the IP portion of the stack.) -- Jim Thompson / Smallworks, Inc. / jim@smallworks.com 512 338 0619 phone / 512 338 0625 fax "Faster, faster, until the thrill of speed overcomes the fear of death." --Hunter S. Thompson From owner-ipsec Tue Sep 23 11:30:55 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA01046 for ipsec-outgoing; Tue, 23 Sep 1997 11:29:05 -0400 (EDT) Message-ID: <3427E256.6F50@fet.com> Date: Tue, 23 Sep 1997 08:37:58 -0700 From: "Scott G. Kelly" Organization: Furukawa Electric Technologies, Inc. X-Mailer: Mozilla 3.03 (Win95; U) MIME-Version: 1.0 To: ipsec@tis.com Subject: [Fwd: Re: Comments on ipsec-arch-sec-01.txt] Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ipsec@ex.tis.com Precedence: bulk Message-ID: <3427E1A5.26B8@fet.com> Date: Tue, 23 Sep 1997 08:35:01 -0700 From: "Scott G. Kelly" Organization: Furukawa Electric Technologies, Inc. X-Mailer: Mozilla 3.03 (Win95; U) MIME-Version: 1.0 To: Ran Atkinson Subject: Re: Comments on ipsec-arch-sec-01.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Here we go again... Once again, let me qualify this by saying that it is not so much this particular post as it is the general issue raised here that I am commenting on: > Requiring that the tunnel/transport-mode distinction be part of the SA > will break several existing implementations that my employer is using. > It also goes against the grain of not changing the specification in a way > that makes existing conforming implementations non-conforming. The convenience of your employer *should not* be an issue here. How this ever became a criteria for deciding if a change is appropriate (if in fact it has) is beyond me. We are talking about the *world's* communications system here; not just the one which will be used by Cisco, BBN, USR, or . If it is inconvenient to make a design change which corrects a flaw in the system, that is the price you pay for leading the crowd - that is why we call it 'the bleeding edge'. From owner-ipsec Tue Sep 23 14:36:09 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA02565 for ipsec-outgoing; Tue, 23 Sep 1997 14:34:07 -0400 (EDT) Message-ID: <34280DD5.728@fet.com> Date: Tue, 23 Sep 1997 11:43:33 -0700 From: "Scott G. Kelly" Organization: Furukawa Electric Technologies, Inc. X-Mailer: Mozilla 3.03 (Win95; U) MIME-Version: 1.0 To: ipsec@tis.com Subject: Re: Comments on ipsec-arch-sec-01.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Here we go again... Once again, let me qualify this by saying that it is not so much this particular post as it is the general issue raised here that I am commenting on: > Requiring that the tunnel/transport-mode distinction be part of the SA > will break several existing implementations that my employer is using. > It also goes against the grain of not changing the specification in a way > that makes existing conforming implementations non-conforming. The convenience of your employer *should not* be an issue here. How this ever became a criteria for deciding if a change is appropriate (if in fact it has) is beyond me. We are talking about the *world's* communications system here; not just the one which will be used by Cisco, BBN, USR, or . If it is inconvenient to make a design change which corrects a flaw in the system, that is the price you pay for leading the crowd - that is why we call it 'the bleeding edge'. From owner-ipsec Tue Sep 23 14:53:57 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA02696 for ipsec-outgoing; Tue, 23 Sep 1997 14:53:37 -0400 (EDT) From: touch@isi.edu Date: Tue, 23 Sep 1997 12:03:17 -0700 Posted-Date: Tue, 23 Sep 1997 12:03:17 -0700 Message-Id: <199709231903.MAA03725@rum.isi.edu> To: ipsec@tis.com Subject: performance comparison kernel patches available Cc: touch@isi.edu X-Sun-Charset: US-ASCII X-auto-sig-adder-by: faber@isi.edu Sender: owner-ipsec@ex.tis.com Precedence: bulk The ATOMIC-2 project is announcing a SunOS 4.1.3 kernel patch and tool set for comparing the performance of authentication in IP. The code includes: kernel patches for various algorithms, including 'null' and 'data touching only', to compare algorithms and the overhead of header processing, etc. user-level test program that uses the socket options provided by the kernel patch (used for testing or as a template) scripts to gather repeated runs and process data into plots automatically See the README below. The file is available on the ATOMIC-2 tools page: http://www.isi.edu/atomic2/tools.html Please let us know if it's helpful, and if there are any questions. Thanks Joe ----------------------- ************************************************************************ README Copyright (c) 1997 University of Southern California. All rights reserved. Redistribution and use in source and binary forms are permitted provided that the above copyright notice and this paragraph are duplicated in all such forms and that any documentation, advertising materials, and other materials related to such distribution and use acknowledge that the software was developed by the University of Southern California, Information Sciences Institute. The name of the University may not be used to endorse or promote products derived from this software without specific prior written permission. THIS SOFTWARE IS PROVIDED "AS IS" AND WITHOUT ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. ************************************************************************ This tarfile includes patches for testing the performance of IPv4 Authentication Header processing, and to compare the performance of various authentication algorithms inside an IP implementation. Further information can be obtained from http://www.isi.edu/atomic2/ Tarfile definition: o SunOS 4.1.3 patchfiles to add IPv4 Authentication Headers (RFC 1826) contained in the following five directories: netinet os sun4m sys conf definition: No keying (to be used to stream performance only) Various algorithms: MD5 As per RFC 1321. (uses little-endian byte order) MD5-optimized Source-code optimized version of MD5, as per J. Touch, "Performance Analysis of MD5", Sigcomm '95, pp. 77-86. NBO-MD5-opt Network-standard byte order version of MD5-optimized. AHA Alternate Hash Algorithm, as suggested in the above Sigcomm paper, by J. Touch. (byte-order invariant) ROG "Alternate Hash" (a.k.a. AH), as per P. Rogaway, "Design and Analysis of Message Authentication Codes," Proc. RSA Data Security Conf., 1996. (uses little-endian byte order) NBO-ROG Network-standard byte order version of ROG. CKSUM Internet checksum algorithm (used as a hash), as per RFC 1071. Used to measure the data-touching overheads, as a 'trivial' algorithm that touches all data. NULL-CKSUM Insert and delete AH headers, but perform no authentication algorithm. Used to measure the header processing overheads. o 'blast' test program The program tests end-to-end performance over TCP, UDP, and paced UDP transfers. Blast has been modified to include command-line options to socket options to engage the various algorithms listed above. Pacing is included to measure the optimal UDP throughput. Unpaced UDP often overruns the receive buffer, resulting in good measurements of send-side performance, but poor measures of receive-side performance. Pacing is optimized to estimate an upper bound on receive-side performance: TCP reliable end-to-end performance UDP upper-bound on send-side performance only UDP_PACED upper-bound on receive-side performance only Blast also provides a template for using the socket options to engage the algorithms. o 'script' test directory Perl (v5) scripts used to gather data via blast tests, and plot the results (using plot). It includes automatic pacing determination. The following is a brief summary of our conclusions: Authentication is often viewed as an end-to-end performance bottleneck in networks. To analyze the impact of IP Authentication Headers (AHs) on end-to-end performance, a comparison of IP AH algorithms in IPv4 on SunOS was completed, indicating that MD5 is 1/3 as fast as stand-alone MD5 (in memory). Network-standard byte-order (NSBO) versions of several hash algorithms were compared to ISI's Alternate Hash Algorithm (AHA) which is native to any byte order [see reference J. Touch, "Performance Analysis of MD5," Proc. ACM SIGCOMM '95, Boston, MA, Aug. 1995, pp. 77-86]. In NSBO, Rogaway's Alternate Hash (AH) [P. Rogaway, "Design and Analysis of Message Authentication Codes," Proc. RSA Data Security Conf., Jan. 1996] is nearly twice the speed of MD5. AHA is the fastest current algorithm, and is twice as fast as AH, which is the next-fastest. This comparison is being used to suggest alternatives to MD5 for IP-level authentication, to enable authentication while retaining high bandwidth. The following people have contributed to this code: Joe Touch Project leader, overall architecture. Optimized MD5 algorithm, AHA algorithm designs. Annette DeSchon Initial blast design and implementation. Avneesh Sachdev Initial version of IPv4 kernel patches for MD5, MD5-OPT, and modifications to blast to engage socket options. Darshan Jani Final implementation of patches, blast, and scripts. Contact touch@isi.edu for more information, or contact the ATOMIC-2 web pages (http://www.isi.edu/atomic2). (end.) ---------------------------------------------------------------------- Joe Touch - touch@isi.edu http://www.isi.edu/~touch/ ISI / Project Leader, ATOMIC-2, LSAM http://www.isi.edu/atomic2/ USC / Research Assistant Prof. http://www.isi.edu/lsam/ From owner-ipsec Tue Sep 23 15:53:57 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA03233 for ipsec-outgoing; Tue, 23 Sep 1997 15:52:42 -0400 (EDT) From: Dan.McDonald@Eng.Sun.Com (Dan McDonald) Message-Id: <199709232002.NAA03371@kebe.eng.sun.com> Subject: Re: Comments on ipsec-arch-sec-01.txt To: ipsec@tis.com Date: Tue, 23 Sep 1997 13:02:14 -0700 (PDT) In-Reply-To: <199709231349.GAA28157@pita.cisco.com> from "Derrell Piper" at Sep 23, 97 06:49:44 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk > Many of the interoperable ISAKMP/Oakley implementations here at the ANX are > using the encapsulation mode attribute to negotiate tunnel/transport mode. > Though not mandated by the current IPSEC DOI, most of us have implemented > this attribute and find it quite useful to know a priori whether we're > negotiating transport or tunnel mode. You'll note that the DOI does *not* > mandate this attribute precisely because you (and others) raised objections > to doing so way back when. However there are many of us who find this > attribute useful and I doubt there is concensus to remove it from the DOI. I was never questioning its value in the DOI. I imagine it could be quite useful for all sorts of policy decisions during key mgmt. I do appreciate that the DOI allows for "both" when it is unspecified. I like this attribute in the DOI because of what it enables w.r.t. policy. I was questioning the whether or not it belonged as a required SA attribute in the IPsec _architecture_ document. I've always thought of the case where two IPsec routers use the same SA to protect traffic between themselves in transport mode with the same SAs they use to protect packets they're forwarding in tunnel mode. Just to be clear. Dan From owner-ipsec Tue Sep 23 19:11:23 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA04618 for ipsec-outgoing; Tue, 23 Sep 1997 19:10:16 -0400 (EDT) Message-ID: <342850A2.E966AE4D@newoak.com> Date: Tue, 23 Sep 1997 19:28:34 -0400 From: smamros@newoak.com (Shawn Mamros) X-Mailer: Mozilla 4.0 [en] (WinNT; U) MIME-Version: 1.0 To: ipsec@tis.com CC: smamros@newoak.com Subject: Experimental SA attributes X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk The new DOI (-04) draft defines a range of SA attribute type values which are designated for "experimental use". Seeing as these attributes only apply to Phase II, is there any intention of doing something similar for the Phase I attributes in the resolution draft? (I didn't see any such range defined in the current isakmp-oakley-04 draft.) -Shawn Mamros E-mail to: smamros@newoak.com From owner-ipsec Wed Sep 24 11:50:38 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA10973 for ipsec-outgoing; Wed, 24 Sep 1997 11:44:00 -0400 (EDT) Message-Id: <3.0.3.32.19970924115051.006adf48@pop.pn.com> X-PGP-Key: X-Sender: rodney@pop.pn.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Wed, 24 Sep 1997 11:50:51 -0400 To: ipsec@tis.com From: Rodney Thayer Subject: [Ottawa bakeoff feedback] problem with ESP Padding Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk Here at the Ottawa ANX workshop we have found a problem with the definition of Padding in the ESP document. We found this problem: The text in sections 2.4 and 2.5 of draft-ietf-ipsec-esp-v2-00.txt discusses Padding and Pad Length. We found that people (including myself) interpreted this like this: Given a block that ends in 'xx xx', to form the tail end of the ESP message, you would get xx xx [Padding=1 2 3 4] [PadLth=4] [NxtProt=4] Note this has the padding stuff being 1..2..3..4..4. That last 4 is the Pad Length. It is the length of the "Padding field", the field BEFORE the Pad Length. The "1.2.3.4" is the Pad (value). It is sort of self-describing. (The NxtProt is the Next Protocol, e.g. a 4 for IP.) This is wrong. It doesn't work for hardware vendors. It does not meet the requirement for self-describing padding, as hardware vendors requested and in the style of PPP. Here is what we should do: Given a block that ends in 'xx xx', the tail of the ESP message would be xx xx [Padding=1 2 3 4]+[PadLth=5] [NxtProt=4] This changes the Pad Length field to mean "the length of the padding field, counting the length byte itself". Note that since the Pad Length is mandatory, the minimum value for this is a 1. This has the padding stuff being 1..2..3..4..5. I propose the draft text change. I propose that section 2.5 now on page 7 change to this: "2.5 Pad Length The Pad Length field indicates the number of pad bytes in the message, including itself. The range of valid values is 1..255, where a value of one means that no Padding bytes are present, other than the Pad Length itself. Zero is not a valid Pad Length field. The Pad Length field is mandatory." This will of course break all the ESP implementations that support the current draft. Note that you can build in backwards compatability by implementing this: if pad length > 1 then if pad length byte is the same as the previous byte then implement previous pad algorithm i.e. pad_length++; From owner-ipsec Wed Sep 24 12:09:05 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA11143 for ipsec-outgoing; Wed, 24 Sep 1997 12:08:25 -0400 (EDT) Date: Wed, 24 Sep 97 15:57:43 GMT Daylight Time From: Ran Atkinson Subject: Re: Comments on ipsec-arch-sec-01.txt To: ipsec@tis.com X-Mailer: Chameleon ATX 6.0, Standards Based IntraNet Solutions, NetManage Inc. X-Priority: 3 (Normal) References: <34280DD5.728@fet.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk --- On Tue, 23 Sep 1997 11:43:33 -0700 "Scott G. Kelly" wrote: > > Requiring that the tunnel/transport-mode distinction be part of the SA > > will break several existing implementations that my employer is using. > > It also goes against the grain of not changing the specification in a way > > that makes existing conforming implementations non-conforming. > > The convenience of your employer *should not* be an issue here. Actually, stability of the protocol, which is what the above discusses, is ENTIRELY relevant. Its relevant to nearly every IETF protocol design activity in fact. Further, there was general agreement within the IPsec WG in the Summer of 1996 that existing implementations would not be made non-conforming unless necessary to fix some known security flaw (e.g. the move from RFC-1829 to the Hughes/Madson DES+HMAC MD5 fixes a flaw published in [Bellovin96]). > How this ever became a criteria for deciding if a change is appropriate (if in > fact it has) is beyond me. Probably because you aren't understanding all of what I said, please see below. > We are talking about the *world's* > communications system here; not just the one which will be used by > Cisco, BBN, USR, or . If it is inconvenient to make a > design change which corrects a flaw in the system, that is the price you > pay for leading the crowd - that is why we call it 'the bleeding edge'. No one has suggested there is a flaw. In fact, there is no security flaw that is being corrected here. This assumption on your part might be the root of the misunderstanding. The argument for NOT requiring that the tunnel/transport attribute be part of an SA is in fact -- that the protocol DOES need to be general to many different organisations. So your assertion at the bottom, supports my assertion that the tunnel/transport attribute ought not be mandated for each SA. As it happens, I agree entirely with Derrell Piper's note that I just read: - There are times when it might be useful to negotiate the tunnel/transport attribute, hence it should be in the DOI. - There are times when it might be useful to not negotiate the tunnel/transport attribute, hence it should not be mandatory to negotiate each time. - The same is true for an SA. It would be fine to say that the tunnel/transport attribute MAY be part of an SA. It would be wrong to require that the tunnel/transport attribute MUST be part of each SA. Ran rja@inet.org From owner-ipsec Wed Sep 24 12:28:39 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA11253 for ipsec-outgoing; Wed, 24 Sep 1997 12:26:57 -0400 (EDT) Message-ID: <3429416A.3E17@fet.com> Date: Wed, 24 Sep 1997 09:35:54 -0700 From: "Scott G. Kelly" Organization: Furukawa Electric Technologies, Inc. X-Mailer: Mozilla 3.03 (Win95; U) MIME-Version: 1.0 To: Ran Atkinson CC: ipsec@tis.com Subject: Re: Comments on ipsec-arch-sec-01.txt References: <3427E1A5.26B8@fet.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk I think I inadvertantly caused some confusion due to my previous post on this subject. I owe it to Ran Atkinson to clarify my comments. I should make clear that I was not attempting to comment on the object of his argument, that is, as to whether 'Requiring that the tunnel/transport-mode distinction be part of the SA' was appropriate or not. Perhaps it is not appropriate; I have not had an opportunity to study that issue as of yet. In terms of my post, no disrespect was intended, and neither was my post meant to be a flame. I recognize that Ran is one of the original designers of the IP security architecture. I have seen code, RFC's, and wg drafts which he has authored. My point is this: when IP security was originally designed and implemented, there were things which were not, indeed could not have been, foreseen. As a result, there have been a series of refinements to the protocols proposed by various members of this working group. Unfortunately, sometimes those proposals are dismissed by various members of the wg using some variation of the argument Ran presented, e.g. 'it will cost my company money to change this, so I don't want to do it.' Alternatively, the argument may be along the lines of 'I thought we agreed there would be no more changes which break currently operating code.' My point is that these types of arguments should not be entertained. As I said, I have not taken the time to examine the original issue this thread pertains to, the one having to do with tunnel/transport attribute representation, but if there is a good argument why this should not be changed, why not let it stand on its own merit? I meant no offense and no disrespect. I guess I'm just somewhat of an idealist, possibly due to my inexperience with the IETF. I just think this wg owes it to the world to give them the best possible protocol. Scott From owner-ipsec Wed Sep 24 15:29:47 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA12406 for ipsec-outgoing; Wed, 24 Sep 1997 15:28:29 -0400 (EDT) Message-Id: <199709241937.PAA00747@thunk.ch.apollo.hp.com> X-Authentication-Warning: thunk.ch.apollo.hp.com: sommerfeld owned process doing -bs To: "Scott G. Kelly" Cc: Ran Atkinson , ipsec@tis.com Subject: Re: Comments on ipsec-arch-sec-01.txt In-Reply-To: scott's message of Wed, 24 Sep 1997 09:35:54 -0700. <3429416A.3E17@fet.com> Date: Wed, 24 Sep 1997 15:37:43 -0400 From: Bill Sommerfeld Sender: owner-ipsec@ex.tis.com Precedence: bulk > I meant no offense and no disrespect. I guess I'm just somewhat of an > idealist, possibly due to my inexperience with the IETF. I just think > this wg owes it to the world to give them the best possible protocol. I think this wg owes the world an IP security protocol. If we wait until we have the "best possible" protocol, we'll never be done. From owner-ipsec Wed Sep 24 15:39:35 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA12459 for ipsec-outgoing; Wed, 24 Sep 1997 15:39:29 -0400 (EDT) Message-Id: <199709241948.PAA00692@morden.sandelman.ottawa.on.ca> To: ipsec@tis.com Subject: Re: [Ottawa bakeoff feedback] problem with ESP Padding In-reply-to: Your message of "Wed, 24 Sep 1997 11:50:51 EDT." <3.0.3.32.19970924115051.006adf48@pop.pn.com> Date: Wed, 24 Sep 1997 15:47:52 -0400 From: Michael Richardson Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Rodney" == Rodney Thayer writes: Rodney> This will of course break all the ESP implementations that Rodney> support the current draft. Note that you can build in Rodney> backwards compatability by implementing this: Rodney> if pad length > 1 then if pad length byte is the same as Rodney> the previous byte then implement previous pad algorithm Rodney> i.e. pad_length++; In testing between SSH and FreeSWAN, we found it had to be: if(pad_length == 0 || (pad_length > 1 && pad_length == previous byte)) { pad_length++; } One can, in theory, use this as a sign to send the esp-v2-00 ESP, but we realized that in practice, at this level of the stack, one doesn't know where the corresponding outgoing SA is (or if there is one). If we can make the decision here in Ottawa, then we could test things tomorrow. ] At the AIAG/ANX IPsec interoperability workshop | one quark [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON | two quark [ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ | red q blue q[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQB1AwUBNCluYMmxxiPyUBAxAQGj1AL/SuD+KcwAvTQ8S14DVF+lvl57r+0roanK 5qUJKIJpXU5L1gG1f6I/Q4hmyb9uUcVDS6g0jeWSHLfeyUEEyfEVuF9qLUSEpYQh lEPtyUeNkopu0YY9e/xo7dOW8+jTtvzq =4Boo -----END PGP SIGNATURE----- From owner-ipsec Wed Sep 24 18:13:16 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA13245 for ipsec-outgoing; Wed, 24 Sep 1997 18:10:34 -0400 (EDT) Message-ID: <342994AD.550FD838@newoak.com> Date: Wed, 24 Sep 1997 18:31:09 -0400 From: smamros@newoak.com (Shawn Mamros) X-Mailer: Mozilla 4.0 [en] (WinNT; U) MIME-Version: 1.0 To: Rodney Thayer , ipsec@tis.com Subject: Re: [Ottawa bakeoff feedback] problem with ESP Padding X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk (Description of padding change removed for brevity...) > This will of course break all the ESP implementations that support the > current draft. Not to mention anything that implements RFC 1829 style ESP, where the Pad Length byte itself has always been excluded from Pad Length, AND where the padding itself is "implementation dependent (preferably random)". Personally, I'll deal with whatever way it winds up being. Still, I honestly can't believe that something this fundamental is changing at this late a date. -Shawn Mamros E-mail to: smamros@newoak.com From owner-ipsec Wed Sep 24 20:53:25 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id UAA14035 for ipsec-outgoing; Wed, 24 Sep 1997 20:51:34 -0400 (EDT) Message-Id: <199709250107.SAA09456@mailsun2.us.oracle.com> Date: 24 Sep 97 17:58:10 -0700 From: "PALAMBER.US.ORACLE.COM" To: rodney@sabletech.com Subject: Re: [Ottawa bakeoff feedback] problem with ESP Padding Cc: ipsec@tis.com X-Orcl-Application: In-Reply-To: UNX02.US.ORACLE.COM:owner-ipsec@portal.ex.tis.com's message of 24-Sep-97 08:50 MIME-Version: 1.0 X-Mailer: Oracle InterOffice (version 4.0.4.0.0) Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk >This is wrong. It doesn't work for hardware vendors. >It does not meet the requirement for self-describing >padding, as hardware vendors requested ... Wrong? It works. The padding field is not self describing, it is located a fixed distance from the end of the ESP packet. The counting was provided for a particular cut and paste attack. This attack is a byproduct of authentication over encryption. These are all features of our current specification:-) >This changes the Pad Length field to mean >"the length of the padding field, counting the length byte itself". This would work... but there is no compelling reason to change the current usage of the pad length field. Paul ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Paul Lambert Director of Security Products Oracle Corporation Phone: (650) 506-0370 500 Oracle Parkway, Box 659410 Fax: (650) 633-2963 Redwood Shores, CA 94065 E-Mail: palamber@us.oracle.com PGP: F4 B9 3B 17 BD 49 3B 0C 9E B9 95 E2 42 CA 02 E3 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From owner-ipsec Thu Sep 25 05:59:24 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id FAA16820 for ipsec-outgoing; Thu, 25 Sep 1997 05:57:13 -0400 (EDT) Date: Thu, 25 Sep 1997 12:01:55 +0300 (IDT) From: Hugo Krawczyk Message-Id: <199709250901.MAA04293@ee.technion.ac.il> To: ipsec@tis.com Subject: change in isakmp/oakley Cc: dharkins@cisco.com Sender: owner-ipsec@ex.tis.com Precedence: bulk I would like to request a change in the isakmp/oakley resolution draft. In version 03 of the draft the value of SKEYID for the encryption mode was defined as: SKEYID = hash(Ni | Nr) Later in version 04 it was changed to: SKEYID = prf(Ni | Nr, CKY-I | CKY-R) This was done for the sake of uniformity with the derivation of SKEYID in the other modes which use a prf. However, Moni Naor pointed out to me that this last form may not provide all the mixing of Ni and Nr as required for the security of the authentication. To guarantee such a mixing I ask to change it back to the form of draft 03 or even better to SKEYID = hash(Ni | Nr | CKY-I | CKY-R) (where hash is the negotiated hash algorithm). This change has no impact on any other part of the specification. If anyone has an objection to this please let me (and the list) know. Otherwise, I'd like to ask Dan Harkins to document this form in draft 05. (Same is applicable to the "revised encryption mode".) Thanks, Hugo PS: Let me clarify that I was responsible for the original definition in draft 03 (which follows my own design in SKEME) and also for requesting the change that was reflected in 04, and which I am undoing now (back to SKEME)... From owner-ipsec Thu Sep 25 10:00:45 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA18615 for ipsec-outgoing; Thu, 25 Sep 1997 09:58:48 -0400 (EDT) Date: Thu, 25 Sep 1997 10:04:20 -0400 From: ho@earth.hpc.org (Hilarie Orman) Message-Id: <199709251404.KAA19887@earth.hpc.org> To: hugo@ee.technion.ac.il Cc: ipsec@tis.com In-reply-to: Yourmessage <199709251026.DAA24866@baskerville.CS.Arizona.EDU> Subject: Re: change in isakmp/oakley Sender: owner-ipsec@ex.tis.com Precedence: bulk I'd certainly appreciate seeing the note justifying the request for change. The continual churning on these issues might be damped providing some insight into the reasoning. Hilarie From owner-ipsec Thu Sep 25 10:16:26 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA18746 for ipsec-outgoing; Thu, 25 Sep 1997 10:14:45 -0400 (EDT) Message-Id: <97Sep25.102416edt.11649@janus.tor.securecomputing.com> To: Hugo Krawczyk cc: ipsec@tis.com, dharkins@cisco.com Subject: Re: change in isakmp/oakley References: <199709250901.MAA04293@ee.technion.ac.il> In-reply-to: hugo's message of "Thu, 25 Sep 1997 05:01:55 -0400". <199709250901.MAA04293@ee.technion.ac.il> From: "C. Harald Koch" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <10778.875197459.1@rafael.tornd.securecomputing.com> Date: Thu, 25 Sep 1997 10:24:19 -0400 Sender: owner-ipsec@ex.tis.com Precedence: bulk In message <199709250901.MAA04293@ee.technion.ac.il>, Hugo Krawczyk writes: > However, Moni Naor pointed out to me that this last form may not > provide all the mixing of Ni and Nr Can we *please* get these protocols stable and published? In other words, stop changing it unless "may not" becomes "must not". -- Harald Koch From owner-ipsec Thu Sep 25 10:19:38 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA18760 for ipsec-outgoing; Thu, 25 Sep 1997 10:18:14 -0400 (EDT) Message-Id: <97Sep25.102755edt.11651@janus.tor.securecomputing.com> To: smamros@newoak.com (Shawn Mamros) cc: Rodney Thayer , ipsec@tis.com Subject: Re: [Ottawa bakeoff feedback] problem with ESP Padding References: <342994AD.550FD838@newoak.com> In-reply-to: Your message of "Wed, 24 Sep 1997 18:31:09 -0400". <342994AD.550FD838@newoak.com> From: "C. Harald Koch" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <11173.875197675.1@rafael.tornd.securecomputing.com> Date: Thu, 25 Sep 1997 10:27:55 -0400 Sender: owner-ipsec@ex.tis.com Precedence: bulk In message <342994AD.550FD838@newoak.com>, Shawn Mamros writes: > > Personally, I'll deal with whatever way it winds up being. Still, > I honestly can't believe that something this fundamental is changing > at this late a date. Agreed. This change breaks every single implementation for negligible gain. Can we *please* get these documents stable and published? -- Harald From owner-ipsec Thu Sep 25 11:37:22 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA19431 for ipsec-outgoing; Thu, 25 Sep 1997 11:35:44 -0400 (EDT) Date: Thu, 25 Sep 1997 17:39:38 +0300 (IDT) From: Hugo Krawczyk Message-Id: <199709251439.RAA10983@ee.technion.ac.il> To: chk@utcc.utoronto.ca, ho@earth.hpc.org Subject: Re: change in isakmp/oakley Cc: dharkins@cisco.com, ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Hilarie and Harald, You cannot complaint to me about continuous changes in the spec. All changes I ever asked were motivated by design and security needs of the protocol, and except for the current one, I never asked to change my own specifications. The reason that some of the design details kept changing is not because I changed my mind, or my cryptographic undersatnding, but because the changes I asked for were only accepted gradually by the WG and editors. My own proposal goes back to 1995 and has not changed since then. It is documented in my SKEME paper published in Feb 1996. This design was (and is) stable, sound, and unchanging. Unfortunately, it took time to get the right details into the ipsec protocols. Actually, they are not all there, but I would not ask for any changes that are not absolutely necessary. One exception is the change from draft 03 to 04 as I described in my previous message. In that case, I "fall to the temptation" of changing the use of hash() to that of prf() in order to gain uniformity in the way SKEYID is derived in all different modes. However, as I said, the mixing of keys (Ni and Nr) needed is SKEME cannot be guaranteed (in general) using a prf as draft 04 does. Cryptographic hash functions as used in the original SKEME and in draft-03 are better suited for that. Now, since the isakmp/oakley draft is going to change anyway, this one is well worth doing. As I said, this change does not require or influence changes in other parts of the spec. Hugo From owner-ipsec Thu Sep 25 12:34:03 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA19714 for ipsec-outgoing; Thu, 25 Sep 1997 12:30:13 -0400 (EDT) Message-Id: <97Sep25.123901edt.11649@janus.tor.securecomputing.com> To: Hugo Krawczyk cc: ho@earth.hpc.org, dharkins@cisco.com, ipsec@tis.com Subject: Re: change in isakmp/oakley References: <199709251439.RAA10983@ee.technion.ac.il> In-reply-to: hugo's message of "Thu, 25 Sep 1997 10:39:38 -0400". <199709251439.RAA10983@ee.technion.ac.il> From: "C. Harald Koch" X-uri: X-Face: )@F:jK?*}hv!eJ}*r*0DD"k8x1.d#i>7`ETe2;hSD2T!:Fh#wu`0pW7lO|Dfe'AbyNy[\Pw z'.bAtgTM!+iq2$yXiv4gf<:D*rZ-|f$\YQi7"D"=CG!JB?[^_7v>8Mm;z:NJ7pss)l__Cw+.>xUJ) did@Pr9 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <15176.875205492.1@rafael.tornd.securecomputing.com> Date: Thu, 25 Sep 1997 12:38:12 -0400 Sender: owner-ipsec@ex.tis.com Precedence: bulk In message <199709251439.RAA10983@ee.technion.ac.il>, Hugo Krawczyk writes: > > You cannot complaint to me about continuous changes > in the spec. Don't feel personally slighted; I'm complaining to everyone about changes these days. It's time to do the BGP thing, and get the standard deployed, and make incompatible changes in the *next* version. > changing the use of hash() to that of prf() in order > to gain uniformity in the way SKEYID is derived in all > different modes. However, as I said, the mixing of keys (Ni and Nr) > needed is SKEME cannot be guaranteed (in general) using a prf > as draft 04 does. Cryptographic hash functions as used in the > original SKEME and in draft-03 are better suited for that. Almost all implementors are currently using MD5 or SHA as the prf. I doubt that anyone has even implemented anything else. > Now, since the isakmp/oakley draft is going to change > anyway, this one is well worth doing. As I said, this change > does not require or influence changes in other parts of the > spec. My understanding is that the IO draft changes are primarily editorial. Your proposal, like the padding change in ESP, breaks every single existing implementation. Many people here have been having a difficult time getting the hashing of the various SKEYIDs and other hashes correct as it is, and they're extremely difficult to debug. I repeat: If this is a MUST change, we should consider it. Otherwise, take it to IPsecond. All MHO, naturally. -- Harald From owner-ipsec Thu Sep 25 13:06:48 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA19915 for ipsec-outgoing; Thu, 25 Sep 1997 13:05:18 -0400 (EDT) Message-Id: <3.0.3.32.19970925131205.00c4e100@dilbert.is.chrysler.com> Reply-To: rgm3@chrysler.com X-Sender: rgm3@dilbert.is.chrysler.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Thu, 25 Sep 1997 13:12:05 -0400 To: Hugo Krawczyk , chk@utcc.utoronto.ca, ho@earth.hpc.org From: Robert Moskowitz Subject: Re: change in isakmp/oakley Cc: dharkins@cisco.com, ipsec@tis.com In-Reply-To: <199709251439.RAA10983@ee.technion.ac.il> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 05:39 PM 9/25/97 +0300, Hugo Krawczyk wrote: > >Now, since the isakmp/oakley draft is going to change >anyway, this one is well worth doing. As I said, this change >does not require or influence changes in other parts of the >spec. Yes, there will be a new isakmp/oakley draft. It will be editorial, and roll in agreed upon items (like some stuff from Oakley, and your enc-encrypt mode). None of these impact the protocol. Changes that impact the protocol need significant justification. Such changes may occur. There are still two more points for changes: IPsecond and proposed->draft standard. Robert Moskowitz Chrysler Corporation (810) 758-8212 From owner-ipsec Thu Sep 25 16:08:37 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA21111 for ipsec-outgoing; Thu, 25 Sep 1997 16:04:49 -0400 (EDT) Message-Id: <3.0.32.19970925131044.00a33ad0@earthlink.net> X-Sender: rmonsour@earthlink.net X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Thu, 25 Sep 1997 13:10:47 -0700 To: "C. Harald Koch" From: Bob Monsour Subject: Re: [Ottawa bakeoff feedback] problem with ESP Padding Cc: smamros@newoak.com (Shawn Mamros), Rodney Thayer , ipsec@tis.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 10:27 AM 9/25/97 -0400, C. Harald Koch wrote: [snip] >Agreed. This change breaks every single implementation for negligible gain. > >Can we *please* get these documents stable and published? Also agreed -- strongly. As one of the hardware vendors in question, we're building a chip that generates padding automatically on compression/encryption/authentication processing and we strip it off automatically on the receive side of things. We support multiple padding modes, but don't output the sequence as currently specified in the ESP draft. We have a mode that outputs the incrementing scheme, but the pad length value output is equal to the value of the last pad byte. We have another padding mode that puts out the correct number of bytes of padding AND the correct value of the pad length byte, but if the values are checked on the receiver side, then the check will fail. The pad byte values are equal to the value of the pad length byte. The ESP draft specifies the incrementing pad scheme as its default (and the DES & 3DES drafts defer to the ESP draft for padding requirements). The ESP draft states "When this padding scheme is employed, the receiver SHOULD inspect the Padding field." A SHOULD is defined as follows (per rfc2119): SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. As you all probably recall (perhaps with some pain), there was a debate on the value of well-defined padding bytes versus "random" padding bytes. I don't wish to re-engage that debate (nor do I fully understand the implications). I leave it to the implementors to decide on how to interpret the "SHOULD inspect the Padding field" specification. Bottom line, I am strongly in favor of *NOT* changing the ESP draft and wanted to implementation community to be aware of this issue. Thanks for listening. -Bob From owner-ipsec Fri Sep 26 10:07:17 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA26380 for ipsec-outgoing; Fri, 26 Sep 1997 10:03:59 -0400 (EDT) Message-Id: <199709261413.KAA12542@mail.thecia.net> From: "Bronislav Kavsan" To: , "Rodney Thayer" Subject: Re: [Ottawa bakeoff feedback] problem with ESP Padding Date: Fri, 26 Sep 1997 10:07:40 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.71.1008.3 X-MimeOle: Produced By Microsoft MimeOLE Engine V4.71.1008.3 X-MDMail-Server: MDaemon v2.5 rB b2 32-R X-MDaemon-Deliver-To: ipsec@tis.com X-MIME-Autoconverted: from 8bit to quoted-printable by mail.thecia.net id KAA12542 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by portal.ex.tis.com id KAA26377 Sender: owner-ipsec@ex.tis.com Precedence: bulk How about using PKCS #5 style padding, which says: The message M and a padding string PS shall be formatted into an octet string EB, the encryption block. EB = M || PS . (1) The padding string PS shall consist of 8 - (||M|| mod 8) octets all having value 8 - (||M|| mod 8). (This makes the length of the encryption block EB a multiple of eight octets.) In other words, the encryption block EB satisfies one of the following statements: EB = M || 01 — if ||M|| mod 8 = 7 ; EB = M || 02 02 — if ||M|| mod 8 = 6 ; × × × EB = M || 08 08 08 08 08 08 08 08 — if ||M|| mod 8 = 0 . Note. The encryption block can be parsed unambiguously since every encryption block ends with a padding string and no padding string is a suffix of another. -----Original Message----- From: Rodney Thayer To: ipsec@tis.com Date: Wednesday, September 24, 1997 2:23 PM Subject: [Ottawa bakeoff feedback] problem with ESP Padding >Here at the Ottawa ANX workshop we have found a problem with the definition >of Padding in the ESP document. We found this problem: > >The text in sections 2.4 and 2.5 of draft-ietf-ipsec-esp-v2-00.txt >discusses Padding and Pad Length. We found that people (including myself) >interpreted this like this: > >Given a block that ends in 'xx xx', to form the tail end of the ESP >message, you would get > > xx xx [Padding=1 2 3 4] [PadLth=4] [NxtProt=4] > >Note this has the padding stuff being 1..2..3..4..4. That last 4 is the >Pad Length. It is the length of the "Padding field", the field BEFORE the >Pad Length. The "1.2.3.4" is the Pad (value). It is sort of >self-describing. (The NxtProt is the Next Protocol, e.g. a 4 for IP.) > >This is wrong. It doesn't work for hardware vendors. It does not meet the >requirement for self-describing padding, as hardware vendors requested and >in the style of PPP. > >Here is what we should do: > >Given a block that ends in 'xx xx', the tail of the ESP message would be > xx xx [Padding=1 2 3 4]+[PadLth=5] [NxtProt=4] >This changes the Pad Length field to mean "the length of the padding field, >counting the length byte itself". Note that since the Pad Length is >mandatory, the minimum value for this is a 1. This has the padding stuff >being 1..2..3..4..5. > >I propose the draft text change. I propose that section 2.5 now on page 7 >change to this: > >"2.5 Pad Length > >The Pad Length field indicates the number of pad bytes in the message, >including itself. The >range of valid values is 1..255, where a value of one means that no Padding >bytes are present, other >than the Pad Length itself. Zero is not a valid Pad Length field. The Pad >Length field is mandatory." > >This will of course break all the ESP implementations that support the >current draft. Note that you can build in backwards compatability by >implementing this: > > if pad length > 1 > then > if pad length byte is the same as the previous byte > then > implement previous pad algorithm i.e. pad_length++; > > > From owner-ipsec Fri Sep 26 16:46:04 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA28666 for ipsec-outgoing; Fri, 26 Sep 1997 16:38:59 -0400 (EDT) Message-Id: <97Sep26.164840edt.11649@janus.tor.securecomputing.com> To: "Bronislav Kavsan" cc: ipsec@tis.com, "Rodney Thayer" Subject: Re: [Ottawa bakeoff feedback] problem with ESP Padding References: <199709261413.KAA12542@mail.thecia.net> In-reply-to: Your message of "Fri, 26 Sep 1997 10:07:40 -0400". <199709261413.KAA12542@mail.thecia.net> From: "C. Harald Koch" X-uri: X-Face: )@F:jK?*}hv!eJ}*r*0DD"k8x1.d#i>7`ETe2;hSD2T!:Fh#wu`0pW7lO|Dfe'AbyNy[\Pw z'.bAtgTM!+iq2$yXiv4gf<:D*rZ-|f$\YQi7"D"=CG!JB?[^_7v>8Mm;z:NJ7pss)l__Cw+.>xUJ) did@Pr9 Date: Fri, 26 Sep 1997 16:48:48 -0400 Sender: owner-ipsec@ex.tis.com Precedence: bulk In message <199709261413.KAA12542@mail.thecia.net>, "Bronislav Kavsan" writes: > How about using PKCS #5 style padding, which says: First off, it's ugly because it always pads blocks that are aligned, resulting in excess wasted bandwidth. Second, remember that we *also* have a payload type octet at the very end of the data. Third, IT'S A GRATUITOUS CHANGE, and we *are* trying to get a Last Call going here. -- Harald From owner-ipsec Sun Sep 28 17:19:39 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA09979 for ipsec-outgoing; Sun, 28 Sep 1997 17:12:25 -0400 (EDT) Message-ID: From: Greg Carter To: "'wdm@epoch.ncsc.mil'" Cc: "'ipsec@tis.com'" Subject: RE: comments on Oakley test items Date: Sun, 28 Sep 1997 17:17:44 -0400 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi Doug, >Section 4.8 of ISAKMP-08 shows the values included in an Informational >Exchange (notify or delete). This includes an ISAKMP Header (containing >the M-ID) and the Notify Payload, described in section 3.15. This >payload includes DOI, P-ID, and SPI. The data portion of the message is >DOI specific (and you're right that DOIv3 doesn't have anything >extra). The Message Type field gives the details of the message. > >Maybe I'm missing your point, but what isn't there that you need? Is >there something that needs to be added to the ISAKMP draft or is it >needed in the DOI draft? The header of the ISAKMP info exchange now uses a unique M-ID to get around IV sync problems. Therefore there is no correlation between the M-ID of the Quick Mode which is being rejected and the M-ID in the Information exchange hdr. In some situations a Quick Mode may be rejected before SPI/P-ID values are learnt, therefore having a way to specify the M-ID of the rejected Quick Mode would be beneficial. Bye. ---- Greg Carter, Entrust Technologies greg.carter@entrust.com Get FREE FIPS-140-1 Validated Crypto for the desktop http://www.entrust.com/solo.htm > From owner-ipsec Sun Sep 28 18:54:07 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA10330 for ipsec-outgoing; Sun, 28 Sep 1997 18:53:23 -0400 (EDT) Message-Id: <3.0.3.32.19970928182648.006aecec@pop.pn.com> X-PGP-Key: X-Sender: rodney@pop.pn.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Sun, 28 Sep 1997 18:26:48 -0400 To: ipsec@tis.com From: Rodney Thayer Subject: [Survey] request for input -- October 1997 Survey Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk This is the revised IETF IPsec WG's Implementation Status "template". If you have an implementation of any portion of the IETF IPsec specifications and are willing to let this be known in public, please fill this in and email it to me. I expect to post a revised summary in approximately three weeks. Suggested answers are in parentheses ready for you to edit. This form originally written by Randall Atkinson. I have changed the form in an attempt to reflect changes in the protocols. If you think the categories on the form should look different, please email me your suggestions. Thanks, Rodney Thayer [form rev 3.1] Name of Implementation : (name of your implementation/product) Version Described : Organization : (name of your organization) Which IP versions are supported : (IPv4, IPv6, or IPv4 and IPv6) Implements RFC-1828 AH MD5 : (YES, NO, In Progress, Planned, Partial; Note -- you should indicate options such as Explicit/Implicit IV) Implements RFC-1829 ESP DES-CBC : (YES, NO, In Progress, Planned, Partial) Implements AH HMAC MD5 : (YES, NO, In Progress, Planned, Partial; draft rev.) Implements AH HMAC SHA-1: (YES, NO, In Progress, Planned, Partial; draft rev.) Implements Combined ESP (DES+MD5+Replay, etc) : Please list combinations you support, and for each combination indicate (YES, NO, In Progress, Planned, Partial; draft rev.) Examples include MD5+DES+Replay, SHA-1+3DES, etc. Other AH Implemented Transforms : (YES, NO, In Progress, Planned, Partial; draft rev.) Other ESP Implemented Transforms : (YES, NO, In Progress, Planned, Partial; draft rev.) Transport mode : (YES, NO, In Progress, Planned, Partial) Tunnel mode : (YES, NO, In Progress, Planned, Partial) Key Management : (Manual, ISAKMP+Oakley, SKIP, Photuris, other, proprietary) Platforms : (4.4-Lite BSD, Solaris, IRIX, , STREAMS, LINUX, etc; also list specific supported host OS, e.g. Streams for MAC-OS) Lineage of IPsec Code : (, ETHZ, JI, KA9Q, NIST, NRL, SUN, not applicable) Lineage of Key Mgmt Code: (, SUN, ETHZ, AK, cisco, not applicable) Key Mgmt Features : (Shared secret, Certs, PGP, etc) Location of Source Code : (provide URL if freely available, use the word "proprietary" if isn't freely available) POINTS of Contact : (email address, optionally also phone/fax/name; note also if there is someone others can contact about over-the-Internet testing) Claimed Interoperability: (list of systems that your implementation fully interoperates with) From owner-ipsec Sun Sep 28 20:54:52 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id UAA10884 for ipsec-outgoing; Sun, 28 Sep 1997 20:53:23 -0400 (EDT) Message-Id: <3.0.3.32.19970928210204.038e704c@pop.pn.com> X-PGP-Key: X-Sender: rodney@pop.pn.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Sun, 28 Sep 1997 21:02:04 -0400 To: ipsec@tis.com From: Rodney Thayer Subject: survey form update Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk I failed to list 1851 and 1852 (3des, earlier style, and AH SHA-1). Angelos caught this. From owner-ipsec Mon Sep 29 04:25:41 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id EAA13170 for ipsec-outgoing; Mon, 29 Sep 1997 04:23:57 -0400 (EDT) Date: Mon, 29 Sep 1997 10:28:17 +0300 (IDT) From: Hugo Krawczyk Message-Id: <199709290728.KAA23246@ee.technion.ac.il> To: chk@utcc.utoronto.ca Subject: Re: change in isakmp/oakley Cc: dharkins@cisco.com, ho@earth.hpc.org, ipsec@tis.com, rgm3@chrysler.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Harald Koch says: > My understanding is that the IO draft changes are primarily editorial. Your > proposal, like the padding change in ESP, breaks every single existing > implementation. Many people here have been having a difficult time getting > the hashing of the various SKEYIDs and other hashes correct as it is, and > they're extremely difficult to debug. > > I repeat: If this is a MUST change, we should consider it. Otherwise, take > it to IPsecond. Yes, I consider it a MUST. I'll try to explain. I prefer a few temporarily "broken" implementations (which are still in development and can be fixed by a few code lines change) to the possibility of seeing (future) compliant implementations whose *security is broken*. In the way the isakmp/oakley is currently defined (draft 04) this can happen in a variety of ways. I will present the simplest example but other are possible. Assume an instantiation of a prf by DES-CBC-MAC using 56 bit of key. The key to the prf is defined as Ni | Nr. If each of these nonces is 64-bit long, then the concatentation Ni|Nr is 128 bit long. Thus, the derivation of a 56-bit key for DES will have to be decided by whoever specifies the above prf. Such a specification could decide to drop the first 72 bits of Ni|Nr and take the last 56 bits as the DES key. Why not? assuming the original 128 bit key was random then that's fine. However, for the particular application we have this would break the security of the protocol. As you can see the computation of SKEYID now does not depend on Ni at all. Thus an attacker impersonating R would succeed in his authentication (no need to decrypt the key sent by I!) Other examples are possible. When carrying out a full analysis of the protocol one can see that a requirement is that SKEYID will be "unpredictably" influenced by both Ni and Nr. For this we need a good mixing function on Ni and Nr. Good hash functions should provide this mixing. This is why SKEME defines (its parallel of) SKEYID as Hash(Ni,Nr) and this is what I am asking to change now in isakmp/oakley. > Almost all implementors are currently using MD5 or SHA as the prf. I doubt > that anyone has even implemented anything else. You are probably right. Let me remark that just using MD5 or SHA as a keyed hash is not enough to guarantee a defense against the above problem. It depends on how you key the hash function. In the case of HMAC the problem does not appear since, by definition, HMAC first hashes the key. However, HMAC is not the only possible function for key derivation, and then the protocol specification needs to be robust enough to ensure that future compliant implementations (which may not use HMAC) are secure too. > Many people here have been having a difficult time getting > the hashing of the various SKEYIDs and other hashes correct as it is, and > they're extremely difficult to debug. > At least in the way we defined the current isakmp/oakley key derivation, all the SKEYID derivatives and HASH values are defined in a single point, and the definitions are common to *all* modes. If you have it right for one mode you will have it right for all. Only the value of SKEYID itself is mode-dependent. (And that's the only change I am asking; nothing else is touched.) Finally, let me offer a specification for SKEYID for the encryption mode which is slightly different than what I requested in the previous message. This one has the same effect but may make the change from the previous definition even simpler: SKEYID = prf(hash(Ni|Nr), CKY-I | CKY-R) In this case the use of prf is preserved. The only change is that instead of using Ni|Nr directly as a key to prf as before, you first hash the concatenation of the nonces. Hugo From owner-ipsec Mon Sep 29 09:29:23 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA15134 for ipsec-outgoing; Mon, 29 Sep 1997 09:26:54 -0400 (EDT) Date: Mon, 29 Sep 1997 09:31:30 -0400 From: ho@earth.hpc.org (Hilarie Orman) Message-Id: <199709291331.JAA02360@earth.hpc.org> To: hugo@ee.technion.ac.il Cc: chk@utcc.utoronto.ca, rgm3@chrysler.com, ipsec@tis.com, dharkins@cisco.com In-reply-to: Yourmessage <199709290728.KAA23246@ee.technion.ac.il> Subject: Re: change in isakmp/oakley Sender: owner-ipsec@ex.tis.com Precedence: bulk I'd thought you were going to contrast collision resistance with "mixing" and use that as the rationale for using prf for authentication, hash for key derivation. And I was going to reply that we expect that the key for prf will always be at least 128 bits, so the point is moot, because the key always fills the first input block for the one-way function. Instead, the worry expressed is that the prf definition will allow key truncation. I'd never considered that a possibility, though I suppose that is why correct composition is such a hard problem --- incomplete specifications of the composition requirements. Do the spec's allow the prf's to do key truncation? What do they do with keys longer than one block? My own opinion is that truncation is a severe bug in any case, and that it should be fixed. This makes their use for session key derivation moot. Hilarie From owner-ipsec Mon Sep 29 10:49:24 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA15677 for ipsec-outgoing; Mon, 29 Sep 1997 10:47:59 -0400 (EDT) Date: Mon, 29 Sep 1997 16:52:47 +0300 (IDT) From: Hugo Krawczyk Message-Id: <199709291352.QAA04612@ee.technion.ac.il> To: ho@earth.hpc.org Subject: Re: change in isakmp/oakley Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk > Instead, the worry expressed is that the prf definition will allow key > truncation. I'd never considered that a possibility, though I suppose > that is why correct composition is such a hard problem --- incomplete > specifications of the composition requirements. Indeed, we are talking about providing complete specifications, and about free-ing future implementers from understanding all the subtleties of these protocols. Prf's can be implemented in a variety of ways (and that's their advantage; in particular they include two fundamental classes of cryptographic algorithms, keyd hash functions and block ciphers). Their only requirement is that the output be cryptographically unpredictable for whoever does not know the (random) key. The specifications of the protocol need to guarantee that if the underlying cryptographic functions are secure (including the prf) then the protocol is secure. The mixing of Ni and Nr as I requested is needed to provide this analytical property of the protocol. Truncation is the easiest example to give, but other functions are possible that do not use all the key bits in a symmetric way. For example, there may be functions where the second half of the bits have a stronger influence in the security of the function than the first half. This could be, for example, the property of an excellent block cipher, and consequently of an excelent prf. (Notice that in this case the effective key length is shorter than the total key length; so what? RSA has such a property and we keep using it.) In any case, the initial mixing of Ni|Nr would prevent any weakness resulting from a-symmetric properties of a key. >Do the spec's allow the prf's to do key truncation? What do they do >with keys longer than one block? My own opinion is that truncation >is a severe bug in any case, and that it should be fixed. This makes >their use for session key derivation moot. The spec specifies which key to use with the prf in each case. However, different prf's may require a diferent number of key bits. While HMAC is defined for any length of key, 3DES-CBC-MAC (which is my preferred candidate for use as a prf for key derivation) is defined with *exactly* 168 bits of key. What do we do in order to use it with another key length? Whoever specifies 3DES-CBC-MAC for use in isakmp/oakley will need to define how to get the right number of key bits in this case. Same for other prf's. Providing Ni|Nr as the initial seed for the key when Nr can be chosen (under certain attacks) by the adversary is not a good idea. Hashing it first prevents this "malicious influence" by the attacker. Hugo From owner-ipsec Mon Sep 29 12:27:03 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA16274 for ipsec-outgoing; Mon, 29 Sep 1997 12:24:28 -0400 (EDT) Message-Id: <199709291503.IAA14341@dharkins-ss20> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: ho@earth.hpc.org (Hilarie Orman) Cc: hugo@ee.technion.ac.il, chk@utcc.utoronto.ca, rgm3@chrysler.com, ipsec@tis.com Subject: Re: change in isakmp/oakley In-Reply-To: Your message of "Mon, 29 Sep 1997 09:31:30 EDT." <199709291331.JAA02360@earth.hpc.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 29 Sep 1997 08:03:19 -0700 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk Hilarie, > Do the spec's allow the prf's to do key truncation? What do they do > with keys longer than one block? My own opinion is that truncation > is a severe bug in any case, and that it should be fixed. This makes > their use for session key derivation moot. The spec doesn't address the particulars of each prf but instead defines two default prfs (which don't do key truncation) and allows for growth by reserving some part of its magic number space for to-be-defined prfs. It would seem to me that any key'd prf (or key'd _anything_) which does key truncation is broken and shouldn't be used in ISAKMP/Oakley, but I guess the point being made is that it's possible to define such a broken function and negotiate it in ISAKMP/Oakley. Let me also note that its possible to define a ROT-13 encryption algorithm and negotiate it too. I don't think I'd accept either in an offer but, I guess, that's not the point. Is the (non)mixing of Ni and Nr in encryption mode authentication broken or does it just reenforce the brokenness of certain (as yet unnamed) prfs? Dan. From owner-ipsec Mon Sep 29 18:26:31 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA18464 for ipsec-outgoing; Mon, 29 Sep 1997 18:20:30 -0400 (EDT) Message-Id: <199709290654.CAA03131@istari.sandelman.ottawa.on.ca> To: anx-sec@dot.netrex.net CC: ipsec@tis.com Reply-To: ipsec@tis.com Subject: Re: Which DOI for the pilot? In-reply-to: Your message of "Mon, 29 Sep 1997 15:11:52 EDT." <199709291905.PAA11801@raptor1.raptor.com> Date: Mon, 29 Sep 1997 02:54:31 -0400 From: "Michael C. Richardson" Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Rizwan" == Rizwan Mallal writes: Rizwan> For the pilot are we now going to be using DOI-4 or are we Rizwan> still sticking to DOI-3 that was tested out in Ottawa??? Unlike DOI-2 to DOI-3, DOI-4 does not redefine any constants, so (I think) DOI-3 and DOI-4 might interoperate, except in the case where someone didn't put the SA lifetime duration after the lifetype attribute. Am I right Dan? In general, we also have a desire to have vendor ID (probably hash of a strong) in the phase 1 message, so that we can define private attributes when we notice we are talking to an instance of our own product. :!mcr!: | Network security programming, currently Michael Richardson | on contract with SSH IPSEC (http://www.ssh.fi/) WWW: mcr@sandelman.ottawa.on.ca. PGP key available. Winner of the 1997 O.C.D.L.D.L.P. award. -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQB1AwUBNC9QpaZpLyXYhL+BAQH9mwL9Has1nsBLUtha7kUGqefISzZhWDhtcbEE bZD4tWCVOtxiCjNcARYKrVMnKtQk5GLR9aB4dh8tM7q7eXvF2TIPLCtU5EnZk2Ux U8zQuqze1bvLIfFQnLQ/rdgWs+C8bwcy =vgHu -----END PGP SIGNATURE----- From owner-ipsec Mon Sep 29 20:48:56 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id UAA19254 for ipsec-outgoing; Mon, 29 Sep 1997 20:47:05 -0400 (EDT) Message-ID: <34304E5E.59E2@cs.umass.edu> Date: Mon, 29 Sep 1997 20:57:02 -0400 From: Lewis McCarthy Organization: UMass-Amherst Theoretical Computer Science Group, X-Mailer: Mozilla 3.01Gold (X11; U; OSF1 V3.2 alpha) MIME-Version: 1.0 To: IP Security List CC: Hugo Krawczyk , Daniel Harkins , Hilarie Orman rman Subject: Re: change in isakmp/oakley References: <199709291352.QAA04612@ee.technion.ac.il> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Hugo Krawczyk writes: > Finally, let me offer a specification for SKEYID for the encryption > mode which is slightly different than what I requested in the > previous message. This one has the same effect but may make the > change from the previous definition even simpler: > > SKEYID = prf(hash(Ni|Nr), CKY-I | CKY-R) [and in a later message] > The spec specifies which key to use with the prf in each case. > However, different prf's may require a diferent number of key bits. > While HMAC is defined for any length of key, 3DES-CBC-MAC (which is > my preferred candidate for use as a prf for key derivation) is > defined with *exactly* 168 bits of key. What do we do in order to use > it with another key length? Whoever specifies 3DES-CBC-MAC for use in > isakmp/oakley will need to define how to get the right number of key > bits in this case. Same for other prf's. Also the spec feeds a couple of different size keys to p.r.f.s in different computations. For the sake of generality I suggest defining in isakmp-oakley a general expansion mechanism for prf keying material (like the feedback method in Appendix B for expanding key material to be used in encrypting ISAKMP messages) and specific indications for each known prf (as is currently done for specific ciphers in Appendix B). Perhaps the prf key would be the first n bits of the sequence BLOCK1 = hash(Ni | Nr), BLOCK2 = hash(Ni| Nr | BLOCK1), BLOCK3 = hash(Ni | Nr | BLOCK2), ... Do we have a current draft that derives key material with feedback in an unkeyed hash function? isakmp-oakley uses feedback in a prf, and key-derivation-01 uses feedback in a block cipher. -Lewis From owner-ipsec Tue Sep 30 08:42:01 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA23051 for ipsec-outgoing; Tue, 30 Sep 1997 08:40:09 -0400 (EDT) Message-Id: <3.0.3.32.19970930083948.00b7e8a0@dilbert.is.chrysler.com> Reply-To: rgm3@chrysler.com X-Sender: rgm3@dilbert.is.chrysler.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Tue, 30 Sep 1997 08:39:48 -0400 To: ipsec@tis.com, anx-sec@dot.netrex.net From: Robert Moskowitz Subject: Re: Which DOI for the pilot? Cc: ipsec@tis.com In-Reply-To: <199709290654.CAA03131@istari.sandelman.ottawa.on.ca> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 02:54 AM 9/29/97 -0400, Michael C. Richardson wrote: > > Unlike DOI-2 to DOI-3, DOI-4 does not redefine any constants, so (I >think) DOI-3 and DOI-4 might interoperate, except in the case where >someone didn't put the SA lifetime duration after the lifetype >attribute. Am I right Dan? > Based on past experience, I and my colleagues perfer that the software tested at Ottawa (for DOI-3) be the baseline for the pilot. Once we have the lab up, software revs can be tested there. Obviously, if a vendor feels that they do not need to make any software changes for DOI-4, they can go ahead and state that for their lab/pilot configurations. Robert Moskowitz Chrysler Corporation (810) 758-8212 From owner-ipsec Tue Sep 30 15:21:38 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA25620 for ipsec-outgoing; Tue, 30 Sep 1997 15:19:43 -0400 (EDT) Date: Tue, 30 Sep 1997 21:24:00 +0300 (IDT) From: Hugo Krawczyk Message-Id: <199709301824.VAA11704@ee.technion.ac.il> To: ipsec@tis.com, lmccarth@cs.umass.edu Subject: Re: change in isakmp/oakley Cc: dharkins@cisco.com, ho@earth.hpc.org Sender: owner-ipsec@ex.tis.com Precedence: bulk > >Also the spec feeds a couple of different size keys to p.r.f.s in >different computations. For the sake of generality I suggest defining >in isakmp-oakley a general expansion mechanism for prf keying material >(like the feedback method in Appendix B for expanding key material to >be used in encrypting ISAKMP messages) and specific indications >for each known prf (as is currently done for specific ciphers in >Appendix B). Perhaps the prf key would be the first n bits of the >sequence BLOCK1 = hash(Ni | Nr), BLOCK2 = hash(Ni| Nr | BLOCK1), >BLOCK3 = hash(Ni | Nr | BLOCK2), ... >Do we have a current draft that derives key material with feedback in >an unkeyed hash function? isakmp-oakley uses feedback in a prf, and >key-derivation-01 uses feedback in a block cipher. > >-Lewis > The question is whether we want to define the process of key derivation for all prf's or want to leave that to the specification of individual prf's. Notice that prf's that do not support arbitraty-length keys will need to adjust the length of the keys in all the modes of the protocol (depending on the length of Ni and Nr in the encryption and signature modes, and depending on the length of the pre-shared key in the case of pre-shared mode). If we want the former then Lewis suggestion is ok with the *added clarification* that in the encryption mode the first block (BLOCK1) is *always* computed regardless of the size of the concatenated Ni|Nr. (For example, if we use 3DES as the prf and we "happen" to use nonces of length 84 bits each, then we still apply hash(Ni|Nr) first, eventhough Ni|Nr by itself already has the right length of 168 bits). If we go for an expansion/shortening definition of keys as Lewis suggests we should consider using HMAC for this instead of the plain hash, i.e. B1 = HMAC(Ni|Nr, 0) B2 = HMAC(Ni|Nr, B2) B3 = HMAC(Ni|Nr, B3) ..... Notice that this is exactly the way that key expansion is defined in Appendix B for expanding encryption keys (page 28). In our case the particular prf is HMAC (using the negotiated hash function). That is, we would be letting people negotiate any prf of their choice, but we will require the derivation of a key for this prf to go via HMAC. (It wil be an overkill for some cases, e.g. when the prf itself is HMAC, but it will make the specification more uniform). Hugo From owner-ipsec Tue Sep 30 15:25:52 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA25730 for ipsec-outgoing; Tue, 30 Sep 1997 15:25:43 -0400 (EDT) Message-Id: <3.0.3.32.19970930141053.00aa8ce0@dilbert.is.chrysler.com> Reply-To: rgm3@chrysler.com X-Sender: rgm3@dilbert.is.chrysler.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Tue, 30 Sep 1997 14:10:53 -0400 To: ipsec@tis.com From: Robert Moskowitz Subject: WG Last Call Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk Ted and I will start work group last call on the following documents effective Oct 6, 1997: draft-ietf-ipsec-isakmp-08.txt draft-ietf-ipsec-oakley-02.txt draft-ietf-ipsec-ipsec-doi-04.txt draft-ietf-ipsec-doc-roadmap-01.txt draft-ietf-ipsec-esp-v2-00.txt draft-ietf-ipsec-auth-header-01.txt draft-ietf-ipsec-auth-hmac-md5-96-00.txt draft-ietf-ipsec-auth-hmac-sha196-00.txt draft-ietf-ipsec-ciph-des-expiv-00.txt The last call will end on Oct 17, 1997. Documents without substantive comments will go directly to the IESG. Common practices on cleaning up wording may result in new drafts going directly to the IESG. Those documents that the workgroup finds broken in some respect will cycle a draft version within the workgroup. draft-ietf-ipsec-isakmp-oakley-05.txt will start its last call shortly after Dan publishes it. The wait period will be determined by the extent of the diff file from Dan and the resolution of the issue brought up by Hugo. draft-ietf-ipsec-arch-sec-01.txt will not go into last call until a sense of working group consensus surfaces. There is no assurance that arch-01 will go into last call. Note all of these drafts represent a unified specification, and the IESG is expecting to review them as a set. Thus it behooves all of us to review them and get this done! ipsec-oakley-02.txt and perhaps ipsec-doc-roadmap-01.txt will most likely be informational, all the rest are standards track. We need everyone to review these and comment on their readiness. PLEASE include the draft name in the subject for everyone's benefit. Those that receive no major comments by 9/26/97 will start wg last call on the 9/29/97. We need to get ALL of these through wg last call before sending on to the IESG! The 3 drafts with notes attached are already not considered ready for last call by the chairs. We request the editors of these documents to submit updated versions, based on wg concensus in the next week. ---------------------------------------------------------- The following documents are still considered wg documents, but will follow the above group to the IESG. We do not want to overload them with reading and slow down approval on the core documents. Note that since the working group consensus was explicit IVs only, this list does not include any proposals that use derived, or 'implicit' IVs. If I did not get this list right in this regard, let me know! draft-ietf-ipsec-ciph-3des-expiv-00.txt draft-ietf-ipsec-ciph-des-xex-00.txt draft-ietf-ipsec-ciph-rc5-cbc-00.txt draft-ietf-ipsec-ciph-cast128-cbc-00.txt draft-ietf-ipsec-ciph-arcfour-00.txt (author reports new ver soon) draft-ietf-ipsec-ciph-blowfish-cbc-00.txt draft-ietf-ipsec-ciph-idea-cbc-00.txt Somehow, it seems that we need to develop applicablity statements for all of these algorithms, suggestions anyone? The following drafts, for various reasons are dead: draft-ietf-ipsec-vpn-00.txt old vpn, watch for wg BOF draft-ietf-ipsec-revised-enc-mode-01.txt roll into isakmp-oakley-05 draft-ietf-ipsec-new-esp-00.txt old esp drop draft-ietf-ipsec-ah-hmac-sha-04.txt old ah drop draft-ietf-ipsec-ah-hmac-sha-1-96-00.txt old ah drop draft-ietf-ipsec-ah-hmac-md5-96-00.txt old ah drop The following draft will be moved to IPsecond: draft-ietf-ipsec-inline-isakmp-01.txt The following drafts are released to their authors for independent Informational RFC publication AFTER the main IPsec drafts are issued as RFCs. The justification for this is either there was no wg concensus on their value to the IPsec specification, or they use protocol designs (for example, derived IV) rejected by wg concensus. draft-ietf-ipsec-cbc-00.txt draft-ietf-ipsec-ciph-des-derived-00.txt draft-ietf-ipsec-ciph-des3-00.txt draft-ietf-ipsec-ciph-desx-00.txt draft-ietf-ipsec-ciph-cast-div-00.txt Thank you all. Theodore T'so and Robert Moskowitz Robert Moskowitz Chrysler Corporation (810) 758-8212 Robert Moskowitz Chrysler Corporation (810) 758-8212 From owner-ipsec Tue Sep 30 18:00:05 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA26855 for ipsec-outgoing; Tue, 30 Sep 1997 17:57:43 -0400 (EDT) From: svakil@usr.com Mime-Version: 1.0 Date: Tue, 30 Sep 1997 17:04:14 -0500 Message-ID: <4317A800.3000@usr.com> Subject: Nonce lengths in ISAKMP messages To: ipsec@tis.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi. I had a few questions on nonces: What should the length of the nonces in the ISAKMP messages be? According to draft-ietf-ipsec-oakley-02, section 2.3.1: Where nonces are indicated, they will be variable precision integers with an entropy value that matches the "strength" attribute of the GRP used with the exchange. If no GRP is indicated, the nonces must be at least 90 bits long. And, sections E.1 and E.2 of the same draft state that the strength of the 768 bit and 1024 bit MODP groups is 26. So, for these two groups should the nonces be atleast 26 bits long but could be any reasonable length > 26? Does it matter if the initiator and responder nonces are of different lengths (so long as they are atleast 'strength' bits long)? Is there a set method to determine this length? Thanks, Sumit A. Vakil Software Engineer 3Com Corporation From owner-ipsec Tue Sep 30 18:46:49 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA27191 for ipsec-outgoing; Tue, 30 Sep 1997 18:43:18 -0400 (EDT) From: pau@watson.ibm.com Date: Tue, 30 Sep 1997 18:54:39 -0400 Message-Id: <9709302254.AA17780@secpwr.watson.ibm.com> To: ipsec@tis.com, lmccarth@cs.umass.edu, hugo@ee.technion.ac.il Subject: Re: change in isakmp/oakley Cc: dharkins@cisco.com, ho@earth.hpc.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Md5: xyErZLwV54wWdsnyuw9E4w== Sender: owner-ipsec@ex.tis.com Precedence: bulk I don't know if this has been addressed or not. But for a prf using block cipher such as 3DES-CBC-MAC, the input data must also be padded to block boundary. How should the padding be done ? Pau-Chen From owner-ipsec Tue Sep 30 21:06:16 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id VAA27936 for ipsec-outgoing; Tue, 30 Sep 1997 21:04:43 -0400 (EDT) Message-Id: <3.0.32.19970930181330.00987c80@192.43.161.2> X-Sender: jburke@192.43.161.2 X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Tue, 30 Sep 1997 18:13:31 -0700 To: ipsec@tis.com, piper@cisco.com From: John Burke Subject: ISAKMP Notification with an SA for Lifetimes Cc: eugenep@cylink.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk I want to object in strongest terms to the introduction in the IP DOI ver-04 of the prescription, that ISAKMP parties can send a Notification which includes an SA giving the new lifetime. Various alternatives were offered on the list when this was discussed, and I don't remember anything like agreement on this one; other alternatives than this one would probably produce minor alteration or none in peoples' code: o Minor: permit responder to return a reduced lifetime; success of the SA setup means unambiguously that both sides accept it; OR, o None: Make no provisions in the protocol; lifetime can be enforced unilaterally anyhow, and one is always allowed to send a Delete (I expect some people do this in any case). The prescribed one is a substantial change by contrast. How did this come about? This is no time to be introducing new functionality of this magnitude into these drafts when there is not an overriding justification. Implementation effort is not the only point; the change is also incomplete; see below; now the draft is further de-stabilized. Reminder to all: if it's in the DOI, implementors are required to support receiving it, unless it is explicitly stated otherwise with words like "only by mutual agreement between the parties". Support requires minimally: o add the new Notify code; o accept a SPI size of 8 and don't reject it (this is different from the treatment of other Notifies directed at a Phase II SA); o do not abort the established SA upon this Notify type. This prescription doesn't address the issue for the Phase I SA, which it must. Remember, the IP DOI is not restricted to Phase II activities. Summary: can't we take this back out? - John Burke, Cylink From owner-ipsec Tue Sep 30 21:06:22 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id VAA27947 for ipsec-outgoing; Tue, 30 Sep 1997 21:06:13 -0400 (EDT) Message-Id: <199710010115.SAA16547@dharkins-ss20> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: pau@watson.ibm.com Cc: ipsec@tis.com, lmccarth@cs.umass.edu, hugo@ee.technion.ac.il, ho@earth.hpc.org Subject: Re: change in isakmp/oakley In-Reply-To: Your message of "Tue, 30 Sep 1997 18:54:39 EDT." <9709302254.AA17780@secpwr.watson.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 30 Sep 1997 18:15:08 -0700 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk It hasn't been addressed yet. Ben Rogers brought up the exact point. If no body can come up with a legitimate reference then are there any complaints about me removing it? I have no qualms with Schneier (as some of you do) but he doesn't address padding. Any other ones out there? I could cook something up but I don't think ISAKMP/Oakley should be defining prf's. I'd rather refer to a (non Internet-Draft) document. Dan. > I don't know if this has been addressed or not. > But for a prf using block cipher such as 3DES-CBC-MAC, > the input data must also be padded to block boundary. > > How should the padding be done ? From owner-ipsec Tue Sep 30 22:29:08 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id WAA28464 for ipsec-outgoing; Tue, 30 Sep 1997 22:27:44 -0400 (EDT) Message-Id: <199710010237.TAA03571@pita.cisco.com> To: John Burke cc: ipsec@tis.com, eugenep@cylink.com Subject: Re: ISAKMP Notification with an SA for Lifetimes In-reply-to: Your message of "Tue, 30 Sep 1997 18:13:31 PDT." <3.0.32.19970930181330.00987c80@192.43.161.2> Date: Tue, 30 Sep 1997 19:37:38 -0700 From: Derrell Piper Sender: owner-ipsec@ex.tis.com Precedence: bulk John, The DOI regrets its egregious affront on your sensibilities and wishes to offer the following justification... The intent of the new text was not to mandate the described behavior but to define how it should be done if the responder wanted to send a notify. You are still free as a responder to accept the proposal and unilaterally expire the SA as you desire. This is what I attempted to convey in saying, "In the latter case,...". >...other alternatives than this one would probably produce minor alteration > or none in peoples' code: > > o Minor: permit responder to return a reduced lifetime; success of the > SA setup means unambiguously that both sides accept it; OR, > > o None: Make no provisions in the protocol; lifetime can be enforced > unilaterally anyhow, and one is always allowed to send a Delete (I > expect some people do this in any case). Your "Minor" change requires ammending the ISAKMP base document to permit the responder to return a changed proposal (with the shorter lifetime) which I believe is a bigger change. This change would require not only the change to ISAKMP, but a change to *all* existing implementations to accept a special-cased modified lifetime attribute. Your "None" change is, as I explained above, intended to be permitted under the draft. I would certainly be willing to state this more explicitly. >Support requires minimally: > > o add the new Notify code; Yes. > o accept a SPI size of 8 and don't reject it (this is different from > the treatment of other Notifies directed at a Phase II SA); This seemed right to me when I wrote it, but upon re-reading the ISAKMP document, I would agree that it should be the ISAKMP cookies. > o do not abort the established SA upon this Notify type. Yes. >This prescription doesn't address the issue for the Phase I SA, which it >must. Remember, the IP DOI is not restricted to Phase II activities. Maybe, maybe not. The Phase II lifetimes might be more interesting, since they're the one's more likely to actually expire. Believe me, I don't want to destabilize these drafts. And if there's concensus that this is a "bad thing", I have no qualms about removing it. However, I will strongly object to proposed changes to the proposal syntax in ISAKMP and I believe that it's desirable to have a way for the responder to inform the initiator of his chosen lifetime. Derrell From owner-ipsec Tue Sep 30 22:52:52 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id WAA28626 for ipsec-outgoing; Tue, 30 Sep 1997 22:52:43 -0400 (EDT) Message-ID: <3431BD3B.446B@cs.umass.edu> Date: Tue, 30 Sep 1997 23:02:19 -0400 From: Lewis McCarthy Organization: UMass-Amherst Theoretical Computer Science Group, X-Mailer: Mozilla 3.01Gold (X11; U; OSF1 V3.2 alpha) MIME-Version: 1.0 To: IP Security List CC: "Sumit A. Vakil" Subject: Re: Nonce lengths in ISAKMP messages References: <4317A800.3000@usr.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Sumit, > And, sections E.1 and E.2 of the same draft state that the > strength of the 768 bit and 1024 bit MODP groups is 26. [...] 26 is an identifier for the group description property "strength of group", not an actual value of this property for any particular group. (I think it's called an "attribute class value", but my standardese may well be wrong.) The actual strength of a particular group is listed in that group's descriptor under the "Data (hex)" subheading of the "Strength of group" heading. So for example Well-Known Group 1 (the 768-bit MODP group) has strength 0x42 --- 66 in decimal. I had the same confusion when I first read Appendix E. -Lewis