From owner-ipsec Fri May 1 08:47:44 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA07191 for ipsec-outgoing; Fri, 1 May 1998 08:42:11 -0400 (EDT) Message-Id: <199805011255.FAA11975@dharkins-ss20.cisco.com> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: jpickering@phase2net.com Cc: ipsec@tis.com Subject: Re: isakmp attrubute ordering question In-Reply-To: Your message of "Thu, 30 Apr 1998 08:54:14 PDT." <35489EA6.6C4F@phase2net.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 01 May 1998 05:55:58 -0700 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk Jeff, > I have some questions about parsing and constructing SA payloads > that I was hoping somebody could answer: > > 1) The ISAKMP draft (sec 4.2) says "The responder SHOULD retain the > Proposal # field in the proposal payload and the Transform # field > in each Transform payload of the selected proposal". > > The intent appears to be making it easy for the initiator to determine > what proposal the responder chose. But since the requirement is SHOULD, > the intiator cant count on the # fields and therefore needs to > use other mechanisms, ie compare each attribute, right? Right. > 2) The IKE draft (sec 5) states "Responders MUST NOT modify > attributes...". Does this mean responders must also maintain > attribute order within a transform? No, there are no ordering requirments. > 3) The IKE draft (sec 5 next sentence) states "If the initiator of > an exchange notices that attribute values have changed..." The term > "notices" seems to be passive and not require that the initiator > actually check for changes. Should this sentence be interpreted > as MUST,SHOULD or MAY check? Interpret it as a MUST. The initiator's original offers are included in the authentication to prevent a man-in-the-middle attack but if you don't check the response I guess you could be violating your own policy. The offers and response couldn't be changed by a man-in-the-middle without detection (either the authentication fails or the two parties fail to communicate due to mis-negotiation) but you could offer, say 3DES and IDEA and the responder could respond with DES. Since you didn't offer DES it would be safe to assume you didn't want to do it for a reason and you shouldn't then start doing it simply because it was offered back to you. > Thanks in advance to anyone who comments. Sure, hope it helps. I guess there's a bit more wordsmithing to do. Groan. Dan. From owner-ipsec Fri May 1 09:41:03 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA07388 for ipsec-outgoing; Fri, 1 May 1998 09:40:14 -0400 (EDT) To: Thomas Narten Cc: "Theodore Y. Ts'o" , jis@MIT.EDU, ipsec@tis.com, ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng 5744) Re: [Karen Seo: Thomas Narten -- clarification, etc.] In-Reply-To: Thomas Narten's message of "Thu, 30 Apr 1998 11:12:27 -0400." References: <199804301512.LAA20002@cichlid.raleigh.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 01 May 1998 07:46:34 +1000 Message-Id: <17976.893972794@munnari.OZ.AU> From: Robert Elz Sender: owner-ipsec@ex.tis.com Precedence: bulk Date: Thu, 30 Apr 1998 11:12:27 -0400 From: Thomas Narten Message-ID: <199804301512.LAA20002@cichlid.raleigh.ibm.com> I just want to pick a piece out of the quoted text... | Let me back up a little and clarify the point that caught my | attention. draft-ietf-ipsec-auth-header-05.txt says: | | >>> If the IPsec implementation encounters an | >>> extension header that it does not recognize, it MUST zero the whole | >>> header except for the Next Header and Hdr Ext Len fields. To me, that reads like nonsense. If the implementation doesn't recognise the header, what would be the basis upon which it would locate the Next Header or Hdr Ext len fields? Is there some (incorrect) implicit assumption here that all headers for all time will have such fields, and that they'll always be in the same place? kre From owner-ipsec Fri May 1 09:41:25 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA07410 for ipsec-outgoing; Fri, 1 May 1998 09:41:14 -0400 (EDT) Message-ID: <3D33CF40366DD111AC4100A0C96B22AC015D53AC@FMSMSX34> From: "Patel, Baiju V" To: "'Steve Bellovin'" , "'Theodore Y. Ts'o'" Cc: "'Thomas Narten'" , "'jis@MIT.EDU'" , "'ipsec@tis.com'" , "'ipng@sunroof.eng.sun.com'" Subject: RE: [Karen Seo: Thomas Narten -- clarification, etc.] Date: Thu, 30 Apr 1998 17:09:05 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk I would agree with Steve's remark that none of these choices are particularly palatable. Here is a solution that exists within IPSEC standards that meets all the requirements and yet, not confusing: Use tunnel mode! Using AH or ESP with tunnel mode will protect IP header (including non-mutable and mutable but predictable headers). I believe that many people have suggested this option on this mailing list earlier and it will work and do the job. Baiju -----Original Message----- From: owner-ipsec@ex.tis.com [mailto:owner-ipsec@ex.tis.com]On Behalf Of Steve Bellovin Sent: Thursday, April 30, 1998 12:27 PM To: Theodore Y. Ts'o Cc: Thomas Narten; jis@MIT.EDU; ipsec@tis.com; ipng@sunroof.eng.sun.com Subject: Re: [Karen Seo: Thomas Narten -- clarification, etc.] None of these choices are particularly palatable. Just so I understand the IPV6 issues a little better --- how likely is it that we will want to invent new extension headers? And how likely is it that the ordering will matter and that the new extension header will have to be before the AH header, and could not be placed after the AH header? Well, Vern Paxson and I are talking about a new header right now -- and it would have to be mutable. From owner-ipsec Fri May 1 09:42:23 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA07431 for ipsec-outgoing; Fri, 1 May 1998 09:42:12 -0400 (EDT) To: "Theodore Y. Ts'o" Cc: Thomas Narten , jis@MIT.EDU, ipsec@tis.com, ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng 5744) Re: [Karen Seo: Thomas Narten -- clarification, etc.] In-Reply-To: "Theodore Y. Ts'o"'s message of "Thu, 30 Apr 1998 21:54:57 -0400." References: <199805010154.VAA20482@dcl.MIT.EDU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 01 May 1998 12:12:44 +1000 Message-Id: <20184.893988764@munnari.OZ.AU> From: Robert Elz Sender: owner-ipsec@ex.tis.com Precedence: bulk Date: Thu, 30 Apr 1998 21:54:57 -0400 From: "Theodore Y. Ts'o" Message-ID: <199805010154.VAA20482@dcl.MIT.EDU> | I'm curious --- was it ever the case that the extension header | processing worked the way I described them in the first paragraph? I don't think so, in fact the three fairly obvious cases where the current header is TCP, UDP, or IPv6 itself (tunnelling) all fail to fit, as does the fragment header if I remember correctly (it is of fixed size, so has no header length field). All of those have been around since the beginning. I have seen people assume that it is possible to skip unknown headers, but that has neevr been correct IPv6 behaviour. kre From owner-ipsec Fri May 1 11:06:17 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA07755 for ipsec-outgoing; Fri, 1 May 1998 11:01:18 -0400 (EDT) Message-Id: <199805011515.KAA00660@gungnir.fnal.gov> To: "Theodore Y. Ts'o" Cc: Robert Elz , Thomas Narten , jis@MIT.EDU, ipsec@tis.com, ipng@sunroof.Eng.Sun.COM From: "Matt Crawford" Subject: Re: (IPng 5744) Re: [Karen Seo: Thomas Narten -- clarification, etc.] In-reply-to: Your message of Thu, 30 Apr 1998 21:54:57 EDT. <199805010154.VAA20482@dcl.MIT.EDU> Date: Fri, 01 May 1998 10:15:20 -0500 Sender: owner-ipsec@ex.tis.com Precedence: bulk There's something sour in the infosoup. I think SOME people are confusing (Extension Headers) with (Hop-by-hop Options and Destination options). IPv6 Extensions headers have a protocol number assigned from the same 8-bit space as IPv4 protocol numbers (although some values will only be seen in an IPv4 packet, and some only in an IPv6 packet). HBH options and destination options are carried in a HBH option extension header or a destination option extension header, respectively. Each option carried has its own 8-bit type code which uses 2 bits to encode the action to be taken when the option is not understood and one bit to declare whether it's to be covered by AH. A receiver "should" reject a packet if it is called upon to process any unknown extension header. An packet with an unknown (HBH or Destination) option, on the other hand, is handled in accordance with the two bit field referred to above. (See page 9 of ..ipv6-spec-v2-01.) Matt From owner-ipsec Sat May 2 10:11:53 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA11031 for ipsec-outgoing; Sat, 2 May 1998 10:03:21 -0400 (EDT) X-Sender: kent@po1.bbn.com (Unverified) Message-Id: In-Reply-To: <3.0.1.32.19980430131537.006b6188@192.9.200.10> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 2 May 1998 10:12:51 -0400 To: K SrinivasRao From: Stephen Kent Subject: Re: Which SPD we have to use ? Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Srinivas, >w.r.t draft-ietf-ipsec-isakmp-08.txt. > >When an outgoing packet does not find any SA associated with it and if >IPSEC process has to be applied on it, then we have start negotiating. For >this we have to send proposals (may be more than one) to the responder. > >* Whether the proposal to be sent are from INBOUND SPD or OUTBOUND SPD at >the initiator? > >* How does the responder selects the SPD entry when he receives the >proposals? Because selectors are not available. Whether he selects INBOUND >SPD or OUTBOUND SPD? I would expect the initiator to send a proposal consistent with his OUTBOUND SPD, and the responder will match that against his INBOUND SPD. We've refined the IPsec Arch Doc over time to try to make the selector set consistent with the DOI proposals, so matching between the two should work. >* I feel for one negotiation all together 4 SAs are created like. > >Initiator - Inbound and Outbound SA -- 2 SAs >Responder - Inbound and Outbound SA -- 2 SAs > Total 4 SAs Am I right ? No, only two SAs are created, 1 in each direction between initiator and responder. The notion of INBOUND and OUTBOUD is local for each end; one SA has an OUTBOUND SPD binding at one end and an INBOUND SPD binding at the other end, but it's still the same SA. >And if any one of this SA timed out (hard life time), then do we need to >terminate all the 4 SAs? How? In principle the 2 (not 4) SAs are independent, but in practice they are created in pairs, so I would expect a pair that was created together to be terminated (and maybe replaced) together. However, I'll defer to my IKE friends on this one. >* Once the negotiation is over how does the initiator and responder links >the INBOUND and OUTBOUND SAs with corresponding INBOUND and OUTBOUND SPD >entry. For all 4 SAs that are created. It is a local matter how this is done, although the Arch Doc notes the need to establish and maintain such a linkage. >* What happens when a INBOUND SA's SoftLifeTime is timed out. Will it start >renegotiation. I feel only OUTBOUND SA can initiate the renegotiation process. Good question. Again, I'll defer to the IKE experts. >* If an SA is timed out (hard life time) do we need to delete all the SAs >in the SA bundle to which it corresponds to. Not necessarily. Steve From owner-ipsec Sat May 2 19:10:27 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA11720 for ipsec-outgoing; Sat, 2 May 1998 19:07:20 -0400 (EDT) Message-Id: <199805022321.QAA01034@gallium.network-alchemy.com> To: Stephen Kent cc: K SrinivasRao , ipsec@tis.com Subject: Re: Which SPD we have to use ? In-reply-to: Your message of "Sat, 02 May 1998 10:12:51 EDT." Date: Sat, 02 May 1998 16:21:27 -0700 From: "Derrell D. Piper" Sender: owner-ipsec@ex.tis.com Precedence: bulk >>And if any one of this SA timed out (hard life time), then do we need to >>terminate all the 4 SAs? How? > >In principle the 2 (not 4) SAs are independent, but in practice they are >created in pairs, so I would expect a pair that was created together to be >terminated (and maybe replaced) together. However, I'll defer to my IKE >friends on this one. This is a local matter. You can track the pair together, but you don't have to. My implementation pairs them up during the negotiation, but once they become valid they live and/or die on their own. (They always start off life with the same expiration.) >>* What happens when a INBOUND SA's SoftLifeTime is timed out. Will it start >>renegotiation. I feel only OUTBOUND SA can initiate the renegotiation process. > >Good question. Again, I'll defer to the IKE experts. By omission, the current documents treat this as a local matter. In my implementation, I'm only initiating a rekey on my outbound SA's. Obviously, what's good to avoid is two sides (say of the same implementation) each deciding to rekey at exactly the same time. Expiration timers should be fuzzy so that one side has a chance of beating the other to the punch... Derrell From owner-ipsec Mon May 4 00:21:53 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id AAA14021 for ipsec-outgoing; Mon, 4 May 1998 00:15:19 -0400 (EDT) Message-Id: <199805040117.VAA20047@smb.research.att.com> From: Steve Bellovin To: ipsec@tis.com Subject: low-end IPSEC boxes? Date: Sun, 03 May 1998 21:14:30 -0400 Sender: owner-ipsec@ex.tis.com Precedence: bulk Is anyone making low-end IPSEC boxes? That is, I'm looking for something that will support tunnel mode for the so-called SOHO (small office, home office) market. I look for throughput of a megabit/second, or perhaps twice that, for ~4-8 client machines in a fairly simple topological relationship to a core network. From owner-ipsec Mon May 4 08:50:41 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA15533 for ipsec-outgoing; Mon, 4 May 1998 08:49:27 -0400 (EDT) X-Sender: deering@postoffice.cisco.com Message-Id: In-Reply-To: <199805010154.VAA20482@dcl.MIT.EDU> References: Robert Elz's message of Fri, 01 May 1998 07:46:34 +1000, <17976.893972794@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 1 May 1998 19:22:03 -0700 To: "Theodore Y. Ts'o" From: Steve Deering Subject: Re: (IPng 5759) Re: [Karen Seo: Thomas Narten -- clarification, etc.] Cc: Robert Elz , Thomas Narten , "Theodore Y. Ts'o" , jis@MIT.EDU, ipsec@tis.com, ipng@sunroof.Eng.Sun.COM Sender: owner-ipsec@ex.tis.com Precedence: bulk At 6:54 PM -0700 4/30/98, Theodore Y. Ts'o wrote: > If this is the case, this simplifies things significantly. This way, if > there is an unknown extension header before the AH header, the IPSEC > host (or security gateway) will have already rejected the packet and > have sent an ICMP packet back at the sender. So we don't need to have > any words about handling unknown extension headers; they will just be > rejected. Can someone in the IPNG working group confirm my reading of > IPV6 spec? Your reading of the IPv6 spec is correct, except that it doesn't say or imply anything about the bahavior of security gateways. Gateways that encapsulate entire IPv6 packets with an AH header will not examine any extension headers in the packet to be encapsulated, and therefore will not reject it on the basis of an unrecognized header. Gateways that insert an AH header into a passing IPv6 packet (architecturally impure device that I hope no one is seriously advocating) will probably have to treat an unrecognized header as a potential end-to-end header (e.g., an unrecognized transport protocol header), and therefore will insert the AH header before the unrecognized header and forward it onward, rather than rejecting it. > I'm curious --- was it ever the case that the extension header > processing worked the way I described them in the first paragraph? No. For the reasons you realized. > The IPV6 expert whom I talked to was pretty definitive that this was the > way things worked; I was pretty surprised, since I thought it was incredibly > ugly and unclean, but I wasn't the IPv6 expert. Your expert was mistaken (perhaps having once argued in favor of the behavior described to you, and forgetting that he or she didn't actually win the argument?). Steve From owner-ipsec Mon May 4 08:50:57 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA15517 for ipsec-outgoing; Mon, 4 May 1998 08:48:28 -0400 (EDT) X-Sender: deering@postoffice.cisco.com Message-Id: In-Reply-To: <199804301512.LAA20002@cichlid.raleigh.ibm.com> References: Your message of "Thu, 30 Apr 1998 01:17:32 EDT." <199804300517.BAA20034@dcl.MIT.EDU> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 1 May 1998 18:53:50 -0700 To: Thomas Narten From: Steve Deering Subject: Re: (IPng 5744) Re: [Karen Seo: Thomas Narten -- clarification, etc.] Cc: "Theodore Y. Ts'o" , jis@MIT.EDU, ipsec@tis.com, ipng@sunroof.Eng.Sun.COM Sender: owner-ipsec@ex.tis.com Precedence: bulk Here's my take on IPv6 options and extension headers vs. AH computation. First, let's consider IPv6 options, i.e., those TLV things that are carried in either the Hop-by-Hop Options header or the Destination Options header. IPv6 options are designed to allow AH processing without understanding the semantics of the option. For example, a new option may be defined in the future, and an upper-layer protocol or application may request (via the IPv6 API) transmission of a packet containing that new option without requiring any change to the IPv6 (including AH) module in the source node. The Type code of the option indicates to the AH implementation whether or not the option data is mutable en-route. If it is mutable, the data is treated as zeros for AH purposes, else the data is treated verbatim. An option whose data is mutable en-route but whose final value is predictable must still be treated as zeros for AH purposes, because even though the final value may be predictable by the entity that requests transmission of the option (an upper-layer protocol or application in the source node), it would not be predictable to the (unmodified) AH implementation in the source node. To allow special handling of the "mutable but predictable" case would require a more elaborate IPv6 API in which both the original value and the predicted final value of an option could be supplied by an application or upper-layer protocol to the IPv6 (including AH) module. I don't think the added flexibility would be worth the extra complexity in the API and the extra documentation needed to explain this feature. Therefore, I am in favor of leaving the current definition of the IPv6 option Type encoding as is. Now let's consider IPv6 extension headers. In order for an AH implementation to compute an authenticating value to place in an AH header of a packet, the IPv6 module of which the AH implementation is a part must understand the semantics of all headers *preceding* the AH header. That is necessary in order to *find* the AH header in the first place (or to decide where to put it, in the case of a black-box AH-inserter). If, while parsing the headers preceding an AH header, an IPv6 module encounters a Next Header value that it does not understand: (a) It cannot tell whether the identified next header is an IPv6 extension header or something else. (E.g., it might be an unrecognized transport protocol header or anything else that can be identified by the IPv4/IPv6 Protocol/Next Header numbering space. (b) Even if it could tell that the next header were an IPv6 extension header, it could not necessarily tell how long that header is or what the type of the subsequent header is. (It is not required that all extension headers even have an explicit length field, let alone a length field in the same location and of the same granularity as in other extension headers, nor is it required that every extension header have its Next Header field at the same relative offset.) (c) Even if it could tell the length and subsequent header type of an unrecognized extension header, it could not necessarily continue parsing after the header. (E.g., imagine an IPv6 module that could recognize the length and next-header field of a Fragment header, but did not understand its semantics. For any packet carrying a non-initial fragment, the stuff that followed the Fragment header cannot be parsed as another header.) An AH implementation is not required to parse or recognize any headers *following* the AH header in a packet -- everything following the AH header must be treated as "payload" to be included in the AH computation as-is. This implies that everything following an AH header is considered immutable, which in turn implies that AH is incompatible with intermediate devices that modify, say, transport-layer headers (like NAT boxes and TCP "helpers"). That's a feature, not a bug. Since an IPv6 implementation processing an AH header must understand the semantics of all headers that precede the AH header, any new extension header designed to precede an AH header can include in its specification whatever AH handling is desired. For example, the specification could specify that certain parts of the header are: - immutable and included as-is in the AH computation, - mutable and treated as zero-valued for the AH computation, or - mutable but with a predictable final value that is to be included in the AH computation. Determining whether or not a destination understands a new extension header (whether it precedes or follows an AH header) is the originator's problem, just like determining whether or not a destination understands a new transport-layer header. A receiver that, in normal IPv6 processing, encounters an unrecognized header sends an ICMP Unrecognized Header Type message back to the source, which at least will explain to a source why it is failing. A device that inserts an AH header into a packet (as opposed to encapsulating the packet as payload following an AH header) without the knowledge and assistance of the source IPv6 module will presumably insert the AH header immediately following all headers that it recognizes as not being end-to-end (those being: a Hop-by-Hop Options header, any Routing headers, and any Destination Options headers that precede any Routing header). It would have no choice but to treat any unrecognized header as end-to-end -- it might well be an unrecognized transport-layer header, for example -- and would have to insert the AH header before the unrecognized header, and therefore treat the entire unrecognized header and everything following it as payload to be included in the AH computation. If such devices become common, it will make it difficult to introduce new extension headers that are not both end-to-end and immutable in transit. Though I think such devices are ill-advised (tunnel mode AH ought to be used instead), I don't think losing the ability to define new non-end-to-end or mutable extension headers would be all that horrible. All of the desired functionality ought to be achievable by the use of options rather than new extension headers, with the exception of getting AH coverage of a predictable final value of a mutable option. In any case, and to conclude after that long-winded explanation, the part of draft-ietf-ipsec-auth-header-05.txt that says: >>> If the IPsec implementation encounters an >>> extension header that it does not recognize, it MUST zero the whole >>> header except for the Next Header and Hdr Ext Len fields. does not make sense. At the source or destination of a packet, the presence of an unrecognized extension header before an AH header will prevent the AH processing from ever being invoked. In a black-box AH-inserter, any unrecognized header would necessarily follow the inserted AH header, and thus be treated as payload data and not zeroed. Steve From owner-ipsec Mon May 4 09:24:01 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA15972 for ipsec-outgoing; Mon, 4 May 1998 09:23:35 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: References: <199805010154.VAA20482@dcl.MIT.EDU> Robert Elz's message of Fri, 01 May 1998 07:46:34 +1000, <17976.893972794@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 4 May 1998 09:27:05 -0400 To: Steve Deering From: Stephen Kent Subject: Re: (IPng 5759) Re: [Karen Seo: Thomas Narten -- clarification, etc.] Cc: "Theodore Y. Ts'o" , Robert Elz , Thomas Narten , jis@MIT.EDU, ipsec@tis.com, ipng@sunroof.Eng.Sun.COM Sender: owner-ipsec@ex.tis.com Precedence: bulk Steve >Gateways that insert an AH header into a passing IPv6 packet (architecturally >impure device that I hope no one is seriously advocating) will probably have >to treat an unrecognized header as a potential end-to-end header (e.g., >an unrecognized transport protocol header), and therefore will insert the >AH header before the unrecognized header and forward it onward, rather than >rejecting it. IPsec requires any security gateway to use tunnel mode for transit traffic, avoiding the problem you cite. Thus such an implementation would not only be "architectually impure," it also would be non-compliant. Steve From owner-ipsec Mon May 4 10:06:33 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA16234 for ipsec-outgoing; Mon, 4 May 1998 10:04:33 -0400 (EDT) From: Mingtai_Chang@ne.3com.com X-Lotus-FromDomain: 3COM To: smb@research.att.com cc: ipsec@tis.com Message-ID: <852565FA.004E4FEA.00@usboxmta.ne.3com.com> Date: Mon, 4 May 1998 10:22:01 -0400 Subject: Re: low-end IPSEC boxes? Mime-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk How low-end are you willing to go? Would a strip-down NT box (v 5.0) do the job. (A simple Pentium motherboad, power supply, and an PCI/NIC, running NT workstation should do.) It also depends on what kind of Network Interface you are talking about. T1? Cable modem? For SOHO market, you may also want NAT running on it, which makes it more interesting. Is anyone making low-end IPSEC boxes? That is, I'm looking for something that will support tunnel mode for the so-called SOHO (small office, home office) market. I look for throughput of a megabit/second, or perhaps twice that, for ~4-8 client machines in a fairly simple topological relationship to a core network. From owner-ipsec Mon May 4 10:58:42 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA16627 for ipsec-outgoing; Mon, 4 May 1998 10:57:40 -0400 (EDT) Date: Fri, 1 May 1998 00:44:22 -0400 From: Gordon Oliver Subject: Re: [Karen Seo: Thomas Narten -- clarification, etc.] To: Michael Richardson Cc: ipsec@tis.com Message-Id: X-Mailer: TkMail 4.0beta9 In-Reply-To: <199804230212.WAA00570@morden.sandelman.ottawa.on.ca> Sender: owner-ipsec@ex.tis.com Precedence: bulk ... Michael Richardson said ... >>>>>> "Thomas" == Thomas Narten writes: > Thomas> If the sender "recognizes" the option, but the receiver > Thomas> does not, presumably there is no issue. The receiver will > Thomas> not know what to do with the header and toss the > Thomas> packet. It doesn't really make sense for a receiver to > > Maybe. Or, maybe some headers are designed to be passed to some (unknown to >IPsec) upper layer. Any header that IPsec cannot quantify as being immutable, it will not be able to authenticate... That is a security risk (severe) if the upper layer thinks it has protection. This is the same as the aforementioned case of a low-level header that goes through security gateways unprotected... > Second, you have to do AH checking first. If not, then the bad guy >just changes headers to bad values, and the receiver discards them. If >the header was covered by AH, then it should really cause an >authentication fail, (which should mean to some user that something >bad is happening) rather than an "invalid option" header. This assumes a particularly strange threat model... A "bad guy" who can change headers to bad values can just change the AH header to a bad value. suddenly there is no authentication... I'm not at all clear on what you could hope to gain by authenticating a message that you know is bad. -gordo From owner-ipsec Mon May 4 11:17:19 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA16740 for ipsec-outgoing; Mon, 4 May 1998 11:15:42 -0400 (EDT) Message-Id: <199805041525.PAA19130@orchard.arlington.ma.us> To: Stephen Kent cc: Steve Deering , "Theodore Y. Ts'o" , Robert Elz , Thomas Narten , jis@MIT.EDU, ipsec@tis.com, ipng@sunroof.eng.sun.com Subject: Re: (IPng 5759) Re: [Karen Seo: Thomas Narten -- clarification, etc.] In-reply-to: Your message of "Mon, 4 May 1998 09:27:05 -0400 ." Date: Mon, 04 May 1998 11:25:51 -0400 From: Bill Sommerfeld Sender: owner-ipsec@ex.tis.com Precedence: bulk > >Gateways that insert an AH header into a passing IPv6 packet (architecturally > >impure device that I hope no one is seriously advocating) will probably have > >to treat an unrecognized header as a potential end-to-end header (e.g., > >an unrecognized transport protocol header), and therefore will insert the > >AH header before the unrecognized header and forward it onward, rather than > >rejecting it. > > IPsec requires any security gateway to use tunnel mode for transit traffic, > avoiding the problem you cite. Thus such an implementation would not only > be "architectually impure," it also would be non-compliant. What about "bump in the cord" security devices which sit between a single host and the rest of the network, and do the AH/ESP protocol processing for them? They are, I believe, allowed for by the ipsec architecture spec, and, depending on how you look at them, they have aspects of both host and security-gateway implementations of AH/ESP.. - Bill From owner-ipsec Mon May 4 11:44:20 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA16952 for ipsec-outgoing; Mon, 4 May 1998 11:43:46 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <199805041525.PAA19130@orchard.arlington.ma.us> References: Your message of "Mon, 4 May 1998 09:27:05 -0400 ." Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 4 May 1998 11:41:27 -0400 To: Bill Sommerfeld From: Stephen Kent Subject: Re: (IPng 5759) Re: [Karen Seo: Thomas Narten -- clarification, etc.] Cc: Steve Deering , "Theodore Y. Ts'o" , Robert Elz , Thomas Narten , jis@MIT.EDU, ipsec@tis.com, ipng@sunroof.eng.sun.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Bill, I believe that the Arch Doc considers a BITW Ipsec device to be a host implementation in that context (at least for a single homed host). If the same device is used in front of a router, then it inherits the security gateway requirements. Steve From owner-ipsec Mon May 4 11:59:02 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA17001 for ipsec-outgoing; Mon, 4 May 1998 11:58:45 -0400 (EDT) Message-Id: <199805041609.QAA19272@orchard.arlington.ma.us> To: Stephen Kent cc: Steve Deering , "Theodore Y. Ts'o" , Robert Elz , Thomas Narten , jis@MIT.EDU, ipsec@tis.com, ipng@sunroof.eng.sun.com Subject: Re: (IPng 5759) Re: [Karen Seo: Thomas Narten -- clarification, etc.] In-reply-to: Your message of "Mon, 4 May 1998 11:41:27 -0400 ." Date: Mon, 04 May 1998 12:09:44 -0400 From: Bill Sommerfeld Sender: owner-ipsec@ex.tis.com Precedence: bulk > I believe that the Arch Doc considers a BITW Ipsec device to be a host > implementation in that context (at least for a single homed host). If the > same device is used in front of a router, then it inherits the security > gateway requirements. However, the fact that the host implementation is in two pieces allows for the possibility that the "real host" can generate extension headers which the "bump" doesn't know about. Actually, given modular software components, the same thing can happen within a single host implementation. >From an engineering point of view, I think there should clearly be a specified behavior in the presence of unknown extension headers.. - Bill From owner-ipsec Mon May 4 12:02:08 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA17025 for ipsec-outgoing; Mon, 4 May 1998 12:01:46 -0400 (EDT) Message-Id: <199805041615.QAA19290@orchard.arlington.ma.us> To: Mingtai_Chang@ne.3com.com cc: smb@research.att.com, ipsec@tis.com Subject: Re: low-end IPSEC boxes? In-reply-to: Your message of "Mon, 4 May 1998 10:22:01 -0400 ." <852565FA.004E4FEA.00@usboxmta.ne.3com.com> Date: Mon, 04 May 1998 12:15:44 -0400 From: Bill Sommerfeld Sender: owner-ipsec@ex.tis.com Precedence: bulk > How low-end are you willing to go? Would a strip-down NT box (v 5.0) > do the job. (A simple Pentium motherboad, power supply, and an > PCI/NIC, running NT workstation should do.) Of course, a stripped down PC running linux or *BSD would be even cheaper than the same hardware running NT.. - Bill From owner-ipsec Mon May 4 12:10:14 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA17077 for ipsec-outgoing; Mon, 4 May 1998 12:09:45 -0400 (EDT) Message-ID: <354DEB8A.41AD9ECF@redcreek.com> Date: Mon, 04 May 1998 09:23:38 -0700 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.05 [en] (Win95; U) MIME-Version: 1.0 To: Steve Bellovin CC: ipsec@tis.com Subject: Re: low-end IPSEC boxes? References: <199805040117.VAA20047@smb.research.att.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi Steve, RedCreek Communications has (among other things) a 4Mbit BITW box that is around the size of a pack of cigarettes that would probably fill the bill, and also windows client software. Check out http://www.redcreek.com for further info, or send me email and I'll direct you to the appropriate RedCreek rep. Scott From owner-ipsec Mon May 4 14:20:14 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA17741 for ipsec-outgoing; Mon, 4 May 1998 14:17:47 -0400 (EDT) Message-ID: <3D33CF40366DD111AC4100A0C96B22AC015D53B4@FMSMSX34> From: "Patel, Baiju V" To: "'Stephen Kent'" , "'Steve Deering'" Cc: "'Theodore Y. Ts'o'" , "'Robert Elz'" , "'Thomas Narten'" , "'jis@MIT.EDU'" , "'ipsec@tis.com'" , "'ipng@sunroof.Eng.Sun.COM'" Subject: RE: (IPng 5759) Re: [Karen Seo: Thomas Narten -- clarification, e tc.] Date: Mon, 4 May 1998 11:31:25 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk Lets say that there is a large server on which it does not make sense to implement IPSEC. In that case, one would put a small dedicated device to do IPSEC transport mode for all the intranet use. It is not a gateway. The dedicated box is implementing IPSEC function on behalf of a single server (could be a coprocessor for a mainframe system for all I know). This I hope is legal and will suffer from the problems being discussed. Baiju -----Original Message----- From: owner-ipsec@ex.tis.com [mailto:owner-ipsec@ex.tis.com]On Behalf Of Stephen Kent Sent: Monday, May 04, 1998 6:27 AM To: Steve Deering Cc: Theodore Y. Ts'o; Robert Elz; Thomas Narten; jis@MIT.EDU; ipsec@tis.com; ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng 5759) Re: [Karen Seo: Thomas Narten -- clarification, etc.] Steve >Gateways that insert an AH header into a passing IPv6 packet (architecturally >impure device that I hope no one is seriously advocating) will probably have >to treat an unrecognized header as a potential end-to-end header (e.g., >an unrecognized transport protocol header), and therefore will insert the >AH header before the unrecognized header and forward it onward, rather than >rejecting it. IPsec requires any security gateway to use tunnel mode for transit traffic, avoiding the problem you cite. Thus such an implementation would not only be "architectually impure," it also would be non-compliant. Steve From owner-ipsec Mon May 4 14:31:13 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA17812 for ipsec-outgoing; Mon, 4 May 1998 14:30:51 -0400 (EDT) Message-Id: <199805041845.OAA20814@cichlid.raleigh.ibm.com> X-Authentication-Warning: cichlid.raleigh.ibm.com: Host localhost.raleigh.ibm.com [127.0.0.1] didn't use HELO protocol To: Steve Deering cc: "Theodore Y. Ts'o" , jis@MIT.EDU, ipsec@tis.com, ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng 5744) Re: [Karen Seo: Thomas Narten -- clarification, etc.] In-reply-to: Your message of "Fri, 01 May 1998 18:53:50 PDT." Date: Mon, 04 May 1998 14:45:14 -0400 From: Thomas Narten Sender: owner-ipsec@ex.tis.com Precedence: bulk Steve, Thanks for the explanation regarding IPv6 options. I was not (and am not) calling for changing the semantics of the "mutable" bit in the options; rather, I was seeking confirmation that the intended semantics were those as written in the current draft. Looking back at RFC 1883, the same text is there also. I was apparently confusing the IPv6 options and extension headers in my original note on this point, assuming they were intended to have similar semantics. Thomas From owner-ipsec Mon May 4 15:34:53 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA18132 for ipsec-outgoing; Mon, 4 May 1998 15:31:47 -0400 (EDT) Message-Id: <98May4.154651edt.11649@janus.tor.securecomputing.com> To: Derrell Piper Cc: ipsec@tis.com Subject: RESPONDER_LIFETIME message format query 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: Mon, 4 May 1998 15:45:49 -0400 Sender: owner-ipsec@ex.tis.com Precedence: bulk The DOI says: 4.6.3.1 RESPONDER-LIFETIME The RESPONDER-LIFETIME status message may be used to communicate the IPSEC SA lifetime chosen by the responder. When present, the Notification Payload MUST have the following format: o Payload Length - set to length of payload + size of data (var) o DOI - set to IPSEC DOI (1) o Protocol ID - set to selected Protocol ID from chosen SA >>>> o SPI Size - set to sixteen (16) (two eight-octet ISAKMP cookies) o Notify Message Type - set to RESPONDER-LIFETIME (Section 4.6.3) >>>> o SPI - set to the two ISAKMP cookies o Notification Data - contains an ISAKMP attribute list with the responder's actual SA lifetime(s) Why is the SPI here the ISAKMP SPI? Shouldn't it be the ISAKMP SPI iff the lifetime in question is the Phase1 lifetime being 'adjusted', and the IPSEC SPI iff the lifetime in question is the Phase2 lifetime? Confused, -- Harald Koch From owner-ipsec Mon May 4 16:40:29 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA18548 for ipsec-outgoing; Mon, 4 May 1998 16:38:47 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <199805041609.QAA19272@orchard.arlington.ma.us> References: Your message of "Mon, 4 May 1998 11:41:27 -0400 ." Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 4 May 1998 16:44:18 -0400 To: Bill Sommerfeld From: Stephen Kent Subject: Re: (IPng 5759) Re: [Karen Seo: Thomas Narten -- clarification, etc.] Cc: Steve Deering , "Theodore Y. Ts'o" , Robert Elz , Thomas Narten , jis@MIT.EDU, ipsec@tis.com, ipng@sunroof.eng.sun.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Bill, >However, the fact that the host implementation is in two pieces allows >for the possibility that the "real host" can generate extension >headers which the "bump" doesn't know about. Actually, given modular >software components, the same thing can happen within a single host >implementation. > >>From an engineering point of view, I think there should clearly be a >specified behavior in the presence of unknown extension headers.. Good point. Steve From owner-ipsec Tue May 5 00:41:20 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id AAA19449 for ipsec-outgoing; Tue, 5 May 1998 00:37:47 -0400 (EDT) Date: Tue, 5 May 1998 00:50:32 -0400 Message-Id: <199805050450.AAA21748@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: Bill Sommerfeld Cc: Stephen Kent , Steve Deering , "Theodore Y. Ts'o" , Robert Elz , Thomas Narten , jis@MIT.EDU, ipsec@tis.com, ipng@sunroof.eng.sun.com In-Reply-To: Bill Sommerfeld's message of Mon, 04 May 1998 12:09:44 -0400, <199805041609.QAA19272@orchard.arlington.ma.us> Subject: Re: (IPng 5759) Re: [Karen Seo: Thomas Narten -- clarification, etc.] Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: owner-ipsec@ex.tis.com Precedence: bulk Date: Mon, 04 May 1998 12:09:44 -0400 From: Bill Sommerfeld However, the fact that the host implementation is in two pieces allows for the possibility that the "real host" can generate extension headers which the "bump" doesn't know about. Actually, given modular software components, the same thing can happen within a single host implementation. >From an engineering point of view, I think there should clearly be a specified behavior in the presence of unknown extension headers.. The question is what a BITW (Bump In The Wire) implementation will do when it tries to apply AH. RFC 1883 specifies a recommended IPv6 extension header order: IPv6 header Hop-by-Hop Options header Destination Options header (note 1) Routing header Fragment header Authentication header (note 2) Encapsulating Security Payload header (note 2) Destination Options header (note 3) upper-layer header So, presumably a BITW implementation will need to paw through the extension headers looking for the right place to insert the AH header. Question --- what should it do if it finds an extension header that it doesn't know about? I suppose it could add the AH header before the unknown extension header, but it's not clear that will always be the right thing. In fact, I'm not sure that a BITW implementation is a good idea for IPV6, given my quick exposure to it. If the IPNG working group wants to preserve flexibility about adding new extension headers, some before the Authentication Header (so that intervening network-layer devices can more easily look at them, or modify them), and some after the Authentication Header, it's not at all clear how to make this work with a BITW implementation that doesn't know where to insert the authentication header. (And while we've been using the AH in this discussion, the same concerns apply for ESP as well. The question is at what point in the extension headers do you apply the security protocol when doing a BITW implementation.) - Ted From owner-ipsec Tue May 5 01:24:33 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id BAA19543 for ipsec-outgoing; Tue, 5 May 1998 01:23:48 -0400 (EDT) Date: Tue, 5 May 1998 01:38:29 -0400 Message-Id: <199805050538.BAA21758@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: ipsec@tis.com, ipng@sunroof.eng.sun.com Subject: [Theodore Y. Ts'o: Re: forward progress on IPSec AH] Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: owner-ipsec@ex.tis.com Precedence: bulk I meant to sent the following to the working group lists, sorry. - Ted ------- Forwarded Message Date: Tue, 5 May 1998 01:21:50 -0400 From: "Theodore Y. Ts'o" To: Thomas Narten Cc: "Theodore Y. Ts'o" , Steve Bellovin , jis@MIT.EDU, rgm-sec@htt-consult.com, mleech@nortel.ca In-Reply-To: Thomas Narten's message of Fri, 01 May 1998 09:34:54 -0400, <199805011334.JAA19312@cichlid.raleigh.ibm.com> Subject: Re: forward progress on IPSec AH Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Date: Fri, 01 May 1998 09:34:54 -0400 From: Thomas Narten What needs to be done to get closure on these documents? OK, what to do... 1) The mutable bit semantics discussion in IPv6 options is (I believe) mostly an IPng discussion. In a sense, IPSec just needs to do what the IPng documents say. I'd like to wait for input from Deering (he's ACKed me that he will do so RSN). If the end result is leave things as currently defined, the issue goes away. Deering has weighed in to not change the mutable bit semantics for options. Assuming that we go with his recommendation, the IPSEC and IPNG drafts seem to be in agreement here, so the issue goes away. I think part of the confusion is caused by rather confusing terminology. There are Extensions (which are sometimes called options, I think incorrectly), as well as sets of individual options (taken from a different number space than the Extension headers) for the Hop by Hop and Destination options Extensions. As near as I can tell, calling the other extension headers "options" is a misnomer. Some extension headers are _optional_, but they should not be called _options_. Some of this confusion is in the AH spec, but I've seen it in other places as well. I think we will eventually want to clean up the text, before we go to draft standard, but I don't think we necessarily need to clear this up now. 2) The interoperability issue I raised with regards to whether the sender includes a "new" extension header in the AH check needs some sort of resolution. This problem is largely independent of 1). I believe that this is an IPSec decision to make. Just pick the least worst solution, it would seem. It looks like the IPV6 drafts very explicitly say that new extension headers cause the packet to be rejected. If we are to harmonize with this position, then the following text in section 3.3.3.1 of the auth-header document must be changed: If the IPsec implementation encounters an extension header that it does not recognize, it MUST zero the whole header except for the Next Header and Hdr Ext Len fields. The length of the extension header MUST be computed by 8 * Hdr Ext Len value + 8. ... since there's no good way to determine where the next header and header length fields were. (It would have been good if the location for next header and header-length were fixed for all non-terminal header, which apparently originally was a design goal, but several IPV6 folks have claimed that this is now a bad assumption to make.) If this is true, I don't see how to what else BITS or BITW implementations can do besides reject packets if they don't know what to do with an extension header which comes before the AH or ESP header. Processing has to stop, since there's no way to continue. Proposed replacement text for the above text in 3.3.3.1: If the IPsec implementation encounters an extension header that it does not recognize, it MUST reject it per section 4 of RFC 1883. Again, in the future, we may want to harmonize the terminology so that there aren't any confusion between how the IPV6 specs says things and the IPSEC spec says thing. We probably need to make more explicit that some IPV6 extension headers may appear before the Authentication Header, and some may appear afterwards, and that all extension headers appearing after the AH are included in the ICV. This is strongly implied, and apparently assumes this is the case, but it is not actually stated explicitly. Comments on the above approach for moving forward? (Leave the mutability text alone, and harmonize with the RFC-1883 position which says that unknown extension headers cause an ICMP code 2 packet.) - Ted ------- End Forwarded Message From owner-ipsec Tue May 5 13:56:39 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA22284 for ipsec-outgoing; Tue, 5 May 1998 13:52:51 -0400 (EDT) Date: Tue, 5 May 1998 14:06:39 -0400 Message-Id: <199805051806.OAA21942@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: Thomas Narten Cc: Robert Moskowitz , "Theodore Y. Ts'o" , Steve Bellovin , jis@MIT.EDU, mleech@nortel.ca, ipsec@tis.com In-Reply-To: Thomas Narten's message of Tue, 05 May 1998 10:22:32 -0400, <199805051422.KAA16206@cichlid.raleigh.ibm.com> Subject: Re: forward progress on IPSec AH Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: owner-ipsec@ex.tis.com Precedence: bulk Date: Tue, 05 May 1998 10:22:32 -0400 From: Thomas Narten > At 01:21 AM 5/5/98 -0400, Theodore Y. Ts'o wrote: > > > >Comments on the above approach for moving forward? (Leave the > >mutability text alone, and harmonize with the RFC-1883 position which > >says that unknown extension headers cause an ICMP code 2 packet.) > Ted, I think you have covered it. Agreed. I think we have a workable compromise which everyone is willing to live with. I've talked to Karen Seo regarding making these changes, and she look into updating the draft and fixing these problems. There were also a set of typographical/editorial changes identified by Marc Hasson that she will also look at incorporating. These are mostly pure editorial changes (i.e., references to section 3.3.2 that really be section 3.3.3, etc.) or other places where we made a change to one part of the document, but forgot to make a similar change in another part of the document, so there was a conflict. (Changes which require making any substantive change to the protocol are out of scope at this point; we will only be making editorial changes.) Last week we reached a compromise on changing the IANA considerations text for the DOI text, and the document editor for the DOI should make those changes and resubmit them as a new I-D. With these changes, I believe the IPSEC documents should be done and ready for publication as RFC's, with all issues raised by the IESG settled. Thanks to all of those who helped get us to this point. - Ted ----------------------------------------------- Date: Thu, 30 Apr 1998 18:38:27 -0700 From: mark@mentat.com (Marc Hasson) To: tytso@MIT.EDU, kseo@bbn.com, skent@bbn.com, clynn@bbn.com Subject: Some minor IPSEC doc comments X-Sun-Charset: US-ASCII I fetched the ESP, AH, and architecture documents off of the MIT URL this morning and have these, mostly minor editorial, comments: esp-v2-05 (E-mail date at top: Thu, 23 Apr 98 4:44:15) 1) section 3.4.3 (Sequence Number Verification), 2nd paragraph The reference to section 3.3.2 looks like it should have been 3.3.3. This was OK for the AH document. 2) Conflict in what a receiver does with padding: in section 2.4 its says "... the receiver SHOULD inspect the Padding field.", presumably to enforce that sequence of integers instead of ignore them. The beginning of this paragraph labels this "... the following default processing MUST be used". However, in section 3.4.5, step 2. we have "The default action is to remove/ignore any padding." This definitely conflicts with the previous. I'm sure this is going to lead to more discussions of "tunables" and whether receivers should be checking the pad byte values or not.... arch-sec-05 (Email date at top: Thu, 23 Apr 98 4:22:01) 1) Section 4.4.2 (Selectors) Destination IP Address (IPv4 or IPv6): How about making it "unicast, multicast, or broadcast (IPv4 only)" since IPv6 doesn't have broadcast addresses? 2) Section 4.4.2 (Selectors) Source IP Addresses: Can a source address really be a broadcast or multicast? This seems like we're having IPSEC condone illegal IP[v6] packet behavior.... Perhaps if I saw the note asking for why src/dst should have the same language I'd understand this? 3) Appendix B.2 (Fragmentation), very last paragraph "Unlike Bump-in-the-stack implementations, security gateways may be able to look up the Source Address in the DNS to provide a System Name..." I'm not sure why this statement is here. Having done both an IPSEC stack for Mentat as well as having worked on a BITS implementation (involving both user and kernel pieces) I don't see any reason why a BITS implementation can't do a DNS lookup for its System name just as well as a "pure" IPSEC host or SG. In fact, part of the dynamic IP assignment (via DHCP perhaps) and DNS update may already have provided a BITS host with what it needs to do a DNS lookup. Hope these comments help more than annoy. I don't feel strongly about any of them, except perhaps the padding one would be nice to make consistent. People discuss that too much as it is... By the way, good work on all the editing. I know this was a tough job, its hard enough just to read these. And I found the CHANGES particularly useful since I didn't have time to read everything line-by-line but was able to read everything covered by CHANGES plus adjacent and related sections for context. Thanks, things look a lot better to me. -- Marc -- From owner-ipsec Tue May 5 16:07:58 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA22668 for ipsec-outgoing; Tue, 5 May 1998 16:04:53 -0400 (EDT) Message-Id: <199805052019.QAA01506@relay.rv.tis.com> Date: Tue, 5 May 98 16:10:28 EDT From: Karen Seo To: ipsec@tis.com, ipng@sunroof.eng.sun.com cc: kseo@bbn.com Subject: Re: forward progress on IPSec AH Sender: owner-ipsec@ex.tis.com Precedence: bulk Ted, >>I think part of the confusion is caused by rather confusing terminology. >>There are Extensions (which are sometimes called options, I think >>incorrectly), as well as sets of individual options (taken from a >>different number space than the Extension headers) for the Hop by Hop >>and Destination options Extensions. As near as I can tell, calling the >>other extension headers "options" is a misnomer. Some extension headers >>are _optional_, but they should not be called _options_. :-) We mentioned this possible source of confusion in our message to you re: Thomas Narten's comments. >>Some of this confusion is in the AH spec, but I've seen it in other >>places as well. I think we will eventually want to clean up the text, >>before we go to draft standard, but I don't think we necessarily need to >>clear this up now. Hmmm...I thought we'd been pretty careful about this. Please let me know where in the AH text we have confused extension headers with either options or extension headers containing options (Hop-by-Hop and Destination). That should certainly get fixed. The above question is not aimed at your statement... "... since there's no good way to determine where the next header and header length fields were. (It would have been good if the location for next header and header-length were fixed for all non-terminal header, which apparently originally was a design goal, but several IPV6 folks have claimed that this is now a bad assumption to make.)" I understand your/other's point about this. Thanks, Karen From owner-ipsec Tue May 5 16:30:08 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA22721 for ipsec-outgoing; Tue, 5 May 1998 16:29:54 -0400 (EDT) Date: Tue, 5 May 1998 16:44:36 -0400 Message-Id: <199805052044.QAA22046@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: Karen Seo Cc: ipsec@tis.com, ipng@sunroof.eng.sun.com, kseo@bbn.com In-Reply-To: Karen Seo's message of Tue, 5 May 98 16:10:28 EDT, <199805052019.QAA01506@relay.rv.tis.com> Subject: Re: forward progress on IPSec AH Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: owner-ipsec@ex.tis.com Precedence: bulk Date: Tue, 5 May 98 16:10:28 EDT From: Karen Seo Hmmm...I thought we'd been pretty careful about this. Please let me know where in the AH text we have confused extension headers with either options or extension headers containing options (Hop-by-Hop and Destination). That should certainly get fixed. They really are minor nits, but since you asked, these were the ones which I was able to find: In section 4.1 of the security architecture document: ... In the case of AH, the protection is also extended to selected portions of the IP header (and options). For more details on the coverage afforded by AH, see the AH specification [KA98a]. "IP header (and options)" should probably read something like this "IP header, extension headers (IPV6), and options (IPV4/IPV6)". In section 3.3.3.1.2.2 Extension Headers -- Options: "The IPv6 extension headers (that are options)..." should probably read "that contain options", since the extension header isn't itself an option. This was one of the things which confused me until I read RFC 1883. I'd probably also change the section title to be "Extension Headers Containing Options". A similar change should probably be made to the following section, 3.3.3.1.2.3 Extension Headers -- non-Options. - Ted From owner-ipsec Wed May 6 00:59:07 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id AAA23989 for ipsec-outgoing; Wed, 6 May 1998 00:54:55 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <3D33CF40366DD111AC4100A0C96B22AC015D53AE@FMSMSX34> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 4 May 1998 18:54:05 -0400 To: "Patel, Baiju V" From: Stephen Kent Subject: RE: IPSEC standardization status Cc: "'Theodore Y. Ts'o'" , ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Baiju, >The IPSEC architecture document says > >B.2 Fragmentation Fragmentation MUST be done after outbound IPsec >processing. > Reassembly MUST be done before inbound IPsec processing. > >When I read it (and there is a table and text that elaborates it), even for >IPSEC tunnel mode, all the fragmentation must be done after IPSEC processing >(i.e., the packet being tunneled cannot be fragmented). > >However, earlier mail from Steve Kent (attached here) states that it >must be done for transport mode and for tunnel mode (his reason >for recommending tunnel-only mode)it is not an issue. Section 3.3.5 in the ESP document, and 3.3.4 in AH clearly state that tunnel mode is applied to IP packets, the payload of which may be a fragment. I think this provides a clearer response to your question, vs. the details of Appendix B of the Arch Doc (which is meant to be read as an adjunct to these other documents). Steve From owner-ipsec Wed May 6 00:59:08 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id AAA23990 for ipsec-outgoing; Wed, 6 May 1998 00:54:55 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <3D33CF40366DD111AC4100A0C96B22AC015D53B4@FMSMSX34> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 4 May 1998 18:34:26 -0400 To: "Patel, Baiju V" From: Stephen Kent Subject: RE: (IPng 5759) Re: [Karen Seo: Thomas Narten -- clarification, e tc.] Cc: , , , , Sender: owner-ipsec@ex.tis.com Precedence: bulk Baiju, >Lets say that there is a large server >on which it does not make sense to implement >IPSEC. In that case, one would put a small >dedicated device to do IPSEC transport >mode for all the intranet use. > >It is not a gateway. The dedicated box >is implementing IPSEC function on >behalf of a single server (could be a >coprocessor for a mainframe system for >all I know). > >This I hope is legal and will suffer from the >problems being discussed. This sounds like the moral equivalent of a BITW IPsec implementation, so to that extent it is already covered. However, as was just noted, for IPv6 this could prove even more complicated in that this device ought to be aware of the same set of extension headers as the (single) host it serves. That's just another example of the added complexity that arises from non-native implementations. That's not to say it can't be done, but it also does not suggest that we ought to modify the spec to make it easier for such implementations. After all, such implementations already have to deal with more complex fragmentation problems than native stack implementations. Steve From owner-ipsec Thu May 7 01:08:16 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id AAA28749 for ipsec-outgoing; Thu, 7 May 1998 00:58:37 -0400 (EDT) Message-Id: <199805070458.AAA10739@smb.research.att.com> From: Steve Bellovin To: ipsec@tis.com Subject: ipsec vs. firewalls Date: Wed, 06 May 1998 20:12:03 -0700 Sender: owner-ipsec@ex.tis.com Precedence: bulk I came up with a disturbing conflict between ubiquitous IPSEC and common firewall policies. I'm not certain how to resolve it, either. A common firewall policy permits most outgoing calls. (The requirement to authenticate such calls, say via AH from the inside host to the firewall, wouldn't affect what comes next.) Suppose, though, that the inside host wants to use ESP for end-to-end encryption to the destination. How will the firewall inspect the return packet? To implement that firewall policy, the return packet *must* be a reply to the outbound packet -- say, the SYN+ACK in response to the SYN. But if it's encrypted, there's no way to tell; it could be a probe from the outside host to some vulnerable ports on the inside client machine. There are a number of possible solutions; each has its limitations. The most obvious, of course, is to prohibit end-to-end encryption, and require that all packets be decrypted at the firewall. Apart from the obvious security risks, this complicates the topology discovery process. Another pretty good solution is per-connection keying. But that only works if the firewall *knows* that the inside machines will indeed enforce that, and drop packets to different ports than are bound to the SPI. A third solution is to use some sort of auxiliary header with cleartext port numbers, similar to that suggested by Greg Minshall. Again, the firewall would have to *know* that hosts would drop packets where the outer and inner port numbers didn't match. Furthermore, in both this case and the previous one, all the firewall knows is the packet direction; SYN, ACK, and FIN bits are still invisible. (Well, we could expose more of the TCP header.) This reduces the ability of a dynamic firewall to handle TCP to its ability to handle UDP. Fourth, we could restrict end-to-end encryption to trusted outside hosts, and in particular to machines that comprise the VPN. Obviously, this works against general use of encryption. Finally, I suspect that some people will regard anything that cripples firewalls as a feature. With all due respect, I tend to differ... I'm not suggesting any changes to anything at this point. I do suggest that IPSEC vendors -- including IPSEC implementations that will live on firewalls -- work towards per-connection keying. From owner-ipsec Thu May 7 01:56:52 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id BAA28914 for ipsec-outgoing; Thu, 7 May 1998 01:56:36 -0400 (EDT) Date: Wed, 6 May 1998 23:11:10 -0700 (PDT) Message-Id: <199805070611.XAA02044@servo.qualcomm.com> From: Phil Karn To: smb@research.att.com CC: ipsec@tis.com, karn@qualcomm.com In-reply-to: <199805070458.AAA10739@smb.research.att.com> (message from Steve Bellovin on Wed, 06 May 1998 20:12:03 -0700) Subject: Re: ipsec vs. firewalls Sender: owner-ipsec@ex.tis.com Precedence: bulk This is hardly unique to IPSEC. SSH can already do something very similar, albeit limited to TCP. I've already used it to work around the annoying firewall that keeps me from logging in directly to my office workstation from home over a cable modem: (on office workstation) ssh -x -f -c blowfish -R1234:127.0.0.1:22 ip_address_of_home_system sleep 1000000 (on home machine) ssh -p 1234 127.0.0.1 It's not as clean as I would like, but it works. I used it heavily until I got an ADSL service installed that brought me in behind the firewall. >Finally, I suspect that some people will regard anything that >cripples firewalls as a feature. With all due respect, I tend >to differ... (rising to the bait) Firewalls are dead. Get used to it. :-) Phil From owner-ipsec Thu May 7 04:16:23 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id EAA29516 for ipsec-outgoing; Thu, 7 May 1998 04:14:36 -0400 (EDT) Date: Thu, 7 May 98 04:47:51 GMT Daylight Time From: Ran Atkinson Subject: RE: [Karen Seo: Thomas Narten -- clarification, etc.] To: "Patel, Baiju V" Cc: "'ipng@sunroof.eng.sun.com'" , "'ipsec@tis.com'" , "'jis@MIT.EDU'" , "'Thomas Narten'" X-Mailer: Chameleon ATX 6.0, Standards Based IntraNet Solutions, NetManage Inc. X-Priority: 3 (Normal) References: <3D33CF40366DD111AC4100A0C96B22AC015D53AC@FMSMSX34> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk Baiju, Tunnel-mode ESP does NOT provide the same security properties as AH. Wishing that it did and marketing it as if it did, doesn't make it true. Folks need to understand what security properties they desire, then use the appropriate mechanism(s) to provide those properties. Ran From owner-ipsec Thu May 7 04:34:19 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id EAA29586 for ipsec-outgoing; Thu, 7 May 1998 04:33:38 -0400 (EDT) Message-Id: <3.0.1.32.19980507104731.00949e20@mail.iway.fr> X-Sender: dwetzel@mail.iway.fr X-Mailer: Windows Eudora Pro Version 3.0.1 (32) [F] Date: Thu, 07 May 1998 10:47:31 +0100 To: Phil Karn From: Damien Wetzel Subject: Re: ipsec vs. firewalls Cc: ipsec@tis.com In-Reply-To: <199805070611.XAA02044@servo.qualcomm.com> References: <199805070458.AAA10739@smb.research.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk hi phil , excuse me to mind you, im working for a french provider as a presale engineer, i'm thinking as steve that firewall are not going to last long but most of our client are asking for them, So could you tell me why you are saying that : > >(rising to the bait) Firewalls are dead. Get used to it. :-) > >Phil > thanks From owner-ipsec Thu May 7 06:27:59 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id GAA29855 for ipsec-outgoing; Thu, 7 May 1998 06:24:39 -0400 (EDT) From: Bill Manning Message-Id: <199805071039.DAA28057@zephyr.isi.edu> Subject: Re: ipsec vs. firewalls To: karn@qualcomm.com (Phil Karn) Date: Thu, 7 May 1998 03:39:46 -0700 (PDT) Cc: smb@research.att.com, ipsec@tis.com, karn@qualcomm.com In-Reply-To: <199805070611.XAA02044@servo.qualcomm.com> from "Phil Karn" at May 6, 98 11:11:10 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 > >Finally, I suspect that some people will regard anything that > >cripples firewalls as a feature. With all due respect, I tend > >to differ... > > (rising to the bait) Firewalls are dead. Get used to it. :-) > > Phil Hum, I suspect that this is not entirely true, its just that most existant firewall technology is not optimally placed. If it moves from somewhere just outside the node, to just inside the node, (and we'll not quibble over the span of control issues on who gets to set the policy screens) then I think that firewalls are alive and well. -- --bill From owner-ipsec Thu May 7 06:57:28 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id GAA29918 for ipsec-outgoing; Thu, 7 May 1998 06:56:40 -0400 (EDT) Message-Id: <199805071109.HAA07101@postal.research.att.com> To: Phil Karn cc: ipsec@tis.com Subject: Re: ipsec vs. firewalls Date: Thu, 07 May 1998 07:09:29 -0400 From: Steve Bellovin Sender: owner-ipsec@ex.tis.com Precedence: bulk This is hardly unique to IPSEC. SSH can already do something very similar, albeit limited to TCP. I've already used it to work around the annoying firewall that keeps me from logging in directly to my office workstation from home over a cable modem: (on office workstation) ssh -x -f -c blowfish -R1234:127.0.0.1:22 ip_address_of_home_system sl eep 1000000 (on home machine) ssh -p 1234 127.0.0.1 It's not as clean as I would like, but it works. I used it heavily until I got an ADSL service installed that brought me in behind the firewall. The difference is that the ssh case implies bad faith on the part of the authorized inside user. The ipsec case does not. From owner-ipsec Thu May 7 09:06:03 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA00289 for ipsec-outgoing; Thu, 7 May 1998 09:03:42 -0400 (EDT) Date: Thu, 7 May 1998 15:15:31 +0200 (MET DST) From: Christophe Gouault X-Sender: gouault@viviane To: ipsec Subject: question about tunnel mode Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi ipsec folks, just a little question : when a packet is tunneled into AH or ESP, what is the value of the field "next header" in the IPsec header ? e.g. : [IPv4 or v6][ESP][IPv4] is it IP(4) or IPIP(94) ? [IPv4 or v6][ESP][IPv6] is it IPv6(41) or IPIP(94) ? Sorry if somebody already asked the question... Chris. Christophe GOUAULT - Network department Dassault Electronique - 55, quai Marcel Dassault 92215 SAINT-CLOUD cedex - FRANCE tel: +33 1 34 81 68 56 EMail: Christophe.Gouault@dassault-elec.fr From owner-ipsec Thu May 7 10:29:50 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA00565 for ipsec-outgoing; Thu, 7 May 1998 10:26:40 -0400 (EDT) Message-Id: <199805071438.KAA11263@postal.research.att.com> To: "Davis, Terry L" cc: "'Phil Karn'" , ipsec@tis.com Subject: Re: ipsec vs. firewalls Date: Thu, 07 May 1998 10:38:44 -0400 From: Steve Bellovin Sender: owner-ipsec@ex.tis.com Precedence: bulk Phil I've been a quiet listener in the background but in reference to your remark: > (rising to the bait) Firewalls are dead. Get used to it. :-) It's nice to hear someone else say that! I have been carrying them as "dead technology" in our architecture for the last two years and telli ng our vendors the same thing. They are "dead" and we need completely ne w concepts for security here. This becomes completely apparent when you start to design security for multi-gigabit links and the top-of-the-line firewalls pass maybe 100 megabits on a good day with tailwind! That's the easy thing to fix -- throw silicon at the problem. While, as I indicated earlier, I don't think firewalls are dead, I whole- heartedly agree that current corporate-scale firewalls are dinosaurs. But the problem is connectivity patterns, not speed. From owner-ipsec Thu May 7 11:20:06 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA00851 for ipsec-outgoing; Thu, 7 May 1998 11:17:46 -0400 (EDT) Message-ID: From: "Davis, Terry L" To: "'Phil Karn'" Cc: ipsec@tis.com, smb@research.att.com Subject: RE: ipsec vs. firewalls Date: Thu, 7 May 1998 07:30:07 -0700 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk Phil I've been a quiet listener in the background but in reference to your remark: > (rising to the bait) Firewalls are dead. Get used to it. :-) It's nice to hear someone else say that! I have been carrying them as "dead technology" in our architecture for the last two years and telling our vendors the same thing. They are "dead" and we need completely new concepts for security here. This becomes completely apparent when you start to design security for multi-gigabit links and the top-of-the-line firewalls pass maybe 100 megabits on a good day with tailwind! Take care, Terry L. Davis, P.E. Security Systems Integration Shared Services Group Boeing From owner-ipsec Thu May 7 11:20:24 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA00858 for ipsec-outgoing; Thu, 7 May 1998 11:18:40 -0400 (EDT) Message-ID: From: "Davis, Terry L" To: "Davis, Terry L" , "'Steve Bellovin'" Cc: "'Phil Karn'" , ipsec@tis.com Subject: RE: ipsec vs. firewalls Date: Thu, 7 May 1998 07:50:53 -0700 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk Steve In reference: > That's the easy thing to fix -- throw silicon at the problem. While, > as I indicated earlier, I don't think firewalls are dead, I whole- > heartedly agree that current corporate-scale firewalls are dinosaurs. > But the problem is connectivity patterns, not speed. > True, but that type of silicon comes with a high price. The cost and manpower curves on firewalls are much steeper than the rest of the infrastructure; we need technology and concepts that bring these back into line. Your last sentence starts to get to the heart of the problem. Take care, Terry L. Davis, P.E. Security Systems Integration Shared Services Group Boeing From owner-ipsec Thu May 7 13:11:28 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA01420 for ipsec-outgoing; Thu, 7 May 1998 13:09:41 -0400 (EDT) Date: Thu, 7 May 1998 10:24:08 -0700 (PDT) Message-Id: <199805071724.KAA04368@servo.qualcomm.com> From: Phil Karn To: bmanning@isi.edu CC: ipsec@tis.com, karn@qualcomm.com In-reply-to: <199805071039.DAA28057@zephyr.isi.edu> (message from Bill Manning on Thu, 7 May 1998 03:39:46 -0700 (PDT)) Subject: Re: ipsec vs. firewalls Sender: owner-ipsec@ex.tis.com Precedence: bulk >the node, (and we'll not quibble over the span of control issues on >who gets to set the policy screens) then I think that firewalls Actually, this "quibble" is the crux of the issue. End users detest firewalls precisely because they don't control them. When a firewall gets in their way, the usual answer from the networking staff is "tough". Even if the staff is halfway reasonable, the tables usually have to be modified manually, and that's a pain if you're trying to do something in the middle of the night from home. This merely provokes the users into setting up secret back doors and tunnels so they can get their work done. The result can be a seemingly secure firewall riddled with hidden wormholes that may or may not create hidden security vulnerabilities. There are several morals here. The most important is that security policies that piss off your users are invariably counterproductive. Another is that the Internet architecture gives so much power to the hosts that the network just can't force two consenting parties to communicate only in a certain way. This is a sort of "firewall corollary" to John Gilmore's famous line about the Net interpreting censorship as damage and routing around it. The Internet architecture has been extremely effective in keeping the telcos in their place. They're desperate to keep the total control that POTS gave them. Most of them still don't grok that they'll never control the Internet no matter how hard they try. And as the Internet has grown, certain elements of the infrastructure are taking on the unfortunate attributes of the telcos. Cable companies providing Internet connectivity are a good example. The network (and firewall) operators in certain large companies are another. Fortunately, the Internet architecture will help us keep them all down in their places along with the telcos. :-) Phil From owner-ipsec Fri May 8 00:58:26 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id AAA03507 for ipsec-outgoing; Fri, 8 May 1998 00:56:04 -0400 (EDT) Message-Id: <3.0.5.32.19980507215018.00a0cac0@homebase.htt-consult.com> X-Sender: rgm-sec@homebase.htt-consult.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 07 May 1998 21:50:18 -0700 To: Damien Wetzel , Phil Karn From: Robert Moskowitz Subject: Re: ipsec vs. firewalls Cc: ipsec@tis.com In-Reply-To: <3.0.1.32.19980507104731.00949e20@mail.iway.fr> References: <199805070611.XAA02044@servo.qualcomm.com> <199805070458.AAA10739@smb.research.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 10:47 AM 5/7/98 +0100, Damien Wetzel wrote: >im working for a french provider as a presale engineer, >i'm thinking as steve that firewall are not going to last long >but most of our client are asking for them, > >So could you tell me why you are saying that : >> >>(rising to the bait) Firewalls are dead. Get used to it. :-) >> Firewalls will serve a much different purpose in the brave new world of IPsec host deployment (coming to your company 2 full years before IPv6 deployment). Ahem. In the new regime, the Firewall will: control policy for unprotected outbound connections (not right to waste company time surfing through disney.com) Manage all of that unsecured inbound (and outbound) mail Block extraneous packets attacking all miscellenous internal devices like hubs, terminal servers and the like that may never get IPsec (or not until they get upgraded to IPv6) I think that there might be a few more items to add to this list...... Robert Moskowitz ICSA Security Interest EMail: rgm-sec@htt-consult.com From owner-ipsec Fri May 8 07:46:58 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA04386 for ipsec-outgoing; Fri, 8 May 1998 07:40:03 -0400 (EDT) From: Vach Kompella To: Subject: Re: ipsec vs. firewalls Message-ID: <5040200014850459000002L092*@MHS> Date: Fri, 8 May 1998 07:58:40 -0400 MIME-Version: 1.0 Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk I guess another solution is through policy definitions. A security policy definition that says you can use ESP through the firewall to the outside world should be accompanied by an entry that allows the firewall to let the packets through. Since the firewall is doing essentially an unnatural act of looking at bits it ought not to (TCP header), the policy definition relieves the firewall of its guilt. It does sound like the policy based networking solution involves a lot of configuration, though. I suppose it is part of the tighter security or **control** the network administrator can enforce. What do people think about providing this level of configuration as well as this level of control to the network administrator, as opposed to "figuring out security policy on the fly?" Vach Kompella IBM Corp. Network Security Product Development kompella@us.ibm.com Ph.: (919) 254-7281 Fax: (919) 254-4239 owner-ipsec@ex.tis.com on 05/07/98 02:30:00 AM Please respond to owner-ipsec@ex.tis.com To: ipsec@tis.com cc: Subject: ipsec vs. firewalls I came up with a disturbing conflict between ubiquitous IPSEC and common firewall policies. I'm not certain how to resolve it, either. A common firewall policy permits most outgoing calls. (The requirement to authenticate such calls, say via AH from the inside host to the firewall, wouldn't affect what comes next.) Suppose, though, that the inside host wants to use ESP for end-to-end encryption to the destination. How will the firewall inspect the return packet? To implement that firewall policy, the return packet *must* be a reply to the outbound packet -- say, the SYN+ACK in response to the SYN. But if it's encrypted, there's no way to tell; it could be a probe from the outside host to some vulnerable ports on the inside client machine. There are a number of possible solutions; each has its limitations. The most obvious, of course, is to prohibit end-to-end encryption, and require that all packets be decrypted at the firewall. Apart from the obvious security risks, this complicates the topology discovery process. Another pretty good solution is per-connection keying. But that only works if the firewall *knows* that the inside machines will indeed enforce that, and drop packets to different ports than are bound to the SPI. A third solution is to use some sort of auxiliary header with cleartext port numbers, similar to that suggested by Greg Minshall. Again, the firewall would have to *know* that hosts would drop packets where the outer and inner port numbers didn't match. Furthermore, in both this case and the previous one, all the firewall knows is the packet direction; SYN, ACK, and FIN bits are still invisible. (Well, we could expose more of the TCP header.) This reduces the ability of a dynamic firewall to handle TCP to its ability to handle UDP. Fourth, we could restrict end-to-end encryption to trusted outside hosts, and in particular to machines that comprise the VPN. Obviously, this works against general use of encryption. Finally, I suspect that some people will regard anything that cripples firewalls as a feature. With all due respect, I tend to differ... I'm not suggesting any changes to anything at this point. I do suggest that IPSEC vendors -- including IPSEC implementations that will live on firewalls -- work towards per-connection keying. From owner-ipsec Fri May 8 09:11:08 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA04695 for ipsec-outgoing; Fri, 8 May 1998 09:07:07 -0400 (EDT) Message-Id: Date: Thu, 7 May 1998 18:33:48 -0700 (PDT) From: Phil Karn To: dwetzel@iway.fr CC: ipsec@tis.com In-reply-to: <3.0.1.32.19980507104731.00949e20@mail.iway.fr> (message from Damien Wetzel on Thu, 07 May 1998 10:47:31 +0100) Subject: Re: ipsec vs. firewalls Reply-to: karn@ka9q.ampr.org References: <199805070458.AAA10739@smb.research.att.com> <3.0.1.32.19980507104731.00949e20@mail.iway.fr> Sender: owner-ipsec@ex.tis.com Precedence: bulk Damien, It's an old battle, and Steve and I are used to sparring over it in a friendly fashion. Firewalls are useful as temporary stopgaps when you're actually under attack, but they try to do what can only be done properly on an end-to-end basis. And to the extent that they give people a false sense of security, firewalls actually diminish security. Steve and his co-author Bill Cheswick refer to this as the "hard exterior with a chewy interior" property of many firewalled networks. Phil From owner-ipsec Fri May 8 10:32:13 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA04947 for ipsec-outgoing; Fri, 8 May 1998 10:30:05 -0400 (EDT) Date: Fri, 8 May 1998 10:43:54 -0400 (EDT) From: "M.C.Nelson" To: Damien Wetzel cc: Phil Karn , ipsec@tis.com Subject: Re: ipsec vs. firewalls In-Reply-To: <3.0.1.32.19980507104731.00949e20@mail.iway.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk I'd like to add my two-cents worth: A firewall is in its essence, a device that attempts to provide access control, without authentication. So, in terms of its technical viability, it was never alive (so far). In terms of its commercial viabilty, worldwide firewall sales reached 36,600 units last year, up 266%. Meanwhile, the average purchase price of firewalls has fallen precipitously. Cost of ownership of course remains high. I think firewalls survive because (i) they are still really the only game there is, and (ii) while occupying that niche, they have managed to dominate mindshare in the network security market. Nonetheless, organization-level access control is probably an important security service and something like a firewall is probably the right way to do it. The trick is to be able to passively authenticate datagrams. Regards, Mitch Nelson On Thu, 7 May 1998, Damien Wetzel wrote: > hi phil , > excuse me to mind you, > im working for a french provider as a presale engineer, > i'm thinking as steve that firewall are not going to last long > but most of our client are asking for them, > > So could you tell me why you are saying that : > > > >(rising to the bait) Firewalls are dead. Get used to it. :-) > > > >Phil > > > thanks > From owner-ipsec Fri May 8 10:52:17 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA04999 for ipsec-outgoing; Fri, 8 May 1998 10:51:07 -0400 (EDT) Message-Id: <199805081502.LAA06659@postal.research.att.com> To: ipsec@tis.com Subject: 3DES (was: ipsec vs. firewalls) Date: Fri, 08 May 1998 11:02:21 -0400 From: Steve Bellovin Sender: owner-ipsec@ex.tis.com Precedence: bulk I'm not sure that a discussion on the merits of firewalls is very profitable here. Regardless of whether or not we like them, I think we can all agree that firewalls are real, and are likely to remain so, and IPSEC (and everything else) should take notice of them. A more interesting topic is whether or not 3DES should be mandatory- to-implement. I suggest that it should be -- DES is obviously doomed (pick your favorite time constant), and we should take that into account. We're better off if the IPSEC boxes being deployed now are ready to switch. From owner-ipsec Fri May 8 10:56:34 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA05019 for ipsec-outgoing; Fri, 8 May 1998 10:56:07 -0400 (EDT) Message-ID: <3552B292.6709DD87@nortel.ca> Date: Fri, 08 May 1998 09:21:54 +0200 From: "Marcus Leech" Organization: Security Development X-Mailer: Mozilla 2.02 (X11; I; Linux 1.2.13 i486) MIME-Version: 1.0 To: karn@ka9q.ampr.org CC: ipsec@tis.com Subject: Re: ipsec vs. firewalls References: <199805070458.AAA10739@smb.research.att.com> <3.0.1.32.19980507104731.00949e20@mail.iway.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Phil Karn wrote: > > Damien, > > It's an old battle, and Steve and I are used to sparring over it in a > friendly fashion. > > Firewalls are useful as temporary stopgaps when you're actually under > attack, but they try to do what can only be done properly on an > end-to-end basis. And to the extent that they give people a false sense > of security, firewalls actually diminish security. > > Steve and his co-author Bill Cheswick refer to this as the "hard > exterior with a chewy interior" property of many firewalled networks. > The problem is that for a corporate network of any substantial size, there will *never* be a way to make the interior crunchy. Working, as I do, for a very large enterprise (250K addressable objects), I can't see any way to fix this. In smallish enterprises, where security policy is enforceable, you can certainly tear down the firewalls. In a large one, you don't stand a chance. One could argue "if you don't abide by the security policy, you're screwing yourself", but in reality, you're screwing the corporation. That's not a risk I want to take. While it's true that a significant number of incidents are internal, in most large enterprises, it's not clear that they dominate. From owner-ipsec Fri May 8 11:15:01 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA05082 for ipsec-outgoing; Fri, 8 May 1998 11:14:09 -0400 (EDT) Message-ID: <3D33CF40366DD111AC4100A0C96B22AC015D53DA@FMSMSX34> From: "Patel, Baiju V" To: "'Ran Atkinson'" Cc: "'ipng@sunroof.eng.sun.com'" , "'ipsec@tis.com'" , "'jis@MIT.EDU'" , "'Thomas Narten'" Subject: RE: [Karen Seo: Thomas Narten -- clarification, etc.] Date: Fri, 8 May 1998 08:27:01 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk Ran, sorry for being so naive but could you please point me to some reference material that articulates differences in security properties of the two so that I can use these two mechanisms appropriately. Thanks in advance -----Original Message----- From: owner-ipsec@ex.tis.com [mailto:owner-ipsec@ex.tis.com]On Behalf Of Ran Atkinson Sent: Wednesday, May 06, 1998 9:48 PM To: Patel, Baiju V Cc: 'ipng@sunroof.eng.sun.com'; 'ipsec@tis.com'; 'jis@MIT.EDU'; 'Thomas Narten' Subject: RE: [Karen Seo: Thomas Narten -- clarification, etc.] Baiju, Tunnel-mode ESP does NOT provide the same security properties as AH. Wishing that it did and marketing it as if it did, doesn't make it true. Folks need to understand what security properties they desire, then use the appropriate mechanism(s) to provide those properties. Ran From owner-ipsec Fri May 8 11:15:24 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA05100 for ipsec-outgoing; Fri, 8 May 1998 11:15:08 -0400 (EDT) Message-Id: <3.0.5.32.19980508112923.009feb50@homebase.htt-consult.com> X-Sender: rgm-sec@homebase.htt-consult.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Fri, 08 May 1998 11:29:23 -0400 To: karn@ka9q.ampr.org, dwetzel@iway.fr From: Robert Moskowitz Subject: Re: ipsec vs. firewalls Cc: ipsec@tis.com In-Reply-To: References: <3.0.1.32.19980507104731.00949e20@mail.iway.fr> <199805070458.AAA10739@smb.research.att.com> <3.0.1.32.19980507104731.00949e20@mail.iway.fr> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 06:33 PM 5/7/98 -0700, Phil Karn wrote: > >Steve and his co-author Bill Cheswick refer to this as the "hard >exterior with a chewy interior" property of many firewalled networks. Particularly now that FBI stats are showing that upwards of 70% of attacks are through back doors. It is like all of the Greek war stories of finding that shepard path around the enemy front line and getting his rear. Robert Moskowitz ICSA Security Interest EMail: rgm-sec@htt-consult.com From owner-ipsec Fri May 8 11:28:47 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA05122 for ipsec-outgoing; Fri, 8 May 1998 11:28:09 -0400 (EDT) Message-ID: <35532813.41C6@cs.umass.edu> Date: Fri, 08 May 1998 11:43:15 -0400 From: Lewis McCarthy Organization: UMass-Amherst Theoretical Computer Science Group, X-Mailer: Mozilla 3.01Gold (X11; U; OSF1 V4.0 alpha) MIME-Version: 1.0 To: Steve Bellovin CC: IP Security List Subject: Re: 3DES (was: ipsec vs. firewalls) References: <199805081502.LAA06659@postal.research.att.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Steve Bellovin writes: > A more interesting topic is whether or not 3DES should be mandatory- > to-implement. I suggest that it should be -- DES is obviously doomed > (pick your favorite time constant), and we should take that into account. I agree, but I thought this was one of the arguments that was lost a long time ago. Can we really revisit it now? -- Lewis http://www.cs.umass.edu/~lmccarth/ "This information is so readily available to anybody who wants to commit an act of terrorism that you have to assume the security community's real interest is to raise attentiveness to their role in preventing terrorism in the hope that they can increase their budget" --Bruce Bueno de Mesquita, Senior Fellow, Hoover Institution, (as quoted by CNN) on objections to the EPA listing chemical storage site locations on the Web From owner-ipsec Fri May 8 11:47:47 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA05156 for ipsec-outgoing; Fri, 8 May 1998 11:46:13 -0400 (EDT) Date: Fri, 8 May 1998 12:00:44 -0400 Message-Id: <199805081600.MAA23598@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: Christophe Gouault Cc: ipsec In-Reply-To: Christophe Gouault's message of Thu, 7 May 1998 15:15:31 +0200 (MET DST), Subject: Re: question about tunnel mode Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: owner-ipsec@ex.tis.com Precedence: bulk Date: Thu, 7 May 1998 15:15:31 +0200 (MET DST) From: Christophe Gouault Hi ipsec folks, just a little question : when a packet is tunneled into AH or ESP, what is the value of the field "next header" in the IPsec header ? e.g. : [IPv4 or v6][ESP][IPv4] is it IP(4) or IPIP(94) ? [IPv4 or v6][ESP][IPv6] is it IPv6(41) or IPIP(94) ? Sorry if somebody already asked the question... The next header field in ESP would be IPv4 or IPv6, as appropriate. - Ted From owner-ipsec Fri May 8 12:15:40 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA05312 for ipsec-outgoing; Fri, 8 May 1998 12:14:12 -0400 (EDT) Message-ID: <3552C740.1B68D6BF@nortel.ca> Date: Fri, 08 May 1998 10:50:08 +0200 From: "Marcus Leech" Organization: Security Development X-Mailer: Mozilla 2.02 (X11; I; Linux 1.2.13 i486) MIME-Version: 1.0 To: Steve Bellovin CC: ipsec@tis.com Subject: Re: 3DES (was: ipsec vs. firewalls) References: <199805081502.LAA06659@postal.research.att.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Steve Bellovin wrote: > > I'm not sure that a discussion on the merits of firewalls is very > profitable here. Regardless of whether or not we like them, I think > we can all agree that firewalls are real, and are likely to remain so, > and IPSEC (and everything else) should take notice of them. > > A more interesting topic is whether or not 3DES should be mandatory- > to-implement. I suggest that it should be -- DES is obviously doomed > (pick your favorite time constant), and we should take that into > account. We're better off if the IPSEC boxes being deployed now are > ready to switch. I'd certainly argue that 3DES should be mandatory, but I'm of the "encrypt 'til it hurts, then back off 3dB" school. There's certainly still a perception that breaking 56-bit DES is "hard". The mindset seems to be that "your average pimply teen hacker" isn't going to bother assembling a brute-forcing farm. It's not, of course, the "pimply teen hackers" than concern me--and neither should they represent the threat model we're (IETF/IPSEC WG) trying to guard against. I could, of course, argue that CAST-128 should me mandatory, but that would be letting my corporate loyalty show through :-) From owner-ipsec Fri May 8 12:30:38 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA05389 for ipsec-outgoing; Fri, 8 May 1998 12:29:12 -0400 (EDT) Message-Id: <2.2.32.19980508164344.00cfbe8c@mailhost.hq.freegate.com> X-Sender: jtardo@mailhost.hq.freegate.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 08 May 1998 09:43:44 -0700 To: ipsec@tis.com From: Joe Tardo Subject: Re: ipsec vs. firewalls Cc: Steve Bellovin Sender: owner-ipsec@ex.tis.com Precedence: bulk At 08:12 PM 5/6/98 -0700, Steve Bellovin wrote: >I came up with a disturbing conflict between ubiquitous IPSEC and >common firewall policies. I'm not certain how to resolve it, >either. > >A common firewall policy permits most outgoing calls. (The >requirement to authenticate such calls, say via AH from the inside >host to the firewall, wouldn't affect what comes next.) Suppose, >though, that the inside host wants to use ESP for end-to-end >encryption to the destination. How will the firewall inspect the >return packet? Why not just have included a 'return' SPI in the header? Also, firewalls aren't showing signs of going away anytime soon. Even if they were, 'feature creep' seems to be leading firewall and router vendors into passive 'QOS', which uses almost identical packet classification selector schemes as firewalls (and, I might add, IPsec). Your issue isn't just with firewalls, it's with this whole industry of 'packet snooping' boxes that seem to have been luking at every turn at Interop this week. -- Joe From owner-ipsec Fri May 8 12:48:17 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA05471 for ipsec-outgoing; Fri, 8 May 1998 12:47:16 -0400 (EDT) Message-ID: <35533A56.5D9C@hydra.acs.uci.edu> Date: Fri, 08 May 1998 10:01:10 -0700 From: Dan Stromberg X-Mailer: Mozilla 3.0 (X11; I; SunOS 5.7 sun4u) MIME-Version: 1.0 To: Marcus Leech CC: ipsec@tis.com Subject: Re: ipsec vs. firewalls References: <199805070458.AAA10739@smb.research.att.com> <3.0.1.32.19980507104731.00949e20@mail.iway.fr> <3552B292.6709DD87@nortel.ca> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Marcus Leech wrote: > > Phil Karn wrote: > > > > Damien, > > > > It's an old battle, and Steve and I are used to sparring over it in a > > friendly fashion. > > > > Firewalls are useful as temporary stopgaps when you're actually under > > attack, but they try to do what can only be done properly on an > > end-to-end basis. And to the extent that they give people a false sense > > of security, firewalls actually diminish security. > > > > Steve and his co-author Bill Cheswick refer to this as the "hard > > exterior with a chewy interior" property of many firewalled networks. > > > The problem is that for a corporate network of any substantial > size, there will *never* be a way to make the interior > crunchy. I have to disagree. Eventually, I believe it is reasonable to expect that vendors will automate patch application, and that patches will be obtained from the vendor over the network. In fact, I expect that part of configuring a machine will include an e-mail address of who to e-mail if a patch application fails, or requires operator intervention. In fact, in the future, I believe that bugs that are so deep rooted in a box's software that it cannot be automatically updated (and perhaps bugs that require a reboot to patch), will be the only security bugs many sites worry about. IPSEC makes this less scary, but it's quite possible without IPSEC. From owner-ipsec Fri May 8 13:27:07 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA05678 for ipsec-outgoing; Fri, 8 May 1998 13:26:19 -0400 (EDT) Date: Fri, 8 May 1998 13:40:37 -0400 Message-Id: <199805081740.NAA23629@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: Steve Bellovin Cc: ipsec@tis.com In-Reply-To: Steve Bellovin's message of Fri, 08 May 1998 11:02:21 -0400, <199805081502.LAA06659@postal.research.att.com> Subject: Re: 3DES (was: ipsec vs. firewalls) Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: owner-ipsec@ex.tis.com Precedence: bulk Date: Fri, 08 May 1998 11:02:21 -0400 From: Steve Bellovin A more interesting topic is whether or not 3DES should be mandatory- to-implement. I suggest that it should be -- DES is obviously doomed (pick your favorite time constant), and we should take that into account. We're better off if the IPSEC boxes being deployed now are ready to switch. While I agree with you, we might need to have another one of Jeff's famous straw polls in Chicago (the "Chicago doctrine", anyone?), given the U.S. Goverment's special hostility to triple-DES. Given that vendors living behind the cryptographic iron curtain weren't all that happy about making DES mandatory, I'd suspect that they would howl over making triple-DES mandatory. - Ted From owner-ipsec Fri May 8 13:27:11 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA05677 for ipsec-outgoing; Fri, 8 May 1998 13:26:19 -0400 (EDT) Message-Id: <3.0.5.32.19980508133943.00a02eb0@homebase.htt-consult.com> X-Sender: rgm-sec@homebase.htt-consult.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Fri, 08 May 1998 13:39:43 -0400 To: Steve Bellovin , ipsec@tis.com From: Robert Moskowitz Subject: Re: 3DES (was: ipsec vs. firewalls) In-Reply-To: <199805081502.LAA06659@postal.research.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 11:02 AM 5/8/98 -0400, Steve Bellovin wrote: > >A more interesting topic is whether or not 3DES should be mandatory- >to-implement. I suggest that it should be -- DES is obviously doomed >(pick your favorite time constant), and we should take that into >account. We're better off if the IPSEC boxes being deployed now are >ready to switch. > I am putting together the ICSA testing criteria for IPsec products for our aug/sep certification round (any vendor that will have PRODUCTION systems by July should subscribe to ipsec@icsa.net (majordomo list)). Right now I have 3DES grouped with IDEA and CAST as 'extra security'. If there is strong concensus among vendors and customers on 3DES, we could move 3DES to the baseline testing. Looking for input. Note our testing need not, and in fact when dealing with rekeying be locked down to the MUSTs. Robert Moskowitz ICSA Security Interest EMail: rgm-sec@htt-consult.com From owner-ipsec Fri May 8 13:36:38 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA05713 for ipsec-outgoing; Fri, 8 May 1998 13:35:21 -0400 (EDT) From: Dan McDonald Message-Id: <199805081748.KAA03051@kebe.eng.sun.com> Subject: Re: 3DES (was: ipsec vs. firewalls) To: smb@research.att.com (Steve Bellovin) Date: Fri, 8 May 1998 10:48:19 -0700 (PDT) Cc: ipsec@tis.com In-Reply-To: <199805081502.LAA06659@postal.research.att.com> from "Steve Bellovin" at May 8, 98 11:02:21 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 > A more interesting topic is whether or not 3DES should be mandatory- > to-implement. I suggest that it should be I agree with all of your reasoning that I just snipped. Lemme ease your fears with this open question to the list: Who all out there is implementing 3DES already?!? I suspect the people answering "yes" will be > 75% of the IPsec vendors, and if you look at it in terms of market share, I suspect the "yes" would cover > 90% of market share. Dan From owner-ipsec Fri May 8 13:37:40 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA05741 for ipsec-outgoing; Fri, 8 May 1998 13:37:20 -0400 (EDT) X-Authentication-Warning: keeks.ioc.ee: helger owned process doing -bs Date: Fri, 8 May 1998 20:49:49 +0300 (EET DST) From: Helger Lipmaa X-Sender: helger@keeks To: ipsec@tis.com Subject: Re: 3DES (was: ipsec vs. firewalls) In-Reply-To: <3552C740.1B68D6BF@nortel.ca> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk On Fri, 8 May 1998, Marcus Leech wrote: > I could, of course, argue that CAST-128 should me mandatory, but that > would be letting my corporate loyalty show through :-) I wonder what will happen with the advent of AES. Will it become mandatory, too? Helger Lipmaa http://home.cyber.ee/helger; Phone +372-6542422 From owner-ipsec Fri May 8 13:44:47 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA05761 for ipsec-outgoing; Fri, 8 May 1998 13:44:20 -0400 (EDT) Message-ID: <19980508135827.P15474@test.legislate.com> Date: Fri, 8 May 1998 13:58:27 -0400 From: Raul Miller To: "M.C.Nelson" , Damien Wetzel Cc: Phil Karn , ipsec@tis.com Subject: Re: ipsec vs. firewalls Mail-Followup-To: "M.C.Nelson" , Damien Wetzel , Phil Karn , ipsec@tis.com References: <3.0.1.32.19980507104731.00949e20@mail.iway.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.1 In-Reply-To: ; from M.C.Nelson on Fri, May 08, 1998 at 10:43:54AM -0400 Sender: owner-ipsec@ex.tis.com Precedence: bulk M.C.Nelson wrote: > Nonetheless, organization-level access control is probably an > important security service and something like a firewall is probably > the right way to do it. The trick is to be able to passively > authenticate datagrams. Not really. If you want a central administrative system the right way to do is is establish an administrative protocol to administer corporate entities, and establish an auditing system to detect entities so far gone that they are invisible to the administrative protocol. Also, you need to think quite a bit about what you're trying to achieve. All too often, people wind up implementing something that looks like a bank vault door mounted on a paper house with holes cut in the walls, when what they really wanted was a wooden house with glass windows and latches on the doors. -- Raul From owner-ipsec Fri May 8 16:47:25 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA06492 for ipsec-outgoing; Fri, 8 May 1998 16:45:19 -0400 (EDT) Message-Id: <199805082059.NAA17183@dharkins-ss20.cisco.com> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: ipsec@tis.com Subject: certificate key usage in IKE Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 08 May 1998 13:59:35 -0700 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk Another issue has come up with RSA encryption mode (both of them) and regrettably the IKE document does not address it. It's concerned with the key usage restrictions that can be added to a certificate. For split-key systems where there is a "signature" key and a "key encipherment" key can the signature key be used for the encrypted nonce-type authentication methods? On the one hand, the argument goes that since it is basically for authentication then it's OK to use a signature-only public key to encrypt a nonce and send to the peer. On the other hand, the argument goes that while the nonce is not used directly for a key (as in some email systems where the key encipherment usage is more straightforward) it is used to generate the key. In fact, the two decrypted nonces are used as the key to the prf that generates the shared secret data from which the encryption and authentication keys are generated. For the extended public key encryption method this might even be more strong since the decrypted nonce is used to generate not only the shared secret data but a symmetric key to decrypt the remaining payloads in the message. So I'm sitting here like Reptavia from Fiddler on the Roof: "but on the other hand...but on the other hand...but on the other hand...." This has to be addressed somewhere, most likely in the IKE document but it would be nice if this went into the certificate profile that Rodney Thayer is developing. (Hint, hint :-). What is the feeling of the WG? I have my own opinion but it is clouded by reluctance to rearchitect my code (as is that of the other vendor with whom interoperability testing today illustrated this issue) so I'd rather not state it here. Dan. From owner-ipsec Fri May 8 17:26:04 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA06648 for ipsec-outgoing; Fri, 8 May 1998 17:25:20 -0400 (EDT) Message-Id: <3.0.1.32.19980508100852.006d5fd8@192.9.200.10> X-Sender: srinu@192.9.200.10 X-Mailer: Windows Eudora Light Version 3.0.1 (32) Date: Fri, 08 May 1998 10:08:52 +0500 To: Christophe Gouault From: K SrinivasRao Subject: Re: question about tunnel mode Cc: ipsec@tis.com In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi Chris, This is not IP within IP. So "next header" will have value of IPv4(4) for the first e.g. and IPv6(41) for the second e.g. No IPIP(94) in any such case At 03:15 PM 5/7/98 +0200, you wrote: >Hi ipsec folks, > >just a little question : >when a packet is tunneled into AH or ESP, what is the value of the field >"next header" in the IPsec header ? > >e.g. : [IPv4 or v6][ESP][IPv4] is it IP(4) or IPIP(94) ? > [IPv4 or v6][ESP][IPv6] is it IPv6(41) or IPIP(94) ? > >Sorry if somebody already asked the question... > >Chris. > > Christophe GOUAULT - Network department > Dassault Electronique - 55, quai Marcel Dassault > 92215 SAINT-CLOUD cedex - FRANCE > tel: +33 1 34 81 68 56 > EMail: Christophe.Gouault@dassault-elec.fr > > > > ****************************************************************** * SrinivasRao. B. Kulkarni * * Rendezvous On Chip Pvt Ltd. * * First Floor, Plot No. 14, * * NewVasaviNagar, Kharkhana, * * SECUNDERABAD - 500019. * * INDIA * * Ph : (040)7742606 * * email address : srinu@trinc.com * ****************************************************************** From owner-ipsec Fri May 8 18:28:02 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA06850 for ipsec-outgoing; Fri, 8 May 1998 18:26:19 -0400 (EDT) Message-ID: <355387E8.28F1CAD3@ire-ma.com> Date: Fri, 08 May 1998 18:32:08 -0400 From: Bronislav Kavsan X-Mailer: Mozilla 4.03 [en] (WinNT; U) MIME-Version: 1.0 To: Daniel Harkins CC: ipsec@tis.com Subject: Re: certificate key usage in IKE References: <199805082059.NAA17183@dharkins-ss20.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-MDaemon-Deliver-To: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Dan, Point of reference. One large company (Microsoft) in its CryptoAPI distinguishes the SignatureKey from the KeyExchangeKey. The SignatureKey can be used for signatures only, but the KeyExchangeKey can be used for both - signatures and key exchanges (encryption). This makes KeyExchangeKey less restrictive and therefore very popular in the Microsoft's certificate model. Daniel Harkins wrote: > Another issue has come up with RSA encryption mode (both of them) and > regrettably the IKE document does not address it. > > It's concerned with the key usage restrictions that can be added to > a certificate. For split-key systems where there is a "signature" key and > a "key encipherment" key can the signature key be used for the encrypted > nonce-type authentication methods? > > On the one hand, the argument goes that since it is basically for > authentication then it's OK to use a signature-only public key to encrypt > a nonce and send to the peer. On the other hand, the argument goes that while > the nonce is not used directly for a key (as in some email systems where the > key encipherment usage is more straightforward) it is used to generate the > key. In fact, the two decrypted nonces are used as the key to the prf that > generates the shared secret data from which the encryption and authentication > keys are generated. For the extended public key encryption method this might > even be more strong since the decrypted nonce is used to generate not only > the shared secret data but a symmetric key to decrypt the remaining payloads > in the message. So I'm sitting here like Reptavia from Fiddler on the Roof: > "but on the other hand...but on the other hand...but on the other hand...." > > This has to be addressed somewhere, most likely in the IKE document but it > would be nice if this went into the certificate profile that Rodney Thayer is > developing. (Hint, hint :-). > > What is the feeling of the WG? I have my own opinion but it is clouded by > reluctance to rearchitect my code (as is that of the other vendor with whom > interoperability testing today illustrated this issue) so I'd rather not > state it here. > > Dan. -- Bronislav Kavsan IRE Secure Solutions, Inc. 100 Conifer Hill Drive Suite 513 Danvers, MA 01923 voice: 978-739-2384 http://www.ire.com From owner-ipsec Sat May 9 03:58:41 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id DAA07604 for ipsec-outgoing; Sat, 9 May 1998 03:53:20 -0400 (EDT) Date: Sat, 9 May 1998 00:58:54 -0700 (PDT) From: Gabriel Montenegro Reply-To: Gabriel Montenegro Subject: Re: ipsec vs. firewalls To: Joe Tardo Cc: ipsec@tis.com, Steve Bellovin In-Reply-To: "Your message with ID" <2.2.32.19980508164344.00cfbe8c@mailhost.hq.freegate.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk > At 08:12 PM 5/6/98 -0700, Steve Bellovin wrote: > > >I came up with a disturbing conflict between ubiquitous IPSEC and > >common firewall policies. I'm not certain how to resolve it, > >either. > > > >A common firewall policy permits most outgoing calls. (The > >requirement to authenticate such calls, say via AH from the inside > >host to the firewall, wouldn't affect what comes next.) Suppose, > >though, that the inside host wants to use ESP for end-to-end > >encryption to the destination. How will the firewall inspect the > >return packet? > > Why not just have included a 'return' SPI in the header? That's essentially what I propose in: ftp://ftp.ietf.org/internet-drafts/draft-montenegro-aatn-nar-00.txt The idea is that your inside host engages in an authentication and negotiation phase with the gateway/firewall/nat (whatever you want to call it), after which the latter will know that a given SPI on inbound packets is bound to the inside host. This allows it to (a) accept the packet, and (b) deliver it to the appropriate inside host. The authentication and negotiation phase between the inside host and the firewall is socks-based, so traditional socks-based authentication mechanisms can be reused. The firewall can impose its policy at the negotiation phase, or alternatively before (a), above. -gabriel From owner-ipsec Sat May 9 19:51:00 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA08902 for ipsec-outgoing; Sat, 9 May 1998 19:46:20 -0400 (EDT) Message-ID: <3554EEB9.FE66E448@cosinecom.com> Date: Sat, 09 May 1998 17:03:05 -0700 From: Abraham R Matthews Organization: Cosine Communications X-Mailer: Mozilla 4.05 [en] (WinNT; I) MIME-Version: 1.0 To: ipsec@tis.com CC: Abraham Matthews Subject: [Q] Inbound processing in SG for end-to-end IPSec Content-Type: multipart/mixed; boundary="------------6CFD763C0D27E15CD209564D" Sender: owner-ipsec@ex.tis.com Precedence: bulk This is a multi-part message in MIME format. --------------6CFD763C0D27E15CD209564D Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi all, The Security Architecture document on page 24, section 4.5, Case 1 discusses end-to-end processing at the two end hosts. Just to clarify I reproduce the diagram ==================================== | | H1* ------ (Inter/Intranet) ------ H2* My question is related to the diagram modified as follows with a security gateway (SG1) in the path between H1 and H2 ... IP3 IP4 |...............SG1................| ==================================== | | H1* ------ (Inter/Intranet) ------ H2* IP1 IP2 The actual route of the packet is H2->SG1->H1 (and also H1->SG1->H2). The IPSec SA is between H1 and H2. The SG1 is not providing any IPSec services for these pair of hosts. My questions are: 1) Is this scenario legal? 2) What should the SPD in SG1 be? 3) What is the processing that takes place at SG1? These are the answers that I have. I am new to IPSec and I am most likely wrong. So please bear with me. (For simplicity,I am assuming ESP in tunnel mode). Q1) Yes this is legal Q2) The SPD is SPD rule: S=IP1,D=IP2,P=ESP/AH ==> Bypass SPD rule: S=IP2,D=IP1,P=ESP/AH ==> Bypass Q3) SG1 does the following (?) H1 sends on interface with address IP1: [D=IP2,S=IP1,P=ESP][D=IP2,S=IP1,P=UDP,] SG1 receives this on interface with address IP3: SPD rule: S=IP1,D=IP2,P=ESP/AH ==> Bypass SPD rule: S=IP2,D=IP1,P=ESP/AH ==> Bypass The document in section 5.2.1, requires a lookup in the SAD using the Dest,SPI and Protocol for any packet having security headers. The Dest (IP2) is not a local address of the router. What does it do? It looks it up in the SPD (as there was no entry in the SAD)? It should discard it as stated in rule 1 of section 5.2.1? This confusion leads me to beleive that this is an invalid configuration! But does this mean that H2 must establish a tunnel with every security gateway in the path? what happens if the route changes? ... An absolutely confused newbie requesting assistance, Abbie. --------------6CFD763C0D27E15CD209564D Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Abraham Matthews Content-Disposition: attachment; filename="vcard.vcf" begin: vcard fn: Abraham Matthews n: Matthews;Abraham org: CoSine Communications adr: Suite 200;;1070 Sixth Avenue;Belmont;CA;94002;USA email;internet: amatthews@cosinecom.com title: Software Architect tel;work: 650-637-4725 tel;fax: 650-637-4778 x-mozilla-cpt: ;0 x-mozilla-html: TRUE version: 2.1 end: vcard --------------6CFD763C0D27E15CD209564D-- From owner-ipsec Sat May 9 23:29:09 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id XAA09235 for ipsec-outgoing; Sat, 9 May 1998 23:26:21 -0400 (EDT) X-Sender: chouanar@fargo.parc.xerox.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1.334 (Beta) Date: Sat, 9 May 1998 20:40:10 PDT To: Steve Bellovin From: Jean Chouanard Subject: Re: ipsec vs. firewalls Cc: ipsec@tis.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-Id: <98May9.204046pdt."32634"@alpha.xerox.com> Sender: owner-ipsec@ex.tis.com Precedence: bulk (Sorry for the repost if any, my first try was not relay to the list) I'm not an IPSEC expert, having no experience with it, but it seems to me that even in tunnel mode, a clear text IP header is available to route the secure datagram from the origin to the destination? Couldn't we use a statefull-like packet filtering on the firewall? It will, for each outgoing IPSEC connection, update/create an entry in a dynamic table, recording the source and dest IP addresses (no port) and create a dynamic ACL to allow *all* packets back from this dest IP addresses to the source address, this for a certain TTL (TTL reset on each outgoing packets)? => just like the firewall-1 packet filtering engine does for udp, except that the port is not even in the table. It won't provide the same level of security than the established scheme, but at least a scan/attack could come *only* from a host your are already talking with. Also, you already are in trouble if your security policy allows outgoing connection for protocols which can be used to tunnel others protocols/application inside (And there is a *lot* of them). Using such encapsulation, your internal user can easily overwrite your firewall policy and establish full IP connectivity between internal and external host. The only way to prevent such tunneling is to look at the application protocol and verify that what's going on the wire is really what you expect, but it becomes really hard to detect when encryption is use. The simple example of establishing a ppp connection over an 'outgoing' ssh link illustrate quite well this problem: the tunnel was establish from an internal host but the result is that your security policy dealing with incoming packet is overwritten: no control any more. One guy inside could fully open your network. \jean At 08:12 PM 5/6/98 -0700, someone using Steve Bellovin's login wrote: >I came up with a disturbing conflict between ubiquitous IPSEC and >common firewall policies. I'm not certain how to resolve it, >either. > >A common firewall policy permits most outgoing calls. (The >requirement to authenticate such calls, say via AH from the inside >host to the firewall, wouldn't affect what comes next.) Suppose, >though, that the inside host wants to use ESP for end-to-end >encryption to the destination. How will the firewall inspect the >return packet? > >To implement that firewall policy, the return packet *must* be a >reply to the outbound packet -- say, the SYN+ACK in response to >the SYN. But if it's encrypted, there's no way to tell; it could >be a probe from the outside host to some vulnerable ports on the >inside client machine. > >There are a number of possible solutions; each has its limitations. > >The most obvious, of course, is to prohibit end-to-end encryption, >and require that all packets be decrypted at the firewall. Apart >from the obvious security risks, this complicates the topology >discovery process. > >Another pretty good solution is per-connection keying. But that >only works if the firewall *knows* that the inside machines will >indeed enforce that, and drop packets to different ports than are >bound to the SPI. > >A third solution is to use some sort of auxiliary header with >cleartext port numbers, similar to that suggested by Greg Minshall. >Again, the firewall would have to *know* that hosts would drop >packets where the outer and inner port numbers didn't match. >Furthermore, in both this case and the previous one, all the firewall >knows is the packet direction; SYN, ACK, and FIN bits are still >invisible. (Well, we could expose more of the TCP header.) This >reduces the ability of a dynamic firewall to handle TCP to its >ability to handle UDP. > >Fourth, we could restrict end-to-end encryption to trusted outside >hosts, and in particular to machines that comprise the VPN. >Obviously, this works against general use of encryption. > >Finally, I suspect that some people will regard anything that >cripples firewalls as a feature. With all due respect, I tend >to differ... > >I'm not suggesting any changes to anything at this point. I do >suggest that IPSEC vendors -- including IPSEC implementations that >will live on firewalls -- work towards per-connection keying. > - jean - From owner-ipsec Sun May 10 07:05:18 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA09786 for ipsec-outgoing; Sun, 10 May 1998 07:02:21 -0400 (EDT) Date: Sun, 10 May 1998 14:16:45 +0300 (IDT) From: Hugo Krawczyk Message-Id: <199805101116.OAA06858@ee.technion.ac.il> To: dharkins@cisco.com, ipsec@tis.com Subject: Re: certificate key usage in IKE Sender: owner-ipsec@ex.tis.com Precedence: bulk >From a cryptographic point of view one of the main reasons to separate signature keys from encryption keys is the principle that you should use different keys with different algorithms. In this sense, I am in favor of using "encryption keys" and not "signature keys" in the encryption mode of IKE. I would like to note that such a "key separation" principle has guided many of the design issues in IKE. Also, notice that "RSA encryption" and "RSA signatures" ARE different algorithms. Hugo >From: Daniel Harkins > > Another issue has come up with RSA encryption mode (both of them) and >regrettably the IKE document does not address it. > > It's concerned with the key usage restrictions that can be added to >a certificate. For split-key systems where there is a "signature" key and >a "key encipherment" key can the signature key be used for the encrypted >nonce-type authentication methods? > From owner-ipsec Sun May 10 09:58:05 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA09909 for ipsec-outgoing; Sun, 10 May 1998 09:55:21 -0400 (EDT) Message-Id: <199805101409.OAA09894@orchard.arlington.ma.us> To: Jean Chouanard cc: Steve Bellovin , ipsec@tis.com Subject: Re: ipsec vs. firewalls In-reply-to: Your message of "Sat, 9 May 1998 20:40:10 PDT ." <98May9.204046pdt."32634"@alpha.xerox.com> Date: Sun, 10 May 1998 10:08:55 -0400 From: Bill Sommerfeld Sender: owner-ipsec@ex.tis.com Precedence: bulk > Also, you already are in trouble if your security policy allows outgoing > connection for protocols which can be used to tunnel others > protocols/application inside (And there is a *lot* of them). I think this is an unwinnable war. I've heard of examples of tunnels running over WWW, DNS, ICMP, etc., etc., etc. If you let *any* non-trivial protocol through your firewall, it will be possible for someone with sufficient cleverness to tunnel any other protocol through it. - Bill From owner-ipsec Sun May 10 12:24:01 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA10139 for ipsec-outgoing; Sun, 10 May 1998 12:20:23 -0400 (EDT) Message-ID: <3555D742.22A88219@mit.edu> Date: Sun, 10 May 1998 12:35:14 -0400 From: "Jeffrey I. Schiller" Organization: Massachusetts Institute of Technology X-Mailer: Mozilla 4.04 [en] (X11; U; Linux 2.0.30 i586) MIME-Version: 1.0 To: "Theodore Y. Ts'o" CC: Bill Sommerfeld , Stephen Kent , Steve Deering , Robert Elz , Thomas Narten , ipsec@tis.com, ipng@sunroof.eng.sun.com Subject: Re: (IPng 5759) Re: [Karen Seo: Thomas Narten -- clarification, etc.] References: <199805050450.AAA21748@dcl.MIT.EDU> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Of course one clever way of doing BITW is to have some cooperation from the host. Specifically the host puts in a skeletal AH header where it wants the real AH header to go and the bump finished the job. Presumably the reason you are using a BITW is because it has hardware encryption support and can do the processing more efficiently. -Jeff From owner-ipsec Sun May 10 16:32:13 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA10434 for ipsec-outgoing; Sun, 10 May 1998 16:29:22 -0400 (EDT) Message-Id: <199805102044.QAA11077@jekyll.piermont.com> To: Steve Bellovin cc: ipsec@tis.com Subject: Re: 3DES In-reply-to: Your message of "Fri, 08 May 1998 11:02:21 EDT." <199805081502.LAA06659@postal.research.att.com> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Sun, 10 May 1998 16:44:06 -0400 From: "Perry E. Metzger" Sender: owner-ipsec@ex.tis.com Precedence: bulk Steve Bellovin writes: > A more interesting topic is whether or not 3DES should be mandatory- > to-implement. I suggest that it should be -- DES is obviously doomed > (pick your favorite time constant), and we should take that into > account. We're better off if the IPSEC boxes being deployed now are > ready to switch. If the political gurus feel we could do so, I would happily agree with the suggestion. As I've said in the past, modulo political problems we all probably wanted 3DES several years ago -- at this point, its moved from important to necessary. Perry From owner-ipsec Sun May 10 17:57:17 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA10564 for ipsec-outgoing; Sun, 10 May 1998 17:56:20 -0400 (EDT) Message-Id: <199805102210.PAA19552@gallium.network-alchemy.com> To: perry@piermont.com cc: Steve Bellovin , ipsec@tis.com Subject: Re: 3DES In-reply-to: Your message of "Sun, 10 May 1998 16:44:06 EDT." <199805102044.QAA11077@jekyll.piermont.com> Date: Sun, 10 May 1998 15:10:36 -0700 From: "Derrell D. Piper" Sender: owner-ipsec@ex.tis.com Precedence: bulk I can't imagine anyone who's bothering to produce an IPSEC product _not_ taking the time to do 3DES. And for those who don't, the market will decide... Derrell From owner-ipsec Sun May 10 18:29:12 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA10609 for ipsec-outgoing; Sun, 10 May 1998 18:28:22 -0400 (EDT) Message-Id: <199805102242.SAA11188@jekyll.piermont.com> To: Dan Stromberg cc: Marcus Leech , ipsec@tis.com Subject: Re: ipsec vs. firewalls In-reply-to: Your message of "Fri, 08 May 1998 10:01:10 PDT." <35533A56.5D9C@hydra.acs.uci.edu> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Sun, 10 May 1998 18:42:37 -0400 From: "Perry E. Metzger" Sender: owner-ipsec@ex.tis.com Precedence: bulk Dan Stromberg writes: > > The problem is that for a corporate network of any substantial > > size, there will *never* be a way to make the interior > > crunchy. > > I have to disagree. > > Eventually, I believe it is reasonable to expect that vendors will > automate patch application, and that patches will be obtained from the > vendor over the network. I don't mean to sound nasty here, but in some of the financial environments I work in integration labs work year round carefully vetting applications before rollout, and nothing hits the production equipment without extensive testing. Are you going to tell me that people who have to be that paranoid lest you call up bitching about your broker not being able to get a trade done for you are going to let random vendors automatically change software on their networks? No way in hell. Perry From owner-ipsec Mon May 11 09:03:43 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA12692 for ipsec-outgoing; Mon, 11 May 1998 08:56:21 -0400 (EDT) Message-Id: <4.0.1.334.19980508155203.03d3ba30@fargo.parc.xerox.com> X-Sender: chouanar@fargo.parc.xerox.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1.334 (Beta) Date: Fri, 8 May 1998 21:35:49 PDT To: Steve Bellovin From: Jean Chouanard Subject: Re: ipsec vs. firewalls Cc: ipsec@tis.com In-Reply-To: <199805070458.AAA10739@smb.research.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk My 2 cents... I'm not an IPSEC expert, having no experience with it, but it seems to me that even in tunnel mode, a clear text IP header is available to route the secure datagram from the origin to the destination? Couldn't we use a statefull-like packet filtering on the firewall? It will, for each outgoing IPSEC connection, update/create an entry in a dynamic table, recording the source and dest IP addresses (no port) and create a dynamic ACL to allow *all* packets back from this dest IP addresses to the source address, this for a certain TTL (TTL reset on each outgoing packets)? => just like the firewall-1 packet filtering engine does for udp, except that the port is not even in the table. It won't provide the same level of security than the established scheme, but at least a scan/attack could come *only* from a host your are already talking with. Also, you already are in trouble if your security policy allows outgoing connection for protocols which can be used to tunnel others protocols/application inside (And there is a *lot* of them). Using such encapsulation, your internal user can easily overwrite your firewall policy and establish full IP connectivity between internal and external host. The only way to prevent such tunneling is to look at the application protocol and verify that what's going on the wire is really what you expect, but it becomes really hard to detect when encryption is use. The simple example of establishing a ppp connection over an 'outgoing' ssh link illustrate quite well this problem: the tunnel was establish from an internal host but the result is that your security policy dealing with incoming packet is overwritten: no control any more. One guy inside could fully open your network. \jean At 08:12 PM 5/6/98 -0700, someone using Steve Bellovin's login wrote: >I came up with a disturbing conflict between ubiquitous IPSEC and >common firewall policies. I'm not certain how to resolve it, >either. > >A common firewall policy permits most outgoing calls. (The >requirement to authenticate such calls, say via AH from the inside >host to the firewall, wouldn't affect what comes next.) Suppose, >though, that the inside host wants to use ESP for end-to-end >encryption to the destination. How will the firewall inspect the >return packet? > >To implement that firewall policy, the return packet *must* be a >reply to the outbound packet -- say, the SYN+ACK in response to >the SYN. But if it's encrypted, there's no way to tell; it could >be a probe from the outside host to some vulnerable ports on the >inside client machine. > >There are a number of possible solutions; each has its limitations. > >The most obvious, of course, is to prohibit end-to-end encryption, >and require that all packets be decrypted at the firewall. Apart >from the obvious security risks, this complicates the topology >discovery process. > >Another pretty good solution is per-connection keying. But that >only works if the firewall *knows* that the inside machines will >indeed enforce that, and drop packets to different ports than are >bound to the SPI. > >A third solution is to use some sort of auxiliary header with >cleartext port numbers, similar to that suggested by Greg Minshall. >Again, the firewall would have to *know* that hosts would drop >packets where the outer and inner port numbers didn't match. >Furthermore, in both this case and the previous one, all the firewall >knows is the packet direction; SYN, ACK, and FIN bits are still >invisible. (Well, we could expose more of the TCP header.) This >reduces the ability of a dynamic firewall to handle TCP to its >ability to handle UDP. > >Fourth, we could restrict end-to-end encryption to trusted outside >hosts, and in particular to machines that comprise the VPN. >Obviously, this works against general use of encryption. > >Finally, I suspect that some people will regard anything that >cripples firewalls as a feature. With all due respect, I tend >to differ... > >I'm not suggesting any changes to anything at this point. I do >suggest that IPSEC vendors -- including IPSEC implementations that >will live on firewalls -- work towards per-connection keying. > - jean - From owner-ipsec Mon May 11 10:11:59 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA13040 for ipsec-outgoing; Mon, 11 May 1998 10:10:20 -0400 (EDT) Message-Id: <199805110517.BAA05493@relay.hq.tis.com> Date: Mon, 11 May 98 1:16:17 EDT From: Karen Seo To: ipsec@tis.com cc: kseo@bbn.com Subject: Latest AH/ESP/Arch drafts and changes Sender: owner-ipsec@ex.tis.com Precedence: bulk Folks, In follow-up to the IESG vote/feedback and recent email... 1. Per direction from Ted Ts'o, we are sending to the IETF secretariat and the mailing list, revised versions of the following drafts: o AH -- draft-ietf-ipsec-auth-header-06.txt o ESP -- draft-ietf-ipsec-esp-v2-05.txt o Architecture -- draft-ietf-ipsec-arch-sec-05.txt These drafts contain the changes listed below in part 1 and part 2. 2. Part 1 below contains edits that have been made since Ted's 4/28 email "IPSEC standardization status". If you've already read the changes that Ted posted to the Web on 4/28, then you only need to look at these new changes. 3. Part 2 below contains the changes made to the 3/13 Internet Drafts up until Ted's 4/28 email on "IPSEC standardization status". He posted these changes (and corresponding drafts, which were not sent to the IETF secretariat) to the Web. They are included here for those who haven't yet had a chance to pull them over from the Web site. Please let us know if you have any questions, etc. Thank you, Karen ******************************************************************************* Part 1 -- Changes made to the drafts since Ted's 4/28 email "IPSEC standardization status" ******************************************************************************* AH 1. Section 3.3.3.1 "Handling Mutable Fields" -- Amended to match IP (v4 and v6) handling of unrecognized extension headers and to clarify the distinction between IPv6 options and extension headers -- per (IPng and IPsec) mailing list discussion. Changed 3.3.3.1, second paragraph, from: ... If the IPsec implementation encounters an extension header that it does not recognize, it MUST zero the whole header except for the Next Header and Hdr Ext Len fields. The length of the extension header MUST be computed by 8 * Hdr Ext Len value + 8. If the IPsec implementation encounters an IPv4 option that it does not recognize, it should zero the whole option, using the second byte of the option as the length. (IPv6 options contain a flag indicating mutability, which determines appropriate processing for such options.) to: ... If the IP (v4 or v6) implementation encounters an extension header that it does not recognize, it will discard the packet and send an ICMP message. IPsec will never see the packet. If the IPsec implementation encounters an IPv4 option that it does not recognize, it should zero the whole option, using the second byte of the option as the length. IPv6 options (in Destination extension headers or Hop by Hop extension header) contain a flag indicating mutability, which determines appropriate processing for such options. 2. Section 3.3.3.1.2.2 "Extension Headers -- Options" -- changed wording to clarify the distinction between IPv6 options and extension headers -- per email from Ted Ts'o on 5/5/98 Changed title from: 3.3.3.1.2.2 Extension Headers -- Options to: 3.3.3.1.2.2 Extension Headers Containing Options Deleted the first sentence of section: The IPv6 extension headers (that are options) are explicitly listed in Appendix A and classified as immutable, mutable but predictable, or mutable. 3. Section 3.3.3.1.2.3 "Extension Headers -- non-Options" -- changed wording to clarify that IPv6 options are contained in extension headers (Hop by Hop and Destination) -- per email from Ted Ts'o on 5/5/98 Changed title from: 3.3.3.1.2.3 Extension Headers -- non-Options to: 3.3.3.1.2.3 Extension Headers Not Containing Options =========================================================================== ESP 1. Section 3.4.3 "Sequence Number Verification" -- fixed incorrect reference -- per email from Marc Hasson on 4/30/98. Changed 3.4.3, second paragraph from: If the receiver does not enable anti-replay for an SA....To avoid having the sender do unnecessary sequence number monitoring and SA setup (see section 3.3.2)..... to: If the receiver does not enable anti-replay for an SA....To avoid having the sender do unnecessary sequence number monitoring and SA setup (see section 3.3.3)..... 2. Section 3.4.5 "Packet Decryption" -- changed this section to be consistent with Section 2.4 "Padding (for Encryption)" paragraph on default padding scheme which says, "When this [the default] padding scheme is employed, the receiver SHOULD inspect the Padding field." -- per email from Marc Hasson on 4/30/98. Changed 3.4.5, step 2 from: 2. processes any padding as specified in the encryption algorithm specification. The default action is to remove/ignore any padding. to: 2. processes any padding as specified in the encryption algorithm specification. If the default padding scheme (see Section 2.4) has been employed, the receiver SHOULD inspect the Padding field before removing the padding prior to passing the decrypted data to the next layer. =========================================================================== Architecture: 1. Section 4.1 "Definition and Scope" -- changed to clarify the distinction between IPv6 options and extension headers -- per email from Ted Ts'o on 5/5/98 NOTE: Because an extension header can be used with IPv4 as well as with IPv6, we did not say that extension headers are IPv6. Changed third paragraph from: ... In the case of AH, the protection is also extended to selected portions of the IP header (and options). For more details on the coverage afforded by AH, see the AH specification [KA98a]... to: ... In the case of AH, the protection is also extended to selected portions of the IP header, selected portions of extension headers, and selected options (contained in the IPv4 header, IPv6 Hop-by-Hop extension header, or IPv6 Destination extension headers). For more details on the coverage afforded by AH, see the AH specification [KA98a] 2. Section 4.4.2 "Selectors" paragraphs on Destination IP Address and Source IP Address -- corrected to reflect the fact that IPv6 does not have broadcast addresses -- per email from Marc Hasson on 4/30/98. RFC 1884 says "IPv6 addresses are 128-bit identifiers for interfaces and sets of interfaces. There are three types of addresses: Unicast: .... Anycast: .... Multicast: .... So we also changed these paragraphs to include "anycast", even though anycast addresses are not syntactically distinguishable from unicast addresses. Changed paragraph on Destination Addresses from: - Destination IP Address (IPv4 or IPv6): this may be a single IP address (unicast, broadcast, or multicast group), a range of addresses (high and low values (inclusive), address + mask, or a wildcard address.... - Source IP Address(es) (IPv4 or IPv6): this may be a single IP address (unicast, broadcast, or multicast group), range of addresses (high and low values inclusive), address + mask, or a wildcard address.... to: - Destination IP Address (IPv4 or IPv6): this may be a single IP address (unicast, anycast, broadcast (IPv4 only), or multicast group), a range of addresses (high and low values (inclusive), address + mask, or a wildcard address.... - Source IP Address(es) (IPv4 or IPv6): this may be a single IP address (unicast, anycast,, broadcast (IPv4 only), or multicast group), range of addresses (high and low values inclusive), address + mask, or a wildcard address.... 3. Section 4.4.2 "Selectors" paragraph on Source IP Address -- The current text says: - Source IP Address(es) (IPv4 or IPv6): this may be a single IP address (unicast, broadcast, or multicast group), range of addresses (high and low values inclusive), address + mask, or a wildcard address. In his 4/30 email, Marc Hasson asked, "Can a source address really be a broadcast or multicast? This seems like we're having IPSEC condone illegal IP[v6] packet behavior...." Since a packet's source address FIELD may not contain a broadcast or multicast address, at first glance, it doesn't make sense for a source address SELECTOR to be a broadcast or multicast address. But this raises the question of what happens during IKE's SA negotiation -- what does the receiving end of an SA setup request do when the destination address is broadcast or multicast and it tries to set up the return half of the SA pair? In particular, what does the (outbound) SPD use for the Source IP Address selector value (as opposed to what would be in a packet)? This seems like a case where the selector values would need to be different from the packet values and hence the current text is correct, provided we change "broadcast" to "broadcast (IPv4 only). Note also that if a multicast receiver initiates an ISAKMP exchange, e.g., to obtain a key from (each) sender to the group, the "destination address selector" would be the multicast sender's address (a unicast address) while the "source address selector" would contain the multicast group address. For now, we are leaving the text as is to cover the possibility that broadcast/multicast might be useful in the future, e.g., to enable one to use a multicast address when doing secure multicasting operations. Since the multicast problem has been deferred to IPsecond (or later?), this issue is similarly deferred.. 4. Appendix B.2 "Fragmentation" -- very last paragraph The last paragraph currently says: c. Security gateways -- integrate IPsec into the IP stack NOTE: The IPsec module will have access to the following selectors .... Unlike Bump-in-the-stack implementations, security gateways may be able to look up the Source Address in the DNS to provide a System Name, e.g., in situations involving use of dynamically assigned IP addresses in conjunction with dynamically updated DNS entries.... From email from Marc Hasson on 4/30/98...[referring to the sentence above, "Unlike Bump-in-the-stack...."] "I'm not sure why this statement is here. Having done both an IPSEC stack for Mentat as well as having worked on a BITS implementation (involving both user and kernel pieces) I don't see any reason why a BITS implementation can't do a DNS lookup for its System name just as well as a "pure" IPSEC host or SG. In fact, part of the dynamic IP assignment (via DHCP perhaps) and DNS update may already have provided a BITS host with what it needs to do a DNS lookup. Our impression was that the community viewed the phrase "bump-in-the-stack" (BITS) as describing an implementation that typically would not have access to various system calls to higher portions of the protocol stack, e.g., DNS lookup. Nonetheless, Marc's comment is still reasonable, and whether or not to remove the sentence seems to depend on the connotations of the phrase "bump-in-the-stack". For now, we've added the word "some" in front of the phrase "Bump-in-the-stack implementations" so that the text now reads: "c. Security gateways -- integrate IPsec into the IP stack NOTE: The IPsec module will have access to the following selectors .... Unlike some Bump-in-the-stack implementations, security gateways may be able to look up the Source Address in the DNS to provide a System Name, e.g., in situations involving use of dynamically assigned IP addresses in conjunction with dynamically updated DNS entries.... ******************************************************************************* Part 2 -- Changes made to 3/13 drafts (as of 4/23). These are the changes Ted announced in his email of 4/28 "IPSEC standardization status" and posted to the Web. ******************************************************************************* ESP ONLY 1. Clarified when the padding computation takes into account the IV -- per private email of 3/24. Changed the text in 2.4 "Padding (for Encryption)", first paragraph after the 3 bullets (which explain the motivation for padding) from: The sender MAY add 0-255 bytes of padding. Inclusion of the Padding field in an ESP packet is optional, but all implementations MUST support generation and consumption of padding. The padding computation applies to the plaintext portion of the Payload Data, exclusive of the IV (if present). to: The sender MAY add 0-255 bytes of padding. Inclusion of the Padding field in an ESP packet is optional, but all implementations MUST support generation and consumption of padding. a. For the purpose of ensuring that the bits to be encrypted are a multiple of the algorithm's blocksize (first bullet above), the padding computation applies to the Payload Data exclusive of the IV, the Pad Length, and Next Header fields. b. For the purposes of ensuring that the Authentication Data is aligned on a 4-byte boundary (second bullet above), the padding computation applies to the Payload Data inclusive of the IV, the Pad Length, and Next Header fields. 2. Corrected and clarified the Outbound and Inbound processing sections -- per private email on 3/20. We now speak in terms of encryption always being applied (where no confidentiality is offered by using the NULL encryption algorithm) so as to avoid confusion about the following issues: o encapsulation and padding are always performed whether or not confidentiality is selected in order to preserve alignment and put the next protocol field in the right place. o encryption is always done before authentication Also corrected decryption to encryption in the Outbound section. Changed the beginning of (Outbound Processing) Section 3.3.2 "Packet Encryption" from: If confidentiality is selected, then the sender: 1. encapsulates.... 2. adds any necessary padding. 3. encrypts the result .... - If explicit cryptographic synchronization data, e.g., an IV, is indicated, it is input to the decryption algorithm per the algorithm specification and placed in the Payload field. - If implicit cryptographic synchronication data, e.g., an IV, is indicated, it is constructed and input to the decryption algorithm as per the algorithm specification. to: In this section, we speak in terms of encryption always being applied because of the formatting implications. This is done with the understanding that "no confidentiality" is offered by using the NULL encryption algorithm. Accordingly, the sender: 1. encapsulates... 2. adds any necessary padding. 3. encrypts the result.... - If explicit cryptographic synchronization data, e.g., an IV, is indicated, it is input to the encryption algorithm per the algorithm specification and placed in the Payload field. - If implicit cryptographic synchronication data, e.g., an IV, is indicated, it is constructed and input to the encryption algorithm as per the algorithm specification. Changed the beginning of (Inbound Processing) Section 3.4.5 "Packet Decryption" from: If confidentiality has been selected, then the receiver: to: As in section 3.3.2, "Packet Encryption", we speak here in terms of encryption always being applied because of the formatting implications. This is done with the understanding that "no confidentiality" is offered by using the NULL encryption algorithm. Accordingly, the receiver: =============================================================================== AH and ESP 1. Updated to use IKE instead of ISAKMP/Oakley. Added IKE to Reference section. 2. Clarified the text explaining the reason for having the receiver notify the sender if anti-replay is disabled -- per private email In both AH and ESP, changed Section 3.4.3 "Sequence Number Verification", paragraph 2 If the receiver does not enable anti-replay for an SA, no inbound checks are performed on the Sequence Number. The default for the sender is that the Sequence Number will be checked at the sender. Hence, if an SA establishment protocol such as ISAKMP/Oakley is employed, the receiver SHOULD notify the sender, during SA establishment, if the receiver will not provide anti-replay protection. to: If the receiver does not enable anti-replay for an SA, no inbound checks are performed on the Sequence Number. However, from the perspective of the sender, the default is to assume that anti-replay is enabled at the receiver. To avoid having the sender do unnecessary sequence number monitoring and SA setup (see section 3.3.2), if an SA establishment protocol such as IKE is employed, the receiver SHOULD notify the sender, during SA establishment, if the receiver will not provide anti-replay protection. Also, changed section 3.3.3 "Sequence Number Generation" to coordinate with the above change. Inserted the following text between paragraph 2 and paragraph 3. The sender assumes anti-replay is enabled as a default, unless otherwise notified by the receiver (see 3.4.3). Thus, if the counter has cycled, the sender will set up a new SA and key (unless the SA was configured with manual key management). =============================================================================== ARCHITECTURE 1. Section 4.2 "Security Association Functionality" -- clarified wording of per email from Bill Sommerfeld on 3/16: Changed "below" to "outside" in 5th sentence of 3rd paragraph which now reads: The scope of the authentication offered by ESP is narrower than for AH, i.e., the IP header(s) "outside" the ESP header is(are) not protected. 2. Section 4.2 "Security Association Functionality", paragraph 4 -- clarified Section to reflect the fact that encryption service in ESP is now optional -- per private email on 3/16. Changed: An ESP (tunnel mode) SA between two security gateways can offer partial traffic flow confidentiality. The use of tunnel mode allows the inner IP headers to be encrypted, concealing the identities of the (ultimate) traffic source and destination..... to: If confidentiality service is selected, then an ESP (tunnel mode) SA between two security gateways can offer partial traffic flow confidentiality. The use of tunnel mode allows the inner IP headers to be encrypted, concealing the identities of the (ultimate) traffic source and destination.... 3. Section 4.4 "Security Association Databases" -- clarified inbound/outbound terminology and model -- per various private and public email. Added the following paragraph at the end of Section 4.4 before 4.4.1: Each interface for which IPsec is enabled requires nominally separate inbound vs. outbound databases (SAD and SPD), because of the directionality of many of the fields that are used as selectors. Typically there is just one such interface, for a host or security gateway (SG). Note that an SG would always have at least 2 interfaces, but the "internal" one to the corporate net, usually would not have IPsec enabled and so only one pair of SADs and one pair of SPDs would be needed. On the other hand, if a host had multiple interfaces or an SG had multiple external interfaces, it might be necessary to have separate SAD and SPD pairs for each interface. 4. Sections 4.4 and 5 -- modified so that mention of the SPD having entries for inbound traffic, outbound traffic, and for each interface are brought up in the SPD section (4.4.1) rather than later on in Section 5 -- per email from Henry Spencer on 3/17 In Section 4.4.1 "The Security Policy Database (SPD)", added the following paragraph after the first paragraph: The SPD must be consulted during the processing of all traffic (INBOUND and OUTBOUND), including non-IPsec traffic. In order to support this, the SPD requires distinct entries for inbound and outbound traffic. One can think of this as separate SPDs (inbound vs. outbound). In addition, a nominally separate SPD must be provided for each IPsec-enabled interface. In Section 5. "IP Traffic Processing", first 2 paragraphs -- removed the text that is now redundant with Section 4.4.1 and combined them. So that the text changed from: The SPD must be consulted during the processing of all traffic (INBOUND and OUTBOUND), including non-IPsec traffic. Note that the SPD requires distinct entries for inbound and outbound traffic. One can think of this as separate SPDs (inbound vs. outbound). Note also that a nominally separate SPD must be provided for each IPsec-enabled interface. If no policy is found in the SPD that matches the packet (for either inbound or outbound traffic), the packet MUST be discarded. into the following text: As mentioned in Section 4.4.1 "The Security Policy Database (SPD)", the SPD must be consulted during the processing of all traffic (INBOUND and OUTBOUND), including non-IPsec traffic. If no policy is found in the SPD that matches the packet (for either inbound or outbound traffic), the packet MUST be discarded. 5. Section 4.4.1, "The Security Policy Database (SPD)" -- modified to reflect the reduced requirements for reuse of SAs (This was changed in the last draft in the Outbound Processing Section 5.1.1 "Selecting and Using and SA or SA Bundle" but not here) -- per email from Henry Spencer on 3/17 on private email on 4/13 Changed 2nd to last paragraph of Section 4.4.1 "The Security Policy Database (SPD)" from: Because a security policy may require that more than one SA be applied to a specified set of traffic, in a specific order, the policy entry in the SPD must preserve these ordering requirements.....For an inbound IPsec packet for which multiple IPsec SAs are to be applied, the lookup based on destination address, IPsec protocol, and SPI should identify a single SA. To allow minimization of the number of SAs, the linkage between the SPD and the SAD (at both the sender and the receiver) MUST allow an SA to be used in more than one bundle. to: Because a security policy may require that more than one SA be applied to a specified set of traffic, in a specific order, the policy entry in the SPD must preserve these ordering requirements.....For an inbound IPsec packet for which multiple IPsec SAs are to be applied, the lookup based on destination address, IPsec protocol, and SPI should identify a single SA. To allow minimization of the number of SAs, the linkage between the SPD and the SAD (at both the sender and the receiver) SHOULD allow an SA to be used in more than one bundle. Modified paragraph 5, last 2 bullets from: b. use the value associated with the policy entry -- if this were to be just a single value, then there would be no difference between (b) and (a). However, if the allowed values for the selector were a range, then (b) would enable use of the SA by any packet with a selector value within the range not just by packets with the selector value of the packet that triggered the creation of the SA. c. use a wildcard value -- this can be used to create an SA that can be shared by a broader set of SPD entries (vs (b)). to: b. use the value associated with the policy entry -- If this were to be just a single value, then there would be no difference between (b) and (a). However, if the allowed values for the selector are a range (for IP addresses) or a wildcard, then in the case of a range,(b) would enable use of the SA by any packet with a selector value within the range not just by packets with the selector value of the packet that triggered the creation of the SA. In the case of a wildcard, (b) would allow use of the SA by packets with any value for this selector. Changed paragraphs 6 and 7, from: For example, suppose there is an SPD entry where the allowed value for source address is any of a range of hosts (192.168.2.1 to 192.168.2.10).... source for the example of value to be new SAD used in the SA selector value --------------- ------------ a. packet 192.168.2.3 (one host) b. SPD entry 192.168.2.1 to 192.168.2.10 (range of hosts) c. wildcard * (any host) Case (c) permits the sharing of an SA (or SA bundle) by multiple SPD entries. Case (a) can be used to prohibit sharing, even among packets that match the same SPD entry. to: For example, suppose there is an SPD entry where the allowed value for source address is any of a range of hosts (192.168.2.1 to 192.168.2.10).... source for the example of value to be new SAD used in the SA selector value --------------- ------------ a. packet 192.168.2.3 (one host) b. SPD entry 192.168.2.1 to 192.168.2.10 (range of hosts) Note that if the SPD entry had an allowed value of wildcard for the source address, then the SAD selector value could be wildcard (any host). Case (a) can be used to prohibit sharing, even among packets that match the same SPD entry. Deleted the last sentence of next to last paragraph. It read: To allow minimization of the number of SAs, the linkage between the SPD and the SAD (at both the sender and the receiver) SHOULD allow an SA to be used in more than one bundle. 6. Section 4.4.2 "Selectors" -- defined term "opaque" -- per email from Bill Sommerfeld on 3/16 and Henry Spencer 3/17 Added definition of "opaque" to last sentence of Section 4.4.2 (also changed UserID to "Name") Note that in the case of receipt of a packet with an ESP header, e.g., at an encapsulating security gateway or BITW implementation, the transport layer protocol, source/destination ports, and UserID (if present) may be opaque. to: Note that in the case of receipt of a packet with an ESP header, e.g., at an encapsulating security gateway or BITW implementation, the transport layer protocol, source/destination ports, and Name (if present) may be "OPAQUE", i.e., inaccessible because of encryption or fragmentation. 7. Section 4.4.2 "Selectors", paragraphs on Source IP Address and Destination IP Address -- corrected text per email from Bill Sommerfeld on 3/16. o Changed text for "Source IP Address" to match "Destination IP Address" o Corrected text to list "address + mask", clarify what a range is, match DOI etc. o Added a note re: not specifying a mix of IPv4 and IPv6 IP addresses Changed paragraphs on Source and Destination IP Addresses from: - Source IP Address(es) (IPv4 or IPv6): this may be a single IP address, range of addresses, or a wildcard (mask) address. The latter two are required to support more than one source system sharing the same SA (e.g., behind a security gateway or in a multihomed host).... - Destination IP Address (IPv4 or IPv6): this may be a single IP address (unicast, broadcast, or multicast group), a range of addresses, or a wildcard (mask) address. The latter two are required to support more than one source system sharing the same SA (e.g., behind a security gateway or in a multihomed host)..... to: - Source IP Address(es) (IPv4 or IPv6): this may be a single IP address (unicast, broadcast, or multicast group), range of addresses (high and low values inclusive), address + mask, or a wildcard address. The last three are required to support more than one source system sharing the same SA (e.g., behind a security gateway or in a multihomed host).... - Destination IP Address (IPv4 or IPv6): this may be a single IP address (unicast, broadcast, or multicast group), a range of addresses (high and low values (inclusive), address + mask, or a wildcard address. The last three are used to support more than one destination system sharing the same SA (e.g., behind a security gateway).... Added the following text at the end of the first paragraph in Section 4.4.2 Selectors: Note also that both Source and Destination addresses should either be IPv4 or IPv6. 8. Section 4.4.2 Selectors, paragraph on "Source and Destination (e.g., TCP/UDP) Ports" -- Amend table to show that "Next Hdr" in SPD is the "Transport Layer Protocol" selector -- per private email of 3/18. Changed: Next Hdr Next Hdr Derived Port Selector Field in Packet in SPD Value in SPD and SAD -------- -------- --------------------------- to: Next Hdr Transport Layer Derived Port Selector Field in Packet Protocol in SPD Value in SPD and SAD -------- --------------- --------------------------- 9. Section 4.4.2 "Selectors" -- correct table near the end of the section to say that the destination address selector can have a value of a single address, a range, or a wildcard in the SAD -- per email from Padma Goli on 4/6/98. Changed the table near the end of Section 4.4.2 "Selectors" from: Field Traffic Value SAD Entry SPD Entry -------- ------------- ---------------- -------------------- src addr single IP addr single,range,wild single,range,wildcard --> dst addr single IP addr single IP addr single,range,wildcard .... to: Field Traffic Value SAD Entry SPD Entry -------- ------------- ---------------- -------------------- src addr single IP addr single,range,wild single,range,wildcard --> dst addr single IP addr single,range,wild single,range,wildcard ..... 10. Section 4.4.2 Selectors -- amended text for "Name" to note that support for name forms other than addresses is not required if manual keying is used -- per private email on 4/8. Changed the [REQUIRED section of the part on "Name" from: [REQUIRED for the following cases..... to: [REQUIRED for the following cases. Note that support for name forms other than addresses is not required for manually keyed SAs.... 11. Sections 4.4.3 "Security Association Database (SAD)" and 5.1.1 "Selecting and Using an SA or SA Bundle" -- corrected inconsistency between these sections on how to handle failure to find an SA that matches a given packet (for outbound processing) -- per mail from K. SrinivasRao on 3/16. Changed first paragraph from: In each IPsec implementation there is a nominal Security Association Database, in which each entry defines the parameters associated with one SA. Each SA has an entry in the SAD. For outbound processing, entries are pointed to by entries in the SPD. Note that if an SPD entry does not currently point to an SA that is appropriate for the packet, before it creates an SA, the implementation should check to see if the SAD already has an appropriate SA (created by some other SPD entry). to: In each IPsec implementation there is a nominal Security Association Database, in which each entry defines the parameters associated with one SA. Each SA has an entry in the SAD. For outbound processing, entries are pointed to by entries in the SPD. Note that if an SPD entry does not currently point to an SA that is appropriate for the packet, the implementation creates an appropriate SA (or SA Bundle) and links the SPD entry to the SAD entry (see Section 5.1.1). so that 4.4.3 matches the outbound processing steps in Section 5.1.1, step 2: 2. Match the packet's selector fields against those in the SA bundles found in (1) to locate the first SA bundle that matches. If no SAs were found or none match, create an appropriate SA bundle and link the SPD entry to the SAD entry. If no key management entity is found, drop the packet. 12. Section 4.4.3 "Security Association Database (SAD)" -- clarified to explain how wildcard might be used for IPsec protocol mode -- per private email in 3/98 Changed Section 4.4.3, paragraph on IPsec Protocol Mode from: o IPsec protocol mode: tunnel, transport or wildcard. Indicates which mode of AH or ESP is applied to traffic on this SA. [REQUIRED for all implementations, unless implicitly defined by context] to: o IPsec protocol mode: tunnel, transport or wildcard. Indicates which mode of AH or ESP is applied to traffic on this SA. Note that if this field is "wildcard" at the sending end of the SA, then the application has to specify the mode to the IPsec implementation. This use of wildcard allows the same SA to be used for either tunnel or transport mode traffic on a per packet basis, e.g., by different sockets. The receiver does not need to know the mode in order to properly process the packet's IPsec headers. [REQUIRED as follows, unless implicitly defined by context: - host implementations must support all modes - gateway implementations must support tunnel mode] NOTE: The use of wildcard for the protocol mode of an inbound SA may add complexity to the situation in the receiver (host only). Since the packets on such an SA could be delivered in either tunnel or transport mode, the security of an incoming packet could depend on which mode had been used to deliver it. If, as a result, an application cared about the SA mode of a given packet, then the application would need a mechanism to obtain this mode information. 13. Section 4.4.3 "Security Association Database (SAD)" -- clarified that the Anti-Replay Window is not used when anti-replay is disabled, e.g., for a manually keyed SA. -- per private email on 4/8. Changed the "REQUIRED" part of the paragraph on "Anti-Replay Window" from: [REQUIRED for all implementations but used only for inbound traffic.] to: [REQUIRED for all implementations but used only for inbound traffic. NOTE: If anti-replay has been disabled by the receiver, e.g., in the case of a manually keyed SA, then the Anti-Replay Window is not used.] 14. [Outbound] Section 5.1.1 "Selecting and Using an SA or SA Bundle" -- clarified that an attempt to create an ESP SA with both a NULL encryption and NULL authentication algorithm -- per private email discussion on 3/17. Added the following text at the end of the section: NOTE: A compliant implementation MUST not allow instantiation of an ESP SA that employs both a NULL encryption and a NULL authentication algorithm. An attempt to negotiate such an SA is an auditable event. 15. Section 5.1.2.2 "IPv6 -- Header Construction for Tunnel Mode" -- corrected "hop count" to "hop limit" -- per email from Peter Curran on 4/21. 16. [Inbound] Section 5.2.1 "Selecting and Using an SA or SA Bundle" -- clarified how/when to match packet selectors to the SA selectors -- per private email on 3/18 Changed step 2 from: ....Local policy determines the specificity of the SA selectors (single value, list, range, wildcard). In general, a packet's source address SHOULD match the SA selector value. (However, an AH or ESP-protected ICMP packet from a gateway may legitimately appear in a tunnel mode SA with a source IP address other than that bound to the SA, and thus such packets should be permitted as exceptions to this check. See Section 6.) Other packet fields MAY match the SA selector values as required by local policy. to: ....Local policy determines the specificity of the SA selectors (single value, list, range, wildcard). In general, a packet's source address MUST match the SA selector value. However, an ICMP packet received on a tunnel mode SA MAY have a source address other than that bound to the SA and thus such packets should be permitted as exceptions to this check. For an ICMP packet, the selectors from the enclosed problem packet (the source and destination addresses and ports should be swapped) should be checked against the selectors for the SA. Note that some or all of these selectors may be inaccessible because of limitations on how many bits of the problem packet the ICMP packet is allowed to carry or due to encryption. See Section 6. 17. Section 6.1.2 Path MTU Discovery (PMTU) -- Fixed parenthetical definition of IPv6 "Code 0" -- per private email of 3/18. Changed from: IPv6 (RFC 1885): - Type = 2 (Packet Too Big) - Code = 0 (Fragmentation needed and DF set) - Next-Hop MTU in the 32 bit MTU field of the ICMP6 message to: IPv6 (RFC 1885): - Type = 2 (Packet Too Big) - Code = 0 (Fragmentation needed) - Next-Hop MTU in the 32 bit MTU field of the ICMP6 message 18. Appendix B.2 "Fragmentation" -- corrected number of cases from 24 to 20, fixed a couple of minor wording problems. 19. Appendix B.2 "Fragmentation" -- modified text to reflect changes previously made in the main body of the text: - remove TOS/Class from list of selectors (per comment in a private email) - add lookup of SPD entry in addition to look up of SA (caught as part of editing process). Changed the 5th paragraph, item (b) from: b. Hosts (Bump-in-the-stack) -- put IPsec between IP layer and network drivers... ..... At the network layer, the IPsec module will have access to the following selectors from the packet -- SRC address, DST address, TOS, Next Protocol, and if there's a transport layer header --> SRC port and DST port. One cannot assume IPsec has access to the User ID. It is assumed that the available selector information is sufficient to figure out the relevant Security Association(s). to: At the network layer, the IPsec module will have access to the following selectors from the packet -- SRC address, DST address, Next Protocol, and if there's a transport layer header --> SRC port and DST port. One cannot assume IPsec has access to the User ID. It is assumed that the available selector information is sufficient to figure out the relevant Security Policy entry and Security Association(s). Changed the 5th paragraph, item (c) from: c. Security gateways -- integrate IPsec into the IP stack NOTE: The IPsec module will have access to the following selectors from the packet -- SRC address, DST address, TOS/Class, Next Protocol, and if there's a transport layer header --> SRC port and DST port. It won't have access to the User ID (only Hosts have access to User ID information.) It also won't have access to the transport layer information if there is an ESP header, or if it's not the first fragment of a fragmented message. It is assumed that the available selector information is sufficient to figure out the relevant Security Association(s). to: NOTE: The IPsec module will have access to the following selectors from the packet -- SRC address, DST address, Next Protocol, and if there's a transport layer header --> SRC port and DST port. It won't have access to the User ID (only Hosts have access to User ID information.) Unlike Bump-in-the-stack implementations, security gateways may be able to look up the Source Address in the DNS to provide a System Name, e.g., in situations involving use of dynamically assigned IP addresses in conjunction with dynamically updated DNS entries. It also won't have access to the transport layer information if there is an ESP header, or if it's not the first fragment of a fragmented message. It is assumed that the available selector information is sufficient to figure out the relevant Security Policy entry and Security Association(s). 20. Corrected references in Section B.3.4 "Per Socket Maintenance of PMTU Data" -- per email from Rohit Aradhya on 3/21. Changed from: Implementation of the calculation of PMTU (Section B.2.2) and support for PMTUs at the granularity of individual "communication associations" (Section B.2.3) is a local matter. to: Implementation of the calculation of PMTU (Section B.3.2) and support for PMTUs at the granularity of individual "communication associations" (Section B.3.3) is a local matter. From owner-ipsec Mon May 11 11:39:12 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA13515 for ipsec-outgoing; Mon, 11 May 1998 11:37:22 -0400 (EDT) Message-ID: <01BD7CBA.20D96000@BIGHUGE> From: Rob Adams To: "'Derrell D. Piper'" , "perry@piermont.com" Cc: Steve Bellovin , "ipsec@tis.com" Subject: RE: 3DES Date: Mon, 11 May 1998 08:52:14 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk However, some of us are saddled with 2 products, for political reasons.. %) One with 3DES and one without. If we add 3DES as a MUST, we're just going to end up with a load of products with interoperable IPSEC code in them that aren't IPSEC compliant.. Go ahead, flame away.. %).. I need some entertainment for this afternoon. -Rob -----Original Message----- From: Derrell D. Piper [SMTP:ddp@network-alchemy.com] Sent: Sunday, May 10, 1998 3:11 PM To: perry@piermont.com Cc: Steve Bellovin; ipsec@tis.com Subject: Re: 3DES I can't imagine anyone who's bothering to produce an IPSEC product _not_ taking the time to do 3DES. And for those who don't, the market will decide... Derrell From owner-ipsec Mon May 11 11:57:07 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA13629 for ipsec-outgoing; Mon, 11 May 1998 11:56:21 -0400 (EDT) Message-Id: <199805111610.JAA17552@greatdane.cisco.com> To: "Theodore Y. Ts'o" cc: Steve Bellovin , ipsec@tis.com Subject: Re: 3DES (was: ipsec vs. firewalls) In-reply-to: Your message of "Fri, 08 May 1998 13:40:37 EDT." <199805081740.NAA23629@dcl.MIT.EDU> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 11 May 1998 09:10:39 -0700 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk OK, if we're gonna entertain 3DES then what about adding another Diffie-Hellman group to IKE? There have been debates about the strength provided by the existing D-H groups and the requirements of 3DES. A larger prime may address some of those concerns. Rich Schroeppel (Univ of Ariz) who generated the 768bit and 1024bit primes for groups 1 and 2 has generated a 1536bit prime which could easily become group 5. (In fact, I know of at least one vendor who has this already). I can't think of any reasons why this shouldn't be added to the IKE draft so if anybody has any, please speak up. Dan. Theodore Y. Ts'o writes: > From: Steve Bellovin > > A more interesting topic is whether or not 3DES should be mandatory- > to-implement. I suggest that it should be -- DES is obviously doomed > (pick your favorite time constant), and we should take that into > account. We're better off if the IPSEC boxes being deployed now are > ready to switch. > > While I agree with you, we might need to have another one of Jeff's > famous straw polls in Chicago (the "Chicago doctrine", anyone?), given > the U.S. Goverment's special hostility to triple-DES. Given that > vendors living behind the cryptographic iron curtain weren't all that > happy about making DES mandatory, I'd suspect that they would howl over > making triple-DES mandatory. From owner-ipsec Mon May 11 12:18:14 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA13762 for ipsec-outgoing; Mon, 11 May 1998 12:17:25 -0400 (EDT) Message-ID: <319A1C5F94C8D11192DE00805FBBADDF0C1B33@exchange.timestep.com> From: Roy Pereira To: Rob Adams , "'Derrell D. Piper'" , perry@piermont.com Cc: Steve Bellovin , ipsec@tis.com Subject: RE: 3DES Date: Mon, 11 May 1998 12:28:02 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk I don't believe that this working group should be mandating such an algorithm as a MUST due to the current nature of export laws. Please, we live in the real world and 3DES is and will not be appropriate to export from the US and Canada anytime soon. Simply stating that the IETF doesn't care about export control will create interoperability issues, and believe me, we have enough of those already! Make it a STRONG SHOULD instead. > -----Original Message----- > From: Rob Adams [mailto:adams@cisco.com] > Sent: Monday, May 11, 1998 11:52 AM > To: 'Derrell D. Piper'; perry@piermont.com > Cc: Steve Bellovin; ipsec@tis.com > Subject: RE: 3DES > > > However, some of us are saddled with 2 products, for > political reasons.. %) > One with 3DES and one without. If we add 3DES as a MUST, we're just > going to end up with a load of products with interoperable > IPSEC code in them > that aren't IPSEC compliant.. > > Go ahead, flame away.. %).. I need some entertainment for > this afternoon. > > -Rob > > -----Original Message----- > From: Derrell D. Piper [SMTP:ddp@network-alchemy.com] > Sent: Sunday, May 10, 1998 3:11 PM > To: perry@piermont.com > Cc: Steve Bellovin; ipsec@tis.com > Subject: Re: 3DES > > I can't imagine anyone who's bothering to produce an IPSEC > product _not_ > taking the time to do 3DES. And for those who don't, the market will > decide... > > Derrell > > > From owner-ipsec Mon May 11 12:31:42 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA13834 for ipsec-outgoing; Mon, 11 May 1998 12:31:20 -0400 (EDT) Date: Mon, 11 May 1998 11:56:44 -0400 (EDT) From: Henry Spencer To: Dan Stromberg cc: ipsec@tis.com Subject: Re: ipsec vs. firewalls In-Reply-To: <35533A56.5D9C@hydra.acs.uci.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk > > The problem is that for a corporate network of any substantial > > size, there will *never* be a way to make the interior crunchy. > > Eventually, I believe it is reasonable to expect that vendors will > automate patch application, and that patches will be obtained from the > vendor over the network... Perry has already pointed out that big outfits with mission-critical applications want to vet new software releases very carefully. Even less-fussy organizations often want to do updates in a controlled way, because changes and new releases so often have unwanted side effects. (Auto-update schemes would be more acceptable to many users if the software suppliers weren't such bungling incompetents half the time.) To say nothing of the security implications of having your binary-only software going off and doing unspecified things over the network without being asked... "Trust us, it's for your own good." Yeah, right. One of the reasons why firewall configurations often restrict outgoing calls, as well as incoming ones, is distrust of software suppliers. Henry Spencer henry@spsystems.net (henry@zoo.toronto.edu) From owner-ipsec Mon May 11 12:37:46 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA13884 for ipsec-outgoing; Mon, 11 May 1998 12:37:21 -0400 (EDT) Date: Mon, 11 May 98 09:48:25 PDT From: jim@mentat.com (Jim Gillogly) Message-Id: <9805111648.AA04074@mentat.com> To: ipsec@tis.com Subject: RE: 3DES Sender: owner-ipsec@ex.tis.com Precedence: bulk Are US export laws in some favored position? The US is not the only country with export restrictions, and some even have tighter crypto controls. I think these decisions should be made on technical grounds rather than political ones. Note that there's no guarantee that you'll get export permission from the US for your product even with full-strength single DES, so leaving out 3DES may not buy you anything in any case. If 3DES is left out of MUST, it should be because it's too slow relative to other strong systems, or because the block size is too small, or because we expect to replace both DES and 3DES with AES within 2 or 3 years... but not because we want to take the pressure off some country's BXA. Jim Gillogly From owner-ipsec Mon May 11 12:50:02 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA13945 for ipsec-outgoing; Mon, 11 May 1998 12:49:20 -0400 (EDT) Date: Mon, 11 May 1998 12:03:44 -0500 (CDT) Message-Id: <199805111703.MAA07707@hosaka.smallworks.com> From: Jim Thompson To: rpereira@TimeStep.com CC: adams@cisco.com, ddp@network-alchemy.com, perry@piermont.com, smb@research.att.com, ipsec@tis.com In-reply-to: <319A1C5F94C8D11192DE00805FBBADDF0C1B33@exchange.timestep.com> (message from Roy Pereira on Mon, 11 May 1998 12:28:02 -0400) Subject: Re: 3DES References: <319A1C5F94C8D11192DE00805FBBADDF0C1B33@exchange.timestep.com> Sender: owner-ipsec@ex.tis.com Precedence: bulk Make it a STRONG SHOULD instead. And let the government(s) win? Never. Governments come and go, and export policies change. The IETF should be about technical work (running code, and all that). -- 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 Mon May 11 13:15:12 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA14085 for ipsec-outgoing; Mon, 11 May 1998 13:14:21 -0400 (EDT) Message-ID: <35573568.4CD94707@redcreek.com> Date: Mon, 11 May 1998 10:29:12 -0700 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.05 [en] (Win95; U) MIME-Version: 1.0 To: ipsec@tis.com Subject: Re: 3DES References: <01BD7CBA.20D96000@BIGHUGE> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Rob Adams wrote: > > However, some of us are saddled with 2 products, for political reasons.. %) > One with 3DES and one without. If we add 3DES as a MUST, we're just > going to end up with a load of products with interoperable IPSEC code in them > that aren't IPSEC compliant.. This is a good point - while I agree that almost any useful implementation will support 3DES, it's not clear that we should *mandate* anything more than a minimal interoperability subset. From owner-ipsec Mon May 11 14:19:09 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA14465 for ipsec-outgoing; Mon, 11 May 1998 14:17:22 -0400 (EDT) Message-Id: <3.0.5.32.19980511142802.00a104e0@homebase.htt-consult.com> X-Sender: rgm-sec@homebase.htt-consult.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Mon, 11 May 1998 14:28:02 -0400 To: Daniel Harkins , "Theodore Y. Ts'o" From: Robert Moskowitz Subject: Re: 3DES (was: ipsec vs. firewalls) Cc: Steve Bellovin , ipsec@tis.com In-Reply-To: <199805111610.JAA17552@greatdane.cisco.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 09:10 AM 5/11/98 -0700, Daniel Harkins wrote: > > Rich Schroeppel (Univ of Ariz) who generated the 768bit and 1024bit primes >for groups 1 and 2 has generated a 1536bit prime which could easily become >group 5. (In fact, I know of at least one vendor who has this already). > Adding additional D_H groups will be part of the next round. Plan on it. Robert Moskowitz ICSA Security Interest EMail: rgm-sec@htt-consult.com From owner-ipsec Mon May 11 14:29:50 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA14523 for ipsec-outgoing; Mon, 11 May 1998 14:29:22 -0400 (EDT) Message-Id: <4.0.1.329.19980511143855.00ddd610@enterprise.unitran.com> X-Sender: rodney@enterprise.unitran.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1.329 (Beta) Date: Mon, 11 May 1998 14:40:13 -0400 To: ipsec@tis.com From: Rodney Thayer Subject: Re: 3DES Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Perhaps what we need to be doing is to emphasize that at least two ciphers is a good idea, and, oh by the way, by convention and for other reasons, best current practice is that DES and 3DES are are a good pair of choices. -----BEGIN PGP SIGNATURE----- Version: PGP for Personal Privacy 5.5.3 iQA/AwUBNVdGDIwpVk/gvJfqEQKuaACgsLEJInj3Lkt/zR4bwtSEgg9ryyMAoKyf OBtFEJJRYM/IcWBgtfdCaCZl =qhwC -----END PGP SIGNATURE----- From owner-ipsec Mon May 11 14:55:49 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA14724 for ipsec-outgoing; Mon, 11 May 1998 14:55:24 -0400 (EDT) Message-ID: <35574CD7.223A@hydra.acs.uci.edu> Date: Mon, 11 May 1998 12:09:11 -0700 From: Dan Stromberg X-Mailer: Mozilla 3.0 (X11; I; SunOS 5.7 sun4u) MIME-Version: 1.0 To: perry@piermont.com CC: Marcus Leech , ipsec@tis.com Subject: Re: ipsec vs. firewalls References: <199805102242.SAA11188@jekyll.piermont.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Perry E. Metzger wrote: > > Dan Stromberg writes: > > > The problem is that for a corporate network of any substantial > > > size, there will *never* be a way to make the interior > > > crunchy. > > > > I have to disagree. > > > > Eventually, I believe it is reasonable to expect that vendors will > > automate patch application, and that patches will be obtained from the > > vendor over the network. > > I don't mean to sound nasty here, but in some of the financial > environments I work in integration labs work year round carefully > vetting applications before rollout, and nothing hits the production > equipment without extensive testing. Are you going to tell me that > people who have to be that paranoid lest you call up bitching about > your broker not being able to get a trade done for you are going to > let random vendors automatically change software on their networks? > > No way in hell. Clearly it's not for everyone. But I believe most businesses will leap at it. It's already starting. If you want to stop it, you probably better start a huge propaganda campaign -today-. I have no idea who you'd have to convince tho. It's probably inevitable. I imagine the best you can hope for, is the option to turn it off. From owner-ipsec Mon May 11 15:35:02 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA14977 for ipsec-outgoing; Mon, 11 May 1998 15:33:24 -0400 (EDT) Message-ID: <3557560D.3D82@hughes.com> Date: Mon, 11 May 1998 12:49:00 -0700 From: "Ronald A Martin" Reply-To: ramartin@hughes.com Organization: Raytheon Company RSC/RHAC X-Mailer: Mozilla 3.0Gold (Macintosh; U; PPC) MIME-Version: 1.0 To: Robert Moskowitz CC: Steve Bellovin , ipsec@tis.com, "Satkus, Jerome R" , "Hantman, Howard L" , "Murray, David E" Subject: Re: 3DES (was: ipsec vs. firewalls) References: <3.0.5.32.19980508133943.00a02eb0@homebase.htt-consult.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Robert, 3DES should be baseline minimum. Ron -- Ronald A. Martin IT Security Architect Raytheon Systems Company Box 92919 R11/M352 Los Angeles, CA 90009-2919 v310-364-8810 f310-322-1454 p800-208-8325 or 2088325@skymail.com This is my personal opinion and not necessarily that of my employer. Robert Moskowitz wrote: > > At 11:02 AM 5/8/98 -0400, Steve Bellovin wrote: > > > >A more interesting topic is whether or not 3DES should be mandatory- > >to-implement. I suggest that it should be -- DES is obviously doomed > >(pick your favorite time constant), and we should take that into > >account. We're better off if the IPSEC boxes being deployed now are > >ready to switch. > > > I am putting together the ICSA testing criteria for IPsec products for our > aug/sep certification round (any vendor that will have PRODUCTION systems > by July should subscribe to ipsec@icsa.net (majordomo list)). > > Right now I have 3DES grouped with IDEA and CAST as 'extra security'. If > there is strong concensus among vendors and customers on 3DES, we could > move 3DES to the baseline testing. > > Looking for input. Note our testing need not, and in fact when dealing > with rekeying be locked down to the MUSTs. > > Robert Moskowitz > ICSA > Security Interest EMail: rgm-sec@htt-consult.com From owner-ipsec Mon May 11 15:52:08 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA15109 for ipsec-outgoing; Mon, 11 May 1998 15:51:23 -0400 (EDT) Message-Id: <199805112009.VAA24860@gate.ticl.co.uk> X-Sender: peter@gate (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Mon, 11 May 1998 21:07:01 +0100 To: Karen Seo From: Peter Curran Subject: Re: Latest AH/ESP/Arch drafts and changes Cc: ipsec@tis.com, kseo@bbn.com In-Reply-To: <199805110517.BAA05493@relay.hq.tis.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk Karen At 01:16 11/05/98 -0400, Karen Seo wrote: >Folks, > >In follow-up to the IESG vote/feedback and recent email... > >1. Per direction from Ted Ts'o, we are sending to the IETF secretariat > and the mailing list, revised versions of the following drafts: > o AH -- draft-ietf-ipsec-auth-header-06.txt > o ESP -- draft-ietf-ipsec-esp-v2-05.txt > o Architecture -- draft-ietf-ipsec-arch-sec-05.txt > > These drafts contain the changes listed below in part 1 and part 2. > ........................ Bit disappointed to see that you did not tidy up the item concerning the handling of IPv6 hop-limit when using tunnel-mode between two boxes, as opposed to the case of forwarding into a tunnel. I think that the discussion here and on the IPNG list agreed that the wording required clarification to differentiate the cases. Is there a reason, or is it a future task, or was it done anyway but not included in your abstract? Regards Peter Curran From owner-ipsec Mon May 11 16:40:48 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA15311 for ipsec-outgoing; Mon, 11 May 1998 16:39:22 -0400 (EDT) Message-Id: <98May11.165455edt.11650@janus.tor.securecomputing.com> To: ipsec@tis.com Subject: (take 2) RESPONDER_LIFETIME message format query From: "C. Harald Koch" MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----- =_aaaaaaaaaa0" Content-ID: <3605.894920014.0@gamera.tornd.securecomputing.com> Date: Mon, 11 May 1998 16:54:12 -0400 Sender: owner-ipsec@ex.tis.com Precedence: bulk ------- =_aaaaaaaaaa0 Content-Type: text/plain; charset="us-ascii" Content-ID: <3605.894920014.1@gamera.tornd.securecomputing.com> Can I assume from the Resouding Silence that no-one is implementing RESPONDER_LIFETIME Notify messages yet? ------- =_aaaaaaaaaa0 MIME-Version: 1.0 Content-Type: message/rfc822 Return-Path: Received: from portal.ex.tis.com ([192.94.214.101]) by janus.tor.securecomputing.com with ESMTP id <11649>; Mon, 4 May 1998 15:55:06 -0400 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA18132 for ipsec-outgoing; Mon, 4 May 1998 15:31:47 -0400 (EDT) Message-Id: <98May4.154651edt.11649@janus.tor.securecomputing.com> To: Derrell Piper Cc: ipsec@tis.com Subject: RESPONDER_LIFETIME message format query 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: Mon, 4 May 1998 15:45:49 -0400 Sender: owner-ipsec@ex.tis.com Precedence: bulk The DOI says: 4.6.3.1 RESPONDER-LIFETIME The RESPONDER-LIFETIME status message may be used to communicate the IPSEC SA lifetime chosen by the responder. When present, the Notification Payload MUST have the following format: o Payload Length - set to length of payload + size of data (var) o DOI - set to IPSEC DOI (1) o Protocol ID - set to selected Protocol ID from chosen SA >>>> o SPI Size - set to sixteen (16) (two eight-octet ISAKMP cookies) o Notify Message Type - set to RESPONDER-LIFETIME (Section 4.6.3) >>>> o SPI - set to the two ISAKMP cookies o Notification Data - contains an ISAKMP attribute list with the responder's actual SA lifetime(s) Why is the SPI here the ISAKMP SPI? Shouldn't it be the ISAKMP SPI iff the lifetime in question is the Phase1 lifetime being 'adjusted', and the IPSEC SPI iff the lifetime in question is the Phase2 lifetime? Confused, -- Harald Koch ------- =_aaaaaaaaaa0-- From owner-ipsec Mon May 11 20:44:48 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id UAA16000 for ipsec-outgoing; Mon, 11 May 1998 20:42:23 -0400 (EDT) Message-Id: <199805120057.UAA25913@jekyll.piermont.com> To: Dan Stromberg cc: perry@piermont.com, Marcus Leech , ipsec@tis.com Subject: Re: ipsec vs. firewalls In-reply-to: Your message of "Mon, 11 May 1998 12:09:11 PDT." <35574CD7.223A@hydra.acs.uci.edu> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Mon, 11 May 1998 20:57:20 -0400 From: "Perry E. Metzger" Sender: owner-ipsec@ex.tis.com Precedence: bulk Dan Stromberg writes: > Clearly it's not for everyone. > > But I believe most businesses will leap at it. Have you actually done a poll of IS managers at fortune 500 companies? My gut is that half will laugh, one third will say "bad idea" without laughing, and the rest are too clueless to understand. > It's already starting. Is it? I've yet to see such a beast. Perry From owner-ipsec Mon May 11 22:50:09 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id WAA16306 for ipsec-outgoing; Mon, 11 May 1998 22:48:29 -0400 (EDT) Message-Id: <3.0.5.32.19980511230031.00a21250@homebase.htt-consult.com> X-Sender: rgm-sec@homebase.htt-consult.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Mon, 11 May 1998 23:00:31 -0400 To: perry@piermont.com, Dan Stromberg From: Robert Moskowitz Subject: Re: ipsec vs. firewalls Cc: perry@piermont.com, Marcus Leech , ipsec@tis.com In-Reply-To: <199805120057.UAA25913@jekyll.piermont.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 08:57 PM 5/11/98 -0400, Perry E. Metzger wrote: > >> It's already starting. > >Is it? I've yet to see such a beast. > Its called Java, Perry :) Robert Moskowitz ICSA Security Interest EMail: rgm-sec@htt-consult.com From owner-ipsec Mon May 11 23:21:58 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id XAA16425 for ipsec-outgoing; Mon, 11 May 1998 23:21:24 -0400 (EDT) Date: Mon, 11 May 1998 23:36:32 -0400 Message-Id: <199805120336.XAA25920@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: Peter Curran Cc: Karen Seo , ipsec@tis.com, kseo@bbn.com In-Reply-To: Peter Curran's message of Mon, 11 May 1998 21:07:01 +0100, <199805112009.VAA24860@gate.ticl.co.uk> Subject: Re: Latest AH/ESP/Arch drafts and changes Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: owner-ipsec@ex.tis.com Precedence: bulk Date: Mon, 11 May 1998 21:07:01 +0100 From: Peter Curran Bit disappointed to see that you did not tidy up the item concerning the handling of IPv6 hop-limit when using tunnel-mode between two boxes, as opposed to the case of forwarding into a tunnel. I think that the discussion here and on the IPNG list agreed that the wording required clarification to differentiate the cases. Is there a reason, or is it a future task, or was it done anyway but not included in your abstract? I at least didn't get the sense that there was consensus about what specific wording changes could be made to make things more clear. I think there was general agreement that the concerns that there was a problem with the text stemmed from a misreading of the text, and that the text is not in conflict with IPV6 and IPv4. The architecture document has fairly explicit text already saying that the ttl/hop limit field is decremented "prior to forwarding". Do you have some specific textual changes you'd like to suggest? - Ted From owner-ipsec Tue May 12 00:30:20 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id AAA16575 for ipsec-outgoing; Tue, 12 May 1998 00:28:22 -0400 (EDT) Message-Id: <199805120443.AAA02003@relay.rv.tis.com> Date: Tue, 12 May 98 0:39:50 EDT From: Karen Seo To: Peter Curran cc: ipsec@tis.com Subject: Re: Latest AH/ESP/Arch drafts and changes Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi Peter, I was under the impression that no change was to be made. In part, some of the email seemed to be saying the current text was fine. Also, some folks were saying that ND should *not* work across an IPsec tunnel (I believe it was stated that ND should use transport mode). And the text as is supports that. If we change the architecture to say that a system which is both the source of a packet and the source end of a tunnel should NOT decrement the TTL, then ND could still work across the IPsec tunnel. Karen From owner-ipsec Tue May 12 00:39:46 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id AAA16617 for ipsec-outgoing; Tue, 12 May 1998 00:39:23 -0400 (EDT) Message-Id: <199805120451.AAA06500@relay.hq.tis.com> Date: Tue, 12 May 98 0:44:18 EDT From: Karen Seo To: ipsec@tis.com Subject: drafts -- AH, ESP, Arch Sender: owner-ipsec@ex.tis.com Precedence: bulk Folks, Just FYI... On Sunday, I sent the drafts to the secretariat and cc:d it to tis.org (:-(). This morning, I re-sent the drafts to tis.com. I still haven't seen them, but figure it's just a mail backlog since other email to the list has been arriving all day. Karen From owner-ipsec Tue May 12 11:10:38 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA18394 for ipsec-outgoing; Tue, 12 May 1998 11:04:27 -0400 (EDT) Message-Id: <199805121519.TAA09346@relay2.elvis.ru> Comments: Authenticated sender is From: "Valery Smyslov" Organization: Elvis+ To: ipsec@tis.com Date: Tue, 12 May 1998 19:19:18 +3 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Some questions X-mailer: Pegasus Mail for Win32 (v2.52) Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi all, I have some questions regarding IPsec processing. 1. As stated in ISAKMP and IKE drafts, when initiator sends SA payload containing several Proposal payloads (each of them may contain several Transform payloads), responder MUST reply with only one Proposal (or with some if they define a protection suit, thus having the same Proposal number) containing only one transform. Then initiator creates 2 SAs (outbound and inbound) using returned (and so selected by the peer) transform and its attributes. It assumes that both SA (in each direction) will use the same transform (e.g. algorithm with its attributes) and will differ only in their keys. Is this reading correct? If so, one cannot create asymmetrical SA with ISAKMP, for example, using DES in one direction and IDEA in the other, that might be useful under some circumstances. 2. Regarding previous question: when protection suite (e.g. sequence of SAs) is negotiated, what should be the order of appliance of those SAs when processing an outgoing packet? Should it be the same as the order in which their proposals appear in the ISAKMP SA Payload? It is very natural, but it seems that IPsec drafts doesn't state this explicitly. Thanks in advance, Valery Smyslov. From owner-ipsec Tue May 12 11:38:53 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA18509 for ipsec-outgoing; Tue, 12 May 1998 11:38:29 -0400 (EDT) Message-Id: <199805121551.IAA11145@greatdane.cisco.com> To: "Valery Smyslov" cc: ipsec@tis.com Subject: Re: Some questions In-reply-to: Your message of "Tue, 12 May 1998 19:19:18." <199805121519.TAA09346@relay2.elvis.ru> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 12 May 1998 08:51:54 -0700 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk Privyet Valery, > 1. As stated in ISAKMP and IKE drafts, when initiator sends SA > payload containing several Proposal payloads (each of them may > contain several Transform payloads), responder MUST reply with only > one Proposal (or with some if they define a protection suit, thus > having the same Proposal number) containing only one transform. Then > initiator creates 2 SAs (outbound and inbound) using returned (and so > selected by the peer) transform and its attributes. It assumes that > both SA (in each direction) will use the same transform (e.g. > algorithm with its attributes) and will differ only in their keys. Is > this reading correct? If so, one cannot create asymmetrical SA with > ISAKMP, for example, using DES in one direction and IDEA in the > other, that might be useful under some circumstances. Yes, that's right, they must use the same transform. Under what situations would you want to have asymmetrical SAs? > 2. Regarding previous question: when protection suite (e.g. sequence > of SAs) is negotiated, what should be the order of appliance of those > SAs when processing an outgoing packet? Should it be the same as the > order in which their proposals appear in the ISAKMP SA Payload? It is > very natural, but it seems that IPsec drafts doesn't state this > explicitly. For situations where you negotiate AH and ESP you apply ESP first. Applying multiple AH or multiple ESP transforms to a single packet is not defined. Dan. From owner-ipsec Tue May 12 12:49:58 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA18850 for ipsec-outgoing; Tue, 12 May 1998 12:48:27 -0400 (EDT) Message-ID: From: Eric Hastings To: "'jpickering@phase2net.com'" , "'ipsec@tis.com'" Subject: RE: isakmp sa attributes Date: Tue, 12 May 1998 11:44:16 -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 don't know if you had this answered, but anyway... > My quess would be that the group type and field size attributes are only for >private >groups and are therefore not required as part of the negotiation. Is this >correct? If so, what should be done if, for example, these attributes are >included when specifying one of the 4 standard groups? IKE states on page 6: Group attributes (such as group type or prime-- see Appendix A) MUST NOT be offered in conjunction with a previously defined group (either a reserved group description or a private use description that is established after conclusion of a New Group Mode exchange). So, I guess you could decide that a proposal providing attributes along with a pre-defined group is an invalid proposal. Eric Hastings > > From owner-ipsec Tue May 12 12:54:55 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA18883 for ipsec-outgoing; Tue, 12 May 1998 12:54:28 -0400 (EDT) Message-Id: <3.0.5.32.19980512130839.00a14500@homebase.htt-consult.com> X-Sender: rgm-sec@homebase.htt-consult.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Tue, 12 May 1998 13:08:39 -0400 To: ipsec@tis.com From: Robert Moskowitz Subject: 40bit DES? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk Does the following draft supply the basis for 40bit DES for IPsec? draft-hoffman-des40-02.txt there seems to be 3 things needed for 'US exportable' IPsec: A 40bit DES ESP algorithm A 40bit DES for IKE A 512 modulus for D-H All three items handled by one draft might be called: 'Dumbed down cryptography for IPsec' or 'USDOJ approved IPsec" Nah scratch the latter. Not nice. Robert Moskowitz ICSA Security Interest EMail: rgm-sec@htt-consult.com From owner-ipsec Tue May 12 13:11:13 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA19027 for ipsec-outgoing; Tue, 12 May 1998 13:10:27 -0400 (EDT) Message-Id: <199805121722.NAA25494@relay.hq.tis.com> X-Sender: rodney@pop.pn.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1.329 (Beta) Date: Tue, 12 May 1998 13:20:25 -0400 To: ipsec@tis.com From: Rodney Thayer Subject: Fwd: Re: Some questions Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk >From: Daniel Harkins > >> 1. As stated in ISAKMP and IKE drafts, when initiator sends SA >> payload containing several Proposal payloads (each of them may >> contain several Transform payloads), responder MUST reply with only >> one Proposal (or with some if they define a protection suit, thus >> having the same Proposal number) containing only one transform. Then >> initiator creates 2 SAs (outbound and inbound) using returned (and so >> selected by the peer) transform and its attributes. It assumes that >> both SA (in each direction) will use the same transform (e.g. >> algorithm with its attributes) and will differ only in their keys. Is >> this reading correct? If so, one cannot create asymmetrical SA with >> ISAKMP, for example, using DES in one direction and IDEA in the >> other, that might be useful under some circumstances. > >Yes, that's right, they must use the same transform. Under what situations >would you want to have asymmetrical SAs? If the path is assymetric, for example the downlink is high speed and the uplink is low speed in a mixed satellite configuration. Or if the downlink must support multiple hardware platforms/implementations (imagine IPSec in a satellite, there's an export headache for you...) and the uplink goes over some other path. Weird, but hey, we want IPSec to go mainstream, right? IPSec in every garage door opener, high tech running shoe and pocket personal crypto-weapon... From owner-ipsec Tue May 12 13:29:57 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA19083 for ipsec-outgoing; Tue, 12 May 1998 13:28:30 -0400 (EDT) Message-Id: <98May12.134329edt.11651@janus.tor.securecomputing.com> To: Robert Moskowitz cc: ipsec@tis.com Subject: Re: 40bit DES? References: <3.0.5.32.19980512130839.00a14500@homebase.htt-consult.com> In-reply-to: Your message of "Tue, 12 May 1998 13:08:39 -0400". <3.0.5.32.19980512130839.00a14500@homebase.htt-consult.com> From: "C. Harald Koch" Date: Tue, 12 May 1998 13:42:41 -0400 Sender: owner-ipsec@ex.tis.com Precedence: bulk In message <3.0.5.32.19980512130839.00a14500@homebase.htt-consult.com>, Robert Moskowitz writes: > > there seems to be 3 things needed for 'US exportable' IPsec: > > A 40bit DES ESP algorithm > A 40bit DES for IKE > A 512 modulus for D-H > > All three items handled by one draft might be called: Only the first entry is required. You can leave the IKE encryption and D-H moduli (and RSA key strengths) at their normal, standard levels. -- Harald From owner-ipsec Tue May 12 13:30:34 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA19096 for ipsec-outgoing; Tue, 12 May 1998 13:30:29 -0400 (EDT) Message-Id: <3.0.5.32.19980512134428.00a1edf0@homebase.htt-consult.com> X-Sender: rgm-sec@homebase.htt-consult.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Tue, 12 May 1998 13:44:28 -0400 To: "C. Harald Koch" From: Robert Moskowitz Subject: Re: 40bit DES? Cc: ipsec@tis.com In-Reply-To: <98May12.134329edt.11651@janus.tor.securecomputing.com> References: <3.0.5.32.19980512130839.00a14500@homebase.htt-consult.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 01:42 PM 5/12/98 -0400, C. Harald Koch wrote: >In message <3.0.5.32.19980512130839.00a14500@homebase.htt-consult.com>, Robert Moskowitz writes: >> >> there seems to be 3 things needed for 'US exportable' IPsec: >> >> A 40bit DES ESP algorithm >> A 40bit DES for IKE >> A 512 modulus for D-H >> >> All three items handled by one draft might be called: > >Only the first entry is required. You can leave the IKE encryption and D-H >moduli (and RSA key strengths) at their normal, standard levels. > I have heard of problems with exporting group 1. Has anyone gotten approval (of course that would prove nothing). Robert Moskowitz ICSA Security Interest EMail: rgm-sec@htt-consult.com From owner-ipsec Tue May 12 13:51:04 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA19145 for ipsec-outgoing; Tue, 12 May 1998 13:49:28 -0400 (EDT) Date: Tue, 12 May 98 10:59:44 PDT From: jim@mentat.com (Jim Gillogly) Message-Id: <9805121759.AA17332@mentat.com> To: chk@utcc.utoronto.ca, rgm-sec@htt-consult.com Subject: Re: 40bit DES? Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk > >> there seems to be 3 things needed for 'US exportable' IPsec: > >> > >> A 40bit DES ESP algorithm > >> A 40bit DES for IKE > >> A 512 modulus for D-H > >> > >> All three items handled by one draft might be called: > > > >Only the first entry is required. You can leave the IKE encryption and D-H > >moduli (and RSA key strengths) at their normal, standard levels. > > > I have heard of problems with exporting group 1. Has anyone gotten > approval (of course that would prove nothing). Tell me again why we want it? We already have the NULL ESP algorithm, which provides a proof of concept of the framework without providing security. Another such algorithm would seem to be overkill. Again -- our job is to provide a technical spec to allow people to communicate securely. If we compromise it so that the lowest common denominator is insecure, we're wasting our time. Jim Gillogly From owner-ipsec Tue May 12 14:26:29 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA19259 for ipsec-outgoing; Tue, 12 May 1998 14:25:29 -0400 (EDT) Message-Id: <199805121840.OAA28473@relay.rv.tis.com> X-Sender: rodney@pop.pn.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1.329 (Beta) Date: Tue, 12 May 1998 14:38:51 -0400 To: ipsec@tis.com From: Rodney Thayer Subject: Fwd: Re: 40bit DES? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk I do think people are going to want these weak ciphers. Whether it's because of their politics, or because they want clearly useless demo-ware (my favorite reason) or because their marketing staff don't care as long as the customers pay money for it, or whatever. Jim does have a point however, there's a variety of features in IKE that would allow negotiation of private ciphers, why not just let people who want 40 bit DES or 6 bit DES or 504-bit 9DES negotiate their own thing? I think we've met the "be architecturally responsible" criteria by allowing private negotiation. >Date: Tue, 12 May 98 10:59:44 PDT >From: jim@mentat.com (Jim Gillogly) >To: chk@utcc.utoronto.ca, rgm-sec@htt-consult.com >Subject: Re: 40bit DES? >Cc: ipsec@tis.com >Sender: owner-ipsec@ex.tis.com > >> >> there seems to be 3 things needed for 'US exportable' IPsec: >> >> >> >> A 40bit DES ESP algorithm >> >> A 40bit DES for IKE >> >> A 512 modulus for D-H >> >> >> >> All three items handled by one draft might be called: >> > >> >Only the first entry is required. You can leave the IKE encryption and D-H >> >moduli (and RSA key strengths) at their normal, standard levels. >> > >> I have heard of problems with exporting group 1. Has anyone gotten >> approval (of course that would prove nothing). > >Tell me again why we want it? We already have the NULL ESP algorithm, >which provides a proof of concept of the framework without providing >security. Another such algorithm would seem to be overkill. > >Again -- our job is to provide a technical spec to allow people to >communicate securely. If we compromise it so that the lowest common >denominator is insecure, we're wasting our time. > > Jim Gillogly > From owner-ipsec Tue May 12 14:38:23 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA19302 for ipsec-outgoing; Tue, 12 May 1998 14:37:28 -0400 (EDT) Message-ID: <35589A3B.41C6@cs.umass.edu> Date: Tue, 12 May 1998 14:51:39 -0400 From: Lewis McCarthy Organization: UMass-Amherst Theoretical Computer Science Group, X-Mailer: Mozilla 3.01Gold (X11; U; OSF1 V4.0 alpha) MIME-Version: 1.0 To: Daniel Harkins CC: IP Security List Subject: Re: Some questions References: <199805121551.IAA11145@greatdane.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Daniel Harkins writes: >>> this reading correct? If so, one cannot create asymmetrical SA with >>> ISAKMP, for example, using DES in one direction and IDEA in the >>> other, that might be useful under some circumstances. > > Yes, that's right, they must use the same transform. Under what situations > would you want to have asymmetrical SAs? I suppose you might be sending relatively uninteresting requests in one direction (i.e., "Tell me everything you know about the nuclear weapons capability of Elbonia."), and fascinating replies in the other direction ("There's an advanced testing facility for high-yield nuclear devices hidden under the swamp 82 miles NE of the Elbonian capital.") -Lewis From owner-ipsec Tue May 12 15:07:24 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA19458 for ipsec-outgoing; Tue, 12 May 1998 15:05:27 -0400 (EDT) Message-Id: <3.0.5.32.19980512151015.00a21b80@homebase.htt-consult.com> X-Sender: rgm-sec@homebase.htt-consult.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Tue, 12 May 1998 15:10:15 -0400 To: jim@mentat.com (Jim Gillogly), chk@utcc.utoronto.ca From: Robert Moskowitz Subject: Re: 40bit DES? Cc: ipsec@tis.com In-Reply-To: <9805121759.AA17332@mentat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 10:59 AM 5/12/98 PDT, Jim Gillogly wrote: >> >> there seems to be 3 things needed for 'US exportable' IPsec: >> >> > >Tell me again why we want it? We already have the NULL ESP algorithm, >which provides a proof of concept of the framework without providing >security. Another such algorithm would seem to be overkill. > >Again -- our job is to provide a technical spec to allow people to >communicate securely. If we compromise it so that the lowest common >denominator is insecure, we're wasting our time. > Sigh. I would rather not do this. In fact "I" will not. Some vendor(s) out there that decide they need this in their product will submit the technique as an informational RFC. The workgroup will be asked to review it per POISED proceedures. We SHOULD be able to state that it does not break the protocol, but to say that it is secure, read RFC 1984... Dumbed down IPsec will not be in the re-charter. It does not have to be in the charter at this point. Robert Moskowitz ICSA Security Interest EMail: rgm-sec@htt-consult.com From owner-ipsec Tue May 12 15:51:57 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA19611 for ipsec-outgoing; Tue, 12 May 1998 15:51:29 -0400 (EDT) Date: Tue, 12 May 1998 15:59:10 -0400 (EDT) From: Henry Spencer To: ipsec@tis.com Subject: Re: 40bit DES? In-Reply-To: <3.0.5.32.19980512130839.00a14500@homebase.htt-consult.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk > All three items handled by one draft might be called: > 'Dumbed down cryptography for IPsec' "Cryptographically challenged IPsec" Henry Spencer henry@spsystems.net (henry@zoo.toronto.edu) From owner-ipsec Tue May 12 15:57:37 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA19688 for ipsec-outgoing; Tue, 12 May 1998 15:57:28 -0400 (EDT) Message-Id: <199805122008.QAA29229@jekyll.piermont.com> To: jim@mentat.com (Jim Gillogly) cc: chk@utcc.utoronto.ca, rgm-sec@htt-consult.com, ipsec@tis.com Subject: Re: 40bit DES? In-reply-to: Your message of "Tue, 12 May 1998 10:59:44 PDT." <9805121759.AA17332@mentat.com> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Tue, 12 May 1998 16:08:30 -0400 From: "Perry E. Metzger" Sender: owner-ipsec@ex.tis.com Precedence: bulk Jim Gillogly writes: > > >> there seems to be 3 things needed for 'US exportable' IPsec: > > >> > > >> A 40bit DES ESP algorithm > Tell me again why we want it? We already have the NULL ESP algorithm, > which provides a proof of concept of the framework without providing > security. Another such algorithm would seem to be overkill. > > Again -- our job is to provide a technical spec to allow people to > communicate securely. If we compromise it so that the lowest common > denominator is insecure, we're wasting our time. Indeed, DES with 56 bits isn't secure. With 40 bits, you are wasting the time of your customers. I've said it before and I'll say it again -- selling 40 bit cryptography to your customers, even if they ask it, is like selling patent medicine to a cancer patient -- its more or less fraud. Even IBM doesn't pretend CDMF provides any security at all -- thus the name. If the U.S. congress wants to hand your customers over to SSH and other overseas companies selling crypto software, complain to Congress, not the IETF. Anyone who wants to can buy compliant code, and if they can't buy it from you because you are "locationally challenged", that's between you and your congressman, and frankly, most of the companies complaining have more than enough money to go out and lobby. Perry From owner-ipsec Tue May 12 16:11:40 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA19735 for ipsec-outgoing; Tue, 12 May 1998 16:09:29 -0400 (EDT) From: Vach Kompella To: Subject: New key-recovery mailing list Message-ID: <5040200014991266000002L062*@MHS> Date: Tue, 12 May 1998 16:28:26 -0400 MIME-Version: 1.0 Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk Folks, As I promised Bob Moskowitz, I've finally set up a key recovery mailing list. I know this is a volatile subject. Let's keep the flames and personal beliefs about key recovery down, and see if we can't get some solution to the export problem. Also, please use judgment in cross-posting to the ipsec mailing list, so that we don't clutter mailboxes, and create flame wars. In particular, the issues we should stick to relate to how to perform key recovery, both for IPSec as well as TLS/SSL, what we know/believe to be the various governments' policies on key recovery and cryptography restrictions. Everyone seems to know that the U.S. gov't has some restrictions, but do other countries, e.g., France? Subscription requests should be sent to majordomo@raleigh.ibm.com with "subscribe key-recovery" in the body of the message or to key-recovery-request@raleigh.ibm.com with just "subscribe". This is currently an unmoderated list. I am the list owner, so please direct all adminstrative questions to me, either at key-recovery-owner@raleigh.ibm.com or kompella@us.ibm.com. Vach Kompella IBM Corp. kompella@us.ibm.com (919) 254-7281 From owner-ipsec Tue May 12 16:11:45 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA19753 for ipsec-outgoing; Tue, 12 May 1998 16:11:28 -0400 (EDT) Message-Id: <199805122026.QAA06636@relay.rv.tis.com> X-Sender: rodney@pop.pn.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1.329 (Beta) Date: Tue, 12 May 1998 16:21:15 -0400 To: ipsec@tis.com From: Rodney Thayer Subject: Fwd: Re: 40bit DES? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk Forgive me, I don't mean to disagree with anything Perry is saying, but is that a "don't put it in the draft" or a "don't admit you've seen an informational RFC" or a "mandate we refuse to think about it" or what? [actually, I think that Perry's statement hangs together quite well.] >To: jim@mentat.com (Jim Gillogly) >cc: chk@utcc.utoronto.ca, rgm-sec@htt-consult.com, ipsec@tis.com >Subject: Re: 40bit DES? >Reply-To: perry@piermont.com >X-Reposting-Policy: redistribute only with permission >Date: Tue, 12 May 1998 16:08:30 -0400 >From: "Perry E. Metzger" >Sender: owner-ipsec@ex.tis.com > > >Jim Gillogly writes: >> > >> there seems to be 3 things needed for 'US exportable' IPsec: >> > >> >> > >> A 40bit DES ESP algorithm > >> Tell me again why we want it? We already have the NULL ESP algorithm, >> which provides a proof of concept of the framework without providing >> security. Another such algorithm would seem to be overkill. >> >> Again -- our job is to provide a technical spec to allow people to >> communicate securely. If we compromise it so that the lowest common >> denominator is insecure, we're wasting our time. > >Indeed, DES with 56 bits isn't secure. With 40 bits, you are wasting >the time of your customers. I've said it before and I'll say it again >-- selling 40 bit cryptography to your customers, even if they ask it, >is like selling patent medicine to a cancer patient -- its more or >less fraud. Even IBM doesn't pretend CDMF provides any security at >all -- thus the name. > >If the U.S. congress wants to hand your customers over to SSH and >other overseas companies selling crypto software, complain to >Congress, not the IETF. Anyone who wants to can buy compliant code, >and if they can't buy it from you because you are "locationally >challenged", that's between you and your congressman, and frankly, >most of the companies complaining have more than enough money to go >out and lobby. > >Perry > From owner-ipsec Tue May 12 16:47:55 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA19868 for ipsec-outgoing; Tue, 12 May 1998 16:47:28 -0400 (EDT) Message-ID: <319A1C5F94C8D11192DE00805FBBADDF0C20A3@exchange.timestep.com> From: Roy Pereira To: perry@piermont.com, jim@mentat.com Cc: chk@utcc.utoronto.ca, rgm-sec@htt-consult.com, ipsec@tis.com Subject: RE: 40bit DES? Date: Tue, 12 May 1998 16:56:14 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk blah, blah, blah..... Regardless of what your opinion is, in the real world we are forced with export issues. Sure 40-bit DES isn't secure, but it sure is a lot better than no encryption or not having any sales? Its time to move from the theoretical to the practical. I can dream of a day when we all live together in harmony with world peace, but reality dictates something else, doesn't it? > -----Original Message----- > From: Perry E. Metzger [mailto:perry@piermont.com] > Sent: Tuesday, May 12, 1998 4:09 PM > To: jim@mentat.com > Cc: chk@utcc.utoronto.ca; rgm-sec@htt-consult.com; ipsec@tis.com > Subject: Re: 40bit DES? > > > > Jim Gillogly writes: > > > >> there seems to be 3 things needed for 'US exportable' IPsec: > > > >> > > > >> A 40bit DES ESP algorithm > > > Tell me again why we want it? We already have the NULL ESP > algorithm, > > which provides a proof of concept of the framework without providing > > security. Another such algorithm would seem to be overkill. > > > > Again -- our job is to provide a technical spec to allow people to > > communicate securely. If we compromise it so that the lowest common > > denominator is insecure, we're wasting our time. > > Indeed, DES with 56 bits isn't secure. With 40 bits, you are wasting > the time of your customers. I've said it before and I'll say it again > -- selling 40 bit cryptography to your customers, even if > they ask it, > is like selling patent medicine to a cancer patient -- its more or > less fraud. Even IBM doesn't pretend CDMF provides any security at > all -- thus the name. > > If the U.S. congress wants to hand your customers over to SSH and > other overseas companies selling crypto software, complain to > Congress, not the IETF. Anyone who wants to can buy compliant code, > and if they can't buy it from you because you are "locationally > challenged", that's between you and your congressman, and frankly, > most of the companies complaining have more than enough money to go > out and lobby. > > Perry > From owner-ipsec Tue May 12 16:59:09 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA19916 for ipsec-outgoing; Tue, 12 May 1998 16:58:27 -0400 (EDT) Message-Id: <199805122110.RAA23875@postal.research.att.com> To: Roy Pereira cc: perry@piermont.com, jim@mentat.com, chk@utcc.utoronto.ca, rgm-sec@htt-consult.com, ipsec@tis.com Subject: Re: 40bit DES? Date: Tue, 12 May 1998 17:10:17 -0400 From: Steve Bellovin Sender: owner-ipsec@ex.tis.com Precedence: bulk blah, blah, blah..... Regardless of what your opinion is, in the real world we are forced with export issues. Sure 40-bit DES isn't secure, but it sure is a lot better than no encryption or not having any sales? Its time to move from the theoretical to the practical. I can dream of a day when we all live together in harmony with world peace, but reality dictates something else, doesn't it? I agree one can make the argument that 56-bit DES is worth something. Even though it's not very good against a serious attacker, it does guard against joy hackers, at least until someone with more money than security savvy builds a DES-cracker and puts it up on the net as a target... I don't think you can even say that for 40-bit DES. Anyone with the ability to sniff something interesting almost certainly has access to enough cycles to crack it -- and that includes most joy hackers, and all serious enemies. What are you protecting, and against whom? (I should note that given the current low level of cryptographic use, the mere fact that something is encrypted singles it out as something to look at.) From owner-ipsec Tue May 12 17:09:02 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA19971 for ipsec-outgoing; Tue, 12 May 1998 17:08:28 -0400 (EDT) Message-Id: <199805122121.RAA29440@jekyll.piermont.com> To: Roy Pereira cc: perry@piermont.com, jim@mentat.com, chk@utcc.utoronto.ca, rgm-sec@htt-consult.com, ipsec@tis.com Subject: Re: 40bit DES? In-reply-to: Your message of "Tue, 12 May 1998 16:56:14 EDT." <319A1C5F94C8D11192DE00805FBBADDF0C20A3@exchange.timestep.com> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Tue, 12 May 1998 17:21:40 -0400 From: "Perry E. Metzger" Sender: owner-ipsec@ex.tis.com Precedence: bulk Roy Pereira writes: > blah, blah, blah..... Regardless of what your opinion is, in the real > world we are forced with export issues. Sure 40-bit DES isn't secure, > but it sure is a lot better than no encryption or not having any sales? Huh? 40 bit DES *is* having no encryption. Its got only one legitimate function -- it will slow your computer down. What's the point? Not having any sales is the vendor's problem, not the customer's. The choice is not "no encryption or 40 bit DES". It is "no encryption or buy from a company like SSH Communcations Security Oy". The mere fact that VENDORS are harmed by this doesn't harm CUSTOMERS. End users get to buy from whom they want. > Its time to move from the theoretical to the practical. I can dream of > a day when we all live together in harmony with world peace, but reality > dictates something else, doesn't it? Reality is that customers get to buy from overseas vendors. I'm sorry if this hurts you as a U.S. vendor. Go and get your lobbyist working. This doesn't inconvenience me as a user. Just because the NSA is pushing job exports doesn't mean you can't go and push for crypto exports. Perry From owner-ipsec Tue May 12 17:35:55 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA20069 for ipsec-outgoing; Tue, 12 May 1998 17:34:30 -0400 (EDT) Message-ID: <319A1C5F94C8D11192DE00805FBBADDF0C20D3@exchange.timestep.com> From: Roy Pereira To: perry@piermont.com Cc: jim@mentat.com, chk@utcc.utoronto.ca, rgm-sec@htt-consult.com, ipsec@tis.com Subject: RE: 40bit DES? Date: Tue, 12 May 1998 17:47:00 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk Actually it doesn't hurt my organization at all, since we are a Canadian corporation and we can export 56-bit DES without key-recovery to almost anywhere. I am just thinking about all those poor US companies that will not be able to export IPSec due to the US's export laws. I agree with you about the severity of the situation for American (and Canadian) organizations, but I disagree using US based IPSec companies as martyrs. We have to ask ourselfs if we wish to use IPSec as a vehicle to change the US government's export laws, or do we wish to make a PROTOCOL. I vote for making an interoperable protocol. There must be other ways to get the US gov to changes its export laws. > -----Original Message----- > From: Perry E. Metzger [mailto:perry@piermont.com] > Sent: Tuesday, May 12, 1998 5:22 PM > To: Roy Pereira > Cc: perry@piermont.com; jim@mentat.com; chk@utcc.utoronto.ca; > rgm-sec@htt-consult.com; ipsec@tis.com > Subject: Re: 40bit DES? > > > > Roy Pereira writes: > > blah, blah, blah..... Regardless of what your opinion is, > in the real > > world we are forced with export issues. Sure 40-bit DES > isn't secure, > > but it sure is a lot better than no encryption or not > having any sales? > > Huh? > > 40 bit DES *is* having no encryption. Its got only one legitimate > function -- it will slow your computer down. What's the point? > > Not having any sales is the vendor's problem, not the customer's. The > choice is not "no encryption or 40 bit DES". It is "no encryption or > buy from a company like SSH Communcations Security Oy". The mere fact > that VENDORS are harmed by this doesn't harm CUSTOMERS. End users get > to buy from whom they want. > > > Its time to move from the theoretical to the practical. I > can dream of > > a day when we all live together in harmony with world > peace, but reality > > dictates something else, doesn't it? > > Reality is that customers get to buy from overseas vendors. I'm sorry > if this hurts you as a U.S. vendor. Go and get your lobbyist > working. This doesn't inconvenience me as a user. Just > because the NSA > is pushing job exports doesn't mean you can't go and push for crypto > exports. > > Perry > From owner-ipsec Tue May 12 17:41:38 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA20123 for ipsec-outgoing; Tue, 12 May 1998 17:41:31 -0400 (EDT) Message-Id: <3.0.5.32.19980512175520.00a21250@homebase.htt-consult.com> X-Sender: rgm-sec@homebase.htt-consult.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Tue, 12 May 1998 17:55:20 -0400 To: Henry Spencer , ipsec@tis.com From: Robert Moskowitz Subject: Re: 40bit DES? In-Reply-To: References: <3.0.5.32.19980512130839.00a14500@homebase.htt-consult.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 03:59 PM 5/12/98 -0400, Henry Spencer wrote: > >"Cryptographically challenged IPsec" EXCELLENT! Robert Moskowitz ICSA Security Interest EMail: rgm-sec@htt-consult.com From owner-ipsec Tue May 12 17:43:35 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA20139 for ipsec-outgoing; Tue, 12 May 1998 17:43:30 -0400 (EDT) Date: Tue, 12 May 1998 16:58:30 -0500 (CDT) Message-Id: <199805122158.QAA16706@hosaka.smallworks.com> From: Jim Thompson To: rpereira@TimeStep.com CC: perry@piermont.com, chk@utcc.utoronto.ca, rgm-sec@htt-consult.com, ipsec@tis.com In-reply-to: <319A1C5F94C8D11192DE00805FBBADDF0C20A3@exchange.timestep.com> (message from Roy Pereira on Tue, 12 May 1998 16:56:14 -0400) Subject: Re: 40bit DES? References: <319A1C5F94C8D11192DE00805FBBADDF0C20A3@exchange.timestep.com> Sender: owner-ipsec@ex.tis.com Precedence: bulk I don't know what 'real world' to which you refer. Selling 40-bit DES can do you customer real harm. You *know* the salesfolk are going to say its secure. Perhaps its time to ask the AD. -- 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 May 12 17:44:34 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA20153 for ipsec-outgoing; Tue, 12 May 1998 17:44:29 -0400 (EDT) Message-Id: <199805122159.OAA19308@dharkins-ss20.cisco.com> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: ipsec@tis.com Subject: Re: 40bit DES? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 12 May 1998 14:59:03 -0700 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk Didn't we go through this about 6 weeks ago? The tone is much more civil now (no one is being called a whore-- yet) but the content hasn't changed. Anybody for a discussion of negotiating the anti-replay window size? Dan. "someone" wrote: > Roy Pereira writes: > > blah, blah, blah..... Regardless of what your opinion is, in the real > > world we are forced with export issues. Sure 40-bit DES isn't secure, > > but it sure is a lot better than no encryption or not having any sales? > > Huh? > > 40 bit DES *is* having no encryption. Its got only one legitimate > function -- it will slow your computer down. What's the point? > > Not having any sales is the vendor's problem, not the customer's. The > choice is not "no encryption or 40 bit DES". It is "no encryption or > buy from a company like SSH Communcations Security Oy". The mere fact > that VENDORS are harmed by this doesn't harm CUSTOMERS. End users get > to buy from whom they want. > > > Its time to move from the theoretical to the practical. I can dream of > > a day when we all live together in harmony with world peace, but reality > > dictates something else, doesn't it? > > Reality is that customers get to buy from overseas vendors. I'm sorry > if this hurts you as a U.S. vendor. Go and get your lobbyist > working. This doesn't inconvenience me as a user. Just because the NSA > is pushing job exports doesn't mean you can't go and push for crypto > exports. > > Perry From owner-ipsec Tue May 12 17:56:15 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA20232 for ipsec-outgoing; Tue, 12 May 1998 17:55:33 -0400 (EDT) Message-ID: <3558C9A4.37E6E76E@newoak.com> Date: Tue, 12 May 1998 18:13:56 -0400 From: johara@newoak.com (John O'Hara) X-Mailer: Mozilla 4.02 [en] (WinNT; I) MIME-Version: 1.0 To: Jim Gillogly CC: chk@utcc.utoronto.ca, rgm-sec@htt-consult.com, ipsec@tis.com Subject: Re: 40bit DES? References: <9805121759.AA17332@mentat.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk OK... since you asked. It's not really needed for export. While our government will generally grant VPN products a export license for 56bit IPsec under a "key management infrastructure exemption" and you can send it all over the world, you can't import it into france unless it's no stronger than 40 bits. The main issue is that the french cannot buy strong ( >40 bit) crypto from any external company without specific pre-authorization. Arguements about the strength of des40 aside is it really better to offer them only AH ? or NULL ESP ?. So you have to rekey every few minutes, it keeps the crypto chip guys in beer and peanuts :-). John O'Hara Jim Gillogly wrote: > > Tell me again why we want it? We already have the NULL ESP algorithm, > which provides a proof of concept of the framework without providing > security. Another such algorithm would seem to be overkill. > > Again -- our job is to provide a technical spec to allow people to > communicate securely. If we compromise it so that the lowest common > denominator is insecure, we're wasting our time. > From owner-ipsec Tue May 12 17:56:19 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA20231 for ipsec-outgoing; Tue, 12 May 1998 17:55:32 -0400 (EDT) Date: Tue, 12 May 1998 18:09:44 -0400 From: Ran Canetti Message-Id: <9805122209.AA30010@ornavella.watson.ibm.com> To: chk@utcc.utoronto.ca, rgm-sec@htt-consult.com Subject: Re: 40bit DES? Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk > > there seems to be 3 things needed for 'US exportable' IPsec: > > > > A 40bit DES ESP algorithm > > A 40bit DES for IKE > > A 512 modulus for D-H > > > > All three items handled by one draft might be called: > > Only the first entry is required. You can leave the IKE encryption and D-H > moduli (and RSA key strengths) at their normal, standard levels. > > -- > Harald > Very good point. Just to stress: the cryptographic strength of the algorithms in IKE has nothing to do with the strength of the data encryption. It only determines the level of confidence in the authenticity and secrecy of the agreed key (however long or short it chooses to be). No reason to weaken that. Ran From owner-ipsec Tue May 12 18:00:47 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA20272 for ipsec-outgoing; Tue, 12 May 1998 18:00:30 -0400 (EDT) Message-ID: <3558CA5B.8B6113CC@cosinecom.com> Date: Tue, 12 May 1998 15:16:59 -0700 From: Abraham R Matthews Organization: Cosine Communications X-Mailer: Mozilla 4.05 [en] (WinNT; I) MIME-Version: 1.0 To: ipsec@tis.com Subject: [Q] SA lookup on receive Content-Type: multipart/mixed; boundary="------------0C30572AC1261F5C32024759" Sender: owner-ipsec@ex.tis.com Precedence: bulk This is a multi-part message in MIME format. --------------0C30572AC1261F5C32024759 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi all, When an ipsec packet is received, an SA is looked up using the tuple . Must the dest-ip be a local ip address of the security gateway? What if the dest-ip address is the address of an internal host? Thanks, Abbie. --------------0C30572AC1261F5C32024759 Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Abraham Matthews Content-Disposition: attachment; filename="vcard.vcf" begin: vcard fn: Abraham Matthews n: Matthews;Abraham org: CoSine Communications adr: Suite 200;;1070 Sixth Avenue;Belmont;CA;94002;USA email;internet: amatthews@cosinecom.com title: Software Architect tel;work: 650-637-4725 tel;fax: 650-637-4778 x-mozilla-cpt: ;0 x-mozilla-html: TRUE version: 2.1 end: vcard --------------0C30572AC1261F5C32024759-- From owner-ipsec Tue May 12 18:02:44 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA20300 for ipsec-outgoing; Tue, 12 May 1998 18:02:32 -0400 (EDT) Date: Tue, 12 May 1998 18:17:13 -0400 Message-Id: <199805122217.SAA10329@tonga.xedia.com> From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: kompella@us.ibm.com Cc: ipsec@tis.com Subject: Re: New key-recovery mailing list References: <5040200014991266000002L062*@MHS> X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-ipsec@ex.tis.com Precedence: bulk >>>>> "Vach" == Vach Kompella writes: Vach> ... Everyone seems to know Vach> that the U.S. gov't has some restrictions, but do other Vach> countries, e.g., France? Yes. See: http://cwis.kub.nl/~frw/people/koops/cls2.htm#fr More in general, see http://cwis.kub.nl/~frw/people/koops/lawsurvy.htm for lots of good info. From owner-ipsec Tue May 12 18:14:21 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA20343 for ipsec-outgoing; Tue, 12 May 1998 18:13:29 -0400 (EDT) Message-Id: <199805122226.SAA29549@jekyll.piermont.com> To: Roy Pereira cc: perry@piermont.com, jim@mentat.com, chk@utcc.utoronto.ca, rgm-sec@htt-consult.com, ipsec@tis.com Subject: Re: 40bit DES? In-reply-to: Your message of "Tue, 12 May 1998 17:47:00 EDT." <319A1C5F94C8D11192DE00805FBBADDF0C20D3@exchange.timestep.com> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Tue, 12 May 1998 18:26:48 -0400 From: "Perry E. Metzger" Sender: owner-ipsec@ex.tis.com Precedence: bulk Roy Pereira writes: > Actually it doesn't hurt my organization at all, since we are a Canadian > corporation and we can export 56-bit DES without key-recovery to almost > anywhere. I am just thinking about all those poor US companies that > will not be able to export IPSec due to the US's export laws. They screwed up. They weren't smart enough to locate in Canada. Quit trying to dumb down IPSec. You aren't doing your customers, or theirs, a favor. It is better that they buy good crypto from you than worthless crud from someone in the U.S. > I agree with you about the severity of the situation for American > (and Canadian) organizations, but I disagree using US based IPSec > companies as martyrs. You are so goddamn vendor-centric. What about the poor customers? Don't you give a tinker's damn about them? They aren't trying to buy something to slow down their machines -- they want to buy something SECURE. > We have to ask ourselfs if we wish to use IPSec as a vehicle to change > the US government's export laws, or do we wish to make a PROTOCOL. We want a SECURE PROTOCOL. I'm not trying to change anyone's policy. I'm trying to get SECURE software in the hands of the users. If that means they have to buy from Canada, so be it. We're doing no customer a favor by selling them fraudulent fake crypto software. Perry From owner-ipsec Tue May 12 18:18:39 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA20376 for ipsec-outgoing; Tue, 12 May 1998 18:18:30 -0400 (EDT) Date: Tue, 12 May 1998 15:30:57 -0700 (PDT) From: Mike Eisler Reply-To: Mike Eisler Subject: RE: 40bit DES? To: Roy Pereira Cc: perry@piermont.com, jim@mentat.com, chk@utcc.utoronto.ca, rgm-sec@htt-consult.com, ipsec@tis.com In-Reply-To: "Your message with ID" <319A1C5F94C8D11192DE00805FBBADDF0C20D3@exchange.timestep.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk > Actually it doesn't hurt my organization at all, since we are a Canadian > corporation and we can export 56-bit DES without key-recovery to almost > anywhere. I am just thinking about all those poor US companies that > will not be able to export IPSec due to the US's export laws. I agree > with you about the severity of the situation for American (and Canadian) > organizations, but I disagree using US based IPSec companies as martyrs. > > We have to ask ourselfs if we wish to use IPSec as a vehicle to change > the US government's export laws, or do we wish to make a PROTOCOL. I Is political activism in one particular nation state part of IPSEC's charter? > vote for making an interoperable protocol. There must be other ways to > get the US gov to changes its export laws. users of IPSEC in the U.S./Canada can use U.S. (and non U.S.) products to interoperate with users of IPSEC outside U.S./Canada that use non-U.S. products with 56DES. That's an interoperable protocol. That U.S. vendors are at a disadvantage competively is an issue outside the scope of IETF. Now if the U.S. bans domestic encryption for privacy, U.S. vendors will possibly feel market pressure to implement "Cryptographically challenged IPsec". In which case, they are free to band together to do so. Perhaps French IPSEC implementors will have it all figured out by then. But there is no point in addressing that "what if" issue today. -mre From owner-ipsec Tue May 12 19:42:58 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA20631 for ipsec-outgoing; Tue, 12 May 1998 19:41:30 -0400 (EDT) Message-ID: <3558E1B3.3D84@hydra.acs.uci.edu> Date: Tue, 12 May 1998 16:56:35 -0700 From: Dan Stromberg X-Mailer: Mozilla 3.0 (X11; I; SunOS 5.7 sun4u) MIME-Version: 1.0 To: ipsec@tis.com Subject: Re: 40bit DES? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk The world has some countries with stupid laws. Who should pay for the stupidity? Those countries, or the entire world? IMO, it should be the countries with stupid laws paying for their own stupidity. Let them drag themselves down, not themselves -and- others. (I say this as a resident of one of the countries that would be paying for its own mistakes) How about making Cryptographically Challenged IPSEC an unrequired option, kind of like SKIP? From owner-ipsec Tue May 12 20:51:16 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id UAA20944 for ipsec-outgoing; Tue, 12 May 1998 20:49:29 -0400 (EDT) Message-Id: <199805130104.VAA12563@relay.rv.tis.com> Date: Tue, 12 May 98 21:00:59 EDT From: Karen Seo To: ipsec@tis.com cc: kseo@bbn.com Subject: Re: drafts -- AH, ESP, Arch Sender: owner-ipsec@ex.tis.com Precedence: bulk I'm not sure what happened to the drafts I re-sent to the list. "ipsec@tis.com" seems to be working fine. At any rate, the copies I sent to the secretariat made it and will be posted tomorrow (Wed 5/13). So I'm going to skip sending them again to the list. From owner-ipsec Tue May 12 23:00:52 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id WAA21251 for ipsec-outgoing; Tue, 12 May 1998 22:59:28 -0400 (EDT) Message-Id: <9805130314.AA15855@columbia.sparta.com> X-Sender: hsw@columbia.sparta.com X-Mailer: Windows Eudora Version 2.1.1 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 12 May 1998 23:14:48 -0400 To: Rodney Thayer , ipsec@tis.com From: Howard Weiss Subject: Re: Fwd: Re: Some questions Sender: owner-ipsec@ex.tis.com Precedence: bulk At 01:20 PM 5/12/98 -0400, Rodney Thayer wrote: >>From: Daniel Harkins >> >>> 1. As stated in ISAKMP and IKE drafts, when initiator sends SA >>> payload containing several Proposal payloads (each of them may >>> contain several Transform payloads), responder MUST reply with only >>> one Proposal (or with some if they define a protection suit, thus >>> having the same Proposal number) containing only one transform. Then >>> initiator creates 2 SAs (outbound and inbound) using returned (and so >>> selected by the peer) transform and its attributes. It assumes that >>> both SA (in each direction) will use the same transform (e.g. >>> algorithm with its attributes) and will differ only in their keys. Is >>> this reading correct? If so, one cannot create asymmetrical SA with >>> ISAKMP, for example, using DES in one direction and IDEA in the >>> other, that might be useful under some circumstances. >> >>Yes, that's right, they must use the same transform. Under what situations >>would you want to have asymmetrical SAs? > >If the path is assymetric, for example the downlink is high speed and the >uplink is low speed in a mixed satellite configuration. Or if the downlink >must support multiple hardware platforms/implementations (imagine IPSec in a >satellite, there's an export headache for you...) and the uplink goes over >some >other path. I somewhat find it hard to believe that anyone would want to negotitate different algorithms based on the assymetry of the connection. I would more imagine that the users would want to negotiate the strongest, most efficient algorithm available for use in both directions. However, since TCP does not deal well with great swings in connection assymetry, there are other problems to be solved. Howie Weiss ____________________________________________________________________ | | |Howard Weiss phone (410) 381-9400 x201 | |SPARTA, Inc. (301) 621-8145 x201 (DC)| |9861 Broken Land Parkway fax: (410) 381-5559 | |Columbia, MD 21046 email: hsw@columbia.sparta.com| |____________________________________________________________________| From owner-ipsec Tue May 12 23:54:50 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id XAA21370 for ipsec-outgoing; Tue, 12 May 1998 23:53:33 -0400 (EDT) Message-Id: <3.0.5.32.19980513000415.0096f700@homebase.htt-consult.com> X-Sender: rgm-sec@homebase.htt-consult.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Wed, 13 May 1998 00:04:15 -0400 To: Ran Canetti , chk@utcc.utoronto.ca From: Robert Moskowitz Subject: Re: 40bit DES? Cc: ipsec@tis.com In-Reply-To: <9805122209.AA30010@ornavella.watson.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 06:09 PM 5/12/98 -0400, Ran Canetti wrote: >> > there seems to be 3 things needed for 'US exportable' IPsec: >> > >> > A 40bit DES ESP algorithm >> > A 40bit DES for IKE >> > A 512 modulus for D-H >> > >> > All three items handled by one draft might be called: >> >> Only the first entry is required. You can leave the IKE encryption and D-H >> moduli (and RSA key strengths) at their normal, standard levels. >> >Very good point. Just to stress: the cryptographic strength of the >algorithms in IKE has nothing to do with the strength of the data >encryption. It only determines the level of confidence in the >authenticity and secrecy of the agreed key (however long or short it >chooses to be). No reason to weaken that. > Actually there appears to be a reason. there are vendors have problems with getting export license for IKE, too strong. Sigh. Keep in mind, that I am working as hard as possible to have as many countries producing their own IPsec products. Robert Moskowitz ICSA Security Interest EMail: rgm-sec@htt-consult.com From owner-ipsec Wed May 13 00:13:59 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id AAA21432 for ipsec-outgoing; Wed, 13 May 1998 00:12:29 -0400 (EDT) Message-Id: <199805130427.AAA00886@jekyll.piermont.com> To: ipsec@tis.com Subject: liability for selling bad crypto? Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: multipart/mixed; boundary="Multipart_Wed_May_13_00:27:12_1998-1" Content-Transfer-Encoding: 7bit Date: Wed, 13 May 1998 00:27:12 -0400 From: "Perry E. Metzger" Sender: owner-ipsec@ex.tis.com Precedence: bulk --Multipart_Wed_May_13_00:27:12_1998-1 Content-Type: text/plain; charset=US-ASCII By the way, the "cryptography" mailing list has been having an interesting discussion of whether companies are liable for selling bad crypto products or for relying upon them if they know that they are bad. I'm forwarding one of the recent messages on the topic. The entire discussion has been interesting thus far, although only some of the participants have been lawyers. Relevance? Look no further than 40 bit DES. Perry --Multipart_Wed_May_13_00:27:12_1998-1 Content-Type: message/rfc822 Return-Path: cryptography-owner@c2.net Delivery-Date: Wed May 13 00:18:54 1998 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: cryptography@c2.net, unicorn@schloss.li Subject: Re: PPTP (again) Date: Wed, 13 May 1998 16:09:18 (NZST) [Followups trimmed somewhat] Black Unicorn writes: >I've been watching trends which might suggest that a firm could be sued for >failing to exercise due diligence in their information protection efforts. >Shareholder derivative suits would be the most interesting from a legal point >of view because the cause-effect chain doesn't need to be very strong for one >such to succeed. So, under what circumstances would Microsoft (which is >exceptionally well represented from a legal standpoint, by the way) be >potentially liable for a security oversight? I wrote a paper on encryption and e-commerce about 2 years ago (http://www.cs.auckland.ac.nz/~pgut001/pubs/icommerce.pdf, rather in need of update in some areas) which briefly covers this issue in the section "Liabilities of Weak Encryption/Poor Security", but from the angle of having stockholders sue the company directors for negligence if they use known weak security and the company stock price slips due to this. For example everyone even vaguely involved in computers and security knows that US-exportable crypto is no good (it's certainly had press coverage in every imaginable medium), so a company which relied on this for security would make itself a prime target for negligence lawsuits when their security was breached. The paper gives a few references for further info, for example the US Federal Sentencing Guidelines for Organisation Defendants which give clear guidelines for judges when sentencing corporations found guilty in federal liability cases. There's only about a page of stuff there (I'm a cryptographer, not a lawyer), but I'd be interested in any thoughts people have on this. Peter. --Multipart_Wed_May_13_00:27:12_1998-1-- From owner-ipsec Wed May 13 00:49:53 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id AAA21529 for ipsec-outgoing; Wed, 13 May 1998 00:49:29 -0400 (EDT) Message-Id: <199805130504.WAA06688@greatdane.cisco.com> To: "Perry E. Metzger" cc: ipsec@tis.com Subject: Re: liability for selling bad crypto? In-reply-to: Your message of "Wed, 13 May 1998 00:27:12 EDT." <199805130427.AAA00886@jekyll.piermont.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 12 May 1998 22:04:01 -0700 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk Ah yes, after being foiled in their "shareholder protection" class action suits filed after a stock drops and realizing that the y2k hype is likely to not engender much support in the courts these parasites are looking for a nice thick vein to suck dry. The tobacco industry is on the ropes for lying and witholding documents (but then so is the White House and the DNC so what's new, huh?) but look how many smoking-related suits have been sucessful against them. Frightfully few. Even for people who smoked before the Surgeon General's Warning! That's highly relevant. Stupidity on behalf of the buyer won't find much favor in a court I fear, but that probably won't stop the slime from filing suit. Ever heard of the "Tort Tax"? It's about 45% of the cost of a ladder; about 90% of the cost of children's medicine. It's a negligible amout of the cost of hardware and software but that may soon change. Dan. > By the way, the "cryptography" mailing list has been having an > interesting discussion of whether companies are liable for selling bad > crypto products or for relying upon them if they know that they are > bad. I'm forwarding one of the recent messages on the topic. The > entire discussion has been interesting thus far, although only some of > the participants have been lawyers. > > Relevance? Look no further than 40 bit DES. From owner-ipsec Wed May 13 03:50:14 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id DAA22253 for ipsec-outgoing; Wed, 13 May 1998 03:48:31 -0400 (EDT) Message-Id: <199805130803.MAA24304@relay2.elvis.ru> Comments: Authenticated sender is From: "Valery Smyslov" Organization: Elvis+ To: ipsec@tis.com Date: Wed, 13 May 1998 12:03:01 +3 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: Some questions In-reply-to: <199805121551.IAA11145@greatdane.cisco.com> References: Your message of "Tue, 12 May 1998 19:19:18." <199805121519.TAA09346@relay2.elvis.ru> X-mailer: Pegasus Mail for Win32 (v2.52) Sender: owner-ipsec@ex.tis.com Precedence: bulk On 12 May 98 at 8:51, Daniel Harkins wrote: > Privyet Valery, Hi Dan, thank you for your answers. You seem to know russian :-) > > ISAKMP, for example, using DES in one direction and IDEA in the > > other, that might be useful under some circumstances. > > Yes, that's right, they must use the same transform. Under what situations > would you want to have asymmetrical SAs? In case of asymmetrical path or when you know for sure, that information, flowing in one direction, is much more important than in the other. Note, that not only transform, but entire protection suit (e.g. - SA bungle) must be the same in both directions. So, you cannot use, for example, transport mode in one direction and tunnel in the other. Note also, that IPsec itself doesn't impose such limitation (one can create asymmetrical SAs manually), it is ISAKMP/IKE that does it. Anyway, I don't think it is important for the most of cases in real life, but there can be a few very special cases when this lack of flexibility of ISAKMP/IKE may be undesirable. It's possible just not to pay attention for such cases... > > 2. Regarding previous question: when protection suite (e.g. sequence > > of SAs) is negotiated, what should be the order of appliance of those > > SAs when processing an outgoing packet? Should it be the same as the > > order in which their proposals appear in the ISAKMP SA Payload? It is > > very natural, but it seems that IPsec drafts doesn't state this > > explicitly. > > For situations where you negotiate AH and ESP you apply ESP first. Well, let's imagine situation when responder receives SA payload that proposes protection suite containing AH and ESP both in transport mode in the order (I mean order of Proposal payloads) AH, ESP. What should it do? Should it reject this suite or accept it, but apply SAs in correct order: ESP, AH (assuming, that peer will do the same, because the other order is prohibited)? > Applying multiple AH or multiple ESP transforms to a single packet is not > defined. Sorry, but it is defined if you use tunnel mode (Architecture document, section 4.3, first case of iterated tunnelling), although marked as "unlikely to be used". But this case isn't prohibited. Moreover, the order of applying SAs (first ESP, then AH) is defined only for transport mode SA bundles (as far, as I understand). Tunnel mode SAs can be applied in any order, so, my second question is still valid > Dan. Thanks, Valery Smyslov. From owner-ipsec Wed May 13 07:35:45 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA22940 for ipsec-outgoing; Wed, 13 May 1998 07:33:33 -0400 (EDT) Message-Id: <199805131148.NAA16539@brussels.cisco.com> X-Sender: evyncke@brussels.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Wed, 13 May 1998 13:39:58 +0200 To: perry@piermont.com, jim@mentat.com (Jim Gillogly) From: Eric Vyncke Subject: Re: 40bit DES? Cc: chk@utcc.utoronto.ca, rgm-sec@htt-consult.com, ipsec@tis.com In-Reply-To: <199805122008.QAA29229@jekyll.piermont.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk I'm an European guy working for an American company :-) and I have talked with dozens of organizations on this topic. May I just add my few 0.01 EUR to the discussion ? 1) There *are* countries which forbid to use of 40+ encryption (France is the most known!). This is a local issue only and has nothing to do with US. 2) There *are* applications which are secured enough with a 40-bit encryption (think about grammar school, small/medium business with nearly no industrial secret, ...). 1) + 2) makes the standardization of 40-bit ESP mandatory. period. AFAIK (but it is not my domain) string D-H groups and long RSA/DSS keys for signatures are usually not restricted. The rest is just bla-bla... And this bla-bla is probably good news, if the list members have time to spent on this thread, this means that the standards, products, ... are mostly available ;-) Just my 0.01 EUR -eric PS: do not take my e-mail message as it is not. If someone ever presented 40-bit encryption as secure enough for *any* application, I would call his/her statement like a lie... At 16:08 12/05/98 -0400, Perry E. Metzger wrote: > >Jim Gillogly writes: >> > >> there seems to be 3 things needed for 'US exportable' IPsec: >> > >> >> > >> A 40bit DES ESP algorithm > >> Tell me again why we want it? We already have the NULL ESP algorithm, >> which provides a proof of concept of the framework without providing >> security. Another such algorithm would seem to be overkill. >> >> Again -- our job is to provide a technical spec to allow people to >> communicate securely. If we compromise it so that the lowest common >> denominator is insecure, we're wasting our time. > >Indeed, DES with 56 bits isn't secure. With 40 bits, you are wasting >the time of your customers. I've said it before and I'll say it again >-- selling 40 bit cryptography to your customers, even if they ask it, >is like selling patent medicine to a cancer patient -- its more or >less fraud. Even IBM doesn't pretend CDMF provides any security at >all -- thus the name. > >If the U.S. congress wants to hand your customers over to SSH and >other overseas companies selling crypto software, complain to >Congress, not the IETF. Anyone who wants to can buy compliant code, >and if they can't buy it from you because you are "locationally >challenged", that's between you and your congressman, and frankly, >most of the companies complaining have more than enough money to go >out and lobby. > >Perry > Eric Vyncke Technical Consultant Cisco Systems Belgium SA/NV Phone: +32-2-778.4677 Fax: +32-2-778.4300 E-mail: evyncke@cisco.com Mobile: +32-75-312.458 From owner-ipsec Wed May 13 07:57:12 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA22988 for ipsec-outgoing; Wed, 13 May 1998 07:56:31 -0400 (EDT) Message-Id: <3.0.5.32.19980513080806.009826e0@homebase.htt-consult.com> X-Sender: rgm-sec@homebase.htt-consult.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Wed, 13 May 1998 08:08:06 -0400 To: "Perry E. Metzger" , ipsec@tis.com From: Robert Moskowitz Subject: Re: liability for selling bad crypto? In-Reply-To: <199805130427.AAA00886@jekyll.piermont.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 12:27 AM 5/13/98 -0400, Perry E. Metzger wrote: Perry, a product could easily bury 40bit DES configure option for domestic use. Most companies, today, can get export license for decent crypto without key recovery for their overseas operations (unless it is located in France, then it is an IMPORT restriction). So the issue is those poor non-US companies that insist on using US products and cross-boarder connections with US products (instead of mix operating environment). So what you detail here is important for those of us fighting the crypto battle in DC, but can be avoided with due dilligence in product development. >By the way, the "cryptography" mailing list has been having an >interesting discussion of whether companies are liable for selling bad >crypto products or for relying upon them if they know that they are >bad. I'm forwarding one of the recent messages on the topic. The >entire discussion has been interesting thus far, although only some of >the participants have been lawyers. > Robert Moskowitz ICSA Security Interest EMail: rgm-sec@htt-consult.com From owner-ipsec Wed May 13 08:34:20 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA23208 for ipsec-outgoing; Wed, 13 May 1998 08:33:31 -0400 (EDT) X-Authentication-Warning: keeks.ioc.ee: helger owned process doing -bs Date: Wed, 13 May 1998 01:50:05 +0300 (EET DST) From: Helger Lipmaa X-Sender: helger@keeks To: ipsec@tis.com Subject: Re: 40bit DES? In-Reply-To: <199805122121.RAA29440@jekyll.piermont.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk On Tue, 12 May 1998, Perry E. Metzger wrote: > 40 bit DES *is* having no encryption. Its got only one legitimate > function -- it will slow your computer down. What's the point? Correct. If you need something that is better than plain text but doesn't give a real encryption, why not use ROT13? 40-bit DES is as slow as 56-bit DES, that is, not very productive. At the same thime, it will be very easily to be broken by any hackers who ever _care_ to try. ROT13 is at least faster. > buy from a company like SSH Communcations Security Oy". The mere fact > that VENDORS are harmed by this doesn't harm CUSTOMERS. End users get > to buy from whom they want. I'm not from Finland and I've no family members there. But I can say, but no-one here buys any `made in US' security products. These actually cost here as much as they do in US. Why waste your money? Therefore, I even can't see any use from stripped down IPSEC to US vendors. And yes, 40-bit DES is not a goot for testing purposes either... It's implementation shouldn't differ very much from the 56-bit DES. It would give a good test-bed for young hackers, tho. :-) Of course, even down here in provincial Europe, SSH is not the only option :-). Helger Lipmaa http://home.cyber.ee/helger; Phone +372-6542422 From owner-ipsec Wed May 13 08:34:23 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA23207 for ipsec-outgoing; Wed, 13 May 1998 08:33:30 -0400 (EDT) X-Authentication-Warning: keeks.ioc.ee: helger owned process doing -bs Date: Wed, 13 May 1998 01:51:47 +0300 (EET DST) From: Helger Lipmaa X-Sender: helger@keeks To: ipsec@tis.com Subject: RE: 40bit DES? In-Reply-To: <319A1C5F94C8D11192DE00805FBBADDF0C20D3@exchange.timestep.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk On Tue, 12 May 1998, Roy Pereira wrote: > vote for making an interoperable protocol. There must be other ways to > get the US gov to changes its export laws. A revolution :-) Helger Lipmaa http://home.cyber.ee/helger; Phone +372-6542422 From owner-ipsec Wed May 13 08:51:30 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA23278 for ipsec-outgoing; Wed, 13 May 1998 08:50:34 -0400 (EDT) Message-Id: <199805131305.JAA18204@cichlid.raleigh.ibm.com> X-Authentication-Warning: cichlid.raleigh.ibm.com: Host localhost.raleigh.ibm.com [127.0.0.1] didn't use HELO protocol To: "Theodore Y. Ts'o" cc: Peter Curran , Karen Seo , ipsec@tis.com Subject: Re: Latest AH/ESP/Arch drafts and changes In-reply-to: Your message of "Mon, 11 May 1998 23:36:32 EDT." <199805120336.XAA25920@dcl.MIT.EDU> Date: Wed, 13 May 1998 09:05:11 -0400 From: Thomas Narten Sender: owner-ipsec@ex.tis.com Precedence: bulk "Theodore Y. Ts'o" writes: > Date: Mon, 11 May 1998 21:07:01 +0100 > From: Peter Curran > Bit disappointed to see that you did not tidy up the item concerning the > handling of IPv6 hop-limit when using tunnel-mode between two boxes, as > opposed to the case of forwarding into a tunnel. I think that the > discussion here and on the IPNG list agreed that the wording required > clarification to differentiate the cases. Is there a reason, or is it a > future task, or was it done anyway but not included in your abstract? > I at least didn't get the sense that there was consensus about what > specific wording changes could be made to make things more clear. I think one can argue that the text as written is not incorrect. However, given the confusion on this point, it might be a good idea to add a sentence to insure there is no misunderstanding. Specifically, for the text: 2. The TTL in the inner header is decremented by the encapsulator prior to forwarding and by the decapsulator if it forwards the packet. (The checksum changes when the TTL changes.) how about adding something like: Note: The decrementing of the TTL is one of the usual actions that takes place when forwarding a packet. Packets originating from the same node as the encapsulator do not have their TTLs decremented, as the sending node is originating the packet rather than forwarding it. Thomas From owner-ipsec Wed May 13 09:52:45 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA23432 for ipsec-outgoing; Wed, 13 May 1998 09:48:28 -0400 (EDT) Message-Id: <199805131402.KAA02876@jekyll.piermont.com> To: Daniel Harkins cc: "Perry E. Metzger" , ipsec@tis.com Subject: Re: liability for selling bad crypto? In-reply-to: Your message of "Tue, 12 May 1998 22:04:01 PDT." <199805130504.WAA06688@greatdane.cisco.com> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Wed, 13 May 1998 10:02:56 -0400 From: "Perry E. Metzger" Sender: owner-ipsec@ex.tis.com Precedence: bulk Daniel Harkins writes: > Ah yes, after being foiled in their "shareholder protection" class > action suits filed after a stock drops and realizing that the y2k hype > is likely to not engender much support in the courts these parasites > are looking for a nice thick vein to suck dry. More power to them. Any company selling 40 bit crypto deserves what it gets, good and hard. It is, as I've said, very close to fraud, if not actual fraud. Perry From owner-ipsec Wed May 13 10:14:25 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA23538 for ipsec-outgoing; Wed, 13 May 1998 10:13:31 -0400 (EDT) Message-Id: <199805131418.KAA14341@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;;;;@tis.com@tis.com;;; Cc: ipsec@tis.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-arch-sec-05.txt Date: Wed, 13 May 1998 10:18:50 -0400 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 : Security Architecture for the Internet Protocol Author(s) : S. Kent, R. Atkinson Filename : draft-ietf-ipsec-arch-sec-05.txt Pages : 66 Date : 12-May-98 This memo specifies the base architecture for IPsec compliant systems. The goal of the architecture is to provide various security services for traffic at the IP layer, in both the IPv4 and IPv6 environments. This document describes the goals of such systems, their components and how they fit together with each other and into the IP environment. It also describes the security services offered by the IPsec protocols, and how these services can be employed in the IP environment. This document does not address all aspects of IPsec architecture. Subsequent documents will address additional architectural details of a more advanced nature, e.g., use of IPsec in NAT environments and more complete support for IP multicast. The following fundamental components of the IPsec security architecture are discussed in terms of their underlying, required functionality. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-arch-sec-05.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipsec-arch-sec-05.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: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-arch-sec-05.txt". NOTE: The mail server at ietf.org 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@ietf.org" Content-Type: text/plain Content-ID: <19980512151742.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-arch-sec-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-arch-sec-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980512151742.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec Wed May 13 10:14:25 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA23537 for ipsec-outgoing; Wed, 13 May 1998 10:13:31 -0400 (EDT) Message-Id: <199805131418.KAA14305@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;;;;@tis.com@tis.com;;; Cc: ipsec@tis.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-esp-v2-05.txt Date: Wed, 13 May 1998 10:18:38 -0400 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 : IP Encapsulating Security Payload (ESP) Author(s) : S. Kent, R. Atkinson Filename : draft-ietf-ipsec-esp-v2-05.txt Pages : 22 Date : 12-May-98 The Encapsulating Security Payload (ESP) header is designed to provide a mix of security services in IPv4 and IPv6. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-esp-v2-05.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipsec-esp-v2-05.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: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-esp-v2-05.txt". NOTE: The mail server at ietf.org 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@ietf.org" Content-Type: text/plain Content-ID: <19980512150941.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-esp-v2-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-esp-v2-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980512150941.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec Wed May 13 10:14:26 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA23521 for ipsec-outgoing; Wed, 13 May 1998 10:12:30 -0400 (EDT) Message-Id: <199805131418.KAA14322@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;;;;;@tis.com;@tis.com;;;;;;;;; Cc: ipsec@tis.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-auth-header-06.txt Date: Wed, 13 May 1998 10:18:44 -0400 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 : IP Authentication Header Author(s) : S. Kent, R. Atkinson Filename : draft-ietf-ipsec-auth-header-06.txt Pages : 23 Date : 12-May-98 The IP Authentication Header (AH) is used to provide connectionless integrity and data origin authentication for IP datagrams (hereafter referred to as just 'authentication'), and to provide protection against replays. This latter, optional service may be selected, by the receiver, when a Security Association is established. (Although the default calls for the sender to increment the Sequence Number used for anti-replay, the service is effective only if the receiver checks the Sequence Number.) AH provides authentication for as much of the IP header as possible, as well as for upper level protocol data. However, some IP header fields may change in transit and the value of these fields, when the packet arrives at the receiver, may not be predictable by the sender. The values of such fields cannot be protected by AH. Thus the protection provided to the IP header by AH is somewhat piecemeal. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-auth-header-06.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipsec-auth-header-06.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: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-auth-header-06.txt". NOTE: The mail server at ietf.org 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@ietf.org" Content-Type: text/plain Content-ID: <19980512151315.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-auth-header-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-auth-header-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980512151315.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec Wed May 13 11:13:20 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA23748 for ipsec-outgoing; Wed, 13 May 1998 11:08:30 -0400 (EDT) Date: Wed, 13 May 1998 11:23:20 -0400 Message-Id: <199805131523.LAA11234@tonga.xedia.com> From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: rgm-sec@htt-consult.com Cc: ipsec@tis.com Subject: Re: 40bit DES? References: <9805122209.AA30010@ornavella.watson.ibm.com> <3.0.5.32.19980513000415.0096f700@homebase.htt-consult.com> X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-ipsec@ex.tis.com Precedence: bulk >>>>> "Robert" == Robert Moskowitz writes: Robert> At 06:09 PM 5/12/98 -0400, Ran Canetti wrote: >>> > there seems to be 3 things needed for 'US exportable' IPsec: > >>> > A 40bit DES ESP algorithm > A 40bit DES for IKE > A 512 modulus >>> for D-H > > All three items handled by one draft might be called: >>> >>> Only the first entry is required. You can leave the IKE >>> encryption and D-H moduli (and RSA key strengths) at their >>> normal, standard levels. >>> >> Very good point. Just to stress: the cryptographic strength of the >> algorithms in IKE has nothing to do with the strength of the data >> encryption. It only determines the level of confidence in the >> authenticity and secrecy of the agreed key (however long or short >> it chooses to be). No reason to weaken that. >> Robert> Actually there appears to be a reason. there are vendors Robert> have problems with getting export license for IKE, too Robert> strong. Perhaps the intent is to weaken the ISAKMP SA, so you can read the quick mode exchanges? Sounds like a good argument to turn on PFS. paul From owner-ipsec Wed May 13 11:28:30 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA23795 for ipsec-outgoing; Wed, 13 May 1998 11:27:30 -0400 (EDT) Message-Id: <3.0.5.32.19980513113543.009715b0@homebase.htt-consult.com> X-Sender: rgm-sec@homebase.htt-consult.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Wed, 13 May 1998 11:35:43 -0400 To: Paul Koning From: Robert Moskowitz Subject: Re: 40bit DES? Cc: ipsec@tis.com In-Reply-To: <199805131523.LAA11234@tonga.xedia.com> References: <9805122209.AA30010@ornavella.watson.ibm.com> <3.0.5.32.19980513000415.0096f700@homebase.htt-consult.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 11:23 AM 5/13/98 -0400, Paul Koning wrote: > >Perhaps the intent is to weaken the ISAKMP SA, so you can read the >quick mode exchanges? Sounds like a good argument to turn on PFS. Good for you! Yes we are dealing with a full security system here with lots of knobs that very few know how to turn. The policy makers will be unable to understand this and in the end will lose out. Unfortunately, the spooks know and if they educate the policy makers our job gets harder. Basically all of this 40bit discuss is mute. The IETF can say what it wants and the vendors will do what they believe will sell. I am much more concerned with any ill-conceived key recovery plan than a device that supports 40 bit DES. Robert Moskowitz ICSA Security Interest EMail: rgm-sec@htt-consult.com From owner-ipsec Wed May 13 11:43:10 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA23857 for ipsec-outgoing; Wed, 13 May 1998 11:42:31 -0400 (EDT) Message-ID: <6236E58EC451D1119E80006097040ED9446A30@lobester.rsa.com> From: Bob Baldwin To: "'perry@piermont.com'" , Roy Pereira Cc: jim@mentat.com, chk@utcc.utoronto.ca, rgm-sec@htt-consult.com, ipsec@tis.com Subject: RE: 40bit DES? & IBM Patents Date: Wed, 13 May 1998 08:55:46 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1460.8) Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk Let me tell you a cautionary tale about 40 bit DES and the IBM patent. The SET Protocol design committee agreed to add IBM's 40 bit DES (called CDMF) as a mandatory part of the SET protocol. IBM wrote a letter that said that the CDMF patent would be licensed in a non-discriminatory way for $10,000 plus a "MINOR" concession. This all seemed reasonable, so the committee made it a mandatory feature. What was the MINOR concession? Oh, that was simply to agree not to enforce any of your company's patents against any part of IBM worldwide, in exchange for using this one little patent from IBM. Does this seem fair? Any vendor implementing SET has to give up all of their patents that might be negotiated with IBM or any of its subsidiaries world wide in order to use just one IBM patent which covers a nice way to do weak crypto with existing DES hardware. Of course, if the vendor did not want to give up all of their intellectual property, an purchase amount (vastly larger than $10,000) could be negotiated with IBM. Well, of course RSA has some problems with this, but we got little sympathy, since everyone already hates RSA for its patents. That's fine. But then other vendors in the banking space noticed the problem, and vendors making set-top boxes noticed, and large corporations (think about a company that make washing machines, nuclear weapons, and Certificate Authorities), noticed that they would have to give up all of their patents (including their classified patents on ignition devices), just to use this IBM patent for weak cryptography. The deal began to look very sour. In the end, the SET vendors discovered that they were allowed to export SET implementations with 56 bit DES and that there was no need for 40 bit CDMF DES, so de facto, CDMF was removed from SET. I suggest that if IPSEC wants a weak crypto algorithm that they pick some algorithm other than CDMF DES. For example, the IETF already has paperwork allowing reasonable use of CAST, SAFER, and RC2 without any MINOR concessions. --Bob Baldwin RSA Data Security > -----Original Message----- > From: Perry E. Metzger [SMTP:perry@piermont.com] > Sent: Tuesday, May 12, 1998 3:27 PM > To: Roy Pereira > Cc: perry@piermont.com; jim@mentat.com; chk@utcc.utoronto.ca; > rgm-sec@htt-consult.com; ipsec@tis.com > Subject: Re: 40bit DES? > > > Roy Pereira writes: > > Actually it doesn't hurt my organization at all, since we are a Canadian > > corporation and we can export 56-bit DES without key-recovery to almost > > anywhere. I am just thinking about all those poor US companies that > > will not be able to export IPSec due to the US's export laws. > > They screwed up. They weren't smart enough to locate in Canada. Quit > trying to dumb down IPSec. You aren't doing your customers, or theirs, > a favor. It is better that they buy good crypto from you than > worthless crud from someone in the U.S. > > > I agree with you about the severity of the situation for American > > (and Canadian) organizations, but I disagree using US based IPSec > > companies as martyrs. > > You are so goddamn vendor-centric. What about the poor customers? > Don't you give a tinker's damn about them? They aren't trying to buy > something to slow down their machines -- they want to buy something > SECURE. > > > We have to ask ourselfs if we wish to use IPSec as a vehicle to change > > the US government's export laws, or do we wish to make a PROTOCOL. > > We want a SECURE PROTOCOL. > > I'm not trying to change anyone's policy. I'm trying to get SECURE > software in the hands of the users. If that means they have to buy > from Canada, so be it. We're doing no customer a favor by selling them > fraudulent fake crypto software. > > Perry From owner-ipsec Wed May 13 12:24:20 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA24014 for ipsec-outgoing; Wed, 13 May 1998 12:22:33 -0400 (EDT) Date: Wed, 13 May 1998 12:31:09 -0400 (EDT) From: Dave Mason Message-Id: <199805131631.MAA14867@rubicon.rv.tis.com> To: ipsec@tis.com Subject: RE: 40bit DES? Sender: owner-ipsec@ex.tis.com Precedence: bulk Instead of 40-bit DES how about just doing an XOR using SKEYID_d :) -dmason From owner-ipsec Wed May 13 12:41:07 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA24169 for ipsec-outgoing; Wed, 13 May 1998 12:40:35 -0400 (EDT) Message-ID: <319A1C5F94C8D11192DE00805FBBADDF0C22D0@exchange.timestep.com> From: Roy Pereira To: Dan Stromberg , ipsec@tis.com Subject: RE: 40bit DES? Date: Wed, 13 May 1998 12:42:41 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk > From: Dan Stromberg [mailto:strombrg@hydra.acs.uci.edu] > > How about making Cryptographically Challenged IPSEC an unrequired > option, kind of like SKIP? I would hope that this discussion is about making 40bit DES a MAY and not a MUST. While I can see the need for it, I wouldn't want to be forced to support it. If an internet draft comes out detailing 40bit DES for ESP, then it would be up to the individual company to support it or not. Just like supporting 40bit RC5 or 40 bit CAST. SKIP? What the hell does that have to do with IPSec? ;-) (It was actually quite amusing to see last week's press release from Sun about how SKIP is the predominant KMP in the Internet) From owner-ipsec Wed May 13 12:47:56 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA24224 for ipsec-outgoing; Wed, 13 May 1998 12:47:40 -0400 (EDT) Message-Id: <199805131702.LAA14714@grissel.Compatible.COM> Comments: Authenticated sender is From: "Steve Goldhaber" To: Roy Pereira Date: Wed, 13 May 1998 11:02:32 -0700 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: RE: 40bit DES? Reply-to: goldy@compatible.com CC: ipsec@tis.com In-reply-to: <319A1C5F94C8D11192DE00805FBBADDF0C20A3@exchange.timestep.com> X-mailer: Pegasus Mail for Win32 (v2.54) Sender: owner-ipsec@ex.tis.com Precedence: bulk > From: Roy Pereira > To: perry@piermont.com, jim@mentat.com > Cc: chk@utcc.utoronto.ca, rgm-sec@htt-consult.com, ipsec@tis.com > Subject: RE: 40bit DES? > Date: Tue, 12 May 1998 16:56:14 -0400 > blah, blah, blah..... Regardless of what your opinion is, in the real > world we are forced with export issues. Sure 40-bit DES isn't secure, > but it sure is a lot better than no encryption or not having any sales? > Its time to move from the theoretical to the practical. I can dream of > a day when we all live together in harmony with world peace, but reality > dictates something else, doesn't it? Speaking of the real world, have you checked out the current export controls (http://www.bxa.doc.gov/encstart.htm) lately? They don't say anything about being able to export 40-bit DES. When the controls transferred from the State Department to the Commerce Department, things actually got worse. The only current algorithm for which you may obtain an export license is 40-bit RC4. To export anything stronger, you must agree to implement key recovery and jump through a bunch of paperwork hoops to get interim approval for 56-bit DES. Otherwise, you may *not* export *any* encryption software (usual caveats for authentication and passwords, etc) which has a user-definable key. Even ROT-X where X is a user-definable number is out. So why the discussion of 40-bit DES? Steve Goldhaber Compatible Systems goldy@compatible.com http://www.compatible.com (303) 444-9532 From owner-ipsec Wed May 13 13:16:02 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA24332 for ipsec-outgoing; Wed, 13 May 1998 13:15:35 -0400 (EDT) Date: Wed, 13 May 1998 12:30:46 -0500 (CDT) Message-Id: <199805131730.MAA21862@hosaka.smallworks.com> From: Jim Thompson To: rpereira@TimeStep.com CC: strombrg@hydra.acs.uci.edu, ipsec@tis.com In-reply-to: <319A1C5F94C8D11192DE00805FBBADDF0C22D0@exchange.timestep.com> (message from Roy Pereira on Wed, 13 May 1998 12:42:41 -0400) Subject: Re: 40bit DES? References: <319A1C5F94C8D11192DE00805FBBADDF0C22D0@exchange.timestep.com> Sender: owner-ipsec@ex.tis.com Precedence: bulk (It was actually quite amusing to see last week's press release from Sun about how SKIP is the predominant KMP in the Internet) Given that a (crippled) version of SKIP ships with every copy of Solaris, there is probably a helluva lot more SKIP than IKE in the world. -- 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 Wed May 13 13:49:54 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA24438 for ipsec-outgoing; Wed, 13 May 1998 13:48:36 -0400 (EDT) Message-Id: <199805131801.OAA03435@jekyll.piermont.com> To: Eric Vyncke cc: perry@piermont.com, jim@mentat.com (Jim Gillogly), chk@utcc.utoronto.ca, rgm-sec@htt-consult.com, ipsec@tis.com Subject: Re: 40bit DES? In-reply-to: Your message of "Wed, 13 May 1998 13:39:58 +0200." <199805131148.NAA16539@brussels.cisco.com> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Wed, 13 May 1998 14:01:03 -0400 From: "Perry E. Metzger" Sender: owner-ipsec@ex.tis.com Precedence: bulk Eric Vyncke writes: > I'm an European guy working for an American company :-) > and I have talked with dozens of organizations on this topic. > > May I just add my few 0.01 EUR to the discussion ? > > 1) There *are* countries which forbid to use of 40+ encryption > (France is the most known!). This is a local issue only and > has nothing to do with US. Then, why use any encryption at all? If you need latency added to your application, then use a timer function. > 2) There *are* applications which are secured enough with a > 40-bit encryption (think about grammar school, small/medium > business with nearly no industrial secret, ...). If it is worth spending the CPU cycles that ISAKMP takes and then that the DES algorithm is going to take, then it is worth encrypting right. Otherwise, why add the delay and expense? If you aren't going to add security, why go through the whole ISAKMP rigamarole? > 1) + 2) makes the standardization of 40-bit ESP mandatory. period. Since 1) and 2) are useless, you haven't made any case here. People still seem to have this delusion that 40 bits is somehow better than nothing. It is WORSE than nothing. It provides no security, but costs money. It gives you an illusion at the expense of heavy CPU utilization. If you really need latency added, why not just put in delay loops? > PS: do not take my e-mail message as it is not. If someone > ever presented 40-bit encryption as secure enough for *any* > application, I would call his/her statement like a lie... If it isn't adding security, why is it worth an engineer's time to write, a salesman's time to sell, and a customer's money to buy? Perry From owner-ipsec Wed May 13 13:50:40 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA24460 for ipsec-outgoing; Wed, 13 May 1998 13:50:35 -0400 (EDT) Date: Wed, 13 May 1998 14:03:05 -0400 Message-Id: <199805131803.OAA11444@tonga.xedia.com> From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: rgm-sec@htt-consult.com Cc: ipsec@tis.com Subject: Re: 40bit DES? References: <3.0.5.32.19980512130839.00a14500@homebase.htt-consult.com> X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-ipsec@ex.tis.com Precedence: bulk >>>>> "Robert" == Robert Moskowitz writes: Robert> Does the following draft supply the basis for 40bit DES for Robert> IPsec? draft-hoffman-des40-02.txt Robert> there seems to be 3 things needed for 'US exportable' IPsec: Robert> A 40bit DES ESP algorithm A 40bit DES for IKE A 512 modulus Robert> for D-H Robert> All three items handled by one draft might be called: Robert> 'Dumbed down cryptography for IPsec' Robert> or Robert> 'USDOJ approved IPsec" Robert> Nah scratch the latter. Not nice. ...but accurate... I was going to suggest "FBI-approved IPsec". paul From owner-ipsec Wed May 13 13:53:41 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA24503 for ipsec-outgoing; Wed, 13 May 1998 13:53:35 -0400 (EDT) Date: Wed, 13 May 1998 14:07:43 -0400 Message-Id: <199805131807.OAA11448@tonga.xedia.com> From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: baldwin@RSA.COM Cc: ipsec@tis.com Subject: RE: 40bit DES? & IBM Patents References: <6236E58EC451D1119E80006097040ED9446A30@lobester.rsa.com> X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-ipsec@ex.tis.com Precedence: bulk >>>>> "Bob" == Bob Baldwin writes: Bob> .... I suggest that if IPSEC wants a weak crypto Bob> algorithm that they pick some algorithm other than CDMF DES. Bob> For example, the IETF already has paperwork allowing reasonable Bob> use of CAST, SAFER, and RC2 without any MINOR concessions. One good reason for pursuing such a suggestion apart from the ones Bob quoted is performance. As everyone knows, DES40 is just as slow as real DES. A bit of research would be in order, but it may well be that other 40-bit capable cryptosystems are substantially faster and would be preferable. (I'm thinking of software crypto in particular, where performance is most likely to be an issue -- it's well known that DES is pessimized for software implementation...) paul From owner-ipsec Wed May 13 14:06:01 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA24617 for ipsec-outgoing; Wed, 13 May 1998 14:05:37 -0400 (EDT) Message-ID: <319A1C5F94C8D11192DE00805FBBADDF0C234B@exchange.timestep.com> From: Roy Pereira To: "IPSEC Mailing List (E-mail)" Subject: FW: New Encryption Export Bill Aims To Ease Controls Date: Wed, 13 May 1998 14:07:36 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk On the current topic....... > New Encryption Export Bill Aims To Ease Controls > ( 5/13/98; 10:00 AM EST) > By Charlotte Dunlap, Computer Reseller News > > Another bill has surfaced by senators trying to ease encryption export > controls. > The E Privacy Act sponsored by Sen. Patrick Leahy (D-Vt.) and Sen. > John Ashcroft (R-Mo.) would allow unlimited strengths of encryption > technology to be exported to countries that already offer that same > level of encryption. > Current U.S. legislation dictates that encryption export be limited to > 40-bit key lengths, and in some cases, 56-bit. Some vendors have slid > around that law by working out case-by-case arrangements with the > government, particularly where the higher-level encryption is used in > data-sensitive industries, such as financial. But for the most part, > it has been an uphill battle by industry vendors, such as RSA Data > Security and Certicom, which are beginning to lose business to foreign > competitors that can offer higher-level encryption to global > customers. > The task of integrating secured solutions, including encryption, has > not been easy for value-added resellers, either. > David Robinson, president of Digital Systems Management, in Lakeland, > Fla., told CRN Online he has had to use the technology of foreign > encryption vendors when his clients' foreign offices need encryption. > Other resellers have told of similar experiences. > The bill, announced Tuesday, along with Americans for Computer Privacy > aims to ban the requirement of "backdoors," or the use of key escrow. > Key escrow is a concept proposed by the government and refers to > including a back up key with the software, so instead of limiting the > strength of cryptography, its gives U.S. law enforcement agents a key > to access the software if they deem necessary. > But encryption vendors have objected to this method all along, saying > their foreign customers would never agree to such an arrangement. > "This doesn't make much sense at all for export," said Phil Deck, CEO > of Certicom, in Mississauga, Ontario, of key escrow. > "The objectives of this bill sound really great, protecting the > Constitution and all that," he added. "Encryption technology is > available in a lot of countries, and it's been a problem for North > American companies when they're competing with domestic technology and > they can't export [it] themselves." > He added that the passing of this bill would "spur a fair amount of > revenue growth for U.S. companies." > From owner-ipsec Wed May 13 14:28:23 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA24807 for ipsec-outgoing; Wed, 13 May 1998 14:27:41 -0400 (EDT) Message-Id: <3.0.5.32.19980513143848.00972100@homebase.htt-consult.com> X-Sender: rgm-sec@homebase.htt-consult.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Wed, 13 May 1998 14:38:48 -0400 To: Dave Mason , ipsec@tis.com From: Robert Moskowitz Subject: RE: 40bit DES? In-Reply-To: <199805131631.MAA14867@rubicon.rv.tis.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 12:31 PM 5/13/98 -0400, Dave Mason wrote: >Instead of 40-bit DES how about just doing an XOR using SKEYID_d :) I will again point out that we have 40 bit RC4 and CAST. If all people want is a weak cypher we have it already. And faster than 40bit DES without the IBM patent. No people want 40Bit DES. They have been conditioned for it. If someone doesn't give it, there will be massive withdrawl attacks all over the world, and somewhere someone will wise up and rule that all crypto is BAD. ERGO: Let it be. Someone will cut the necessary IDs. Our illustrious ADs will get wording to let the RFC readers know the score. Robert Moskowitz ICSA Security Interest EMail: rgm-sec@htt-consult.com From owner-ipsec Wed May 13 15:16:33 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA25086 for ipsec-outgoing; Wed, 13 May 1998 15:13:38 -0400 (EDT) Date: Wed, 13 May 1998 15:27:59 -0400 Message-Id: <199805131927.PAA26583@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: Thomas Narten Cc: "Theodore Y. Ts'o" , Peter Curran , Karen Seo , jis@MIT.EDU, ipsec@tis.com In-Reply-To: Thomas Narten's message of Wed, 13 May 1998 09:05:11 -0400, <199805131305.JAA18204@cichlid.raleigh.ibm.com> Subject: Re: Latest AH/ESP/Arch drafts and changes Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: owner-ipsec@ex.tis.com Precedence: bulk Thomas, I was instructed by Jeff Schiller to ask the document editors to get their final changes into the Secretariat by yesterday, so to make sure that by Thursday, the final I-D's would all be published. This way, should the IESG decide that they want to redo the ballot (given that we made a few more changes than were originally formally agreed by the full IESG --- for example, the IANA considerations text), the IESG will have had the final set of changes in front of them for the full week before the next IESG meeting. Now, I'm not sure whether another IESG vote is actually going to be taken, but my sense was that Jeff didn't want there to be any chance that the IPSEC documents would be further delayed caused by procedure-based objections by any IESG member who might be sticklers about fine points of procedure. It wouldn't be hard to make this change, but it will require submitting yet publishing yet another version of the I-D, and said I-D wouldn't be in front of IESG members for the full requisite week should another vote be necessary. Question: is this important enough for us to add this clarifying text now, or can we batch this change until the IPSEC specifications get revised for elevation to Draft standard? - Ted From owner-ipsec Wed May 13 15:28:58 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA25122 for ipsec-outgoing; Wed, 13 May 1998 15:28:39 -0400 (EDT) Date: Wed, 13 May 1998 15:41:27 -0400 Message-Id: <199805131941.PAA26616@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: Bob Baldwin Cc: "'perry@piermont.com'" , Roy Pereira , jim@mentat.com, chk@utcc.utoronto.ca, rgm-sec@htt-consult.com, ipsec@tis.com In-Reply-To: Bob Baldwin's message of Wed, 13 May 1998 08:55:46 -0700, <6236E58EC451D1119E80006097040ED9446A30@lobester.rsa.com> Subject: Re: 40bit DES? & IBM Patents Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: owner-ipsec@ex.tis.com Precedence: bulk From: Bob Baldwin Date: Wed, 13 May 1998 08:55:46 -0700 Let me tell you a cautionary tale about 40 bit DES and the IBM patent. The SET Protocol design committee agreed to add IBM's 40 bit DES (called CDMF) as a mandatory part of the SET protocol. IBM wrote a letter that said that the CDMF patent would be licensed in a non-discriminatory way for $10,000 plus a "MINOR" concession. This all seemed reasonable, so the committee made it a mandatory feature. What was the MINOR concession? Oh, that was simply to agree not to enforce any of your company's patents against any part of IBM worldwide, in exchange for using this one little patent from IBM. Does this seem fair? On the other hand, it's fairly common for a company to grant a no-cost license to use a patent for protocol XYZZY to require that other companies must grant a no-cost license to that company if other patents turn out to be necessary to implement protocol XYZZY. This has generally to be considered a good thing. That being said, there are other ways of doing 40-bit DES without using CDMF that aren't patented, and while I dislike 40-bit crypto, patent problems are really a legitmate excuse not to use 40-bit crypto. (Someone should have done a favor and patented the concept of using 40-bit crypto, just as Apple patented the concept of using reusable one-time pads. :-) Furthermore, no one has suggested using CDMF, so any further discussion about patent licensing issues would not seem to be related to the work of the ipsec wg. - Ted From owner-ipsec Wed May 13 15:55:21 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA25200 for ipsec-outgoing; Wed, 13 May 1998 15:54:38 -0400 (EDT) X-Authentication-Warning: keeks.ioc.ee: helger owned process doing -bs Date: Wed, 13 May 1998 23:18:18 +0300 (EET DST) From: Helger Lipmaa X-Sender: helger@keeks To: Robert Moskowitz cc: Dave Mason , ipsec@tis.com Subject: RE: 40bit DES? In-Reply-To: <3.0.5.32.19980513143848.00972100@homebase.htt-consult.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk On Wed, 13 May 1998, Robert Moskowitz wrote: > No people want 40Bit DES. They have been conditioned for it. If someone > doesn't give it, there will be massive withdrawl attacks all over the > world, and somewhere someone will wise up and rule that all crypto is BAD. In the Soviet Union, all the intelligentsia was thought to be bad 50 years ago. In some countries they are thought to be bad even now. Should we therefore resign? Should the IKE and the algorithms made be weaker just because the public opinion or some wicked governments? This is not a part of our mission. Some of my colleagues have worked hard for our covernment not to restrict crypto in any manner. They succeeded. It should give you an excellent paragon: we should not surrender to the opinions of simple in such questions. Helger Lipmaa Cybernetica Ltd, senior research engineer http://home.cyber.ee/helger; Phone +372-6542422 From owner-ipsec Wed May 13 16:00:48 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA25231 for ipsec-outgoing; Wed, 13 May 1998 16:00:39 -0400 (EDT) Message-Id: <199805132014.QAA03843@jekyll.piermont.com> To: Paul Koning cc: rgm-sec@htt-consult.com, ipsec@tis.com Subject: Re: 40bit DES? In-reply-to: Your message of "Wed, 13 May 1998 14:03:05 EDT." <199805131803.OAA11444@tonga.xedia.com> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Wed, 13 May 1998 16:14:47 -0400 From: "Perry E. Metzger" Sender: owner-ipsec@ex.tis.com Precedence: bulk Paul Koning writes: > Robert> 'USDOJ approved IPsec" > > Robert> Nah scratch the latter. Not nice. > > ...but accurate... > > I was going to suggest "FBI-approved IPsec". "FBI ``Job Security'' IPsec. The strongest security J. Edgar Hoover would want you to have." From owner-ipsec Wed May 13 16:14:11 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA25391 for ipsec-outgoing; Wed, 13 May 1998 16:13:41 -0400 (EDT) Message-Id: <3.0.5.32.19980513162703.0096c650@homebase.htt-consult.com> X-Sender: rgm-sec@homebase.htt-consult.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Wed, 13 May 1998 16:27:03 -0400 To: Helger Lipmaa From: Robert Moskowitz Subject: RE: 40bit DES? Cc: Dave Mason , ipsec@tis.com In-Reply-To: References: <3.0.5.32.19980513143848.00972100@homebase.htt-consult.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 11:18 PM 5/13/98 +0300, Helger Lipmaa wrote: >On Wed, 13 May 1998, Robert Moskowitz wrote: > >> No people want 40Bit DES. They have been conditioned for it. If someone >> doesn't give it, there will be massive withdrawl attacks all over the >> world, and somewhere someone will wise up and rule that all crypto is BAD. > >In the Soviet Union, all the intelligentsia was thought to be bad 50 years >ago. In some countries they are thought to be bad even now. Should we >therefore resign? Should the IKE and the algorithms made be weaker just >because the public opinion or some wicked governments? This is not a part >of our mission. Some of my colleagues have worked hard for our covernment >not to restrict crypto in any manner. They succeeded. It should give you >an excellent paragon: we should not surrender to the opinions of simple >in such questions. > Nice view of the problem, but the question is adding 40bDES to the other 8 cryptos, not taking anything away. This is really the process of assigning a DOI # for the crypto instead of having some vendor forum going off and using one of the private #s. Like I said, this is over for this list for now. I brought it up only as there was an ID on 40bDES. now lets go back to what we were doing... Robert Moskowitz ICSA Security Interest EMail: rgm-sec@htt-consult.com From owner-ipsec Wed May 13 16:29:40 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA25800 for ipsec-outgoing; Wed, 13 May 1998 16:28:42 -0400 (EDT) Message-Id: <199805131418.KAA14305@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; Cc: ipsec@tis.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-esp-v2-05.txt Date: Wed, 13 May 1998 10:18:38 -0400 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 : IP Encapsulating Security Payload (ESP) Author(s) : S. Kent, R. Atkinson Filename : draft-ietf-ipsec-esp-v2-05.txt Pages : 22 Date : 12-May-98 The Encapsulating Security Payload (ESP) header is designed to provide a mix of security services in IPv4 and IPv6. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-esp-v2-05.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipsec-esp-v2-05.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: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-esp-v2-05.txt". NOTE: The mail server at ietf.org 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@ietf.org" Content-Type: text/plain Content-ID: <19980512150941.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-esp-v2-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-esp-v2-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980512150941.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec Wed May 13 16:29:41 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA25794 for ipsec-outgoing; Wed, 13 May 1998 16:28:40 -0400 (EDT) Message-Id: <199805131418.KAA14322@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; Cc: ipsec@tis.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-auth-header-06.txt Date: Wed, 13 May 1998 10:18:44 -0400 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 : IP Authentication Header Author(s) : S. Kent, R. Atkinson Filename : draft-ietf-ipsec-auth-header-06.txt Pages : 23 Date : 12-May-98 The IP Authentication Header (AH) is used to provide connectionless integrity and data origin authentication for IP datagrams (hereafter referred to as just 'authentication'), and to provide protection against replays. This latter, optional service may be selected, by the receiver, when a Security Association is established. (Although the default calls for the sender to increment the Sequence Number used for anti-replay, the service is effective only if the receiver checks the Sequence Number.) AH provides authentication for as much of the IP header as possible, as well as for upper level protocol data. However, some IP header fields may change in transit and the value of these fields, when the packet arrives at the receiver, may not be predictable by the sender. The values of such fields cannot be protected by AH. Thus the protection provided to the IP header by AH is somewhat piecemeal. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-auth-header-06.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipsec-auth-header-06.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: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-auth-header-06.txt". NOTE: The mail server at ietf.org 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@ietf.org" Content-Type: text/plain Content-ID: <19980512151315.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-auth-header-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-auth-header-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980512151315.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec Wed May 13 16:29:45 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA25799 for ipsec-outgoing; Wed, 13 May 1998 16:28:41 -0400 (EDT) Message-Id: <199805131418.KAA14341@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; Cc: ipsec@tis.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-arch-sec-05.txt Date: Wed, 13 May 1998 10:18:50 -0400 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 : Security Architecture for the Internet Protocol Author(s) : S. Kent, R. Atkinson Filename : draft-ietf-ipsec-arch-sec-05.txt Pages : 66 Date : 12-May-98 This memo specifies the base architecture for IPsec compliant systems. The goal of the architecture is to provide various security services for traffic at the IP layer, in both the IPv4 and IPv6 environments. This document describes the goals of such systems, their components and how they fit together with each other and into the IP environment. It also describes the security services offered by the IPsec protocols, and how these services can be employed in the IP environment. This document does not address all aspects of IPsec architecture. Subsequent documents will address additional architectural details of a more advanced nature, e.g., use of IPsec in NAT environments and more complete support for IP multicast. The following fundamental components of the IPsec security architecture are discussed in terms of their underlying, required functionality. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-arch-sec-05.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipsec-arch-sec-05.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: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-arch-sec-05.txt". NOTE: The mail server at ietf.org 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@ietf.org" Content-Type: text/plain Content-ID: <19980512151742.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-arch-sec-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-arch-sec-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980512151742.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec Wed May 13 17:26:45 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA26003 for ipsec-outgoing; Wed, 13 May 1998 17:25:38 -0400 (EDT) Message-ID: <355A140F.6C4B8AE8@newoak.com> Date: Wed, 13 May 1998 17:43:43 -0400 From: johara@newoak.com (John O'Hara) X-Mailer: Mozilla 4.02 [en] (WinNT; I) MIME-Version: 1.0 To: "Theodore Y. Ts'o" CC: ipsec@tis.com Subject: Re: 40bit DES? & IBM Patents References: <199805131941.PAA26616@dcl.MIT.EDU> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk and further I believe the draft: draft-hoffman-des40-02.txt is NOT using CDMF.... so the whole thread about the IBM patents is kind of moot. John Theodore Y. Ts'o wrote: > > From: Bob Baldwin > Date: Wed, 13 May 1998 08:55:46 -0700 > > Let me tell you a cautionary tale about 40 bit DES > and the IBM patent. The SET Protocol design committee > agreed to add IBM's 40 bit DES (called CDMF) as a mandatory > part of the SET protocol. IBM wrote a letter that said that > the CDMF patent would be licensed in a non-discriminatory > way for $10,000 plus a "MINOR" concession. This all seemed > reasonable, so the committee made it a mandatory feature. > What was the MINOR concession? Oh, that was simply to > agree not to enforce any of your company's patents against > any part of IBM worldwide, in exchange for using this one > little patent from IBM. Does this seem fair? > > On the other hand, it's fairly common for a company to grant a no-cost > license to use a patent for protocol XYZZY to require that other > companies must grant a no-cost license to that company if other patents > turn out to be necessary to implement protocol XYZZY. This has > generally to be considered a good thing. > > That being said, there are other ways of doing 40-bit DES without using > CDMF that aren't patented, and while I dislike 40-bit crypto, patent > problems are really a legitmate excuse not to use 40-bit crypto. > (Someone should have done a favor and patented the concept of using > 40-bit crypto, just as Apple patented the concept of using reusable > one-time pads. :-) > > Furthermore, no one has suggested using CDMF, so any further discussion > about patent licensing issues would not seem to be related to the work > of the ipsec wg. > > - Ted From owner-ipsec Wed May 13 17:33:58 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA26025 for ipsec-outgoing; Wed, 13 May 1998 17:31:38 -0400 (EDT) Message-Id: <199805132149.WAA28568@gate.ticl.co.uk> X-Sender: peter@gate (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Wed, 13 May 1998 22:47:02 +0100 To: Karen Seo From: Peter Curran Subject: Re: Latest AH/ESP/Arch drafts and changes Cc: ipsec@tis.com, tytso@MIT.EDU, narten@raleigh.ibm.com In-Reply-To: <199805120446.FAA25536@gate.ticl.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk Karen Sorry about the slow response - I was out of the office for a day or so. At 00:39 12/05/98 -0400, Karen Seo wrote: >Hi Peter, > >I was under the impression that no change was to be made. In part, some >of the email seemed to be saying the current text was fine. Also, some >folks were saying that ND should *not* work across an IPsec tunnel (I >believe it was stated that ND should use transport mode). And the text >as is supports that. If we change the architecture to say that a system >which is both the source of a packet and the source end of a tunnel >should NOT decrement the TTL, then ND could still work across the IPsec >tunnel. > >Karen > I was about to write you a long explanation of why I thought that there was an issue here concerning the wording, not actually related to NDP et al. Basically, I think the text is ambiguous as it stands and requires clarification to bring it into line with the RFC2003 description of tunnelling: . When encapsulating a datagram, the TTL in the inner IP header is decremented by one if the tunneling is being done as part of forwarding the datagram; otherwise, the inner header TTL is not changed during encapsulation. If the resulting TTL in the inner IP header is 0, the datagram is discarded and an ICMP Time Exceeded message SHOULD be returned to the sender. An encapsulator MUST NOT encapsulate a datagram with TTL = 0. The TTL in the inner IP header is not changed when decapsulating. If, after decapsulation, the inner datagram has TTL = 0, the decapsulator MUST discard the datagram. If, after decapsulation, the decapsulator forwards the datagram to one of its network interfaces, it will decrement the TTL as a result of doing normal IP forwarding. However, later on in my mailbox I find this from Thomas Narten which seems to satisfy the situation well. >I think one can argue that the text as written is not incorrect. >However, given the confusion on this point, it might be a good idea to >add a sentence to insure there is no misunderstanding. Specifically, >for the text: > > 2. The TTL in the inner header is decremented by the > encapsulator prior to forwarding and by the decapsulator if > it forwards the packet. (The checksum changes when the TTL > changes.) > >how about adding something like: > > Note: The decrementing of the TTL is one of the usual > actions that takes place when forwarding a packet. Packets > originating from the same node as the encapsulator do not > have their TTLs decremented, as the sending node is > originating the packet rather than forwarding it. > >Thomas > Regards Peter Curran TICL From owner-ipsec Wed May 13 18:10:18 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA26125 for ipsec-outgoing; Wed, 13 May 1998 18:07:40 -0400 (EDT) Date: Wed, 13 May 1998 18:21:42 -0400 From: Ran Canetti Message-Id: <9805132221.AA30772@ornavella.watson.ibm.com> To: canetti@watson.ibm.com, chk@utcc.utoronto.ca, rgm-sec@htt-consult.com Subject: Re: 40bit DES? Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk > >Very good point. Just to stress: the cryptographic strength of the > >algorithms in IKE has nothing to do with the strength of the data > >encryption. It only determines the level of confidence in the > >authenticity and secrecy of the agreed key (however long or short it > >chooses to be). No reason to weaken that. > > > Actually there appears to be a reason. there are vendors have problems > with getting export license for IKE, too strong. > > Sigh. yes, i've heard. thats indeed too bad, and should be taken into account. my point was technical: from a cryptographic point of view there is no real reason to prohibit strong key-exchange, if the ESP then uses weak encryption. For instance, weak IKE will also, and unnecessarily so, result in weak AH... > > Keep in mind, that I am working as hard as possible to have as many > countries producing their own IPsec products. > > > Robert Moskowitz From owner-ipsec Thu May 14 00:33:07 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id AAA27110 for ipsec-outgoing; Thu, 14 May 1998 00:30:46 -0400 (EDT) Message-Id: <3.0.5.16.19980514004250.09674e3e@world.std.com> X-Sender: dpj@world.std.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (16) Date: Thu, 14 May 1998 00:42:50 -0400 To: perry@piermont.com, Daniel Harkins From: David Jablon Subject: Re: liability for selling bad crypto? Cc: "Perry E. Metzger" , ipsec@tis.com In-Reply-To: <199805131402.KAA02876@jekyll.piermont.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk Daniel Harkins wrote: >> Ah yes, after being foiled in their "shareholder protection" class >> action suits filed after a stock drops and realizing that the y2k hype >> is likely to not engender much support in the courts these parasites >> are looking for a nice thick vein to suck dry. At 10:02 AM 5/13/98 -0400, Perry E. Metzger wrote: >More power to them. Any company selling 40 bit crypto deserves what it >gets, good and hard. It is, as I've said, very close to fraud, if not >actual fraud. As far as liability is concerned, the court that seems to matter the most today is the court of public opinion. Protocols open to 40-bit (or easier) attack should be easy to discredit in the marketplace. But if not, then I I doubt they can be discredited in adversarial legal action. Curiously, this liability thread was inspired by a parallel discussion on cryptography@c2.net of weaknesses in PPTP, which uses RC4 with keys of indeterminate size. Like many challenge/response password systems, it uses password-derived session keys with often less than 40 bits of entropy. I can hear the defense already ... "So, I ask you, if challenge/response protocols are a standard accepted practice in the industry, isn't it just a wee bit fanatical to demand that all keys be larger than 40 bits?" ------------------------------------ David Jablon Integrity Sciences, Inc. dpj@world.std.com From owner-ipsec Thu May 14 10:22:21 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA29323 for ipsec-outgoing; Thu, 14 May 1998 10:17:50 -0400 (EDT) Message-Id: <199805141418.KAA11302@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; Cc: ipsec@tis.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-ipsec-doi-09.txt Date: Thu, 14 May 1998 10:18:59 -0400 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-09.txt Pages : 30 Date : 13-May-98 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, payloads, and processing guidelines that occur within a given Domain of Interpretation (DOI). This document defines the Internet IP Security DOI (IPSEC DOI), which instantiates ISAKMP for use with IP when IP uses ISAKMP to negotiate security associations. For a list of changes since the previous version of the IPSEC DOI, please see Section 7. Internet-Drafts are available by anonymous FTP. Login with 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-09.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipsec-ipsec-doi-09.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: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-ipsec-doi-09.txt". NOTE: The mail server at ietf.org 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@ietf.org" Content-Type: text/plain Content-ID: <19980513173134.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-ipsec-doi-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-ipsec-doi-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980513173134.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec Thu May 14 15:02:54 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA00767 for ipsec-outgoing; Thu, 14 May 1998 14:58:53 -0400 (EDT) Message-Id: In-Reply-To: <3558CA5B.8B6113CC@cosinecom.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 14 May 1998 15:06:17 -0400 To: Abraham R Matthews , ipsec@tis.com From: Stephen Kent Subject: Re: [Q] SA lookup on receive Sender: owner-ipsec@ex.tis.com Precedence: bulk Abraham, >When an ipsec packet is received, an SA is looked up using the >tuple . Must the dest-ip be a local ip >address of the security gateway? What if the dest-ip address is >the address of an internal host? Any SA involving a security gateway MUST be a tunnel mode SA, so the outer IP address will be that of the gateway, not of the internal (ultimate destination) host. The latter address will be in the inner IP header. Steve From owner-ipsec Thu May 14 17:40:41 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA01235 for ipsec-outgoing; Thu, 14 May 1998 17:38:05 -0400 (EDT) Message-Id: <199805142156.WAA00221@gate.ticl.co.uk> X-Sender: peter@gate (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Thu, 14 May 1998 22:53:20 +0100 To: "Theodore Y. Ts'o" From: Peter Curran Subject: Re: Latest AH/ESP/Arch drafts and changes Cc: Thomas Narten , "Theodore Y. Ts'o" , Karen Seo , jis@MIT.EDU, ipsec@tis.com In-Reply-To: <199805131927.PAA26583@dcl.MIT.EDU> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk Ted > Question: is this important enough for us to add this clarifying >text now, or can we batch this change until the IPSEC specifications get >revised for elevation to Draft standard? > IMHO, lets get this ball rolling and fix the problem next time round. Peter From owner-ipsec Thu May 14 23:10:30 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id XAA01947 for ipsec-outgoing; Thu, 14 May 1998 23:07:59 -0400 (EDT) Message-Id: <3.0.5.32.19980514055452.009d8c20@homebase.htt-consult.com> X-Sender: rgm-sec@homebase.htt-consult.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 14 May 1998 05:54:52 -0400 To: Bob Baldwin , ipsec@tis.com From: Robert Moskowitz Subject: RE: 40bit DES? & IBM Patents In-Reply-To: <6236E58EC451D1119E80006097040ED9446A30@lobester.rsa.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 08:55 AM 5/13/98 -0700, Bob Baldwin wrote: > Let me tell you a cautionary tale about 40 bit DES >and the IBM patent. The SET Protocol design committee >agreed to add IBM's 40 bit DES (called CDMF) as a mandatory >part of the SET protocol. IBM wrote a letter that said that >the CDMF patent would be licensed in a non-discriminatory >way for $10,000 plus a "MINOR" concession. This all seemed >reasonable, so the committee made it a mandatory feature. draft-hoffman-des40-02.txt does not use CDMF, and specifically states this at the end. I will ask the authors to add a statement (hopefully backed by IBM) that this method does not infringe on the CDMF patent, nor anyother published IPR. Robert Moskowitz ICSA Security Interest EMail: rgm-sec@htt-consult.com From owner-ipsec Fri May 15 16:24:01 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA05923 for ipsec-outgoing; Fri, 15 May 1998 16:18:50 -0400 (EDT) Message-ID: <000f01bd8040$4ca3afe0$9111e120@jetavs> From: "John Tavs" To: Subject: Re: 40bit DES? & IBM Patents Date: Fri, 15 May 1998 16:30:14 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-ipsec@ex.tis.com Precedence: bulk Let me attempt to clarify the situation here. 1) What is being described is not our standard conditions and internally called "Special Licensing" because it has unique terms. 2) Here's the actual wording "IBM will commit not to assert its CDMF patent ... against any party using it to implementthe MasterCard/Visa SET protocol. This commitment will continue as long as that Party does not assert its own patents against any IBM implementation of such protocol in an IBM product or service." In other words, since we gave away our rights here, we expect others not to make claims on us in doing this protocol. There is no reason RSA need fear that it nuclear weapon programs are exposed here or any other use of its patents towards other protocols. 3) Regarding IPSEC, our standards terms are in force and that means CDMF implementations would include a royalty. I have not pursued a special license for IPSEC, because I didn't think people were interested in 40 keys. -----Original Message----- From: Bob Baldwin To: 'perry@piermont.com' ; Roy Pereira Cc: jim@mentat.com ; chk@utcc.utoronto.ca ; rgm-sec@htt-consult.com ; ipsec@tis.com Date: Wednesday, May 13, 1998 1:19 PM Subject: RE: 40bit DES? & IBM Patents > Let me tell you a cautionary tale about 40 bit DES >and the IBM patent. The SET Protocol design committee >agreed to add IBM's 40 bit DES (called CDMF) as a mandatory >part of the SET protocol. IBM wrote a letter that said that >the CDMF patent would be licensed in a non-discriminatory >way for $10,000 plus a "MINOR" concession. This all seemed >reasonable, so the committee made it a mandatory feature. > What was the MINOR concession? Oh, that was simply to >agree not to enforce any of your company's patents against >any part of IBM worldwide, in exchange for using this one >little patent from IBM. Does this seem fair? Any vendor >implementing SET has to give up all of their patents that >might be negotiated with IBM or any of its subsidiaries >world wide in order to use just one IBM patent which covers >a nice way to do weak crypto with existing DES hardware. >Of course, if the vendor did not want to give up all of >their intellectual property, an purchase amount (vastly >larger than $10,000) could be negotiated with IBM. > Well, of course RSA has some problems with this, but >we got little sympathy, since everyone already hates RSA for >its patents. That's fine. But then other vendors in the >banking space noticed the problem, and vendors making set-top >boxes noticed, and large corporations (think about a company >that make washing machines, nuclear weapons, and Certificate >Authorities), noticed that they would have to give up all >of their patents (including their classified patents on >ignition devices), just to use this IBM patent for weak >cryptography. > The deal began to look very sour. In the end, the SET >vendors discovered that they were allowed to export SET >implementations with 56 bit DES and that there was no need >for 40 bit CDMF DES, so de facto, CDMF was removed from SET. > I suggest that if IPSEC wants a weak crypto algorithm >that they pick some algorithm other than CDMF DES. For >example, the IETF already has paperwork allowing reasonable >use of CAST, SAFER, and RC2 without any MINOR concessions. > --Bob Baldwin > RSA Data Security > >> -----Original Message----- >> From: Perry E. Metzger [SMTP:perry@piermont.com] >> Sent: Tuesday, May 12, 1998 3:27 PM >> To: Roy Pereira >> Cc: perry@piermont.com; jim@mentat.com; chk@utcc.utoronto.ca; >> rgm-sec@htt-consult.com; ipsec@tis.com >> Subject: Re: 40bit DES? >> >> >> Roy Pereira writes: >> > Actually it doesn't hurt my organization at all, since we are a Canadian >> > corporation and we can export 56-bit DES without key-recovery to almost >> > anywhere. I am just thinking about all those poor US companies that >> > will not be able to export IPSec due to the US's export laws. >> >> They screwed up. They weren't smart enough to locate in Canada. Quit >> trying to dumb down IPSec. You aren't doing your customers, or theirs, >> a favor. It is better that they buy good crypto from you than >> worthless crud from someone in the U.S. >> >> > I agree with you about the severity of the situation for American >> > (and Canadian) organizations, but I disagree using US based IPSec >> > companies as martyrs. >> >> You are so goddamn vendor-centric. What about the poor customers? >> Don't you give a tinker's damn about them? They aren't trying to buy >> something to slow down their machines -- they want to buy something >> SECURE. >> >> > We have to ask ourselfs if we wish to use IPSec as a vehicle to change >> > the US government's export laws, or do we wish to make a PROTOCOL. >> >> We want a SECURE PROTOCOL. >> >> I'm not trying to change anyone's policy. I'm trying to get SECURE >> software in the hands of the users. If that means they have to buy >> from Canada, so be it. We're doing no customer a favor by selling them >> fraudulent fake crypto software. >> >> Perry > From owner-ipsec Sun May 17 14:16:35 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA09548 for ipsec-outgoing; Sun, 17 May 1998 14:06:01 -0400 (EDT) Date: Sun, 17 May 1998 14:19:15 -0400 From: "D. Hugh Redelmeier" To: ipsec@tis.com Subject: combining SA proposals in IKE [was: Some questions] In-Reply-To: <199805121519.TAA09346@relay2.elvis.ru> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk Valery Smyslov asked a question that is very timely for me. I'm writing code to encode and decode IKE SA Payloads, and haven't yet been able to figure out the semantics of combining Proposal Payloads with the same proposal number. At the end of this message, I'll quote the relevant parts of the thread. I feel that my questions are still not resolved, so I'll ask them here. This message was actually prepared before the thread started. BTW, I fully expect that some of these answers are in the drafts but that I've missed them or misunderstood them. In Phase 2 / Quick Mode, IKE SA Payloads are for specifying IPsec SAs (as opposed to ISAKMP SAs, which are the subject of Phase 1 / Main Mode). Actually, Phase 2 can be used for DOIs other than IPsec, but that does not concern me at the moment. The SA Payload contains nested sub-payloads that are combined as disjunctions and conjunctions: An SA Payload contains Proposal Payloads. These are given monotonically non-decreasing numbers. All proposals with the same number are taken together ("AND"). Those with different numbers are alternatives ("OR"). Within a Proposal Payload, Transform Payloads are taken as alternatives. I don't understand how the AND is to work. I understand that the intent is to allow AH and ESP (and IPcomp?) to be combined. With tunneling, more than just one of each can be combined. I don't see any specification of the order of their combination. There are two obvious ones (reflecting the order of their proposals), but any permutation would not violate anything I've read. (draft-ietf-ipsec-isakmp-09.txt section 4.2) ==> How are ANDed proposals to be composed (in the mathematical sense of the word)? [My code parses these things. I've gotten stuck trying to ascribe a meaning (action) to what has been parsed.] If ANDed proposals have different durations, what will happen? I assume the SA becomes useless as soon as any of its components expires. Is this right? It has been stated that there is no need to compose multiple ESP transforms. The justification is that we believe that there are reasonable ESP choices that are computationally hard enough so that composing would just be overkill. But we don't know if there are back doors or gross flaws in some of the transforms: by composing ESP transforms, we can be betting that at least one has no back door known to our adversaries. A similar argument holds for authentication. I think that this justifies allowing more compositions of transforms. ================ There may be several SA Payloads, each negotiating a separate SA. The rules for how they relate are not clear to me (I didn't even see them). There is an expressed intent which might help one guess: multiple SAs can be the same in all ways except SPI; the extras can be kept in reserve for when the first expires. I guess it is up to the sender of a packet to have a policy to choose amongst these SAs (a packet would only go through one, but which one?). The receiver has no problem because the SPI set by the sender does the selection. ==> How do multiple SAs negotiated in one exchange relate? If multiple SA Payloads occur, how are they matched up in the Initiator's and Responder's messages? SPI won't work -- the Initiator's and Responder's SPI's need not match. Are they presumed to be in the same order (I haven't noticed this as an ordering constraint)? I think that this should be nailed down. Speaking of ordering constraints, the IKE draft (-07) says in 5.5 "With the exception of HASH, SA, and the optional ID payloads, there are no payload ordering restrictions on Quick Mode." I did not notice a constraint on ID Payloads, and I only noticed a restriction on "a (sic) SA Payload", not every SA Payload. I'm guessing that the multiple simultaneous proposal technique is the only way to compose transforms. I don't think I should be guessing. ================ There is another puzzling thing about IPsec Transform Payloads in Phase 2. One attribute specifies an Oakley (i.e. ISAKMP) group for purposes of rekeying to achieve PFS. I don't see how the full panoply of ISAKMP groups can be specified with this single attribute. Since some feel that the canned groups provide too little entropy, I am concerned. (All the more reason to get the new larger MODP accepted as a standard group.) ==> How is a non-standard Oakley group specified for Phase 2 DH exponentiation? Every transform of every proposal of every SA in a Phase 2 message MUST specify the same group if a KE Payload is supplied (or all must not specify a group if there is no KE). This feels like bad design. The group has nothing to do with the characteristics of the SA, so it should not be part of the SA Payload. I realize that it is too late to change something like this. ================ When testing our IKE daemon, I've noticed that the keying material is often the same in both directions. This strikes me as unfortunate (it worries me, but I'm not absolutely sure that it matters). The IKE document section 5.5 says that this won't happen because the keying material depends on the SPI number (it is part of the hash), and the two SPIs will be different. Well, fresh copies of our daemon pick the same SPI number, so this logic doesn't work. Perhaps we should go to some trouble to ensure that these SPIs are distinct (or just probably distinct?). Perhaps they should even have non-trivial Hamming distance (I don't imagine that this is needed, but I'm not a cryptographer). I see nothing in the standards that specifies that SPIs should be unpredictable or different. Is this a weakness of the standards? Partial answers, or even additional questions are welcome! Hugh Redelmeier hugh@mimosa.com voice: +1 416 482-8253 | From: "Valery Smyslov" | 2. Regarding previous question: when protection suite (e.g. sequence | of SAs) is negotiated, what should be the order of appliance of those | SAs when processing an outgoing packet? Should it be the same as the | order in which their proposals appear in the ISAKMP SA Payload? It is | very natural, but it seems that IPsec drafts doesn't state this | explicitly. | From: Daniel Harkins | For situations where you negotiate AH and ESP you apply ESP first. | Applying multiple AH or multiple ESP transforms to a single packet is not | defined. | From: "Valery Smyslov" | Well, let's imagine situation when responder receives SA payload that | proposes protection suite containing AH and ESP both in transport | mode in the order (I mean order of Proposal payloads) AH, ESP. What | should it do? Should it reject this suite or accept it, but apply SAs | in correct order: ESP, AH (assuming, that peer will do the same, | because the other order is prohibited)? | | > Applying multiple AH or multiple ESP transforms to a single packet is not | > defined. | | Sorry, but it is defined if you use tunnel mode (Architecture | document, section 4.3, first case of iterated tunnelling), although | marked as "unlikely to be used". But this case isn't prohibited. | Moreover, the order of applying SAs (first ESP, then AH) is defined | only for transport mode SA bundles (as far, as I understand). Tunnel | mode SAs can be applied in any order, so, my second question is still | valid From owner-ipsec Sun May 17 17:34:38 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA09744 for ipsec-outgoing; Sun, 17 May 1998 17:30:01 -0400 (EDT) Message-ID: <70C20C1647EBD11183F800805FA67B43DC@vpnet.com> From: Sumit Vakil To: ipsec@tis.com Subject: RE: combining SA proposals in IKE [was: Some questions] Date: Sun, 17 May 1998 14:44:27 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1460.8) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@ex.tis.com Precedence: bulk > -----Original Message----- > From: D. Hugh Redelmeier [SMTP:hugh@mimosa.com] > Sent: Sunday, May 17, 1998 11:19 AM > To: ipsec@tis.com > Subject: combining SA proposals in IKE [was: Some questions] > > Valery Smyslov asked a question that is very timely for me. I'm > writing code to encode and decode IKE SA Payloads, and haven't yet > been able to figure out the semantics of combining Proposal Payloads > with the same proposal number. > > At the end of this message, I'll quote the relevant parts of the > thread. I feel that my questions are still not resolved, so I'll ask > them here. This message was actually prepared before the thread > started. BTW, I fully expect that some of these answers are in the > drafts but that I've missed them or misunderstood them. > > In Phase 2 / Quick Mode, IKE SA Payloads are for specifying IPsec SAs > (as opposed to ISAKMP SAs, which are the subject of Phase 1 / Main > Mode). Actually, Phase 2 can be used for DOIs other than IPsec, but > that does not concern me at the moment. > > The SA Payload contains nested sub-payloads that are combined as > disjunctions and conjunctions: > > An SA Payload contains Proposal Payloads. These are given > monotonically non-decreasing numbers. All proposals with the same > number are taken together ("AND"). Those with different numbers > are alternatives ("OR"). > > Within a Proposal Payload, Transform Payloads are taken as > alternatives. > > I don't understand how the AND is to work. I understand that the > intent is to allow AH and ESP (and IPcomp?) to be combined. With > tunneling, more than just one of each can be combined. I don't see > any specification of the order of their combination. There are two > obvious ones (reflecting the order of their proposals), but any > permutation would not violate anything I've read. > (draft-ietf-ipsec-isakmp-09.txt section 4.2) > > ==> How are ANDed proposals to be composed (in the mathematical sense > of the word)? [Sumit] The order in which the proposal payloads appear in an ISAKMP exchange does not determin the order in which the resulting SAs are applied to data packets. The Security Architecture document describes the acceptable AH and ESP combinations. Section 4.5 describes the MUST to support combinations. Besides, if AH and ESP are negotiated together as a single protection suite, always apply ESP first, then AH. For example, in tunnel mode, with both AH and ESP in use, the order should be IP(outer) AH ESP IP(inner). IP(outer) ESP AH IP(inner) is not going to work since AH covers the outer IP header also. > > [My code parses these things. I've gotten stuck trying to ascribe a > meaning (action) to what has been parsed.] > > If ANDed proposals have different durations, what will happen? I > assume the SA becomes useless as soon as any of its components > expires. Is this right? [Sumit] If one SA in a protection suite times out, you cannot simply re-negotiate that one SA because the protection suite must always be negotiated as a whole and not in parts. However, the other SAs are still valid. What you do with them is an implementation detail. Maybe you want to receive data on them till they timout, but start sending on the new SAs, or maybe you want to send out deletes for the older SAs, etc. > It has been stated that there is no need to compose multiple ESP > transforms. The justification is that we believe that there are > reasonable ESP choices that are computationally hard enough so that > composing would just be overkill. But we don't know if there are back > doors or gross flaws in some of the transforms: by composing ESP > transforms, we can be betting that at least one has no back door known > to our adversaries. A similar argument holds for authentication. I > think that this justifies allowing more compositions of transforms. [Sumit] I'm not sure I understand what you're trying to say, but if someone wants to come up with a new ESP transform draft, they are perfectly free to do so. The IETF is an open forum. Anyone can propose their ideas. If you are asking whether a proposal payload in a phase 2 exchange can have multiple transform payloads, the answer is absolutely. See the example in section 7.2 of IKE. The proposal payload there has two transform payloads. > ================ > > There may be several SA Payloads, each negotiating a separate SA. The > rules for how they relate are not clear to me (I didn't even see > them). There is an expressed intent which might help one guess: > multiple SAs can be the same in all ways except SPI; the extras can be > kept in reserve for when the first expires. I guess it is up to the > sender of a packet to have a policy to choose amongst these SAs (a > packet would only go through one, but which one?). The receiver has > no problem because the SPI set by the sender does the selection. > > ==> How do multiple SAs negotiated in one exchange relate? > > If multiple SA Payloads occur, how are they matched up in the > Initiator's and Responder's messages? SPI won't work -- the > Initiator's and Responder's SPI's need not match. Are they presumed > to be in the same order (I haven't noticed this as an ordering > constraint)? I think that this should be nailed down. [Sumit] I couldn't find the reference in IKE, but yes, you are correct. Multiple sets of SAs can be negotiated during quick mode to allow for fast re-keying, and to reduce the number of roundtrips per SA. Except for the SPIs, the SA payloads (and the various proposal and transform payloads within the SA payload) must be identical. So you will end up with identical SAs but different SPIs and hence keys. Once you get a set of inbound and outbound SAs, pick one SA to send packets on. It won't matter which one. The packets that you receive will have enough information on them (SPI, protocol, dest. addr) to allow you to find the proper inbound SA. > Speaking of ordering constraints, the IKE draft (-07) says in 5.5 > "With the exception of HASH, SA, and the optional ID payloads, there > are no payload ordering restrictions on Quick Mode." I did not notice > a constraint on ID Payloads, and I only noticed a restriction on "a > (sic) SA Payload", not every SA Payload. [Sumit] The Id payload ordering restriction is that if the payloads are present, there must be two of them, and they must contain the Ids of the parties for which the phase 2 SA is being negotiated, and the order of the Ids must be the Id on the initiator side followed by the Id on the responder side. It isn't written down anwhere, but going by the diagram there, it seems that all SA payloads must happen before any other payloads (except the hash payload, ofcourse). > I'm guessing that the multiple simultaneous proposal technique is the > only way to compose transforms. I don't think I should be guessing. > > ================ > > There is another puzzling thing about IPsec Transform Payloads in > Phase 2. One attribute specifies an Oakley (i.e. ISAKMP) group for > purposes of rekeying to achieve PFS. I don't see how the full panoply > of ISAKMP groups can be specified with this single attribute. Since > some feel that the canned groups provide too little entropy, I am > concerned. (All the more reason to get the new larger MODP accepted > as a standard group.) > > ==> How is a non-standard Oakley group specified for Phase 2 DH > exponentiation? [Sumit] First do a New group exchange. That will give you a non-standard DH group. Then, use that group's Id in the phase 2 exchange. > Every transform of every proposal of every SA in a Phase 2 message > MUST specify the same group if a KE Payload is supplied (or all must > not specify a group if there is no KE). This feels like bad design. > The group has nothing to do with the characteristics of the SA, so it > should not be part of the SA Payload. I realize that it is too late > to change something like this. [Sumit] The group description is a data attribute and data attributes always go inside of payloads. Hence the group description attribute has to be present in every transform. > ================ > > When testing our IKE daemon, I've noticed that the keying material is > often the same in both directions. This strikes me as unfortunate (it > worries me, but I'm not absolutely sure that it matters). The IKE > document section 5.5 says that this won't happen because the keying > material depends on the SPI number (it is part of the hash), and the > two SPIs will be different. Well, fresh copies of our daemon pick the > same SPI number, so this logic doesn't work. > > Perhaps we should go to some trouble to ensure that these SPIs are > distinct (or just probably distinct?). Perhaps they should even have > non-trivial Hamming distance (I don't imagine that this is needed, but > I'm not a cryptographer). > > I see nothing in the standards that specifies that SPIs should be > unpredictable or different. Is this a weakness of the standards? [Sumit] That's an implementation issue. The SPI has local significance only and it is upto the implementation to decide how it will generate SPIs. Instead of starting at the same SPI value, maybe you want your implementation to start with a value that depends on some local parameters that are unique to each device. Maybe you want to use pseudo-random SPIs. I don't think that the protocol should be changed to ensure distinct SPIs. If you look at the definition of SPI in the Security Association, all it says is that it is an opaque bit string that simply enables the receiving system to find the correct SA to process the packet with. It does not mention using the SPI in deriving keys or doing anything else. Sumit A. Vakil VPNet Technologies, Inc. From owner-ipsec Sun May 17 18:59:35 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA09871 for ipsec-outgoing; Sun, 17 May 1998 18:56:04 -0400 (EDT) Message-Id: <199805172311.QAA09399@greatdane.cisco.com> To: "D. Hugh Redelmeier" cc: ipsec@tis.com Subject: Re: combining SA proposals in IKE [was: Some questions] In-reply-to: Your message of "Sun, 17 May 1998 14:19:15 EDT." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 17 May 1998 16:11:03 -0700 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk > It has been stated that there is no need to compose multiple ESP > transforms. The justification is that we believe that there are > reasonable ESP choices that are computationally hard enough so that > composing would just be overkill. But we don't know if there are back > doors or gross flaws in some of the transforms: by composing ESP > transforms, we can be betting that at least one has no back door known > to our adversaries. A similar argument holds for authentication. I > think that this justifies allowing more compositions of transforms. I don't know where that's been stated but it hasn't been in the IKE draft. No justification for allowing more compositions of transforms is necessary because there is nothing prohibiting them. > There may be several SA Payloads, each negotiating a separate SA. The > rules for how they relate are not clear to me (I didn't even see > them). There is an expressed intent which might help one guess: > multiple SAs can be the same in all ways except SPI; the extras can be > kept in reserve for when the first expires. I guess it is up to the > sender of a packet to have a policy to choose amongst these SAs (a > packet would only go through one, but which one?). The receiver has > no problem because the SPI set by the sender does the selection. You seem to be mixing "how are they negotiated" with "how are they used once they're negotiated". I don't know the answer to the 2nd. > ==> How do multiple SAs negotiated in one exchange relate? Multiple SA payloads when negotiated in phase 2 are not necessarily related. The components of each SA payload-- proposals and their component transforms-- are all related-- are related but there is no relation between SA payloads themselves. If ID and/or KE payloads are present they must apply to all SA payloads (and all proposals or all SA payloads). > If multiple SA Payloads occur, how are they matched up in the > Initiator's and Responder's messages? SPI won't work -- the > Initiator's and Responder's SPI's need not match. Are they presumed > to be in the same order (I haven't noticed this as an ordering > constraint)? I think that this should be nailed down. Yes, it's order. That should be nailed down better. > Speaking of ordering constraints, the IKE draft (-07) says in 5.5 > "With the exception of HASH, SA, and the optional ID payloads, there > are no payload ordering restrictions on Quick Mode." I did not notice > a constraint on ID Payloads, and I only noticed a restriction on "a > (sic) SA Payload", not every SA Payload. The constraint on ID payloads is that they must be passed as IDci followed by IDcr. This is described in the document. > There is another puzzling thing about IPsec Transform Payloads in > Phase 2. One attribute specifies an Oakley (i.e. ISAKMP) group for > purposes of rekeying to achieve PFS. I don't see how the full panoply > of ISAKMP groups can be specified with this single attribute. Since > some feel that the canned groups provide too little entropy, I am > concerned. (All the more reason to get the new larger MODP accepted > as a standard group.) > > ==> How is a non-standard Oakley group specified for Phase 2 DH > exponentiation? You have to do a New Group Mode to agree on that one attribute. > Every transform of every proposal of every SA in a Phase 2 message > MUST specify the same group if a KE Payload is supplied (or all must > not specify a group if there is no KE). This feels like bad design. > The group has nothing to do with the characteristics of the SA, so it > should not be part of the SA Payload. I realize that it is too late > to change something like this. On the contrary. Since the group is used to generate the key which is part of the SA I think it does have something to do with the SA. Not only is it too late, your change is bad design. If the group identifier was removed from the negotiated payloads how would you decide how to generate keys for the various negotiated SAs in the presence of a KE payload? In what context would you take the KE payload? I'm sorry you don't like the design but the alternative is worse. > When testing our IKE daemon, I've noticed that the keying material is > often the same in both directions. This strikes me as unfortunate (it > worries me, but I'm not absolutely sure that it matters). The IKE > document section 5.5 says that this won't happen because the keying > material depends on the SPI number (it is part of the hash), and the > two SPIs will be different. Well, fresh copies of our daemon pick the > same SPI number, so this logic doesn't work. The logic works just fine, it's your daemon that doesn't work. KEYMAT is dependant on the nonces as well as the SPI and protocol. If you're generating identical KEYMAT for each direction that means that not only are the SPIs identical, the nonces are too. That calls into question your whole pseudo- random number generation. Are your Diffie-Hellman exponentials identical as well? Do fresh copies of your daemon produce identical Diffie-Hellman public values? Given the important use of nonces in phase 1 authentication I'd be very worried. > Perhaps we should go to some trouble to ensure that these SPIs are > distinct (or just probably distinct?). Perhaps they should even have > non-trivial Hamming distance (I don't imagine that this is needed, but > I'm not a cryptographer). > > I see nothing in the standards that specifies that SPIs should be > unpredictable or different. Is this a weakness of the standards? I'm not so sure I see a need for requiring that the SPIs be unpredictable. But I really see a need for the nonces to be. I guess the Security Considerations of IKE should strongly state this. Dan. From owner-ipsec Mon May 18 03:51:21 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id DAA11123 for ipsec-outgoing; Mon, 18 May 1998 03:47:04 -0400 (EDT) Date: Mon, 18 May 1998 11:01:00 +0300 (IDT) From: Hugo Krawczyk Message-Id: <199805180801.LAA16533@ee.technion.ac.il> To: dharkins@cisco.com, hugh@mimosa.com Subject: Re: combining SA proposals in IKE [was: Some questions] Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk >> Perhaps we should go to some trouble to ensure that these SPIs are >> distinct (or just probably distinct?). Perhaps they should even have >> non-trivial Hamming distance (I don't imagine that this is needed, but >> I'm not a cryptographer). >> >> I see nothing in the standards that specifies that SPIs should be >> unpredictable or different. Is this a weakness of the standards? > >I'm not so sure I see a need for requiring that the SPIs be unpredictable. >But I really see a need for the nonces to be. I guess the Security >Considerations of IKE should strongly state this. The cryptographic design of IKE does not assume anything about the SPIs. They can be as structured or unstructured as you want: fixed to zero if that works for you, a counter, or a perfectly random number. As Dan correctly points out, it is the (pseudo) randomness of the nonces that counts. That is used to enusre freshness and independence of authentication and key derivation. Indeed, a clarification in the security considerations is in place (maybe even at the first "definition" of what Nx stands for). BTW, even if you want to use a random SPI for the above freshness purposes, 32-bit of them wouldn't be enough in some cases. A 32-bit random quantity will repeat with high probability after 2^16 uses, that may be too little for ensuring freshness in some applications. Hugo From owner-ipsec Mon May 18 11:49:52 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA12552 for ipsec-outgoing; Mon, 18 May 1998 11:45:17 -0400 (EDT) Message-ID: <70C20C1647EBD11183F800805FA67B43FC@vpnet.com> From: Sumit Vakil To: ipsec@tis.com Subject: Authentication Only Bit Date: Mon, 18 May 1998 08:59:27 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1460.8) Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk I'm having trouble understanding how to use the authentication only bit in the ISAKMP header. If this bit is set in the header, what algorithm and key should be used to generate the authentication information? What payload should carry that information? I looked through ISAKMP, IKE and the IPDOI, but couldn't find a clear explanation on the use of this bit. If the use of this bit involves using the ISAKMP SA (e.g. the hash payload as described in section 5.7 of IKE), then why not just encrypt? If SKEYID_a is available, then, so is SKEYID_e, and hence the encryption key. If the intent was to allow sending authenticated notify messages without an existing phase 1 SA, then a detailed explanation on choosing and using an appropriate asymmetric key algorithm or pre-shared key is required. Thanks, Sumit A. Vakil VPNet Technologies, Inc. From owner-ipsec Mon May 18 11:59:36 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA12642 for ipsec-outgoing; Mon, 18 May 1998 11:57:16 -0400 (EDT) Message-Id: <199805181611.QAA16924@orchard.arlington.ma.us> To: Daniel Harkins Cc: ipsec@tis.com Subject: Re: combining SA proposals in IKE [was: Some questions] In-Reply-To: Your message of "Sun, 17 May 1998 16:11:03 PDT." <199805172311.QAA09399@greatdane.cisco.com> Date: Mon, 18 May 1998 12:11:54 -0400 From: Bill Sommerfeld Sender: owner-ipsec@ex.tis.com Precedence: bulk > I'm not so sure I see a need for requiring that the SPIs be unpredictable. THis isn't an IKE concern, it's an overall *system*-level concern. AH/ESP SPI's should be unpredictable so that off-path clogging/denial-of-service attacks aren't ridiculously easy.. it's much more efficient to discard a packet with a unknown SPI than to verify the MAC on one with a valid SPI... - Bill From owner-ipsec Mon May 18 13:47:17 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA13244 for ipsec-outgoing; Mon, 18 May 1998 13:45:18 -0400 (EDT) From: Dan McDonald Message-Id: <199805181758.KAA02529@kebe.eng.sun.com> Subject: Policy question To: ipsec@tis.com Date: Mon, 18 May 1998 10:58:44 -0700 (PDT) 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 Consider that I have a machine that has no specified security preferences. That is, w/o additional per-socket tweaking, outbound traffic goes out in the clear and that inbound traffic is cheerfully accepted in the clear. Now consider an encrypted TCP SYN that is received by this machine. For the time being, assume the inbound SA is in place (I'll touch more on this later). Given the lack of policy constraints I can do several things: 1.) Send back the SYN/ACK in the clear. This certainly obeys the "no specified security preferences" policy, but it has the disadvantages of sending cleartext in response to ciphertext (possibly aiding an eavesdropping adversary), and that cleartext reply may be dropped by the sender for failing the sender's policy. 2.) Drop the SYN. This has the advantage of not providing an adversary any clues beyond "encrypted packets get rejected", and it will cause the sender's TCP to time out. This also means bits do not get transferred. 3.) Send the SYN/ACK using the same levels of security as the inbound SYN. This will keep the sender happy, foil the eavesdropper, and move bits. This also means possibly making TCP more aware of IPsec state. I deliberately picked TCP as the example because connections are "latched" into place, and because UDP endpoints are connectionless, and policy may be different between different destination ports or addresses. One other thing to consider, which you may have picked up earlier, is that it is possible to have the IKE daemon on this machine deliberately reject all requests for negotiating secure services in this case. (This means the SYN would never arrive, as the IKE negotiation would fail.) This is okay, but if only manual keying is being used, you can't have that sort of access control. So what should one do given the above situation? I suspect my alternatives were ordered least-to-most preferable. I'd appreciate feedback from the list on this. Thanks, Dan From owner-ipsec Mon May 18 15:27:24 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA13641 for ipsec-outgoing; Mon, 18 May 1998 15:21:18 -0400 (EDT) Message-ID: <35608E01.B0725AFB@cosinecom.com> Date: Mon, 18 May 1998 12:37:37 -0700 From: Abraham R Matthews Organization: Cosine Communications X-Mailer: Mozilla 4.05 [en] (WinNT; I) MIME-Version: 1.0 To: Stephen Kent , ipsec@tis.com Subject: Re: [Q] SA lookup on receive References: Content-Type: multipart/mixed; boundary="------------B609D1F613BECB9F8ED7F87D" Sender: owner-ipsec@ex.tis.com Precedence: bulk This is a multi-part message in MIME format. --------------B609D1F613BECB9F8ED7F87D Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Stephen, I agree that the SA MUST be a tunnel mode if the SA was between the IPSec host/gateway and the IPSec gateway. However. I am considering the case where the SA is between 2 IPSec hosts and one of the routers in between is an IPSec gateway. The host _does not_ have an SA with the IPSec gateway. In this case, the IPSec gateway receives an IPSec packet ... but the destination address in the "outer" header (or the header in the clear) is NOT one of the local addresses of the gateway. A strict reading of the security architecture document would cause this packet to be dropped. Thus the request for the clarification. As I see it the input processing for the IPSec gateway probably should be: If (not an IPSec packet) { look up in SPD and process accordingly } else { if (the destination is not local) look up in SPD and process accordingly else look up in SAD and process according to ID } Thanks, Abbie. Stephen Kent wrote: > > Abraham, > > >When an ipsec packet is received, an SA is looked up using the > >tuple . Must the dest-ip be a local ip > >address of the security gateway? What if the dest-ip address is > >the address of an internal host? > > Any SA involving a security gateway MUST be a tunnel mode SA, so the outer > IP address will be that of the gateway, not of the internal (ultimate > destination) host. The latter address will be in the inner IP header. > > Steve --------------B609D1F613BECB9F8ED7F87D Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Abraham Matthews Content-Disposition: attachment; filename="vcard.vcf" begin: vcard fn: Abraham Matthews n: Matthews;Abraham org: CoSine Communications adr: Suite 200;;1070 Sixth Avenue;Belmont;CA;94002;USA email;internet: amatthews@cosinecom.com title: Software Architect tel;work: 650-637-4725 tel;fax: 650-637-4778 x-mozilla-cpt: ;0 x-mozilla-html: TRUE version: 2.1 end: vcard --------------B609D1F613BECB9F8ED7F87D-- From owner-ipsec Mon May 18 15:45:44 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA13721 for ipsec-outgoing; Mon, 18 May 1998 15:45:16 -0400 (EDT) Message-Id: <199805181946.PAA12524@ensun102.UD.Engr> Subject: CFP: IC3N'98: 7th Int Conf on Comp Communications & Networks To: ipsec@ans.net Date: Mon, 18 May 1998 15:46:22 -0400 (EDT) Reply-To: atiq@engr.udayton.edu (Mohammed Atiquzzaman) From: atiq@engr.udayton.edu (Mohammed Atiquzzaman) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk **************************************************************************** ********* Pls note new submission deadline of May 29, 1998 ***************** **************************************************************************** IC3N'98 CALL FOR PAPERS SEVENTH INTERNATIONAL CONFERENCE ON COMPUTER COMMUNICATIONS AND NETWORKS October 12-15, 1998, Lafayette, Louisiana, USA Sponsored (pending approval) by IEEE Communication Society (TCCC Tech. Co-Sponsor), BellSouth, Army Research Office, NASA. In cooperation (pending approval) with The Center for Telecommunications Studies and the Center for Advanced Computer Studies at USL, NSF, NIST, ACM. Technical co-sponsored by IEEE COMSOC Technical Committee on Personal Communications (TCPC), Technical Committee on Parallel Processing (pending), IEEE ComSoc Technical Committee on Network Operations and Managements (CNOM) http://www.cacs.usl.edu/~ic3n The objective of this conference is to provide an effective forum for original and fundamental advances in Computer Communications and Networks and to foster communication among researchers and practitioners working in a wide variety of scientific areas with a common interest in improving Computer Communications and Networks. SCOPE ===== The primary focus of the conference is on new and original research results in the areas of design, implementation and applications of Computer Communications and Networks. We solicit the submission of papers that address novel, challenging and innovative results. Therefore the topics that will be addressed include, but are not limited to: o Optical Communications Networks o Wireless/Mobile Communication Networks o ATM Networking o Internet Services/Applications o Wireless Multimedia Applications o Real-time Communications o Quality of Services (QoS) Issues o LAN/WAN Internetworking o Network Interoperability & Scalability o Personal Communication Services o Network Control Management o Broadband Networks o Intelligent Networks o Multicast & Routing Protocols o Network Security o Media Access Control/Mobility Algorithms o Network Reliability o High Speed Network OAM/Protocols o Video-on-Demand o Data Traffic Engineering o Network Management o Global Infrastructure Network Evolution o Multimedia Human-Machine Interface o Performance Modeling/Analysis o Communication Software o Protocol Design/Validation/Testing o Networked Databases o Network Architectures SUBMISSION =========== Authors are invited to submit complete and original papers. Papers that may be submitted for consideration include those that have not previously been published in another forum, or are not currently being published or reviewed by another journal or conference. All submitted papers will be refereed for quality, correctness, originality and relevance. The program committee reserves the right to accept a submission as long, short or poster presentation. Of particular interest are papers which address experiences with concrete Computer Communications and applications. All accepted papers will be published in the conference proceedings. Authors will be interested to know that special issues of journals containing outstanding papers from the conference are being planned. Manuscripts should include an abstract and be limited to 5000 words. Submissions should include the title, author(s), author's affiliation, e-mail address, fax number and postal address. In case of multiple authors, an indication of which author is responsible for correspondence and preparing the camera ready paper for the proceedings should also be included. Six copies of the manuscript should be submitted by Friday, May 29,1998 (extended) to one of the Program Co-Chairs: Dr. Kia Makki The Center for Telecommunications Studies The University of Southwestern Louisiana Lafayette, LA 70504-3890 e-mail: kia@usl.edu Tel: (318) 482-5872 Fax: (318) 482-5872 Dr. Imrich Chlamtac MS EC33, P.O. Box 830688 The University of Texas at Dallas Richardson, TX 75083 e-mail: chlamtac@utdallas.edu Tel: (972) 883-6295 Fax: (972) 883-2710 For more information about the conference (as opposed to paper submissions) please send e-mail to ic3n@cacs.usl.edu. IMPORTANT DATES ================ Paper submission deadline: May 29, 1998 Notification of acceptance: July 17, 1998 Camera ready papers due: August 10, 1998 WORKSHOPS, TUTORIALS AND INDUSTRIAL EXHIBITS ============================================ Proposals must clearly identify the intended audience. Tutorial proposal should be considerably broader than the communications and network research communities. Exhibits should should illustrate innovative technology. Please send your proposal by May 29, 1998 to Professor O. Frieder, Workshop and Tutorial Chair, College of Engineering, Florida Institute of Technology, Melbourne, FL 32901 (ophir@ee.fit.edu). SOCIAL ACTIVITIES ================== Lafayette is situated within 130 miles of New Orleans and 220 miles of Houston. It is serviced by the major Airlines. It is famous for its distinct Cajun culture, food and music. Besides the technical program, a very entertaining social program and tours are being planned. CONFERENCE ORGANIZING COMMITTEE =============================== General Chairs: B. Mukherjee, UC Davis N. Pissinou, USL Program Chairs: I. Chalmtac, UT Dallas K. Makki, USL Program Vice-Chairs: Y. Fang, UT Dallas C. Qiao, SUNY Buffalo Program Committee: I. F. Akyildiz, Georgia Tech. M. H. Ammar, Georgia Tech. H. Arabnia, U. of Georgia B. Chen, UT Dallas J. C.I. Chuang, AT&T Labs-Research P. Dowd, DoD D. Everitt, Univ. of Melbourne, Australia A. Farago, UT Dallas B. Gavish, Vanderbilt U. S. Goyal, GTE Labs R. Guerin, IBM T.J.Watson Research Center Z. Haas, Cornell Univ. D. Kazakos, USL L. Kleinrock, UCLA R. Krishnan, UT Dallas Y. B. Lin, NCTU, Taiwan T. Liu, Ascend Communications M. T. Liu, Ohio State U. F. Lombardi, Texas A&M S. Makki, RMIT P. McKinley, Michigan State. R. Melhem, Univ of Pittsburgh W. M. Moh, San Jose St. L. E. Moser, UC S. Barbara M. Mutka, Michigan State L. Ni, Michigan State Y. Pan, U. of Dayton D. K. Panda, Ohio State W. Peng, SW Texas State G. Polyzos, UC San Diego S. S. Rappaport, SUNY at Stony Brooks I. Rubin, UCLA S. Sahni, U. of Florida G. Sasaki, U. Hawaii M. Schwartz, Columbia U. M. Singhal, Ohio State K. Sohraby, U. of Missouri A. K. Somani, Iowa State T. Todd, McMaster H.C. Torng, Cornell U. E. Torng, Michigan State S. Tripathi, UC Riverside Y. Yang, U. of Vermont T. Znati, Univ. of Pittsburgh Z. Zhang, Bell Laboratories others (See Web Site) Industrial Committee: K. Bhat, Lucent Tech. C. Fayet, INT, France A. Gaivoronski, ITALTEL IT A. Kogiantis, Lucent Tech. P. O'Reilly, GTE Lab. H. Saito, NTT, Japan A. Vernon, BellSouth H. Rudin, IBM, Switzerland Government Committee: S. Balikirsky, US Army P. W. Dowd, U.S. Department of Defense D. Fisher, NSF M. Halem, NASA D. Su, NIST D. Grossman, US Gov. T. Pressley, ARO International Committee: I. Cidon, Technion, Israel T. S. Dillon, LaTrobe, AU J. Misic, Hong U. ST Y. Oie, KIT, Japan Z. Y. Zomaya, UWA, AU Publicity Chairs: M. Atiquzzaman, U. Dayton J. Wigglesworth, IBM CA Panel Chairs: F. Golshani, Arizona State M. S. Obaidat, Monmouth Local Arrangm. Chair: R. Henry, USL Social Activities Chair: J. V. Lillie, BellSouth Treasurer: E. K. Park, U. of Missouri Registration Chairs: S. Busovaca, Cal. State Sac X. Jia, City U. Hong Kong Information: http://www.cacs.usl.edu/~ic3n From owner-ipsec Mon May 18 16:24:10 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA13843 for ipsec-outgoing; Mon, 18 May 1998 16:22:18 -0400 (EDT) Message-Id: <199805182036.QAA03200@istari.sandelman.ottawa.on.ca> To: Dan McDonald CC: ipsec@tis.com Subject: Re: Policy question In-reply-to: Your message of "Mon, 18 May 1998 10:58:44 PDT." <199805181758.KAA02529@kebe.eng.sun.com> Date: Mon, 18 May 1998 16:36:31 -0400 From: "Michael C. Richardson" Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Dan" == Dan McDonald writes: Dan> Consider that I have a machine that has no specified security preferences. Dan> That is, w/o additional per-socket tweaking, outbound traffic goes out in the Dan> clear and that inbound traffic is cheerfully accepted in the clear. Okay. I will assume for the purposes of discussion that this is a Unix machine. When you say that you have no specific security preferences, I assume that this means: 1. either no-bsd-<1024-port restrictions are in place (that is, your rexecd will believe what I say regardless of what port I arrive on), or no such services are accepted, period. 2. your telnetd, if you have one, isn't going to restrict root logins from network ports. 3. you have no tcp wrappers, or other ways of selectively accepting network traffic at the application layer. In other words, I suggest that "no specific security preferences" goes beyond whether traffic is encrypted or authenticated. In general, a host has a set of security policies which are used to determine how much authentication is required before the host will believe that some entity is authorized to do some action. Dan> Now consider an encrypted TCP SYN that is received by this machine. For the Dan> time being, assume the inbound SA is in place (I'll touch more on this Dan> later). Given the lack of policy constraints I can do several things: ... Dan> One other thing to consider, which you may have picked up earlier, is that it Dan> is possible to have the IKE daemon on this machine deliberately reject all Dan> requests for negotiating secure services in this case. (This means the SYN Dan> would never arrive, as the IKE negotiation would fail.) This is okay, but if Dan> only manual keying is being used, you can't have that sort of access control. 1. manual keys can still have selectors. Perhaps people are unlikely to configure per-port SA's with manual keys, but if they configure per-host keying, then they are effectively configuring any-port keys. If they don't configure a per-host outbound SA as well, then I guess they are saying that outbound traffic need not be encrypted. 2. Ideally, the IKE deamon's permitted policy database can be informed of application specific requirements. I know that many applications have policies far more specific than can be expressed at present with, for instance, the BSD-sockets IPsec extensions, or can be communicated by the kernel to the IKE via PFKey. Clearly this is a field for a lot of OS-specific experimentation. I can imagine ktelnet or ssh-like remote logins via IPsec+IKE. I don't, however, expect IKE to read the .rhosts .shosts .ssh/authorized_keys, etc. Dan> So what should one do given the above situation? I suspect my alternatives Dan> were ordered least-to-most preferable. I'd appreciate feedback from the list Dan> on this. I think your options were artificial since you assumed the inbound SA was already in place. Clearly, you must have some policy in place. Imagine a busy web server with your most-preferable solution (do encryption if asked), and no hardware assist on the encryption... :!mcr!: | Sandelman Software Works Corporation, Ottawa, ON Michael Richardson | SSH IPsec: http://www.ssh.fi/. Secure, strong, international Personal: mcr@sandelman.ottawa.on.ca. PGP key available. Corporate: sales@sandelman.ottawa.on.ca. -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQB1AwUBNWCbydiXVu0RiA21AQEqPAMAyoDm9eho1bdpkxZvNov653qa6ht2bBDh MA5g+AwWcit8+lxXeozI7udb5BRLH9ZEjieLJQFzzJXu4WK6NBZb4prsCXDvpEUG nhIb24+cSQST3we3bPGAyUmXlckYjhpw =45p7 -----END PGP SIGNATURE----- From owner-ipsec Mon May 18 21:18:45 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id VAA14450 for ipsec-outgoing; Mon, 18 May 1998 21:15:22 -0400 (EDT) Message-Id: <199805190127.KAA29485@isl.rdc.toshiba.co.jp> To: ipsec@tis.com Subject: Re: combining SA proposals in IKE [was: Some questions] In-reply-to: dharkins's message of "Sun, 17 May 1998 16:11:03 MST." <199805172311.QAA09399@greatdane.cisco.com> Date: Tue, 19 May 1998 10:27:43 +0900 From: FUKUMOTO Atsushi Sender: owner-ipsec@ex.tis.com Precedence: bulk Daniel Harkins wrote in reply to "D. Hugh Redelmeier": > > When testing our IKE daemon, I've noticed that the keying material is > > often the same in both directions. This strikes me as unfortunate (it : > The logic works just fine, it's your daemon that doesn't work. KEYMAT is > dependant on the nonces as well as the SPI and protocol. If you're generating > identical KEYMAT for each direction that means that not only are the SPIs > identical, the nonces are too. Well, I think you are missing something. I too noticed it when I experimented with isakmp-test.ssh.fi, since it was replying the same SPI when it was configured as responder. KEYMAT is generated as: KEYMAT = prf(SKEYID_d, protocol | SPI | Ni_b | Nr_b) Both nonces are included in the hash input in same order, regardless which direction the security association is. This results in the same KEYMAT for both direction iff the responder chooses the same SPI. And this choice is done solely by responder, although the initiator may be able to reject it by Informational message or Delete message. I think it may be able to be used in some form of replay attack, since I can cut a data from one direction of packet and inject it into different direction. Replay protection doesn't work well since it's different SA for different direction. FUKUMOTO Atsushi fukumoto@isl.rdc.toshiba.co.jp From owner-ipsec Tue May 19 00:54:18 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id AAA14810 for ipsec-outgoing; Tue, 19 May 1998 00:52:21 -0400 (EDT) Message-ID: <35611370.500F@cs.umass.edu> Date: Tue, 19 May 1998 01:06:56 -0400 From: Lewis McCarthy Organization: UMass-Amherst Theoretical Computer Science Group, X-Mailer: Mozilla 3.01Gold (X11; U; OSF1 V4.0 alpha) MIME-Version: 1.0 To: IP Security List CC: FUKUMOTO Atsushi Subject: Re: combining SA proposals in IKE [was: Some questions] References: <199805190127.KAA29485@isl.rdc.toshiba.co.jp> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk FUKUMOTO Atsushi writes: > Both nonces are included in the hash input in same order, regardless > which direction the security association is. This results in the same > KEYMAT for both direction iff the responder chooses the same SPI. [...] > I think it may be able to be used in some form of replay attack, since > I can cut a data from one direction of packet and inject it into > different direction. Replay protection doesn't work well since it's > different SA for different direction. If AH or tunnel-mode ESP with authentication is used, then I don't see how deriving the keys for each direction from the same KEYMAT would allow a successful cut-and-paste replay attack. In AH the ICV is computed over the src IP addr and dest IP addr, among other headers and the payload of upper layer protocol data. In tunnel-mode ESP-with-auth the ICV is computed over the ciphertext of the full original IP packet, including src addr and dest addr. The ordered pair of (src IP addr, dest IP addr) will differ in each direction unless the initiator and responder live at the same IP address. Transport-mode ESP-with-auth is only designed to protect upper protocol layer info, not IP layer info (uh, with the possible exception of some IPv6 destination options). So it's not trying to provide IP-layer data origin authentication. Just using ESP without an auth algorithm is asking for this type of trouble, as noted in the ESP document. -- Lewis http://www.cs.umass.edu/~lmccarth/ "This information is so readily available to anybody who wants to commit an act of terrorism that you have to assume the security community's real interest is to raise attentiveness to their role in preventing terrorism in the hope that they can increase their budget" --Bruce Bueno de Mesquita, Senior Fellow, Hoover Institution, (as quoted by CNN) on objections to the EPA listing chemical storage site locations on the Web From owner-ipsec Tue May 19 06:46:04 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id GAA15783 for ipsec-outgoing; Tue, 19 May 1998 06:44:25 -0400 (EDT) Message-ID: <250F9C8DEB9ED011A14D08002BE4F64C01959106@wade.reo.dec.com> From: Stephen Waters To: ipsec@tis.com Subject: RFC status for IPSEC? Date: Tue, 19 May 1998 11:55:54 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1460.8) Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk When are ISAKMP/IKE, ESP,AH, IPCOMP likely to go to RFC status? I'm looking forward to using hardware (something like the hifn 7711) for all this stuff. Cheers, Steve. From owner-ipsec Tue May 19 20:43:34 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id UAA19305 for ipsec-outgoing; Tue, 19 May 1998 20:34:39 -0400 (EDT) Date: Tue, 19 May 1998 17:42:28 -0700 (PDT) From: Vipul Gupta Reply-To: Vipul Gupta Subject: =?US-ASCII?Q?ISAKMP_configuration=04and_Mobile-IP?= To: mobile-ip@smallworks.com Cc: vgupta@nobel.Eng.Sun.COM, ipsec@tis.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: W7SCYpAh5sgPpwIDwd22yg== X-Mailer: dtmail 1.1.0 CDE Version 1.1 SunOS 5.5.1 sun4u sparc Sender: owner-ipsec@ex.tis.com Precedence: bulk This is a repost. My apologies if you receive multiple copies. During Roy Pereira's presentation of at the LA IETF, one of the questions raised was the interaction of the proposed mechanisms with Mobile IP [RFC2002]. Here are some thoughts on the subject. The quick summary is that the two protocols can work well together provided the Mobile IP implementation on the mobile node is careful in its selection of a co-located care-of address. No changes are necessary at the home agent. vipul --------------------- Details follow ------------------------ Roy's draft "The ISAKMP Configuration Method" describes a mechanism by which a nomadic host on the Internet (e.g. a corporate employee "on the road") acquire an "internal address" belonging to a protected network (e.g. the firewall-protected corporate network) and communicate securely with other hosts on the protected network. Keys and security associations necessary to protect such communication are negotiated through IKE. For the rest of this discussion, IKE+ refers to IKE plus the ISAKMP Configuration method. In this case, the "external" nomadic host is assigned two addresses: one belonging to the protected network (negotaited via ISAKMP Configuration), and (2) a topologically significant address on the Internet (assigned by an ISP through DHCP, PPP, or manual intervention). It is certainly possible to set things up so that a nomadic host always acquires the same "internal" IP address whenever it is out on the Internet. This is enough to emulate a limited type of "mobility support" -- no matter where the portable computer is on the Internet, it will be reachable at the same "internal" address. Here IKE+ is used to "register" the portable computer's "care-of address" with the IPSec gateway and to set up a (IPSec) tunnel between the gateway and the portable computer. With this mechanism, however, mobility support is only available for addresses that are normally routed to the IPSec gateway within the protected network. When the portable computer is moved inside the corporate network (say at the employee's office desk), it would typically use a different address (one that is not routed to the gateway). To allow the portable computer to use the same IP address within the protected network and outside on the Internet, one could do the following: - Use the topologically significant address to initiate IKE+ with the IPSec gateway and acquire an "internal" address valid within the protected network (call it I). After this negotiation, the portable computer will be able to communicate securely with all hosts within the protected network. Its communication partners within the protected network will see communications originating from I. - Use the newly acquired address (I) as a co-located care-of address for normal Mobile IP registration. The Mobile IP implementation MUST not register its topologically significant address since there is no guarantee that this external address will be reachable from the home agent (which may be well inside the protected network). Many protected networks keep internal routers unaware of external addresses, nor do they use default routing to carry packets for such external addresses to the periphery gateway. This automatically implies that Mobile IP must be able to distinguish between "internal" and "external" addresses. The following packet flow diagrams illustrate how the overall scheme would work. The relative positions of the portable computer, the IPSec gateway and the home agent are assumed to be: | Protected Net | Internet | Home Agent IPSec Gateway Portable | computer | | These figures also assume that a mobile host uses reverse tunneling [RFC 2344] to tunnel traffic for correspondent nodes through its home agent and that ESP* (newer ESP with authentication) is used to protect traffic on the Internet. I: An "internal" address acquired by the portable computer through the ISAKMP configuration method T: The topologically significant address of the portable computer. It identifies its current point of attachment to the Internet. MN: The portable computer's "home address". This is the address at which the portable computer is always reachable if it uses Mobile IP. GW: An "external" address at which the IPSec gateway is reachable from hosts on the Internet. HA: home agent CN: correspondent node (a communication partner of the mobile node). a->b: An IP header in which a is the source and b is the destination. Registration request: ==================== From portable computer to IPSec gateway (across the Internet) |<- This part->|<-- This part generated ->| generated by by Mobile IP IPSec <--------- +--------+-----+----------+--------------+ | T->GW | ESP*| I -> HA | UDP reg req | +--------+-----+----------+--------------+ outer IP inner IP From IPSec gateway to home agent (within the protected network) <--------- +----------+--------------+ | I -> HA | UDP reg req | +----------+--------------+ Registration reply: ================== From home agent to IPSec gateway (within the protected network) ---------> +--------------+----------+ | UDP reg req | HA -> I | +--------------+----------+ From IPSec gateway to portable computer (across the Internet) --------> +--------------+----------+-----+--------+ | UDP reg req | HA -> I | ESP*| GW->T | +--------------+----------+-----+--------+ inner IP outer IP Outer IP and ESP* are consumed by IPSec, the rest of the pkt is processed by Mobile IP. Data transfer from Mobile host to a correspondent node: ====================================================== From portable computer to IPSec gateway (across the Internet) |<-- gen. by ->|<-Generated by Mobile IP->| IPSec <--------- +--------+-----+----------+--------+-----+ | T->GW | ESP*| I -> HA | MN->CN | ULP | +--------+-----+----------+--------+-----+ outer IP Inner IP From IPSec gateway to home agent (within the protected network) <--------- +----------+--------+-----+ | I -> HA | MN->CN | ULP | +----------+--------+-----+ From home agent to correspondent node (the exact location of the CN is unspecified and the mechanism used to deliver packets to the CN is the same as that used when the mobile node is "at home"). <--------- +--------+-----+ | MN->CN | ULP | +--------+-----+ Data transfer from the correspondent node to the mobile node: ============================================================ From the correspondent node to the home agent ---------> +-----+--------+ | ULP | MN->CN | +-----+--------+ From the home agent to the IPSec gateway (within the protected network) ---------> +-----+--------+----------+ | ULP | CN->MN | HA -> I | +-----+--------+----------+ From the IPSec gateway to the portable computer (across the Internet) MIP hdr --------> +-----+--------+----------+-----+--------+ | ULP | CN->MN | HA -> I | ESP*| T->GW | +-----+--------+----------+-----+--------+ innermost IP outermost IP Again, the outermost IP and ESP* are consumed by IPSec and the rest is processed by Mobile IP. These packet formats are very similar to (but not the same as) those described in ("Firewall Support for Mobile IP", Montenegro and Gupta). The use of multiple tunnels and IPSec increases the size of packets and their processing time. The performance impact of these changes is discussed in "Secure And Mobile Networking", Gupta and Montenegro, available from http://playground.sun.com/pub/mobile-ip/. That paper uses SKIP (in-line keying) and separate ESP and AH headers (old style) to secure traffic on the Internet. Since the above scheme uses out-of-band key management and newer ESP (which includes authentication), it has lower overhead. ------------- End Forwarded Message ------------- From owner-ipsec Wed May 20 05:42:00 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id FAA20619 for ipsec-outgoing; Wed, 20 May 1998 05:39:48 -0400 (EDT) Message-Id: <199805200949.SAA21424@isl.rdc.toshiba.co.jp> To: IP Security List Subject: Re: combining SA proposals in IKE [was: Some questions] In-reply-to: lmccarth's message of "Tue, 19 May 1998 01:06:56 -0400." <35611370.500F@cs.umass.edu> Date: Wed, 20 May 1998 18:49:41 +0900 From: FUKUMOTO Atsushi Sender: owner-ipsec@ex.tis.com Precedence: bulk Lewis McCarthy wrote regarding same KEYMAT for both direction: > If AH or tunnel-mode ESP with authentication is used, then I don't see how > deriving the keys for each direction from the same KEYMAT would allow a > successful cut-and-paste replay attack. In AH the ICV is computed over the src : > Transport-mode ESP-with-auth is only designed to protect upper protocol layer > info, not IP layer info (uh, with the possible exception of some IPv6 > destination options). So it's not trying to provide IP-layer data origin > authentication. What I had in my mind was this: if transport-mode ESP-with-auth is used, and if KEYMAT are same for both direction (and I can detect this easily since SPI are in clear text), I can extract the whole ESP data (header and payload), add new IP header, and inject into the opposite flow of stream. It will pass the ICV check since KEYMAT are same, and replay-protection sequence number is accepted since it passed ICV check (although this may depend on implementation or security policy detail...). Since the replay-protection sequence number was updated, the next legitimate packet to this SA will be rejected, resulting degrade or denial of service. Of course, IKE draft says: Different SPIs for each SA (one chosen by the initiator, the other by the responder) guarantee a different key for each direction. So I guess this is a moot point. (Although I feel it should be explicitly stated as a MUST.) FUKUMOTO Atsushi fukumoto@isl.rdc.toshiba.co.jp From owner-ipsec Wed May 20 12:50:55 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA22162 for ipsec-outgoing; Wed, 20 May 1998 12:47:58 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <35611370.500F@cs.umass.edu> References: <199805190127.KAA29485@isl.rdc.toshiba.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 20 May 1998 12:55:39 -0400 To: Lewis McCarthy From: Stephen Kent Subject: Re: combining SA proposals in IKE [was: Some questions] Cc: IP Security List , FUKUMOTO Atsushi Sender: owner-ipsec@ex.tis.com Precedence: bulk Lewis, Well, we do try to provide IP layer data origin authentication, as this info is important to higher layer protocols. The inbound SAD checks against the selectors used for the SA are part of this, to prevent an authorized sender from relabeling traffic as being from a different sender. So, I think we do need to prevent looping attacks even for transport mode ESP. Using different keys for each direction does this pretty well. Perhaps we ought to tighten the KEYMAT specs to fix this potential problem. >Transport-mode ESP-with-auth is only designed to protect upper protocol layer >info, not IP layer info (uh, with the possible exception of some IPv6 >destination options). So it's not trying to provide IP-layer data origin >authentication. > >Just using ESP without an auth algorithm is asking for this type of trouble, >as noted in the ESP document. Steve From owner-ipsec Wed May 20 13:02:17 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA22189 for ipsec-outgoing; Wed, 20 May 1998 12:59:58 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <35608E01.B0725AFB@cosinecom.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 20 May 1998 13:15:09 -0400 To: Abraham R Matthews From: Stephen Kent Subject: Re: [Q] SA lookup on receive Cc: Stephen Kent , ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Abbie, >I agree that the SA MUST be a tunnel mode if the SA was between >the IPSec host/gateway and the IPSec gateway. However. I am >considering the case where the SA is between 2 IPSec hosts and >one of the routers in between is an IPSec gateway. The host _does >not_ have an SA with the IPSec gateway. If neither host is a party to an SA with the security gateway, then processing of these transit packets is based on SPD entries defined for BYPASSed traffic. >In this case, the IPSec gateway receives an IPSec packet ... but >the destination address in the "outer" header (or the header in >the clear) is NOT one of the local addresses of the gateway. No problem. If an inbound packet is not addresses to the SG, it will be looked up in the SPD based on the selectors extracted from the outer header. If local policy allows transit of IPsec traffic, there should be an entry that calls for this traffic to be bypassed. In this case, no IPsec processing is applicable, so the discussion on inbound traffic processing in section 5.2 does not apply. We could do a better job of describing inbound processing for transit traffic for security gateways. Sorry for the confusion. >A strict reading of the security architecture document would >cause this packet to be dropped. Thus the request for the >clarification. As I see it the input processing for the IPSec >gateway probably should be: > > If (not an IPSec packet) > { > look up in SPD and process accordingly > } > else > { > if (the destination is not local) > look up in SPD and process accordingly > else > look up in SAD and process according to >ID I would not make the top level decision based on whether the packet had AH or ESP as the next protocol. The first decision is based on whether the packet is addressed to the SG or not. If not, then lookup in the SPD to see whether the packet is to be bypassed or discarded. Otherwise, if it is addressed to the SG, and if it is IPsec, ... Steve From owner-ipsec Wed May 20 15:12:45 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA22706 for ipsec-outgoing; Wed, 20 May 1998 15:09:02 -0400 (EDT) From: Cliff Wang To: Subject: mutiple phase 1 tunnel and proxy ID issues Message-ID: <5040200015281705000002L052*@MHS> Date: Wed, 20 May 1998 15:29:10 -0400 MIME-Version: 1.0 Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk I have the following questions on ISAKMP/IPsec: 1)Multiple Phase 1 tunnels between a pair of ISAKMP entities. Suppose GW1 and GW2 are ISAKMP peers and are configured with security policies. If multiple Phase 1 SAs are established between them, and assuming the IDii and IDir are the same for each of the Phase 1 SAs. When a phase 2 SA needs to be negotiated, how to decide which phase 1 SA to use? A related question is do we really need multiple phase 1 SAs between the same pair of ISAKMP peers? 2) Phase 1 ID Suppose the ISAKMP engine is on a multi-homed host, such as a router, which can talk with multiple peers of different subnet, do we need different local IDs for each subnet ? Is there an advantage to use different IDs for different subnet or just use one ID for every peer? On the hand, when the ISAKMP engine is an end host with one IP address, do we need more than one local IDs when he talks to the same peer or just one local ID? I think this boils down the policy configuration in terms how much granuality is given to the phase 1 policy setup. I would appreciate feedbacks based on implementation experience. 3)Phase 2 Proxy ID For Phase 2 negotiation, the ID payload can be of type "fully qualified user name string", such as piper@foo.com. Even we can negotiated the phase 2 SA successfully, the negotiated SA can not be used to protect packets until the user name is turned into some IP address(host, range, subnet). How do we solve this user name to IP address mapping? Assuming the user is mobile, this mapping can be quite dynamic. Thanks! Cliff Wang IBM cxwang@us.ibm.com 919 486 1255 From owner-ipsec Wed May 20 15:45:47 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA22805 for ipsec-outgoing; Wed, 20 May 1998 15:43:58 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <5040200015281705000002L052*@MHS> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 20 May 1998 15:59:01 -0400 To: Cliff Wang From: Stephen Kent Subject: Re: mutiple phase 1 tunnel and proxy ID issues Cc: Sender: owner-ipsec@ex.tis.com Precedence: bulk Cliff, I'll address this last issue, and leave the former 2 to the IKE experts. >3)Phase 2 Proxy ID >For Phase 2 negotiation, the ID payload can be of >type "fully qualified user name string", such as >piper@foo.com. Even we can negotiated the phase 2 >SA successfully, the negotiated SA can not be used >to protect packets until the user name is turned into >some IP address(host, range, subnet). How do we >solve this user name to IP address mapping? Assuming >the user is mobile, this mapping can be quite dynamic. When an SA is established and a name form other than an IP addres is used to authenticate the peer, it will be necessary to create a dynamic SPD entry (as well as the usual SAD entry) that specifies the (dynamically-assigned) address of the peer. For inbound traffic, the SAD entry (selected by the SPI/dest addr/protocol triple) is used to perform the necessary selector checks after IPsec primary processing. For outbound traffic, the newly created SPD entry is used to vector traffic to the right SA (SAD entry). There needs to be a housekeeping function to remove the SAD entry afterwards, but there does not seem to be a security problem if the same dynamic address is assigned to a new peer, since the keying material would be different and the SA establishment procedure should detect the SPD reuse. Steve From owner-ipsec Wed May 20 16:06:45 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA22871 for ipsec-outgoing; Wed, 20 May 1998 16:04:59 -0400 (EDT) From: Cliff Wang To: Cc: Subject: Re: mutiple phase 1 tunnel and proxy ID issues Message-ID: <5040200015283906000002L062*@MHS> Date: Wed, 20 May 1998 16:25:50 -0400 MIME-Version: 1.0 Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk Steve, I totally agree what you have replied in the mail. Actually my question is that if user name instead of IP address is used in the ID payload of phase 2 negotiation, even if a Phase 2 SA is negotiated successfully, we cannot create a SPD entry since user ID cannot be used to process packet. We need to turn that ID into address in order to create a SPD entry. But I am not sure how to map that ID into an IP address. This is a practical case when two mobile user logs into two different ISP box, get a dynamic address and they want to have their data traffic protected. The ISP boxes's policy can only be configured with the mobile user's ID, since their address are dynamically assigned. The ISP boxes can negotiate a Phase 2 SA with ID, but then they somehow need to exchange user ID to IP address mapping to each other. Otherwise SPD entry can not be created. Thanks, cliff kent@bbn.com on 05/20/98 04:02:45 PM Please respond to kent@bbn.com To: Cliff Wang/Raleigh/IBM@ibmus cc: ipsec@tis.com Subject: Re: mutiple phase 1 tunnel and proxy ID issues Cliff, I'll address this last issue, and leave the former 2 to the IKE experts. >3)Phase 2 Proxy ID >For Phase 2 negotiation, the ID payload can be of >type "fully qualified user name string", such as >piper@foo.com. Even we can negotiated the phase 2 >SA successfully, the negotiated SA can not be used >to protect packets until the user name is turned into >some IP address(host, range, subnet). How do we >solve this user name to IP address mapping? Assuming >the user is mobile, this mapping can be quite dynamic. When an SA is established and a name form other than an IP addres is used to authenticate the peer, it will be necessary to create a dynamic SPD entry (as well as the usual SAD entry) that specifies the (dynamically-assigned) address of the peer. For inbound traffic, the SAD entry (selected by the SPI/dest addr/protocol triple) is used to perform the necessary selector checks after IPsec primary processing. For outbound traffic, the newly created SPD entry is used to vector traffic to the right SA (SAD entry). There needs to be a housekeeping function to remove the SAD entry afterwards, but there does not seem to be a security problem if the same dynamic address is assigned to a new peer, since the keying material would be different and the SA establishment procedure should detect the SPD reuse. Steve From owner-ipsec Wed May 20 16:40:34 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA22938 for ipsec-outgoing; Wed, 20 May 1998 16:37:59 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <5040200015283906000002L062*@MHS> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 20 May 1998 16:52:16 -0400 To: Cliff Wang From: Stephen Kent Subject: Re: mutiple phase 1 tunnel and proxy ID issues Cc: Sender: owner-ipsec@ex.tis.com Precedence: bulk Cliff, >I totally agree what you have replied in the mail. Actually >my question is that if user name instead of IP address is >used in the ID payload of phase 2 negotiation, even if > a Phase 2 SA is negotiated successfully, we cannot >create a SPD entry since user ID cannot be used to >process packet. We need to turn that ID into address >in order to create a SPD entry. But I am not sure how >to map that ID into an IP address. This is a practical case >when two mobile user logs into two different ISP box, >get a dynamic address and they want to have their >data traffic protected. The ISP boxes's policy can only be >configured with the mobile user's ID, since their >address are dynamically assigned. The ISP boxes >can negotiate a Phase 2 SA with ID, but then they >somehow need to exchange user ID to IP address >mapping to each other. Otherwise SPD entry can not be >created. Sorry. I forgot to address that important detail. The address for the remote peer should be acquired from the inner IP header (it's a security gateway, so we must be using tunnel mode) of the client traffic. It would be cleaner if IKE expressly stated the address, but lacking that one can grab the first inbound packet for the SA (it must come from the remote peer since the SG and the clients behind it don't know the address yet) and extract the address to fill in the SPD and SAD entries re the IP address selectors. Other selectors, if applicable, could have been filled in from the name-based SPD entry. Steve From owner-ipsec Wed May 20 17:00:55 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA23026 for ipsec-outgoing; Wed, 20 May 1998 16:58:59 -0400 (EDT) From: Cliff Wang To: Subject: Re: mutiple phase 1 tunnel and proxy ID issues Message-ID: <5040200015286331000002L012*@MHS> Date: Wed, 20 May 1998 17:19:21 -0400 MIME-Version: 1.0 Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk Steve, It seems that both gateway needs to be informed the two mobiles user's addresses. Otherwise you will not be able to add the outbound SPD entry for client traffic. Of cource when outbound SPD entry is there, then traffic can be sent to the peer. The peer can use inner header to get address in order to add inbound SPD entry. But this creates a security hole since you are using inbound traffic to generate inbound SPD entry. I would think the inbound SPD entry should be created before inbound IPsec packet processing. Anyway it seems to me that when user names are used in IKE phase 2 negotiations, we need some mechanism to resolve the IDs to IP addresses before SPD entries can be created to process traffic. Unfortunately the usuage of IDs in the IPsec is a a fairly complicated issue which deserves more look into it. Thanks, cliff kent@bbn.com on 05/20/98 04:47:34 PM Please respond to kent@bbn.com To: Cliff Wang/Raleigh/IBM@ibmus cc: ipsec@tis.com Subject: Re: mutiple phase 1 tunnel and proxy ID issues Cliff, >I totally agree what you have replied in the mail. Actually >my question is that if user name instead of IP address is >used in the ID payload of phase 2 negotiation, even if > a Phase 2 SA is negotiated successfully, we cannot >create a SPD entry since user ID cannot be used to >process packet. We need to turn that ID into address >in order to create a SPD entry. But I am not sure how >to map that ID into an IP address. This is a practical case >when two mobile user logs into two different ISP box, >get a dynamic address and they want to have their >data traffic protected. The ISP boxes's policy can only be >configured with the mobile user's ID, since their >address are dynamically assigned. The ISP boxes >can negotiate a Phase 2 SA with ID, but then they >somehow need to exchange user ID to IP address >mapping to each other. Otherwise SPD entry can not be >created. Sorry. I forgot to address that important detail. The address for the remote peer should be acquired from the inner IP header (it's a security gateway, so we must be using tunnel mode) of the client traffic. It would be cleaner if IKE expressly stated the address, but lacking that one can grab the first inbound packet for the SA (it must come from the remote peer since the SG and the clients behind it don't know the address yet) and extract the address to fill in the SPD and SAD entries re the IP address selectors. Other selectors, if applicable, could have been filled in from the name-based SPD entry. Steve From owner-ipsec Thu May 21 08:40:55 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA25227 for ipsec-outgoing; Thu, 21 May 1998 08:36:07 -0400 (EDT) Date: Tue, 19 May 1998 15:24:28 -0700 (PDT) From: Vipul Gupta Reply-To: Vipul Gupta Subject: =?US-ASCII?Q?ISAKMP_configuration=04and_Mobile-IP?= To: mobile-ip@smallworks.com Cc: vgupta@nobel.Eng.Sun.COM, ipsec@tis.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: JIPa64K55MVL9BYWSKIYlA== X-Mailer: dtmail 1.1.0 CDE Version 1.1 SunOS 5.5.1 sun4u sparc Sender: owner-ipsec@ex.tis.com Precedence: bulk During Roy Pereira's presentation of at the LA IETF, one of the questions raised was the interaction of the proposed mechanisms with Mobile IP [RFC2002]. Here are some thoughts on the subject. The quick summary is that the two protocols can work well together provided the Mobile IP implementation on the mobile node is careful in its selection of a co-located care-of address. No changes are necessary at the home agent. vipul --------------------- Details follow ------------------------ Roy's draft "The ISAKMP Configuration Method" describes a mechanism by which a nomadic host on the Internet (e.g. a corporate employee "on the road") acquire an "internal address" belonging to a protected network (e.g. the firewall-protected corporate network) and communicate securely with other hosts on the protected network. Keys and security associations necessary to protect such communication are negotiated through IKE. For the rest of this discussion, IKE+ refers to IKE plus the ISAKMP Configuration method. In this case, the "external" nomadic host is assigned two addresses: one belonging to the protected network (negotaited via ISAKMP Configuration), and (2) a topologically significant address on the Internet (assigned by an ISP through DHCP, PPP, or manual intervention). It is certainly possible to set things up so that a nomadic host always acquires the same "internal" IP address whenever it is out on the Internet. This is enough to emulate a limited type of "mobility support" -- no matter where the portable computer is on the Internet, it will be reachable at the same "internal" address. Here IKE+ is used to "register" the portable computer's "care-of address" with the IPSec gateway and to set up a (IPSec) tunnel between the gateway and the portable computer. With this mechanism, however, mobility support is only available for addresses that are normally routed to the IPSec gateway within the protected network. When the portable computer is moved inside the corporate network (say at the employee's office desk), it would typically use a different address (one that is not routed to the gateway). To allow the portable computer to use the same IP address within the protected network and outside on the Internet, one could do the following: - Use the topologically significant address to initiate IKE+ with the IPSec gateway and acquire an "internal" address valid within the protected network (call it I). After this negotiation, the portable computer will be able to communicate securely with all hosts within the protected network. Its communication partners within the protected network will see communications originating from I. - Use the newly acquired address (I) as a co-located care-of address for normal Mobile IP registration. The Mobile IP implementation MUST not register its topologically significant address since there is no guarantee that this external address will be reachable from the home agent (which may be well inside the protected network). Many protected networks keep internal routers unaware of external addresses, nor do they use default routing to carry packets for such external addresses to the periphery gateway. This automatically implies that Mobile IP must be able to distinguish between "internal" and "external" addresses. The following packet flow diagrams illustrate how the overall scheme would work. The relative positions of the portable computer, the IPSec gateway and the home agent are assumed to be: | Protected Net | Internet | Home Agent IPSec Gateway Portable | computer | | These figures also assume that a mobile host uses reverse tunneling [RFC 2344] to tunnel traffic for correspondent nodes through its home agent and that ESP* (newer ESP with authentication) is used to protect traffic on the Internet. I: An "internal" address acquired by the portable computer through the ISAKMP configuration method T: The topologically significant address of the portable computer. It identifies its current point of attachment to the Internet. MN: The portable computer's "home address". This is the address at which the portable computer is always reachable if it uses Mobile IP. GW: An "external" address at which the IPSec gateway is reachable from hosts on the Internet. HA: home agent CN: correspondent node (a communication partner of the mobile node). a->b: An IP header in which a is the source and b is the destination. Registration request: ==================== From portable computer to IPSec gateway (across the Internet) |<- This part->|<-- This part generated ->| generated by by Mobile IP IPSec <--------- +--------+-----+----------+--------------+ | T->GW | ESP*| I -> HA | UDP reg req | +--------+-----+----------+--------------+ outer IP inner IP From IPSec gateway to home agent (within the protected network) <--------- +----------+--------------+ | I -> HA | UDP reg req | +----------+--------------+ Registration reply: ================== From home agent to IPSec gateway (within the protected network) ---------> +--------------+----------+ | UDP reg req | HA -> I | +--------------+----------+ From IPSec gateway to portable computer (across the Internet) --------> +--------------+----------+-----+--------+ | UDP reg req | HA -> I | ESP*| GW->T | +--------------+----------+-----+--------+ inner IP outer IP Outer IP and ESP* are consumed by IPSec, the rest of the pkt is processed by Mobile IP. Data transfer from Mobile host to a correspondent node: ====================================================== From portable computer to IPSec gateway (across the Internet) |<-- gen. by ->|<-Generated by Mobile IP->| IPSec <--------- +--------+-----+----------+--------+-----+ | T->GW | ESP*| I -> HA | MN->CN | ULP | +--------+-----+----------+--------+-----+ outer IP Inner IP From IPSec gateway to home agent (within the protected network) <--------- +----------+--------+-----+ | I -> HA | MN->CN | ULP | +----------+--------+-----+ From home agent to correspondent node (the exact location of the CN is unspecified and the mechanism used to deliver packets to the CN is the same as that used when the mobile node is "at home"). <--------- +--------+-----+ | MN->CN | ULP | +--------+-----+ Data transfer from the correspondent node to the mobile node: ============================================================ From the correspondent node to the home agent ---------> +-----+--------+ | ULP | MN->CN | +-----+--------+ From the home agent to the IPSec gateway (within the protected network) ---------> +-----+--------+----------+ | ULP | CN->MN | HA -> I | +-----+--------+----------+ From the IPSec gateway to the portable computer (across the Internet) MIP hdr --------> +-----+--------+----------+-----+--------+ | ULP | CN->MN | HA -> I | ESP*| T->GW | +-----+--------+----------+-----+--------+ innermost IP outermost IP Again, the outermost IP and ESP* are consumed by IPSec and the rest is processed by Mobile IP. These packet formats are very similar to (but not the same as) those described in ("Firewall Support for Mobile IP", Montenegro and Gupta). The use of multiple tunnels and IPSec increases the size of packets and their processing time. The performance impact of these changes is discussed in "Secure And Mobile Networking", Gupta and Montenegro, available from http://playground.sun.com/pub/mobile-ip/. That paper uses SKIP (in-line keying) and separate ESP and AH headers (old style) to secure traffic on the Internet. Since the above scheme uses out-of-band key management and newer ESP (which includes authentication), it has lower overhead. From owner-ipsec Thu May 21 08:50:34 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA25390 for ipsec-outgoing; Thu, 21 May 1998 08:50:05 -0400 (EDT) Date: Wed, 20 May 1998 11:09:56 +0900 (JST) Message-Id: <199805200209.LAA10667@kame206.kame.net> From: Ne To: ipsec@tis.com Subject: the tunnel mode who change address family. Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Mailer: mnews [version 1.21PL3] 1998-04/12(Sun) Sender: owner-ipsec@ex.tis.com Precedence: bulk Is there a IP packet applied the tunnel mode of ESP or AH whoes outer header is IPv6 and inner header is IPv4, and is there the reverse that ? e.g. [IPv6][ESP][IPv4][upper] [IPv4][AH][IPv6][upper] If existence, Where are any field copied ? Regards. ----------------------------------------- Shoichi 'NE' Sakane From owner-ipsec Thu May 21 08:57:36 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA25622 for ipsec-outgoing; Thu, 21 May 1998 08:57:07 -0400 (EDT) Date: Thu, 21 May 1998 08:14:08 +0200 Message-Id: <199805210614.IAA01785@mir3.ida.liu.se> To: ipsec@tis.com From: Yahya Al-Salqan Subject: Enterprise Security Workshop: Call for participation Sender: owner-ipsec@ex.tis.com Precedence: bulk ============================================================= Call for Participation: IEEE WET ICE '98 Third International Workshop on Enterprise Security Stanford University, Palo Alto, USA June 17-19 1998 ============================================================= On behalf of the Workshop Program and Organizing Committees, I would like to invite you to participate in The 3rd IEEE International Enterprise Security Workshop to be held on June 17-19, Stanford University, Palo Alto, California. The Workshop includes paper presentations, panel discussions, keynote speeches and invited talks covering all aspects of enterprise security. Topics to be covered include: Public key infrastructure, intrusion detection, Web security, application security (e.g. digital library and health care), and access control. Highlights of the program: o Keynote speech by Dr. Li Gong, Java Security Architect, Sun Microsystems; o Industrial security expertise from: Microsoft NT security group, Sun Microsystems, Entrust, Certicom, Verisign, SSH Communication security and many others. It is an unprecedented opportunity to put all these companies in one room. Don't miss it. o Participation of IETF security group leaders; o Participation of NSA (National Security Agency); o Two panel discussions: - "State-of-the-art Enterprise Security: Practice and Future" - "Intrusion Detection: Present and Future" o Workshop is held in conjunction with other WETICE workshops: - "Web-based infrastructure for collaborative Enterprises," - "Collaboration in Presence of Mobility," o Two social events. The Workshop Preliminary program can be found at: http://www.ida.liu.se/labs/iislab/SECWK/agenda.html The Registration form can be found at: http://www.cerc.wvu.edu/WETICE/WETICE98/registration.html (Please mark the Enterprise Security Workshop on the registration form) The Workshop main page can be found at: http://www.ida.liu.se/labs/iislab/SECWK/ I look forward to meeting you at the Workshop. Sincerely, Yahya Al-Salqan, Ph.D. Workshop General Chair Sun Microsystems From owner-ipsec Thu May 21 15:41:13 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA27254 for ipsec-outgoing; Thu, 21 May 1998 15:38:22 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <199805200209.LAA10667@kame206.kame.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 21 May 1998 15:52:09 -0400 To: Ne From: Stephen Kent Subject: Re: the tunnel mode who change address family. Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Shoichi, >Is there a IP packet applied the tunnel mode of ESP or AH >whoes outer header is IPv6 and inner header is IPv4, >and is there the reverse that ? > >e.g. > [IPv6][ESP][IPv4][upper] > [IPv4][AH][IPv6][upper] > >If existence, Where are any field copied ? Section 5.1.2 of the Architecture Document provides guidance on what fields are copied to the outer headers from the inner headers under these mixed version circumstances. Steve From owner-ipsec Fri May 22 10:19:49 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA01082 for ipsec-outgoing; Fri, 22 May 1998 10:13:51 -0400 (EDT) Message-Id: <199805221414.KAA03664@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; Cc: ipsec@tis.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-isakmp-xauth-02.txt Date: Fri, 22 May 1998 10:14:09 -0400 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 : Extended Authentication Within ISAKMP/Oakley Author(s) : R. Pereira Filename : draft-ietf-ipsec-isakmp-xauth-02.txt Pages : 10 Date : 21-May-98 This document describes a method for using existing unidirectional authentication mechanisms such as RADIUS, SecurID, and OTP within IPSec's ISAKMP protocol. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-isakmp-xauth-02.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipsec-isakmp-xauth-02.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: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-isakmp-xauth-02.txt". NOTE: The mail server at ietf.org 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@ietf.org" Content-Type: text/plain Content-ID: <19980521150842.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-isakmp-xauth-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-isakmp-xauth-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980521150842.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec Fri May 22 10:19:52 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA01088 for ipsec-outgoing; Fri, 22 May 1998 10:13:56 -0400 (EDT) Message-Id: <199805221414.KAA03683@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; Cc: ipsec@tis.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-isakmp-mode-cfg-04.txt Date: Fri, 22 May 1998 10:14:14 -0400 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 ISAKMP Configuration Method Author(s) : B. Patel, R. Pereira, S. Anand Filename : draft-ietf-ipsec-isakmp-mode-cfg-04.txt Pages : 12 Date : 21-May-98 This document describes a new ISAKMP method that allows configuration items to be exchanged securely by using both push/acknowledge or request/reply paradigms. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-isakmp-mode-cfg-04.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipsec-isakmp-mode-cfg-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: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-isakmp-mode-cfg-04.txt". NOTE: The mail server at ietf.org 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@ietf.org" Content-Type: text/plain Content-ID: <19980521151207.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-isakmp-mode-cfg-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-isakmp-mode-cfg-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980521151207.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec Fri May 22 15:13:59 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA02414 for ipsec-outgoing; Fri, 22 May 1998 15:08:46 -0400 (EDT) Message-Id: <3.0.5.32.19980522152116.00a26400@homebase.htt-consult.com> X-Sender: rgm-sec@homebase.htt-consult.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Fri, 22 May 1998 15:21:16 -0400 To: ipsec@tis.com From: Robert Moskowitz Subject: Items for new charter Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk Yes, i know that the current IDs are just dragging along. getting the 'last' nits in so they can get published. Ted is doing a good job of bird-dogging that effort, and it is past time to write the new charter. To this end, I have put together a list of items that looks reasonable to tackle. I want people to review them, and comment/subtract/add. then I will rough out a new charter for the group. 1) fix broken but usable Tero's issue with IKE. Rekeying (well not so much as broke, but do we have the heuristic right?) 2) desperately needed functionality Host bootstrap (config) Extended Authentication Policy/tunnel endpoint discovery Attribute Certs? KX records? ICMP messages? Something else? ICMP messages (TTL exceeded, port/host unreachable, admin denied, ipsec-specific). 3) wise things to do PMTU (Path MTU) for tunnels Standardized error codes MIBs HMAC-RIPEM (EU wants THEIR standards included, reasonably enough) 4) nice touches. MAC-DES Other encryption algorithms Other key exchange protocols Simple and advanced crypto API Dynamic discovery of complex ipsec topologies. Robert Moskowitz ICSA Security Interest EMail: rgm-sec@htt-consult.com From owner-ipsec Fri May 22 16:29:15 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA02861 for ipsec-outgoing; Fri, 22 May 1998 16:28:04 -0400 (EDT) Date: Fri, 22 May 1998 16:42:58 -0400 Message-Id: <199805222042.QAA03013@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: ipsec@tis.com Subject: Thomas Narten's DISCUSS vote Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: owner-ipsec@ex.tis.com Precedence: bulk Unfortunately, we had a little bureacratic mess-up. Thomas Narten, one of the Internet AD's, sent in his formal DISCUSS vote late (Friday night). Jeff had already fowarded me an earlier message which we thought outlined all of Thomas's objections, and then Narten's formal DISCUSS vote never was forwarded on to me (or to anyone else on the working group), until this week. Grump, grump, grump, grump, grump. A few of the items will likely require making a few changes to a number of the documents, and I apologize to the working group editors for having to make yet more round of changes. They should fortunately be quite limited, as we are not open to making any other changes to these drafts at this time. I've made an initial overview through his objections, and have made some comments below. Could the document editors for the Arch-SEC, AH, ESP, DOI, ISAKMP, and IKE please look at his objections and make corrections please? Aside from those places where I've pointed text that Narten had missed, I think most of his proposed complaints are reasonable ones to make. The only one which may be somewhat contentions is the TTL sequence number decrementing, but I advised Charlie to take this issue to the IESG two weeks ago, so hopefully if there is going to be any clarification from the Routing gods, we'll hear from them soon. If someone thinks one of Thomas's objections should NOT be handled in the obvious way, please let us know of your objections immediately, so that we not add any further delay to the process. Again, I beg the working group's indulgence for this last minute set of objections that we didn't have a chance to deal with; hopefully we can satisfy the IESG members and get these darned documents published once and for all! - Ted >From: Thomas Narten >To: iesg@ietf.org >Date: Fri, 24 Apr 1998 17:55:25 -0400 >Subject: Re: Ballot: Security Architecture for the Internet Protocol to Proposed Standard > >Apologies for the delay. > > Yes No-Objection Discuss * Abstain >Thomas Narten [ ] [ ] [X ] [ ] > >> o Security Architecture for the Internet Protocol [PROPOSED] >> > >page 7, paragraph on IPPCP should be updated. Work is done, there are >drafts/RFCs to reference. WG will be shut down as soon as IPSec >documents are out. This is an RFC editor function. The RFC number (to our knowledge) has not been assigned yet. >Text relating to decrementing TTL of inner header of encapsulated >packet needs clarification. Text should be clarified to say TTL >decremented only if packet was forwarded (i.e., the forwarding >operation is what decrements the TTL, not the fact that a complete IP >packet is being encapsulated again upon entry to an IPSec tunnel). If >packet originates from node, TTL is left unchanged. This is consistent >with the current general practice of when to decrement TTLs, and some >aspects of IPv6 protocols (i.e, ND) depend on it. My understanding is that everyone is implementing this anyway. Thomas in a later message suggested the following clarification, to be added after the text which described when the TTL in the inner header should be decremented: Note: The decrementing of the TTL is one of the usual actions that takes place when forwarding a packet. Packets originating from the same node as the encapsulator do not have their TTLs decremented, as the sending node is originating the packet rather than forwarding it. Charile Lynn has sent mail dissenting, claiming that it would be a bad thing to do this since it would imply that this would imply that IPSEC tunnels change the Internet Routing Topology, and if so, they might have to conform to all requirements for Internet Routers. (I don't think that's the case today for normal IP-IP tunnels, is it?) Not clear what's the best way to resolve it. If Charlie is right that this has some bad architectural implications, can we please get some Internet Routing experts to explain to us exactly what the problem is please? (and quickly). If my sense that everyone is implementing it the way Thomas and what apparently what most of the IPV6 working group wants, then we might as well document that in the spec. My instincts are to document what people are actually implementing and shipping as products, and if it's a problem we can fix it later. This is *only* a proposed standard folks ---- we don't have to wait until it is perfect (and the technology obsolete) before we ship it. >> o PMTU message with >64 bits of IPsec header -- If the ICMP message >> contains more information from the original packet, e.g., the 576 >> byte minimum for IPv6, then there MAY be enough non-opaque >> information to immediately determine to which host to propagate the >> ICMP/PMTU message and to provide that system with the 5 fields >> (source address, destination address, source port, destination >> port, transport protocol) needed to determine where to store/update >> the PMTU. Under such circumstances, a security gateway MUST >> generate an ICMP PMTU message immediately upon receipt of an ICMP >> PMTU from further down the path. > >reference to 576 byte MTU in IPv6 should be dropped (since it is >incorrect per the latest drafts). Reference is probably irrelevant to >the point being made here anyway, so it can easily be removed (i.e., >no need to reference the value itself). sure... > >> IP Authentication Header [PROPOSED] >> > > >> As a new extension header or IPv4 option is created, it will be >> defined in its own RFC and SHOULD include (in the Security >> Considerations section) directions for how it should be handled when >> calculating the AH ICV. If the IPsec implementation encounters an >> extension header that it does not recognize, it MUST zero the whole >> header except for the Next Header and Hdr Ext Len fields. The length >> of the extension header MUST be computed by 8 * Hdr Ext Len value + >> 8. If the IPsec implementation encounters an IPv4 option that it >> does not recognize, it should zero the whole option, using the second >> byte of the option as the length. (IPv6 options contain a flag >> indicating mutability, which determines appropriate processing for >> such options.) > >Text regarding processing of unknown extension options seems wrong >(there are bits in header saying whether field is mutable). Sync up >with IPv6 documents. Note: IPv6 document says "mutable" rather than >"has predicatble value at receiver" > >Note: I've sent mail to IPng chairs seeking clarification. This has been dealt with. >> 3.3.2 Sequence Number Generation >> >> The sender's counter is initialized to 0 when an SA is established. >> The sender increments the Sequence Number for this SA and inserts the >> new value into the Sequence Number Field. Thus the first packet sent >> using a given SA will have a Sequence Number of 1. >> >> If anti-replay is enabled (the default), the sender checks to ensure >> that the counter has not cycled before inserting the new value in the >> Sequence Number field. In other words, the sender MUST not send a >> packet on an SA if doing so would cause the Sequence Number to cycle. >> An attempt to transmit a packet that would result in Sequence Number >> overflow is an auditable event. (Note that this approach to Sequence >> Number management does not require use of modular arithmetic.) >> >> If anti-replay has been disabled, the sender does not need to monitor >> or reset the counter, e.g., in the case of manual key management. > >Clarify last sentence. Is sender *always* required to increment >sequence number? Or does disable mean always sends the same one (which >may cause interoperability problems with receivers)? > >I would guess that the intent is that you always increment, and the >anti-replay simply disables the deletion of the SA when the sequence >number cycles back to 0. Once the replay counter reaches its max >value, it "sticks". Or does the counter simply contain a random value? >I just can't quite tell from the text. > >Another way of clarifying this to me is if there was clear text that >says: anti-replay should be enabled only if the sender has specific >knowledge that the receiver ignores the replay counter (i.e., the >information has been negotiated via ISAKMP or manual configuration). I thought this was pretty obvious to all implementors. If anti-reply has been disable, the sequence number still increments, and when you reach the max value, it rolls over to back to zero. Perhaps the use of the vernacular "cycles" is the problem here. The text in the last paragraph pretty clear that in the absense of anti-reply, you just always let the sequence number roll over (and the text in the first paragrph indicates that you always increment). I suppose we can make this even more explicit, since if the Internet AD thought it ambiguous, there's a good chance other folks might also get confused. > >> 3.4.3 Sequence Number Verification > >> If the receiver does not enable anti-replay for an SA, no inbound >> checks are performed on the Sequence Number. The default for the >> sender is that the Sequence Number will be checked at the sender. >> Hence, if an SA establishment protocol such as ISAKMP/Oakley is >> employed, the receiver SHOULD notify the sender, during SA >> establishment, if the receiver will not provide anti-replay >> protection. > >Why SHOULD? what action can the sender take? (this is related to the >above question, no doubt.) The idea here is that the sender should know what security services are being provided (and possibly stop sending if the security services being provided are not to its liking). > >> 5. Conformance Requirements >> >> Implementations that claim conformance or compliance with this >> specification MUST fully implement the AH syntax and processing >> described here and MUST comply with all requirements of the Security >> Architecture document. If the key used to compute an ICV is manually >> distributed, correct provision of the anti-replay service would >> require correct maintenance of the counter state at the sender, until >> the key is replaced, and there likely would be no automated recovery >> provision if counter overflow were imminent. Thus a compliant >> implementation SHOULD NOT provide this service in conjunction with >> SAs that are manually keyed. > >Don't understand above, probably related to my confusion regarding >what is required for sequence counters. The "counter overflow" is referring to the fact that the sequence number rolls over when you increment a 32-bit value with all bits set by one. > > >> IP Encapsulating Security Payload (ESP) [PROPOSED] >> > >Sequence number stuff. If text in AH gets changed (per above) change >should be made here as well. I think it's clear enough, but sure, we can add the same clarifying text to both the AH and ESP documents..... > >> The Internet IP Security Domain of Interpretation for >> ISAKMP [PROPOSED] >> >> > >> 4.4.1.4 PROTO_IPCOMP >> >> The PROTO_IPCOMP type specifies IP payload compression. > >Add explicit reference to draft-ietf-ippcp-protocol-05.txt > >> 4.4.4.4 ESP_RC5 >> >> The ESP_RC5 type specifies the RC5 transform defined in [ESPCBC]. >> >> 4.4.4.5 ESP_IDEA >> >> The ESP_IDEA type specifies the IDEA transform defined in [ESPCBC]. >> >> 4.4.4.6 ESP_CAST >> >> The ESP_CAST type specifies the CAST transform defined in [ESPCBC]. >> >> 4.4.4.7 ESP_BLOWFISH >> >> The ESP_BLOWFISH type specifies the BLOWFISH transform defined in >> [ESPCBC]. > >Are the above required or MAY? (I assume they are optional, adding a >sentence to that effect would be good and consistent.) All algorithsm which are required have MUST's. Can we simply put a blanket statement at the beginning of the session saying that all items which do not explicitly state "MUST implement" are optional? > >> 4.4.5.2 IPCOMP_DEFLATE >> >> The IPCOMP_DEFLATE type specifies the use of the "zlib" deflate >> algorithm. > >Add reference to draft-ietf-ippcp-deflate-03.txt (draft approved by IESG >for publication). > >> >> 4.4.5.3 IPCOMP_LZS >> >> The IPCOMP_LZS type specifies the use of the Stac Electronics LZS >> algorithm. > >Add reference to draft-ietf-ippcp-lzs-04.txt (draft approved by IESG >for publication). > >> 4.4.5.4 IPCOMP_V42BIS >> >> The IPCOMP_V42BIS type specifies the use of V42bis compression. > >Delete this section/definition (and all references to V42bis) per >conversation with Naganand Doraswamy (IPPCP WG Chair). No document >exists or is expected. Sure... > >Section 6.6: resolve inconsistency between IPPCP document and this >one. This has been dealt with. > >> Internet Security Association and Key Management Protocol >> (ISAKMP) [PROPOSED] >> > >references to RFC 1825 need to be updated. I assume that 1825 will be >obsoleted? Yes, references to RFC-1825 should be updated to whatever the RFC of the newly assigned arch-sec document. Doug, you should change this to state draft-ietf-ipsec-sec-arch-xx.txt for now...., to make sure the RFC editor catches these. > >> When transmitting an ISAKMP message, the transmitting entity (initiator or >> responder) MUST do the following: >> >> >> 1. Set a timer and initialize a retry counter. > >Leave timer value, and retransmission issues completely to >implementation? Is this good for Internet? Perhaps add text along the >lines: > >Implementations MUST NOT use a fixed timer. Instead, retransmission >timer values should be adjusted dynamically based on measured round >trip times. In addition, successive retransmissions of the same packet >should be separated by increasingly longer time intervals (e.g., >exponential backoff). Yes, that seems fair criticism. We should make this change. > >> 3. Check the Major and Minor Version fields to confirm they are correct. >> If the Version field validation fails, the message is discarded and >> the following actions are taken: > >Clarify what check is required. If minor numbers don't match, reject? >Accept same major, but lower minor? (or did I miss the text on this >point?) You missed text on this point. See section 3.1, ISAKMP Header Format, where it states: o Major Version (4 bits) - indicates the major version of the ISAKMP protocol in use. Implementations based on this version of the ISAKMP Internet-Draft MUST set the Major Version to 1. Implementations based on previous versions of ISAKMP Internet-Drafts MUST set the Major Version to 0. Implementations SHOULD never accept packets with a major version number larger than its own. o Minor Version (4 bits) - indicates the minor version of the ISAKMP protocol in use. Implementations based on this version of the ISAKMP Internet-Draft MUST set the Minor Version to 0. Implementations based on previous versions of ISAKMP Internet-Drafts MUST set the Minor Version to 1. Implementations SHOULD never accept packets with a minor version number larger than its own, given the major version numbers are identical. >> The Internet Key Exchange (IKE) [PROPOSED] >> > >> IKE implementations MUST support the following attribute values: >> >> - DES-CBC with a weak, and semi-weak, key check (weak and semi- >> weak keys are referenced in [Sch96] and listed in Appendix A). The >> key is derived according to Appendix B. >> >> - MD5 and SHA. >> >> - Authentication via pre-shared keys. The Digital Signature >> Standard SHOULD be supported; RSA-- both signatures and >> authentication with public key encryption-- SHOULD be supported. >> >> - MODP over the default group (see below). ECP and EC2N groups MAY >> be supported. >> > >Clarify MUST/SHOULD for authentication. What part is the SHOULD, what >part is the MUST? (Or am I confused?) I thought it was straightforward. All are MUST's, except for those things listed which are explicitly should's. We can word it more like a legal document to make sure there's no chance anyone could possibly get confused on that point. > >Need reference to PKCS #1 (normative). > >Appendix A: > >add explicit references to documents in places where well known >numbers are "defined", for example: > > - Encryption Algorithm > DES-CBC 1 > IDEA-CBC 2 > Blowfish-CBC 3 > RC5-R16-B64-CBC 4 > 3DES-CBC 5 > CAST-CBC 6 > >This should be done in several places. Sure..... I don't personally think this was worth holding up documents at the PROPOSED STANDARD level, but while we're making changes, we can add the references. > >> The NULL Encryption Algorithm and Its Use With IPsec [PROPOSED] >> > > >> The IPsec Authentication Header [AH] specification provides a similar >> service, by computing authentication data which covers the data >> portion of a packet as well as the immutable in transit portions of >> the IP header. ESP_NULL does not include the IP header in >> calculating the authentication data. This can be useful in providing >> IPsec services through Network Address Translation (NAT) devices and >> non-IP network devices. The discussion on how ESP_NULL might be >> used with NAT and non-IP network devices is outside the scope of this >> document. > >Comment about NAT seems very questionable, since all useful protocols >that run on IP (i.e. TCP/UDP) have a pseudo-header that depends on the >addresses. I suspect the authors were thinking that with the payload >in the clear, NAT could update the checksum. However, the AH check >will not allow that. Suggest removing text. The text is valid; ESP includes integrity protection, although ESP doesn't cover the IP header. In the new IPSEC scheme, it is extremely unlikely that someone will use both ESP and AH. ESP-NULL provides no data confidentiality, but it does provide integrity over the packet data (but not of the IP headers), thus allowing NAT boxes to muck with the IP headers. Whether or not this is a horrible abstraction violation is besides the point; if the goal is to allow NAT boxes to work, while still providing data integrity services for the packet contents, ESP NULL is one way of accomplishing that goal. - Ted From owner-ipsec Fri May 22 16:52:47 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA02962 for ipsec-outgoing; Fri, 22 May 1998 16:52:08 -0400 (EDT) Message-ID: <3565E827.C4F89BE6@ire-ma.com> Date: Fri, 22 May 1998 17:03:35 -0400 From: Bronislav Kavsan X-Mailer: Mozilla 4.03 [en] (WinNT; U) MIME-Version: 1.0 To: ipsec@tis.com Subject: Life and death of IKE SAs and IPSEC SAs Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-MDaemon-Deliver-To: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk There is an important issue which not covered by any draft standards and a subject of the debate between IKE implementors, and that is: Should or shouldn't we delete IPSEC SAs when "umbrella" IKE SA is deleted? The deletion of IKE SA may occur when: 1) It expires on the local host 2) It expires on the remote host which sends re-negotiation proposal to my local host 3) The remote host notifies local host to delete it for whatever reason 4) Local host decides to delete it for whatever reason, 5) etc. Is this behaviour described anywhere in drafts? Is it a matter of local policy? (and if it is - could it create interoperabilty problems?) -- Bronislav Kavsan IRE Secure Solutions, Inc. 100 Conifer Hill Drive Suite 513 Danvers, MA 01923 voice: 978-739-2384 http://www.ire.com From owner-ipsec Fri May 22 17:35:28 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA03079 for ipsec-outgoing; Fri, 22 May 1998 17:34:05 -0400 (EDT) Date: Fri, 22 May 1998 14:42:38 -0700 (PDT) From: Vipul Gupta Reply-To: Vipul Gupta Subject: Re: Thomas Narten's DISCUSS vote To: tytso@MIT.EDU Cc: ipsec@tis.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: DwdbVmEJO1/+xlt94QHpaA== X-Mailer: dtmail 1.1.0 CDE Version 1.1 SunOS 5.5.1 sun4u sparc Sender: owner-ipsec@ex.tis.com Precedence: bulk I think Tom's comment is valid. Even when used with NULL encryption, ESP's integrity check will include the TCP/UDP header and, in particular, the TCP/UDP checksum field. Since this checksum is computed over a pseudoheader which includes the IP src and destination, a NAT box would need to update the checksum whenever it updates the IP src/dst fields. Unless the NAT box has knowledge of the SA parameters protecting the traffic, one of two things will happen: - IP src/dst is updated but not the checksum => transport checksum failure at the receiver - NAT box changes IP src/dst and updates checksum => ESP integrity failure at the receiver vipul > > > >> The NULL Encryption Algorithm and Its Use With IPsec [PROPOSED] > >> > > > > > >> The IPsec Authentication Header [AH] specification provides a similar > >> service, by computing authentication data which covers the data > >> portion of a packet as well as the immutable in transit portions of > >> the IP header. ESP_NULL does not include the IP header in > >> calculating the authentication data. This can be useful in providing > >> IPsec services through Network Address Translation (NAT) devices and > >> non-IP network devices. The discussion on how ESP_NULL might be > >> used with NAT and non-IP network devices is outside the scope of this > >> document. > > [Tom Narten wrote:] > >Comment about NAT seems very questionable, since all useful protocols > >that run on IP (i.e. TCP/UDP) have a pseudo-header that depends on the > >addresses. I suspect the authors were thinking that with the payload > >in the clear, NAT could update the checksum. However, the AH check > >will not allow that. Suggest removing text. [to which Ted Tso responded ...] > The text is valid; ESP includes integrity protection, although ESP > doesn't cover the IP header. In the new IPSEC scheme, it is extremely > unlikely that someone will use both ESP and AH. ESP-NULL provides no > data confidentiality, but it does provide integrity over the packet data > (but not of the IP headers), thus allowing NAT boxes to muck with the IP > headers. > > Whether or not this is a horrible abstraction violation is besides the > point; if the goal is to allow NAT boxes to work, while still providing > data integrity services for the packet contents, ESP NULL is one way of > accomplishing that goal. From owner-ipsec Sun May 24 06:14:33 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id GAA06534 for ipsec-outgoing; Sun, 24 May 1998 06:03:24 -0400 (EDT) From: Gabriel.Montenegro@Eng.Sun.Com Date: Sun, 24 May 1998 03:18:20 -0700 Message-Id: <199805241018.DAA21526@hsmpka.eng.sun.com> To: ipsec@tis.com Reply-To: gab@Eng.Sun.Com X-Mailer: Sun NetMail 2.1.4 Subject: Re: Thomas Narten's DISCUSS vote Sender: owner-ipsec@ex.tis.com Precedence: bulk > Note: The decrementing of the TTL is one of the usual > actions that takes place when forwarding a packet. Packets > originating from the same node as the encapsulator do not > have their TTLs decremented, as the sending node is > originating the packet rather than forwarding it. > >Charile Lynn has sent mail dissenting, claiming that it would be a bad >thing to do this since it would imply that this would imply that IPSEC >tunnels change the Internet Routing Topology, and if so, they might have >to conform to all requirements for Internet Routers. (I don't think >that's the case today for normal IP-IP tunnels, is it?) This is the most persistent zombie ever to haunt the Mobile IP working group. It has been dormant for a while now, and as reported in Jim Solomon's book on Mobile IP, rfc1883 (ipv6) has had a lot to do with this. perhaps this quote from rfc1883 helps clarify things: Note: it is possible, though unusual, for a device with multiple interfaces to be configured to forward non-self-destined packets arriving from some set (fewer than all) of its interfaces, and to discard non-self-destined packets arriving from its other interfaces. Such a device must obey the protocol requirements for routers when receiving packets from, and interacting with neighbors over, the former (forwarding) interfaces. It must obey the protocol requirements for hosts when receiving packets from, and interacting with neighbors over, the latter (non-forwarding) interfaces. The case that concerns us is not quite covered by the above note. Perhaps this addition will suffice: Furthermore, with respect to any of its forwarding interfaces a device behaves as a host when originating or consuming a packet (instead of forwarding it into or out of the interface). Hope this helps, -gabriel From owner-ipsec Sun May 24 06:17:38 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id GAA06551 for ipsec-outgoing; Sun, 24 May 1998 06:12:25 -0400 (EDT) From: Gabriel.Montenegro@Eng.Sun.Com Date: Sun, 24 May 1998 03:26:50 -0700 Message-Id: <199805241026.DAA22149@hsmpka.eng.sun.com> To: ipsec@tis.com Reply-To: gab@Eng.Sun.Com X-Mailer: Sun NetMail 2.1.4 Subject: Re: Thomas Narten's DISCUSS vote Sender: owner-ipsec@ex.tis.com Precedence: bulk "Vipul Gupta" wrote: >Date: Fri, 22 May 1998 14:42:38 -0700 (PDT) > > I think Tom's comment is valid. Even when used with NULL encryption, > ESP's integrity check will include the TCP/UDP header and, Only assuming transport mode ESP. Tunnel mode ESP should work fine. Perhaps this should be mentioned explicitly in the ESP_NULL draft: >> >> The IPsec Authentication Header [AH] specification provides a similar >> >> service, by computing authentication data which covers the data >> >> portion of a packet as well as the immutable in transit portions of >> >> the IP header. ESP_NULL does not include the IP header in >> >> calculating the authentication data. This can be useful in providing >> >> IPsec services through Network Address Translation (NAT) devices and >> >> non-IP network devices. ^^^^^^^^^^^^^^^^^^^^^^^, particularly if using tunnel mode. >> >> The discussion on how ESP_NULL might be >> >> used with NAT and non-IP network devices is outside the scope of this >> >> document. >> > -gabriel From owner-ipsec Tue May 26 10:05:47 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA15451 for ipsec-outgoing; Tue, 26 May 1998 09:43:46 -0400 (EDT) From: Vach Kompella To: , Subject: Re: Thomas Narten's DISCUSS vote Message-ID: <5040200015408410000002L002*@MHS> Date: Tue, 26 May 1998 09:22:23 -0400 MIME-Version: 1.0 Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk But you are trying to NAT the inner IP header. The outer IP header's src IP address is the Security Gateway's IP address. That is an externally valid IP address (otherwise it won't fly in the Internet). The address you need to NAT is the src IP address in the inner IP header that belongs to some host inside the enterprise that has the illegal/net-10 address. Vach Kompella IBM Corp. owner-ipsec@ex.tis.com on 05/24/98 07:17:43 AM Please respond to gab@Eng.Sun.Com To: ipsec@tis.com cc: Subject: Re: Thomas Narten's DISCUSS vote "Vipul Gupta" wrote: >Date: Fri, 22 May 1998 14:42:38 -0700 (PDT) > > I think Tom's comment is valid. Even when used with NULL encryption, > ESP's integrity check will include the TCP/UDP header and, Only assuming transport mode ESP. Tunnel mode ESP should work fine. Perhaps this should be mentioned explicitly in the ESP_NULL draft: >> >> The IPsec Authentication Header [AH] specification provides a similar >> >> service, by computing authentication data which covers the data >> >> portion of a packet as well as the immutable in transit portions of >> >> the IP header. ESP_NULL does not include the IP header in >> >> calculating the authentication data. This can be useful in providing >> >> IPsec services through Network Address Translation (NAT) devices and >> >> non-IP network devices. ^^^^^^^^^^^^^^^^^^^^^^^, particularly if using tunnel mode. >> >> The discussion on how ESP_NULL might be >> >> used with NAT and non-IP network devices is outside the scope of this >> >> document. >> > -gabriel From owner-ipsec Tue May 26 10:23:47 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA15669 for ipsec-outgoing; Tue, 26 May 1998 10:22:46 -0400 (EDT) Message-Id: <199805261434.KAA05377@postal.research.att.com> To: "Theodore Y. Ts'o" cc: ipsec@tis.com Subject: Re: Thomas Narten's DISCUSS vote Date: Tue, 26 May 1998 10:34:24 -0400 From: Steve Bellovin Sender: owner-ipsec@ex.tis.com Precedence: bulk The text is valid; ESP includes integrity protection, although ESP doesn't cover the IP header. In the new IPSEC scheme, it is extremely unlikely that someone will use both ESP and AH. ESP-NULL provides no data confidentiality, but it does provide integrity over the packet data (but not of the IP headers), thus allowing NAT boxes to muck with the IP headers. Whether or not this is a horrible abstraction violation is besides the point; if the goal is to allow NAT boxes to work, while still providing data integrity services for the packet contents, ESP NULL is one way of accomplishing that goal. The objection is valid -- because of the transport checksum, which is protected by ESP-NULL's integrity algorithm, the IP addresses can't be tinkered with in a useful fashion. (Well, I suppose that a NAT box could change the source port number to offset the changes to the addresses -- but I don't really regard that as useful...) ESP-NULL has a lot of advantages -- but enabling NAT isn't one of them. (Well, I suppose that one could argue that defeating NAT is itself a nice feature, but that's out of bounds for this WG...) From owner-ipsec Tue May 26 12:52:29 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA16771 for ipsec-outgoing; Tue, 26 May 1998 12:49:58 -0400 (EDT) Date: Tue, 26 May 1998 13:02:35 -0400 From: ho@earth.hpc.org (Hilarie Orman) Message-Id: <199805261702.NAA22913@earth.hpc.org> To: smb@research.att.com Cc: ipsec@tis.com In-reply-to: Yourmessage <199805261451.HAA08773@baskerville.CS.Arizona.EDU> Subject: Re: Thomas Narten's DISCUSS vote Sender: owner-ipsec@ex.tis.com Precedence: bulk What a tangled web is that, Devised by those who practice NAT. And would we all not be much better, Had we not used a pseudohdr? Anonymous God in his wisdom made the NAT, Now please tell me, why is that? Ogden Hash Because, without warning, on Tue, 26 May 1998 at 07:51:13 -0700 (MST) Steve Bellovin intoned: > The objection is valid -- because of the transport checksum, which > is protected by ESP-NULL's integrity algorithm, the IP addresses > can't be tinkered with in a useful fashion. (Well, I suppose that > a NAT box could change the source port number to offset the changes > to the addresses -- but I don't really regard that as useful...) > ESP-NULL has a lot of advantages -- but enabling NAT isn't one of them. > (Well, I suppose that one could argue that defeating NAT is itself > a nice feature, but that's out of bounds for this WG...) From owner-ipsec Tue May 26 14:35:09 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA17399 for ipsec-outgoing; Tue, 26 May 1998 14:32:01 -0400 (EDT) Message-Id: <199805261846.OAA03988@cichlid.raleigh.ibm.com> X-Authentication-Warning: cichlid.raleigh.ibm.com: Host localhost.raleigh.ibm.com [127.0.0.1] didn't use HELO protocol To: "Theodore Y. Ts'o" cc: ipsec@tis.com Subject: Re: Thomas Narten's DISCUSS vote In-reply-to: Your message of "Fri, 22 May 1998 16:42:58 EDT." <199805222042.QAA03013@dcl.MIT.EDU> Date: Tue, 26 May 1998 14:46:46 -0400 From: Thomas Narten Sender: owner-ipsec@ex.tis.com Precedence: bulk > >> o Security Architecture for the Internet Protocol [PROPOSED] > >> > > > >page 7, paragraph on IPPCP should be updated. Work is done, there are > >drafts/RFCs to reference. WG will be shut down as soon as IPSec > >documents are out. > This is an RFC editor function. The RFC number (to our knowledge) has > not been assigned yet. I should have been more clear. The current paragraph says: The IPsec DOI supports negotiation of IP compression, motivated in part by the observation that when encryption is employed within IPsec, it prevents effective compression by lower protocol layers. The IETF working group, "IP Payload Compression Protocol (ippcp)" has the charter to "develop protocol specifications that make it possible to perform lossless compression on individual payloads before the payload is processed by a protocol that encrypts it. These specifications will allow for compression operations to be performed prior to the encryption of a payload by such protocols as IPsec." It doesn't reference any document (i.e., the RFC editor won't see this). The point I meant to make was that although the WG is technically still in existance, it has actually completed its work (which can be cited) and will go away once the IPSec documents are out. So the text could be updated. (This is a minor point, but thought it would be worth updating if the TTL decrementing text is also to be updated.) > >Text relating to decrementing TTL of inner header of encapsulated > >packet needs clarification. Text should be clarified to say TTL > >decremented only if packet was forwarded (i.e., the forwarding > >operation is what decrements the TTL, not the fact that a complete IP > >packet is being encapsulated again upon entry to an IPSec tunnel). If > >packet originates from node, TTL is left unchanged. This is consistent > >with the current general practice of when to decrement TTLs, and some > >aspects of IPv6 protocols (i.e, ND) depend on it. > My understanding is that everyone is implementing this anyway. Thomas > in a later message suggested the following clarification, to be added > after the text which described when the TTL in the inner header should > be decremented: > Note: The decrementing of the TTL is one of the usual > actions that takes place when forwarding a packet. Packets > originating from the same node as the encapsulator do not > have their TTLs decremented, as the sending node is > originating the packet rather than forwarding it. > Charile Lynn has sent mail dissenting, claiming that it would be a bad > thing to do this since it would imply that this would imply that IPSEC > tunnels change the Internet Routing Topology, and if so, they might have > to conform to all requirements for Internet Routers. (I don't think > that's the case today for normal IP-IP tunnels, is it?) > Not clear what's the best way to resolve it. If Charlie is right that > this has some bad architectural implications, can we please get some > Internet Routing experts to explain to us exactly what the problem is > please? (and quickly). > If my sense that everyone is implementing it the way Thomas and what > apparently what most of the IPV6 working group wants, then we might as > well document that in the spec. My instincts are to document what > people are actually implementing and shipping as products, and if it's a > problem we can fix it later. This is *only* a proposed standard folks > ---- we don't have to wait until it is perfect (and the technology > obsolete) before we ship it. I think it's important to get this specified right the first time for the IPv6 case. There are scenarios in IPv6 where decrementing the TTL incorrectly will prevent ND from operating correctly over tunneled links. Better to nip this one in the bud. > >> 3.3.2 Sequence Number Generation > I thought this was pretty obvious to all implementors. If anti-reply has > been disable, the sequence number still increments, and when you reach > the max value, it rolls over to back to zero. Perhaps the use of the > vernacular "cycles" is the problem here. The text in the last paragraph > pretty clear that in the absense of anti-reply, you just always let the > sequence number roll over (and the text in the first paragrph indicates > that you always increment). > I suppose we can make this even more explicit, since if the Internet AD > thought it ambiguous, there's a good chance other folks might also get > confused. Since I don't think there is really an interoperability issue here, regardless of what the sender implements when anti-replay is enabled (i.e,. the receiver doesn't care), leaving the text alone would be not be a big deal. However, assuming the document is going to be cycled anyway for the TTL stuff, how about just adding something like the following: On the sending side, the only difference in behavior for the cases where anti-replay is enabled or disabled is that in the latter case, when the sequence number wraps back to 0, transmission continues using the same SA. When anti-replay is enabled, the sequence number is not permitted to wrap; at the point when the sequence counter is about to wrap back to 0, no more packets may be sent out using that SA. > >> The Internet IP Security Domain of Interpretation for > >> ISAKMP [PROPOSED] > >> > >> > > > >> 4.4.1.4 PROTO_IPCOMP > >> > >> The PROTO_IPCOMP type specifies IP payload compression. > > > >Add explicit reference to draft-ietf-ippcp-protocol-05.txt > > > >> 4.4.4.4 ESP_RC5 > >> > >> The ESP_RC5 type specifies the RC5 transform defined in [ESPCBC]. > >> > >> 4.4.4.5 ESP_IDEA > >> > >> The ESP_IDEA type specifies the IDEA transform defined in [ESPCBC]. > >> > >> 4.4.4.6 ESP_CAST > >> > >> The ESP_CAST type specifies the CAST transform defined in [ESPCBC]. > >> > >> 4.4.4.7 ESP_BLOWFISH > >> > >> The ESP_BLOWFISH type specifies the BLOWFISH transform defined in > >> [ESPCBC]. > > > >Are the above required or MAY? (I assume they are optional, adding a > >sentence to that effect would be good and consistent.) > All algorithsm which are required have MUST's. Can we simply put a > blanket statement at the beginning of the session saying that all items > which do not explicitly state "MUST implement" are optional? That would be fine. I just seemed inconsistent to not say MAY here, since all the other transform-specfic definitions where explicit. (Also, this change is certainly not a show stopper, but seemed worth making given the need for changes related to IPPCP.) > >> Internet Security Association and Key Management Protocol > >> (ISAKMP) [PROPOSED] > >> > > > >> 3. Check the Major and Minor Version fields to confirm they are correct. > >> If the Version field validation fails, the message is discarded and > >> the following actions are taken: > > > >Clarify what check is required. If minor numbers don't match, reject? > >Accept same major, but lower minor? (or did I miss the text on this > >point?) > You missed text on this point. Yep! Thanks. > >> The Internet Key Exchange (IKE) [PROPOSED] > >> > > > >> IKE implementations MUST support the following attribute values: > >> > >> - DES-CBC with a weak, and semi-weak, key check (weak and semi- > >> weak keys are referenced in [Sch96] and listed in Appendix A). The > >> key is derived according to Appendix B. > >> > >> - MD5 and SHA. > >> > >> - Authentication via pre-shared keys. The Digital Signature > >> Standard SHOULD be supported; RSA-- both signatures and > >> authentication with public key encryption-- SHOULD be supported. > >> > >> - MODP over the default group (see below). ECP and EC2N groups MAY > >> be supported. > >> > > > >Clarify MUST/SHOULD for authentication. What part is the SHOULD, what > >part is the MUST? (Or am I confused?) > I thought it was straightforward. All are MUST's, except for those > things listed which are explicitly should's. We can word it more like a > legal document to make sure there's no chance anyone could possibly get > confused on that point. I read it as saying authentication via pre-shared keys is required. But then the text lists specific algorithms that SHOULD (not MUST) be supported. I suppose there is an assumption that one can use other mandatory transforms. The question I had in my mind was whether something was required in the MUST sense, but that the SHOULDs could lead to different implementations not interoperating because they didn't implement a common transform. Given that there are mandatory transforms, this shouldn't be an issue. > >Need reference to PKCS #1 (normative). > > > >Appendix A: > > > >add explicit references to documents in places where well known > >numbers are "defined", for example: > > > > - Encryption Algorithm > > DES-CBC 1 > > IDEA-CBC 2 > > Blowfish-CBC 3 > > RC5-R16-B64-CBC 4 > > 3DES-CBC 5 > > CAST-CBC 6 > > > >This should be done in several places. > > Sure..... I don't personally think this was worth holding up documents > at the PROPOSED STANDARD level, but while we're making changes, we can > add the references. Actually, the references are pretty important. There will most certainly be interoperability issues if there is confusion about which RFCs correspond to which transform numbers. Thomas From owner-ipsec Tue May 26 16:30:43 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA17919 for ipsec-outgoing; Tue, 26 May 1998 16:28:01 -0400 (EDT) Message-ID: <319A1C5F94C8D11192DE00805FBBADDF124101@exchange.timestep.com> From: Roy Pereira To: Cliff Wang , kent@bbn.com Cc: ipsec@tis.com Subject: RE: mutiple phase 1 tunnel and proxy ID issues Date: Tue, 26 May 1998 16:29:03 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk For a mobile client, its phase 1 ID will be something like an email address since its IP address is not static. For its phase 2 ID though, it will need to send an IP address. This IP address is its dynamically assigned IP address that it recieved through PPP, DHCP, ISAKMP-CFG or any other means. The trick is that the gateway must be able to remember the phase 1 ID to get policy for the phase 2 negotiation. Although, not in any internet draft, I really don't believe that all ID types are valid for phase 1 and phase 2. Phase 1, for instance, doesn't really support subnets and ranges. While phase 2 doesn't really support email, DN & GN. > I totally agree what you have replied in the mail. Actually > my question is that if user name instead of IP address is > used in the ID payload of phase 2 negotiation, even if > a Phase 2 SA is negotiated successfully, we cannot > create a SPD entry since user ID cannot be used to > process packet. We need to turn that ID into address > in order to create a SPD entry. But I am not sure how > to map that ID into an IP address. This is a practical case > when two mobile user logs into two different ISP box, > get a dynamic address and they want to have their > data traffic protected. The ISP boxes's policy can only be > configured with the mobile user's ID, since their > address are dynamically assigned. The ISP boxes > can negotiate a Phase 2 SA with ID, but then they > somehow need to exchange user ID to IP address > mapping to each other. Otherwise SPD entry can not be > created. From owner-ipsec Tue May 26 17:47:29 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA18172 for ipsec-outgoing; Tue, 26 May 1998 17:46:04 -0400 (EDT) Message-ID: <356B3AD4.EBD24886@ire-ma.com> Date: Tue, 26 May 1998 17:57:41 -0400 From: Bronislav Kavsan X-Mailer: Mozilla 4.03 [en] (WinNT; U) MIME-Version: 1.0 To: Roy Pereira CC: Cliff Wang , kent@bbn.com, ipsec@tis.com Subject: Re: mutiple phase 1 tunnel and proxy ID issues References: <319A1C5F94C8D11192DE00805FBBADDF124101@exchange.timestep.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-MDaemon-Deliver-To: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Why mobil user has to send ID (IP address or anything else) in Phase 2? Isn't it already unquely identified (and policy-matched) by the gateway in Phase 1 by its e-mail, FQDN or DN? Roy Pereira wrote: > For a mobile client, its phase 1 ID will be something like an email > address since its IP address is not static. For its phase 2 ID though, > it will need to send an IP address. This IP address is its dynamically > assigned IP address that it recieved through PPP, DHCP, ISAKMP-CFG or > any other means. The trick is that the gateway must be able to remember > the phase 1 ID to get policy for the phase 2 negotiation. > > Although, not in any internet draft, I really don't believe that all ID > types are valid for phase 1 and phase 2. Phase 1, for instance, doesn't > really support subnets and ranges. While phase 2 doesn't really support > email, DN & GN. > > > I totally agree what you have replied in the mail. Actually > > my question is that if user name instead of IP address is > > used in the ID payload of phase 2 negotiation, even if > > a Phase 2 SA is negotiated successfully, we cannot > > create a SPD entry since user ID cannot be used to > > process packet. We need to turn that ID into address > > in order to create a SPD entry. But I am not sure how > > to map that ID into an IP address. This is a practical case > > when two mobile user logs into two different ISP box, > > get a dynamic address and they want to have their > > data traffic protected. The ISP boxes's policy can only be > > configured with the mobile user's ID, since their > > address are dynamically assigned. The ISP boxes > > can negotiate a Phase 2 SA with ID, but then they > > somehow need to exchange user ID to IP address > > mapping to each other. Otherwise SPD entry can not be > > created. -- Bronislav Kavsan IRE Secure Solutions, Inc. 100 Conifer Hill Drive Suite 513 Danvers, MA 01923 voice: 978-739-2384 http://www.ire.com From owner-ipsec Tue May 26 17:54:33 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA18192 for ipsec-outgoing; Tue, 26 May 1998 17:54:05 -0400 (EDT) From: Cliff Wang To: Cc: , , Subject: Re: mutiple phase 1 tunnel and proxy ID issues Message-ID: <5040200015433813000002L032*@MHS> Date: Tue, 26 May 1998 18:15:34 -0400 MIME-Version: 1.0 Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk If FQDN or DN is used to negotiate Phase 2 tunnel, the FQDN or DN needs to be translated to ID address so that SPD entry can be created for packets processing. This ID->IP address translation can be done through DNS lookup. But for a mobile user whose address is dynamically given, DNS lookup is probably not going to work. So some mechanism is needed to notify the remote gateway of this address mapping so that a new SPD entry can be created on that remote gateway. Cliff bkavsan@ire-ma.com on 05/26/98 05:55:03 PM Please respond to bkavsan@ire-ma.com To: rpereira@TimeStep.com cc: ipsec@tis.com, kent@bbn.com, Cliff Wang/Raleigh/IBM@ibmus Subject: Re: mutiple phase 1 tunnel and proxy ID issues Why mobil user has to send ID (IP address or anything else) in Phase 2? Isn't it already unquely identified (and policy-matched) by the gateway in Phase 1 by its e-mail, FQDN or DN? Roy Pereira wrote: > For a mobile client, its phase 1 ID will be something like an email > address since its IP address is not static. For its phase 2 ID though, > it will need to send an IP address. This IP address is its dynamically > assigned IP address that it recieved through PPP, DHCP, ISAKMP-CFG or > any other means. The trick is that the gateway must be able to remember > the phase 1 ID to get policy for the phase 2 negotiation. > > Although, not in any internet draft, I really don't believe that all ID > types are valid for phase 1 and phase 2. Phase 1, for instance, doesn't > really support subnets and ranges. While phase 2 doesn't really support > email, DN & GN. > > > I totally agree what you have replied in the mail. Actually > > my question is that if user name instead of IP address is > > used in the ID payload of phase 2 negotiation, even if > > a Phase 2 SA is negotiated successfully, we cannot > > create a SPD entry since user ID cannot be used to > > process packet. We need to turn that ID into address > > in order to create a SPD entry. But I am not sure how > > to map that ID into an IP address. This is a practical case > > when two mobile user logs into two different ISP box, > > get a dynamic address and they want to have their > > data traffic protected. The ISP boxes's policy can only be > > configured with the mobile user's ID, since their > > address are dynamically assigned. The ISP boxes > > can negotiate a Phase 2 SA with ID, but then they > > somehow need to exchange user ID to IP address > > mapping to each other. Otherwise SPD entry can not be > > created. -- Bronislav Kavsan IRE Secure Solutions, Inc. 100 Conifer Hill Drive Suite 513 Danvers, MA 01923 voice: 978-739-2384 http://www.ire.com From owner-ipsec Tue May 26 18:19:53 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA18237 for ipsec-outgoing; Tue, 26 May 1998 18:19:05 -0400 (EDT) Message-Id: <199805262234.PAA25522@dharkins-ss20.cisco.com> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: Bronislav Kavsan Cc: ipsec@tis.com Subject: Re: Life and death of IKE SAs and IPSEC SAs In-Reply-To: Your message of "Fri, 22 May 1998 17:03:35 EDT." <3565E827.C4F89BE6@ire-ma.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 26 May 1998 15:34:35 -0700 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk Slava, The only time I could see this being done is if the ISAKMP SA is being deleted because a CRL or a cert expired and you needed to re-authenticate the peer. Generally, the ISAKMP SA will die because you don't want to derive any more IPSec keys from SKEYID_D. In that case it doesn't make any sense to kill all existing IPSec SAs that were derived from the ISAKMP SA. If the IPSec SAs have PFS it makes even less sense. Actually, if one was to delete the IPSec SAs when the ISAKMP SA expires it would be impossible to assure PFS for both identities and keys since, in that case, the ISAKMP SA is supposed to expire immediately upon creation of the IPSec SAs. Deleteing the just-established IPSec SAs would not be right. Deleting the IPSec SAs when the ISKAMP SA expires would also cause unnecessary interruptions in the transmission since there is no guarantee that the expiry timers of the two types of SAs are in sync (i.e. that they will expire at the same time). If the ISAKMP SA expired first there would be an ugly hiccup in the transmission while new SAs are being established. Allowing these "orphaned" IPSec SAs to exist will allow a new ISAKMP SA and replacement IPSec SAs to be established in the back- ground (when those "orphaned" SAs time out on their own) and ensure a smooth transition of SAs and uninterupted service. Dan. > There is an important issue which not covered by any draft standards > and a subject of the debate between IKE implementors, and that is: > > Should or shouldn't we delete IPSEC SAs when "umbrella" IKE SA is > deleted? > The deletion of IKE SA may occur when: > 1) It expires on the local host > 2) It expires on the remote host which sends re-negotiation proposal to > my local host > 3) The remote host notifies local host to delete it for whatever reason > 4) Local host decides to delete it for whatever reason, > 5) etc. > > Is this behaviour described anywhere in drafts? Is it a matter of local > policy? (and if it is - could it create interoperabilty problems?) From owner-ipsec Tue May 26 20:40:57 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id UAA18654 for ipsec-outgoing; Tue, 26 May 1998 20:39:07 -0400 (EDT) Message-ID: <356B6207.60DF8DC9@ire-ma.com> Date: Tue, 26 May 1998 20:44:55 -0400 From: Bronislav Kavsan X-Mailer: Mozilla 4.03 [en] (WinNT; U) MIME-Version: 1.0 To: Cliff Wang CC: "ipsec@tis.com" Subject: Re: mutiple phase 1 tunnel and proxy ID issues References: <5040200015433813000002L032*@MHS> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-MDaemon-Deliver-To: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Mobile User's IP address is contained in all packets coming out of the mobile host (Source Address). Why do we need explicitly supply it in Phase 2 ID? What if his IP Address used in Phase 2 ID doesn't match the Source Address of his packets for some reason? If we bother to check this match, why don't we just use the Source IP Address to do the mapping and get away with using IP Address as a Phase 2 ID? In other words ID->IP translation could be done by mapping Phase 1 User ID (USER_FQDN, FQDN, DN) to Source IP Address of any packets arriving from this host. Cliff Wang wrote: > If FQDN or DN is used to negotiate Phase 2 tunnel, the FQDN or DN > needs to be translated to ID address so that SPD entry can be > created for packets processing. This ID->IP address translation > can be done through DNS lookup. But for a mobile user whose > address is dynamically given, DNS lookup is probably not > going to work. So some mechanism is needed to notify > the remote gateway of this address mapping so that a new SPD > entry can be created on that remote gateway. > > Cliff > > bkavsan@ire-ma.com on 05/26/98 05:55:03 PM > Please respond to bkavsan@ire-ma.com > To: rpereira@TimeStep.com > cc: ipsec@tis.com, kent@bbn.com, Cliff Wang/Raleigh/IBM@ibmus > Subject: Re: mutiple phase 1 tunnel and proxy ID issues > > Why mobil user has to send ID (IP address or anything else) in Phase 2? > Isn't it already unquely identified (and policy-matched) by the gateway in > Phase 1 by its e-mail, FQDN or DN? > > Roy Pereira wrote: > > > For a mobile client, its phase 1 ID will be something like an email > > address since its IP address is not static. For its phase 2 ID though, > > it will need to send an IP address. This IP address is its dynamically > > assigned IP address that it recieved through PPP, DHCP, ISAKMP-CFG or > > any other means. The trick is that the gateway must be able to remember > > the phase 1 ID to get policy for the phase 2 negotiation. > > > > Although, not in any internet draft, I really don't believe that all ID > > types are valid for phase 1 and phase 2. Phase 1, for instance, doesn't > > really support subnets and ranges. While phase 2 doesn't really support > > email, DN & GN. > > > > > I totally agree what you have replied in the mail. Actually > > > my question is that if user name instead of IP address is > > > used in the ID payload of phase 2 negotiation, even if > > > a Phase 2 SA is negotiated successfully, we cannot > > > create a SPD entry since user ID cannot be used to > > > process packet. We need to turn that ID into address > > > in order to create a SPD entry. But I am not sure how > > > to map that ID into an IP address. This is a practical case > > > when two mobile user logs into two different ISP box, > > > get a dynamic address and they want to have their > > > data traffic protected. The ISP boxes's policy can only be > > > configured with the mobile user's ID, since their > > > address are dynamically assigned. The ISP boxes > > > can negotiate a Phase 2 SA with ID, but then they > > > somehow need to exchange user ID to IP address > > > mapping to each other. Otherwise SPD entry can not be > > > created. > > -- > Bronislav Kavsan > IRE Secure Solutions, Inc. > 100 Conifer Hill Drive Suite 513 > Danvers, MA 01923 > voice: 978-739-2384 > http://www.ire.com From owner-ipsec Tue May 26 21:46:31 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id VAA18886 for ipsec-outgoing; Tue, 26 May 1998 21:43:07 -0400 (EDT) Message-ID: <19980526215819.Q3613@test.legislate.com> Date: Tue, 26 May 1998 21:58:19 -0400 From: Raul Miller To: Roy Pereira , Cliff Wang , kent@bbn.com Cc: ipsec@tis.com Subject: Re: mutiple phase 1 tunnel and proxy ID issues Mail-Followup-To: Roy Pereira , Cliff Wang , kent@bbn.com, ipsec@tis.com References: <319A1C5F94C8D11192DE00805FBBADDF124101@exchange.timestep.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.1 In-Reply-To: <319A1C5F94C8D11192DE00805FBBADDF124101@exchange.timestep.com>; from Roy Pereira on Tue, May 26, 1998 at 04:29:03PM -0400 Sender: owner-ipsec@ex.tis.com Precedence: bulk Roy Pereira wrote: > For a mobile client, its phase 1 ID will be something like an email > address since its IP address is not static. It's perfectly valid for a mobile client to have a static ip address. Here, you would have something along the lines of a router (almost a NAT) which the mobile client sits behind. The client comes in from wherever, presents its credentials to the re-router and sets up an encrypted tunnel for the "final hop" in the route to the static address. This is a bit different from a NAT because the client knows about two ip addresses, its dynamic address and its static address. The dynamic address may be fine for transient things like browsing, the static address is more useful for long-term activities. [For efficiency reasons, you may want policy based routing in the client.] Of course it's possible to have a mobile client which doesn't have a long-term identity, or maybe this functionality doesn't show up on the mass-market, but it's quite feasible. -- Raul From owner-ipsec Wed May 27 03:37:37 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id DAA19563 for ipsec-outgoing; Wed, 27 May 1998 03:35:08 -0400 (EDT) From: Kai Martius Organization: Uniklinik TUD To: Bronislav Kavsan Date: Wed, 27 May 1998 09:37:13 +0100 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: mutiple phase 1 tunnel and proxy ID issues Reply-to: kai@imib.med.tu-dresden.de CC: ipsec@tis.com In-reply-to: <356B6207.60DF8DC9@ire-ma.com> X-mailer: Pegasus Mail for Windows (v2.54) Message-ID: <2203AC932E8@fltserv.imib.med.tu-dresden.de> Sender: owner-ipsec@ex.tis.com Precedence: bulk Hello, Bronislav. > Mobile User's IP address is contained in all packets coming out of the mobile > host (Source Address). Why do we need explicitly supply it in Phase 2 ID? What > if his IP Address used in Phase 2 ID doesn't match the Source Address of his > packets for some reason? If we bother to check this match, why don't we just > use the Source IP Address to do the mapping and get away with using IP Address > as a Phase 2 ID? > > In other words ID->IP translation could be done by mapping Phase 1 User ID > (USER_FQDN, FQDN, DN) to Source IP Address of any packets arriving from this > host. I suppose, there could be a (theoretical) threat using an unauthenticated IDui in Phase II (which is the case when I take the IP address from the packet header or, as proposed too, when (insecure) DNS lookup is used to determine it from DN / FQDN ), but I can't proove it, yet. May be a real cryptographer could help... Kai # Kai Martius # # Dpt. of Medical CS and Biometrics / Dresden University of Technology # # PGP Fingerprint: to be compared after download of my key # # Key and more info (especially IP-security related) see my Homepage # # http://www.imib.med.tu-dresden.de/imib/personal/kai.html # From owner-ipsec Wed May 27 06:34:05 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id GAA19971 for ipsec-outgoing; Wed, 27 May 1998 06:31:07 -0400 (EDT) Message-ID: <250F9C8DEB9ED011A14D08002BE4F64C01959155@wade.reo.dec.com> From: Stephen Waters To: Steve Bellovin Cc: ipsec@tis.com Subject: RE: Thomas Narten's DISCUSS vote Date: Wed, 27 May 1998 11:43:03 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk NAT is a many-flavoured thing. I can think of a couple of useful NAT setups while using IPSEC: 1) Hosts are armed with IPSEC and use transport mode to chat. When a security gateway gets in the way, this transport mode ESP packet will need to be re-ESPed with tunnel mode. If a remote site is using a private numbering scheme (private in that it is not part of the companies Intranet address space), NAT will need to be applied to the IP header on the host's packet before it is tunneled: Host 10.1.1.1------ SG1-----Internet----SG2-------Home LAN 17.0.0.0 In this example, SG1 will have allocated (dynamically or statically) and address from the 17.0.0.0 numbering plan. This Intranet address will then need to be imposed on any packets carrying 10.1.1.1 that SG1 forwards. Once the NAT function has been performed on the 'LAN' side of SG1, the packet will need to be tunneled (EPS tunnel) over the Internet. If you are using a new-style VPN carrier with whom you share your address space, the tunnel may not be needed (depending of whether you wish to enforce encryption or not). In this configuration, it is a MUST to NOT use AH on the hosts. There is nothing stopping the SGs using AH to protect the tunneled packet's outer IP header. 2) As for 1), but hosts have no IPSEC This is the same as 1) as far as the SGs are concerned: map the host's address and tunnel using any transport you fancy. These two examples use NAT to translate between Intranet addresses and local/private adresses. NAT can of course be used to translate between Internet addresses and Intranet/local addresses, but IPSEC is unlikely to be involved. NAT could be quite useful at a SOHO site. If you model a SOHO site as a remote-access client (say using dial-in ISDN to connect to the Internet), then you can use the same dynamic address assignment techniques as for a remote laptop and allow the SOHO router to NAT the address for the various systems on the SOHO LAN. Probably all discussed to death elsewhere, but It may help - provided I'm right :) Cheers, Steve. -----Original Message----- From: Steve Bellovin [SMTP:smb@research.att.com] Sent: Tuesday, May 26, 1998 3:34 PM To: Theodore Y. Ts'o Cc: ipsec@tis.com Subject: Re: Thomas Narten's DISCUSS vote The text is valid; ESP includes integrity protection, although ESP doesn't cover the IP header. In the new IPSEC scheme, it is extremely unlikely that someone will use both ESP and AH. ESP-NULL provides no data confidentiality, but it does provide integrity over the packet data (but not of the IP headers), thus allowing NAT boxes to muck with the IP headers. Whether or not this is a horrible abstraction violation is besides the point; if the goal is to allow NAT boxes to work, while still providing data integrity services for the packet contents, ESP NULL is one way of accomplishing that goal. The objection is valid -- because of the transport checksum, which is protected by ESP-NULL's integrity algorithm, the IP addresses can't be tinkered with in a useful fashion. (Well, I suppose that a NAT box could change the source port number to offset the changes to the addresses -- but I don't really regard that as useful...) ESP-NULL has a lot of advantages -- but enabling NAT isn't one of them. (Well, I suppose that one could argue that defeating NAT is itself a nice feature, but that's out of bounds for this WG...) From owner-ipsec Wed May 27 08:27:04 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA20424 for ipsec-outgoing; Wed, 27 May 1998 08:23:08 -0400 (EDT) Message-Id: <199805271234.IAA15259@relay.hq.tis.com> Date: 27 May 1998 08:36 EDT To: ipsec@tis.com From: "Amal Maalouf" Subject: SPI question Sender: owner-ipsec@ex.tis.com Precedence: bulk Hello, Please can anyone clarify the following.. When two end systems are negotiating an SA using Quick mode, the initiator sends an ISAKMP message with the SA payload, proposal payload(s) and transform payload(s). What does the initiator fill in the SPI field of the proposal payload? Is this SPI used at all to identify the SAs created on both sides? I understood from reading the AH/ESP drafts that it is the responder that specifies the SPI that the initiator is to use in the AH header and/or ESP header sent to the responder. I figuered that this SPI is sent from the responder to the initiator when the responder chooses one of the proposals that the initiator is suggesting, i.e. when the responder responds in the SA Quick mode negotiation. If this is the case, then what is the SPI field set by the initiator in this negotiation used for? Thanks, Amal. From owner-ipsec Wed May 27 08:40:38 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA20500 for ipsec-outgoing; Wed, 27 May 1998 08:38:12 -0400 (EDT) Message-Id: <199805271244.IAA11159@clipper.hq.tis.com> X-Sender: balenson@pop.hq.tis.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Wed, 27 May 1998 08:52:07 -0400 To: ids@uow.edu.au, firewalls@greatcircle.com, cat-ietf@MIT.EDU, ietf@ns.ietf.org, ipsec@tis.com, dns-security@tis.com, www-security@ns2.rutgers.edu, www-buyinfo@allegra.att.com, ietf-otp@bellcore.com, pem-dev@tis.com, virus-l@lehigh.edu, ietf-pkix@tandem.com, spki@c2.net, ietf-tls@consensus.com, ietf-open-pgp@imc.org, ietf-smime@imc.org, aft@socks.nec.com, ietf-radius@livingston.com, ietf-ssh@clinet.fi, OGsecurity@opengroup.org, cryptography@c2.net, risks@csl.sri.com From: "David M. Balenson" Subject: CFP: 1999 Network & Distributed System Security Symposium (NDSS '99) Cc: balenson@tis.com Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_896287927==_" Sender: owner-ipsec@ex.tis.com Precedence: bulk --=====================_896287927==_ Content-Type: text/plain; charset="us-ascii" --=====================_896287927==_ Content-Type: text/plain; charset="us-ascii" C A L L F O R P A P E R S The Internet Society 1999 Network and Distributed System Security Symposium (NDSS'99) Where: Catamaran Resort, San Diego, California When: February 3-5, 1999 GOAL: The symposium will foster information exchange among hardware and software developers of network and distributed system security services. The intended audience includes those who are interested in the practical aspects of network and distributed system security, focusing on actual system design and implementation, rather than theory. A major goal of the symposium is to encourage and enable the Internet community to apply, deploy, and advance the state of available security technology. The proceedings of the symposium will be published by the Internet Society. Topics for the symposium include, but are not limited to, the following: * Security in malleable systems: mobile code, mobile agents, active networks, dynamic policy updates, etc. * Special problems: e.g. interplay between security goals and other goals such as efficiency, usability, reliability, interoperability, resource sharing, and cost. * Integrating security services with system and application security facilities and with application protocols, including message handling, file transport, remote file access, directories, time synchronization, data base management, routing, voice and video multicast, network management, boot services, and mobile computing. * Fundamental services: authentication, integrity, confidentiality, authorization, non-repudiation, and availability. * Supporting mechanisms and APIs: key management and certification infrastructures, audit, and intrusion detection. * Telecommunications security, especially for emerging technologies -- very large systems, e.g., the Internet, high-speed systems, e.g., the gigabit testbeds, wireless systems, personal communication systems, and large-scale, heterogeneous distributed systems. * Controls: firewalls, packet filters, application gateways * Object security and security objects * Network information resources and tools such as World Wide Web (WWW), Gopher, archie, and WAIS. * Electronic commerce: payment services, fee-for-access, EDI, notary services; endorsement, licensing, bonding, and other forms of assurance; rights management and other forms of intellectual property protection * Implementation and management of network security policy * Security for voice over IP * Security for routing GENERAL CHAIR: Stephen Welke, Trusted Computer Solutions PROGRAM CHAIRS: Stephen Kent, BBN Technologies Gene Tsudik, USC/Information Sciences Institute TUTORIAL CHAIR: Doug Maughan, National Security Agency PROGRAM COMMITTEE: David Balenson, TIS Labs at Network Associates Steve Bellovin, AT&T Labs -- Research Matt Bishop, University of California at Davis Bob Blakley, IBM Doug Engert, Argonne National Laboratories Warwick Ford, VeriSign Li Gong, Sun Microsystems Rich Graveman, Bellcore Ari Juels, RSA Laboratories Tom Longstaff, CERT Doug Maughan, National Security Agency Dan Nessett, 3Com Corporation Michael Roe, Cambridge University Jeffrey Schiller, MIT Wolfgang Schneider, GMD Darmstadt Christoph Schuba, Purdue University Win Treese, Open Market Jonathan Trostle, Cisco LOCAL ARRANGEMENTS CHAIR: Thomas Hutton, San Diego Supercomputer Center PUBLICATIONS CHAIR: John Kochmar, SEI PUBLICITY CHAIR: David Balenson, TIS Labs at Network Associates LOGISTICS CHAIR: Carla Rosenfeld, Internet Society REGISTRATIONS CHAIR Beth Strait, Internet Society SUBMISSIONS: The committee invites technical papers and panel proposals, for topics of technical and general interest. Technical papers should be 10-20 pages in length. Panel proposals should be two pages and should describe the topic, identify the panel chair, explain the format of the panel, and list three to four potential panelists. Technical papers will appear in the proceedings. A description of each panel will appear in the proceedings, and may at the discretion of the panel chair, include written position statements from each panelist. Each submission must contain a separate title page with the type of submission (paper or panel), the title or topic, the names of the author(s), organizational affiliation(s), telephone and FAX numbers, postal addresses, Internet electronic mail addresses, and must list a single point of contact if more than one author. The names of authors, affiliations, and other identifying information should appear only on the separate title page. Submissions must be received by 31 July 1998, and must be made via electronic mail in either PostScript or ASCII format. If the committee is unable to print a PostScript submission, it will be returned and hardcopy requested. Therefore, PostScript submissions must arrive well before 31 July. All submissions and program related correspondence (only) should be directed to the program chair: Stephen Kent c/o BBN Technologies 70 Fawcett Street Cambridge, Mass. 02138 Email:sndss99-submissions@bbn.com Phone: +1 (617) 873-1996 FAX: +1 (617) 873-4086 Dates, final call for papers, advance program, and registration information will be available at the URL: http://www.isoc.org/ndss99. Each submission will be acknowledged by e-mail. If acknowledgment is not received within seven days, please contact the program chair as indicated above. Authors and panelists will be notified of acceptance by 18 September 1998. Instructions for preparing camera-ready copy for the proceedings will be sent at that time. The camera-ready copy must be received by 16 October 1998. --=====================_896287927==_ Content-Type: text/plain; charset="us-ascii" ---------------------------------------------------------------------------- David M. Balenson, Publicity Chair, NDSS '99 TIS Labs at Network Associates, Inc. 3060 Washington Road, Glenwood, MD 21738 USA balenson@tis.com; 301-854-5358; fax 301-854-5363 --=====================_896287927==_-- From owner-ipsec Wed May 27 08:45:58 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA20538 for ipsec-outgoing; Wed, 27 May 1998 08:44:09 -0400 (EDT) Message-ID: <250F9C8DEB9ED011A14D08002BE4F64C0195915E@wade.reo.dec.com> From: Stephen Waters To: ipsec@tis.com Subject: IPSEC MIBs? Date: Wed, 27 May 1998 13:56:10 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk Is anyone working away on an ISAKMP/IKE MIB? I suppose it is more likely that a router's security policy, including transforms and filters, would be down-loaded from a central security server some how - active directory sort of thing. Steve. Stephen Waters DEVON, UK National: 01548 551012 / 550474 International: 44 1548 551012 / 550474 Stephen.Waters@Digital.com From owner-ipsec Wed May 27 09:10:03 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA20609 for ipsec-outgoing; Wed, 27 May 1998 09:08:09 -0400 (EDT) Message-Id: <3.0.1.32.19980527185440.00690100@172.16.1.10> X-Sender: srinu@172.16.1.10 X-Mailer: Windows Eudora Light Version 3.0.1 (32) Date: Wed, 27 May 1998 18:54:40 +0500 To: ipsec@tis.com From: Srinivas B Kulkarni Subject: keying material Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi SKEYID is a string derived from secret material known only to the active players in the exchange. SKEYID_e is the keying material used by the ISAKMP SA to protect the confidentiality of its messages. SKEYID_a is the keying material used by the ISAKMP SA to authenticate its messages. SKEYID_d is the keying material used to derive keys for non- ISAKMP security associations. when the Hashes are derived from the payload data , I assumed that the data that goes into that are in the NETWORK Byte order. IS IT CORRECT? -Thanks in Advance -ramana ****************************************************************** * SrinivasRao. B. Kulkarni * * Rendezvous On Chip Pvt Ltd. * * First Floor, Plot No. 14, * * NewVasaviNagar, Kharkhana, * * SECUNDERABAD - 500015. * * INDIA * * Ph : (040) 7742606, 7740406 * * email address : srinu@trinc.com * ****************************************************************** From owner-ipsec Wed May 27 09:16:49 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA20675 for ipsec-outgoing; Wed, 27 May 1998 09:15:09 -0400 (EDT) From: Cliff Wang To: Cc: , Subject: Re: mutiple phase 1 tunnel and proxy ID issues Message-ID: <5040200015452284000002L042*@MHS> Date: Wed, 27 May 1998 09:35:20 -0400 MIME-Version: 1.0 Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk Kai, Thanks for pointing out the security holes here. This is exactly what I thought to be the problem using FQDN or DN in phase 2 negotiation. We can use FQDN or DN to negotiate, but in order to start processing packet we need to add SPD entries which require ID to IP address translation. Unless secure DNS lookup is used, using incoming packets or insecure DNS lookup may pose a security threat. In addition when a mobile user or dial-in user's IP address is dynamically assigned, DNS lookup may not be feasible. cliff owner-ipsec@ex.tis.com on 05/27/98 04:47:07 AM Please respond to kai@imib.med.tu-dresden.de To: bkavsan@ire-ma.com cc: ipsec@tis.com Subject: Re: mutiple phase 1 tunnel and proxy ID issues Hello, Bronislav. > Mobile User's IP address is contained in all packets coming out of the mobile > host (Source Address). Why do we need explicitly supply it in Phase 2 ID? What > if his IP Address used in Phase 2 ID doesn't match the Source Address of his > packets for some reason? If we bother to check this match, why don't we just > use the Source IP Address to do the mapping and get away with using IP Address > as a Phase 2 ID? > > In other words ID->IP translation could be done by mapping Phase 1 User ID > (USER_FQDN, FQDN, DN) to Source IP Address of any packets arriving from this > host. I suppose, there could be a (theoretical) threat using an unauthenticated IDui in Phase II (which is the case when I take the IP address from the packet header or, as proposed too, when (insecure) DNS lookup is used to determine it from DN / FQDN ), but I can't proove it, yet. May be a real cryptographer could help... Kai # Kai Martius # # Dpt. of Medical CS and Biometrics / Dresden University of Technology # # PGP Fingerprint: to be compared after download of my key # # Key and more info (especially IP-security related) see my Homepage # # http://www.imib.med.tu-dresden.de/imib/personal/kai.html # From owner-ipsec Wed May 27 10:24:56 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA21298 for ipsec-outgoing; Wed, 27 May 1998 10:16:11 -0400 (EDT) Message-Id: <3.0.1.32.19980527193120.006f781c@172.16.1.10> X-Sender: srinu@172.16.1.10 (Unverified) X-Mailer: Windows Eudora Light Version 3.0.1 (32) Date: Wed, 27 May 1998 19:31:20 +0500 To: ipsec@tis.com From: Ramana Yarlagadda Subject: cookies Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi Karn's suggested method for creating the cookie is to perform fast hash over the IP source and destination address ,the UDP source andn Destination ports and a locally generated secret random value. ISAKMP requires that the cookies be unique for each establisment to help prevent replay attacks, therefor the date and time must be added to the information added. [ from page 20, 21 of ISAKMP draft] and says cookie is an anti-clogging token. in ISAKMP Header Processing: WHEN WE CREATE an ISAKMP message: create respective cookie WHEN WE RECEIVE an ISAKMP message: verify the initiator and responder cookie... [from pg 57 of ISAKMP draft] 1) how does the cookie acts as ACT and prevents from REPLAY 2) How do we verify the cookies?. -thanks in advance -ramana ****************************************************************** * SrinivasRao. B. Kulkarni * * Rendezvous On Chip Pvt Ltd. * * First Floor, Plot No. 14, * * NewVasaviNagar, Kharkhana, * * SECUNDERABAD - 500015. * * INDIA * * Ph : (040) 7742606, 7740406 * * email address : srinu@trinc.com * ****************************************************************** From owner-ipsec Wed May 27 10:54:32 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA21670 for ipsec-outgoing; Wed, 27 May 1998 10:51:11 -0400 (EDT) Date: Wed, 27 May 1998 08:05:13 -0700 (PDT) From: "pcalhoun@eng.sun.com" Reply-To: "pcalhoun@eng.sun.com" Subject: Re: Items for new charter To: Robert Moskowitz Cc: ipsec@tis.com In-Reply-To: "Your message with ID" <3.0.5.32.19980522152116.00a26400@homebase.htt-consult.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk How about external Policy Server Support? This could be used to "download" policies as well as for Extended Authentication. PatC > Yes, i know that the current IDs are just dragging along. getting the > 'last' nits in so they can get published. Ted is doing a good job of > bird-dogging that effort, and it is past time to write the new charter. > > To this end, I have put together a list of items that looks reasonable to > tackle. > > I want people to review them, and comment/subtract/add. then I will rough > out a new charter for the group. > > 1) fix broken but usable > > Tero's issue with IKE. > Rekeying (well not so much as broke, but do we have the heuristic > right?) > > 2) desperately needed functionality > > Host bootstrap (config) > Extended Authentication > Policy/tunnel endpoint discovery > Attribute Certs? KX records? ICMP messages? > Something else? > ICMP messages (TTL exceeded, port/host unreachable, admin > denied, ipsec-specific). > > 3) wise things to do > > PMTU (Path MTU) for tunnels > Standardized error codes > MIBs > HMAC-RIPEM (EU wants THEIR standards included, reasonably enough) > > 4) nice touches. > > MAC-DES > Other encryption algorithms > Other key exchange protocols > Simple and advanced crypto API > Dynamic discovery of complex ipsec topologies. > > > > Robert Moskowitz > ICSA > Security Interest EMail: rgm-sec@htt-consult.com From owner-ipsec Wed May 27 11:18:11 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA21784 for ipsec-outgoing; Wed, 27 May 1998 11:16:13 -0400 (EDT) Date: Wed, 27 May 1998 11:29:10 -0400 Message-Id: <199805271529.LAA10554@tonga.xedia.com> From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: srinu@trinc.com Cc: ipsec@tis.com Subject: Re: keying material References: <3.0.1.32.19980527185440.00690100@172.16.1.10> X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-ipsec@ex.tis.com Precedence: bulk >>>>> "Srinivas" == Srinivas B Kulkarni writes: Srinivas> Hi SKEYID is a string derived from secret material known Srinivas> only to the active players in the exchange. >... Srinivas> when the Hashes are derived from the payload data , I Srinivas> assumed that the data that goes into that are in the Srinivas> NETWORK Byte order. Srinivas> IS IT CORRECT? Doesn't sound like it. The hash functions take byte strings as input (not multibyte fields like integers) so it's not meaningful to talk about network byte order. Byte strings only come in one order. Meanwhile, as I mentioned a month or so ago, it would be useful to have byte order spelled out. Right now it's not and this is bound to cause interoperability problems. Not so much for the hash functions (where at least some of the underlying specs are fairly clear) but more so for things like DES, where it simply is NOT specified. paul From owner-ipsec Wed May 27 12:20:53 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA22060 for ipsec-outgoing; Wed, 27 May 1998 12:16:10 -0400 (EDT) Message-Id: <199805271630.MAA23227@bcn.East.Sun.COM> Date: Wed, 27 May 1998 12:30:47 -0400 (EDT) From: Anne Anderson - Sun Microsystems Reply-To: Anne Anderson - Sun Microsystems Subject: Re: Items for new charter To: rgm-sec@htt-consult.com Cc: ipsec@tis.com X-Mailer: dtmail 1.2.0 CDE Version 1.2 SunOS 5.6 sun4u sparc Content-Type: text X-Sun-Text-Type: ascii Sender: owner-ipsec@ex.tis.com Precedence: bulk Multicast issues with IPSec should be on the list of items to tackle. Anne Anderson Email: anne@east.sun.com Sun Microsystems Laboratories Tel: (978) 442-0928 2 Elizabeth Drive, UCHL03-205 Fax: (978) 250-5067 Chelmsford, MA 01824 USA From owner-ipsec Wed May 27 12:35:58 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA22156 for ipsec-outgoing; Wed, 27 May 1998 12:33:13 -0400 (EDT) Message-Id: <199805271643.MAA03686@postal.research.att.com> To: Anne Anderson - Sun Microsystems cc: rgm-sec@htt-consult.com, ipsec@tis.com Subject: Re: Items for new charter Date: Wed, 27 May 1998 12:43:23 -0400 From: Steve Bellovin Sender: owner-ipsec@ex.tis.com Precedence: bulk Multicast issues with IPSec should be on the list of items to tackle. Multicast is probably going to be a separate group, possibly in the IRTF. From owner-ipsec Wed May 27 15:02:09 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA22758 for ipsec-outgoing; Wed, 27 May 1998 14:59:09 -0400 (EDT) Message-ID: <356C63A5.61CC@ccnet.com> Date: Wed, 27 May 1998 12:04:05 -0700 From: Kurt Stammberger X-Mailer: Mozilla 3.01 (Macintosh; I; PPC) MIME-Version: 1.0 To: ids@uow.edu.au, firewalls@greatcircle.com, cat-ietf@MIT.EDU, ietf@ietf.org, ipsec@tis.com, dns-security@tis.com, www-security@ns2.rutgers.edu, www-buyinfo@allegra.att.com, ietf-otp@bellcore.com, pem-dev@tis.com, virus-l@lehigh.edu, ietf-pkix@tandem.com, spki@c2.net, ietf-tls@consensus.com, ietf-open-pgp@imc.org, ietf-smime@imc.org, aft@socks.nec.com, ietf-radius@livingston.com, ietf-ssh@clinet.fi, OGsecurity@opengroup.org, cryptography@c2.net, risks@csl.sri.com Subject: RSA'99 Deadline Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Dave's NDSS note reminded me to remind y'all: D E A D L I N E ! D E A D L I N E ! The Deadline for talk proposals for RSA'99 is SIX DAYS AWAY (June 1st). For more information, or to propose a talk or submit a paper for presentation, visit www.rsa.com/conf99 Questions? E-mailez-moi. Kurt Stammberger Conference Director RSADSI From owner-ipsec Wed May 27 15:29:31 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA22997 for ipsec-outgoing; Wed, 27 May 1998 15:27:12 -0400 (EDT) Message-Id: <199805271925.MAA21067@basilisk.Eng.Sun.COM> Date: Wed, 27 May 1998 12:25:35 -0700 (PDT) From: Yahya Al-Salqan Reply-To: Yahya Al-Salqan Subject: Call for participation (FYI) To: firewalls@greatcircle.com, cat-ietf@MIT.EDU, ietf@ietf.org, ipsec@tis.com, dns-security@tis.com, www-security@ns2.rutgers.edu, www-buyinfo@allegra.att.com, ietf-otp@bellcore.com, pem-dev@tis.com, virus-l@lehigh.edu, ietf-pkix@tandem.com, spki@c2.net, ietf-tls@consensus.com, ietf-open-pgp@imc.org, ietf-smime@imc.org, aft@socks.nec.com, ietf-radius@livingston.com, ietf-ssh@clinet.fi, OGsecurity@opengroup.org, cryptography@c2.net, risks@csl.sri.com Cc: ssl-talk@netscape.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: SCk4v9pjCPXd6BFIFnKHgg== X-Mailer: dtmail 1.2.0 CDE Version 1.2 SunOS 5.6 sun4u sparc Sender: owner-ipsec@ex.tis.com Precedence: bulk Today is the deadline for the early registration ... take advantage of it. My appology if you receive this e-mail more than once! ================================================= Call for Participation: IEEE WET ICE '98 Third International Workshop on Enterprise Security Stanford University, Palo Alto, USA June 17-19 1998 ================================================= On behalf of the Workshop Program and Organizing Committees, I would like to invite you to participate in The 3rd IEEE International Enterprise Security Workshop will be held June 17-19, Stanford University, Palo Alto, California. The Workshop includes paper presentations, panel discussions, keynote speeches and invited talks covering all aspects of enterprise security. Topics to be covered include: Public key infrastructure, intrusion detection, Web security, application security (e.g. digital library and healthcare), and access control. Highlights of the program: o Keynote speech by Dr. Li Gong, Java Security Architect, Sun Microsystems; o Industrial security expertise from: Microsoft NT security group, Sun Microsystems, Entrust, Certicom, Verisign, SSH Communication security and many others. It is an unprecedented opportunity to put all these companies in one room. Don't miss it. o Participation of IETF security group leaders; o Participation of NSA (National Security Agency); o Two panel discussions: - "State-of-the-art Enterprise Security: Practice and Future" - "Intrusion Detection: Present and Future" o Workshop held in conjunction with other WETICE workshops: "Web-based infrastructure for collaborative Enterprises," "Collaboration in Presence of Mobility," o Two social events. The Workshop Preliminary program can be found at: http://www.ida.liu.se/labs/iislab/SECWK/agenda.html The Registration form can be found at: http://www.cerc.wvu.edu/WETICE/WETICE98/registration.html (Please mark the Enterprise Security on the registration form) The Workshop main page can be found at: http://www.ida.liu.se/labs/iislab/SECWK/ I look forward to meeting you at the Workshop. Sincerely, Yahya Al-Salqan, Ph.D. Workshop General Chair Sun Microsystems ------------- End Forwarded Message ------------- ------------- End Forwarded Message ------------- From owner-ipsec Wed May 27 16:13:21 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA23251 for ipsec-outgoing; Wed, 27 May 1998 16:09:14 -0400 (EDT) Date: Wed, 27 May 1998 16:21:06 -0400 From: ho@earth.hpc.org (Hilarie Orman) Message-Id: <199805272021.QAA18977@earth.hpc.org> To: smb@research.att.com cc: ipsec@tis.com In-reply-to: Yourmessage <199805271704.KAA09674@baskerville.CS.Arizona.EDU> Subject: Re: Items for new charter Sender: owner-ipsec@ex.tis.com Precedence: bulk Inimitably, on Wed, 27 May 1998 at 10:04:27 -0700 (MST) Steve Bellovin opined: > Multicast is probably going to be a separate group, possibly in the IRTF. Oh, c'mon, it's not so difficult a topic as to require indeterminate seclusion. Hilarie From owner-ipsec Wed May 27 17:01:37 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA23449 for ipsec-outgoing; Wed, 27 May 1998 16:59:09 -0400 (EDT) Message-ID: <319A1C5F94C8D11192DE00805FBBADDF124393@exchange.timestep.com> From: Roy Pereira To: Bronislav Kavsan Cc: Cliff Wang , kent@bbn.com, ipsec@tis.com Subject: RE: mutiple phase 1 tunnel and proxy ID issues Date: Wed, 27 May 1998 17:08:27 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk You always have to send IDs in phase 2 if you are tunneling. If we are talking about a mobile user, then they are tunneling into a gateway, thus they have to send their and the destination's IDs in phase 2. Otherwise, the SA is between them and the gateway and not between them and their destination behind the gateway. > -----Original Message----- > From: Bronislav Kavsan [mailto:bkavsan@ire-ma.com] > Sent: Tuesday, May 26, 1998 5:58 PM > To: Roy Pereira > Cc: Cliff Wang; kent@bbn.com; ipsec@tis.com > Subject: Re: mutiple phase 1 tunnel and proxy ID issues > > > Why mobil user has to send ID (IP address or anything else) > in Phase 2? > Isn't it already unquely identified (and policy-matched) by > the gateway in > Phase 1 by its e-mail, FQDN or DN? > > Roy Pereira wrote: > > > For a mobile client, its phase 1 ID will be something like an email > > address since its IP address is not static. For its phase > 2 ID though, > > it will need to send an IP address. This IP address is its > dynamically > > assigned IP address that it recieved through PPP, DHCP, > ISAKMP-CFG or > > any other means. The trick is that the gateway must be > able to remember > > the phase 1 ID to get policy for the phase 2 negotiation. > > > > Although, not in any internet draft, I really don't believe > that all ID > > types are valid for phase 1 and phase 2. Phase 1, for > instance, doesn't > > really support subnets and ranges. While phase 2 doesn't > really support > > email, DN & GN. > > > > > I totally agree what you have replied in the mail. Actually > > > my question is that if user name instead of IP address is > > > used in the ID payload of phase 2 negotiation, even if > > > a Phase 2 SA is negotiated successfully, we cannot > > > create a SPD entry since user ID cannot be used to > > > process packet. We need to turn that ID into address > > > in order to create a SPD entry. But I am not sure how > > > to map that ID into an IP address. This is a practical case > > > when two mobile user logs into two different ISP box, > > > get a dynamic address and they want to have their > > > data traffic protected. The ISP boxes's policy can only be > > > configured with the mobile user's ID, since their > > > address are dynamically assigned. The ISP boxes > > > can negotiate a Phase 2 SA with ID, but then they > > > somehow need to exchange user ID to IP address > > > mapping to each other. Otherwise SPD entry can not be > > > created. > > > > -- > Bronislav Kavsan > IRE Secure Solutions, Inc. > 100 Conifer Hill Drive Suite 513 > Danvers, MA 01923 > voice: 978-739-2384 > http://www.ire.com > > > From owner-ipsec Wed May 27 18:14:47 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA23598 for ipsec-outgoing; Wed, 27 May 1998 18:11:14 -0400 (EDT) Message-ID: <250F9C8DEB9ED011A14D08002BE4F64C01959165@wade.reo.dec.com> From: Stephen Waters To: ippcp@external.cisco.com, ipsec@tis.com Subject: IPCOMP and IPSEC Date: Wed, 27 May 1998 23:19:08 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk Is IPCOMP restricted for use by Hosts (at packet origin), or can it be appended by a Security Gateway as part of the process of adding an IPSEC tunnel header? e.g. Original host packet [IP1][TCP][data] After passing through a security gateway/IP tunnel: [IP2][ESP][IPCOMP][IP1][TCP][data][padding/next protocol][ESP auth] If this is supported, is it detailed anywhere? For example, if an Explicit IV is used, would it come after the ESP header or after the IPCOMP header? Stephen Waters DEVON, UK National: 01548 551012 / 550474 International: 44 1548 551012 / 550474 Stephen.Waters@Digital.com From owner-ipsec Wed May 27 18:29:09 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA23676 for ipsec-outgoing; Wed, 27 May 1998 18:27:13 -0400 (EDT) Message-ID: <250F9C8DEB9ED011A14D08002BE4F64C01959167@wade.reo.dec.com> From: Stephen Waters To: ipsec@tis.com Subject: ESP Qs Date: Wed, 27 May 1998 23:39:07 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk A few questions from my latest read of the latest draft... 1) Does IKE support indicating that anti-replay is not offered ( r to i ), i.e. that the ESP sequence number will not be checked? 2) If the sender (same as initiator?) is told that there is no checking, should it leave the sequence number at zero? 3) In the case of manual-keying - when anti-replay SHOULD NOT be used, should the value of Sequence number be left zero? 4) The IPSEC DOI seems to suggest that implicit IV is the ONLY MUST, with explicit IV as the 'old way'. Most implementations I've seen only support explicit IV. Cheers, Steve. Stephen Waters DEVON, UK National: 01548 551012 / 550474 International: 44 1548 551012 / 550474 Stephen.Waters@Digital.com From owner-ipsec Wed May 27 18:53:34 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA23725 for ipsec-outgoing; Wed, 27 May 1998 18:51:13 -0400 (EDT) Message-Id: <199805272306.QAA26796@dharkins-ss20.cisco.com> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: Stephen Waters Cc: ippcp@external.cisco.com, ipsec@tis.com Subject: Re: IPCOMP and IPSEC In-Reply-To: Your message of "Wed, 27 May 1998 23:19:08 BST." <250F9C8DEB9ED011A14D08002BE4F64C01959165@wade.reo.dec.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 27 May 1998 16:06:58 -0700 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk Stephen, > Is IPCOMP restricted for use by Hosts (at packet origin), or can it be > appended by a Security Gateway as part of the process of adding an IPSEC > tunnel header? Sure, it can be done in a Security Gateway. > e.g. > > Original host packet [IP1][TCP][data] > > After passing through a security gateway/IP tunnel: > > [IP2][ESP][IPCOMP][IP1][TCP][data][padding/next protocol][ESP auth] > > If this is supported, is it detailed anywhere? For example, if an > Explicit IV is used, would it come after the ESP header or after the > IPCOMP header? It would have to come after the ESP header. Since the next header field is encrypted the recipient would have no idea yet that IPCOMP has been added and not know to skip over that field. Anybody out there want to test IPSec and IPCOMP together? Send me an email. Dan. From owner-ipsec Wed May 27 21:15:39 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id VAA24035 for ipsec-outgoing; Wed, 27 May 1998 21:11:21 -0400 (EDT) Message-Id: <3.0.5.32.19980527201601.00a5f970@homebase.htt-consult.com> X-Sender: rgm-sec@homebase.htt-consult.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Wed, 27 May 1998 20:16:01 -0400 To: Stephen Waters , ipsec@tis.com From: Robert Moskowitz Subject: Re: IPSEC MIBs? In-Reply-To: <250F9C8DEB9ED011A14D08002BE4F64C0195915E@wade.reo.dec.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 01:56 PM 5/27/98 +0100, Stephen Waters wrote: > >Is anyone working away on an ISAKMP/IKE MIB? I suppose it is more >likely that a router's security policy, including transforms and >filters, would be down-loaded from a central security server some how - >active directory sort of thing. > This is an outstanding item that was put off for IPsecond. You will see it in the new proposed charter. Of course we will need at least a document editor (hint hint). Robert Moskowitz ICSA Security Interest EMail: rgm-sec@htt-consult.com From owner-ipsec Wed May 27 21:15:39 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id VAA24036 for ipsec-outgoing; Wed, 27 May 1998 21:11:21 -0400 (EDT) Message-Id: <3.0.5.32.19980527202035.00a5ad00@homebase.htt-consult.com> X-Sender: rgm-sec@homebase.htt-consult.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Wed, 27 May 1998 20:20:35 -0400 To: Anne Anderson - Sun Microsystems From: Robert Moskowitz Subject: Re: Items for new charter Cc: ipsec@tis.com In-Reply-To: <199805271630.MAA23227@bcn.East.Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 12:30 PM 5/27/98 -0400, Anne Anderson - Sun Microsystems wrote: >Multicast issues with IPSec should be on the list of >items to tackle. > The IRTF is setting up a Secure Multicast research group. As this group produces engineerable work, the IETF can tackle that defined problem(s). Robert Moskowitz ICSA Security Interest EMail: rgm-sec@htt-consult.com From owner-ipsec Wed May 27 21:15:39 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id VAA24037 for ipsec-outgoing; Wed, 27 May 1998 21:11:22 -0400 (EDT) Message-Id: <3.0.5.32.19980527201818.00a54360@homebase.htt-consult.com> X-Sender: rgm-sec@homebase.htt-consult.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Wed, 27 May 1998 20:18:18 -0400 To: "pcalhoun@eng.sun.com" From: Robert Moskowitz Subject: Re: Items for new charter Cc: ipsec@tis.com In-Reply-To: References: <"Your message with ID" <3.0.5.32.19980522152116.00a26400@homebase.htt-consult.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 08:05 AM 5/27/98 -0700, pcalhoun@eng.sun.com wrote: >How about external Policy Server Support? This could be used to "download" >policies as well as for Extended Authentication. > Part of IPsecond. Robert Moskowitz ICSA Security Interest EMail: rgm-sec@htt-consult.com From owner-ipsec Thu May 28 02:25:15 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id CAA24774 for ipsec-outgoing; Thu, 28 May 1998 02:21:20 -0400 (EDT) Message-Id: <3.0.1.32.19980528095744.006e957c@172.16.1.10> X-Sender: srinu@172.16.1.10 X-Mailer: Windows Eudora Light Version 3.0.1 (32) Date: Thu, 28 May 1998 09:57:44 +0500 To: Paul Koning From: "Srinivas. B. Kulkarni" Subject: Re: keying material Cc: ipsec@tis.com In-Reply-To: <199805271529.LAA10554@tonga.xedia.com> References: <3.0.1.32.19980527185440.00690100@172.16.1.10> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 11:29 AM 5/27/98 -0400, you wrote: >Doesn't sound like it. The hash functions take byte strings as input >(not multibyte fields like integers) so it's not meaningful to talk >about network byte order. Byte strings only come in one order. >From the IKE draft : HASH_I = prf(SKEYID, g^xi | g^xr | CKY-I | CKY-R | SAi_b | IDii_b ) HASH_R = prf(SKEYID, g^xr | g^xi | CKY-R | CKY-I | SAi_b | IDir_b ) Here, we are calculating the hash on the body of the SA and ID payloads which, I presume, are in network byte order when concatenating into a single stream of bytes for use by the PRF. I just wanted to confirm if my assumption is right. >Meanwhile, as I mentioned a month or so ago, it would be useful to >have byte order spelled out. Right now it's not and this is bound to >cause interoperability problems. Not so much for the hash functions >(where at least some of the underlying specs are fairly clear) but >more so for things like DES, where it simply is NOT specified. > > paul ****************************************************************** * SrinivasRao. B. Kulkarni * * Rendezvous On Chip Pvt Ltd. * * First Floor, Plot No. 14, * * NewVasaviNagar, Kharkhana, * * SECUNDERABAD - 500015. * * INDIA * * Ph : (040) 7742606, 7740406 * * email address : srinu@trinc.com * ****************************************************************** From owner-ipsec Thu May 28 02:25:19 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id CAA24766 for ipsec-outgoing; Thu, 28 May 1998 02:20:20 -0400 (EDT) Message-Id: <3.0.1.32.19980528095016.006e9b28@172.16.1.10> X-Sender: srinu@172.16.1.10 X-Mailer: Windows Eudora Light Version 3.0.1 (32) Date: Thu, 28 May 1998 09:50:16 +0500 To: "Amal Maalouf" From: "Srinivas. B. Kulkarni" Subject: Re: SPI question Cc: ipsec@tis.com In-Reply-To: <199805271234.IAA15259@relay.hq.tis.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk Hello Amal, At 08:36 AM 5/27/98 EDT, Amal Maalouf wrote: >Hello, > >Please can anyone clarify the following.. > >When two end systems are negotiating an SA using Quick mode, >the initiator sends an ISAKMP message with the SA payload, >proposal payload(s) and transform payload(s). What does >the initiator fill in the SPI field of the proposal payload? Srinu>> The initiator will generate an SPI, which will be used as the SPI value for INBOUND SA at initiator side and OUTBOUND SA at the responder side. >Is this SPI used at all to identify the SAs created on both >sides? Srinu>> YES. As I said before, this SPI value will used to identify INBOUND SA at the initiator side and OUTBOUND SA at the responder side. >I understood from reading the AH/ESP drafts that it is the responder >that specifies the SPI that the initiator is to use in the >AH header and/or ESP header sent to the responder. I figuered >that this SPI is sent from the responder to the initiator >when the responder chooses one of the proposals that the initiator >is suggesting, i.e. when the responder responds in the SA Quick >mode negotiation. If this is the case, then what is the SPI field >set by the initiator in this negotiation used for? Srinu>> OK, responder in response to the initiator proposals will select one of them, and then he(responder) will generate an SPI value for his(responder) INBOUND SA and send it to the initiator to use it to identify his(initiator) OUTBOUND SA. Hope this HELPS .. > >Thanks, >Amal. > > Bridging the gap between hardware and software with best wishes - K. SrinivasRao(email : srinu@trinc.com ) From owner-ipsec Thu May 28 04:08:30 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id EAA25054 for ipsec-outgoing; Thu, 28 May 1998 04:04:22 -0400 (EDT) Message-ID: <250F9C8DEB9ED011A14D08002BE4F64C01959171@wade.reo.dec.com> From: Stephen Waters To: Ran Atkinson Cc: ipsec@tis.com Subject: RE: IPSEC MIBs? Date: Thu, 28 May 1998 09:15:46 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk There is nothing to prevent IPSEC being used to protect the SNMP management stream, I take it? Steve. Stephen Waters DEVON, UK National: 01548 551012 / 550474 International: 44 1548 551012 / 550474 Stephen.Waters@Digital.com -----Original Message----- From: Ran Atkinson [SMTP:rja@inet.org] Sent: Thursday, May 28, 1998 3:11 AM To: Stephen Waters Subject: Re: IPSEC MIBs? Doing a useful MIB for IPsec would tend to reduce the security of an IPsec implementation to the min(IPsec security, SNMP security). The latter (SNMP Security) is generally accepted to be weaker (especially pre-SNMPv3, but even with SNMPv3 in place). I'd suggest that weakening the security of an implementation of a security protocol is probably not a good global optimisation. Ran From owner-ipsec Thu May 28 06:25:49 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id GAA25606 for ipsec-outgoing; Thu, 28 May 1998 06:21:21 -0400 (EDT) Message-ID: <250F9C8DEB9ED011A14D08002BE4F64C01959175@wade.reo.dec.com> From: Stephen Waters To: "Srinivas. B. Kulkarni" Cc: ipsec@tis.com Subject: RE: SPI question Date: Thu, 28 May 1998 11:33:03 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk Hello Amal, Srinu>> The initiator will generate an SPI, which will be used as the SPI value for INBOUND SA at initiator side and OUTBOUND SA at the responder side. ... Srinu>> OK, responder in response to the initiator proposals will select one of them, and then he(responder) will generate an SPI value for his(responder) INBOUND SA and send it to the initiator to use it to identify his(initiator) OUTBOUND SA. Waters> Isn't this the wrong way round? If the initiator is setting up an SA, it is probably because Waters> there is a packet waiting to go OUT. Waters> Waters> It seems more logical to me that the initiator should specify the SPI for the Initiator's OUTBOUND and Waters> the responder's INBOUND, and that the responder should create another SPI for the responder's Waters> OUTBOUND and the initiator's INBOUND. Waters> Waters> This is all guess-work though - I haven't read it anywhere. I know, you can tell :) Waters> Cheers, Steve. From owner-ipsec Thu May 28 08:41:20 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA26621 for ipsec-outgoing; Thu, 28 May 1998 08:37:21 -0400 (EDT) From: Vach Kompella To: Subject: Re: IPCOMP and IPSEC Message-ID: <5040200015510813000002L032*@MHS> Date: Thu, 28 May 1998 08:59:13 -0400 MIME-Version: 1.0 Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk But a word of caution: the reason ippcp and esp are done at the same point is that a really decent encryption algorithm renders the data immune to compression by basically creating a more randomized ciphertext. In that case, while it may be possible to apply compression at a security gateway, it may not be effective. Vach Kompella IBM Corp. owner-ipsec@ex.tis.com on 05/27/98 08:04:47 PM Please respond to owner-ipsec@ex.tis.com To: Stephen.Waters@digital.com cc: ipsec@tis.com, ippcp@external.cisco.com Subject: Re: IPCOMP and IPSEC Stephen, > Is IPCOMP restricted for use by Hosts (at packet origin), or can it be > appended by a Security Gateway as part of the process of adding an IPSEC > tunnel header? Sure, it can be done in a Security Gateway. > e.g. > > Original host packet [IP1][TCP][data] > > After passing through a security gateway/IP tunnel: > > [IP2][ESP][IPCOMP][IP1][TCP][data][padding/next protocol][ESP auth] > > If this is supported, is it detailed anywhere? For example, if an > Explicit IV is used, would it come after the ESP header or after the > IPCOMP header? It would have to come after the ESP header. Since the next header field is encrypted the recipient would have no idea yet that IPCOMP has been added and not know to skip over that field. Anybody out there want to test IPSec and IPCOMP together? Send me an email. Dan. From owner-ipsec Thu May 28 09:02:14 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA26751 for ipsec-outgoing; Thu, 28 May 1998 09:00:22 -0400 (EDT) Message-Id: <3.0.32.19980528085427.00db5a50@bl-mail1.corpeast.baynetworks.com> X-Sender: ndoraswa_pop@bl-mail1.corpeast.baynetworks.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Thu, 28 May 1998 08:54:28 -0400 To: Stephen Waters , ippcp@external.cisco.com, ipsec@tis.com From: Naganand Doraswamy Subject: Re: IPCOMP and IPSEC Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk >If this is supported, is it detailed anywhere? For example, if an >Explicit IV is used, would it come after the ESP header or after the >IPCOMP header? > You construct the ESP payload in the same fashion for any protocol payload you are carrying. ESP treats IPCOMP as an other protocol- IP, TCP. --Naganand ----------------------------------------------------------------- Naganand Doraswamy (978)916-1323 (O) Bay Architecture Lab (978)916-0620 (Fax) 3 Federal St, Mail Stop BL3-03 Billerica, MA 01821 From owner-ipsec Thu May 28 09:06:46 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA26784 for ipsec-outgoing; Thu, 28 May 1998 09:05:21 -0400 (EDT) Date: Thu, 28 May 1998 09:19:58 -0400 Message-Id: <199805281319.JAA21796@tonga.xedia.com> From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: ipsec@tis.com Subject: RE: IPSEC MIBs? References: <250F9C8DEB9ED011A14D08002BE4F64C01959171@wade.reo.dec.com> X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-ipsec@ex.tis.com Precedence: bulk -----Original Message----- From: Ran Atkinson Ran> [SMTP:rja@inet.org] Sent: Thursday, May 28, 1998 3:11 AM To: Ran> Ran Waters Subject: Re: IPSEC MIBs? Ran> Doing a useful MIB for IPsec would tend to reduce the Ran> security of an IPsec implementation to the min(IPsec Ran> security, SNMP security). The latter (SNMP Security) is Ran> generally accepted to be weaker (especially pre-SNMPv3, but Ran> even with SNMPv3 in place). Ran> I'd suggest that weakening the security of an implementation Ran> of a security protocol is probably not a good global Ran> optimisation. True. But any IPSEC implementation will have management, and any implementation of IPSEC has the property that it is as strong as its weakest link. It strikes me that replacing proprietary MIBs by a standard MIB can only improve matters. As Stephen Waters pointed out, quite apart from whatever mechanisms SNMP itself may have (adequate or not), one can protect SNMP by carrying it over IPSEC once IPSEC has been bootstrapped using local management. paul From owner-ipsec Thu May 28 10:04:32 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA27156 for ipsec-outgoing; Thu, 28 May 1998 09:59:20 -0400 (EDT) From: Cliff Wang To: Cc: Subject: RE: IPSEC MIBs? Message-ID: <5040200015513229000002L092*@MHS> Date: Thu, 28 May 1998 09:56:07 -0400 MIME-Version: 1.0 Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk If the MIB is just used to monitor the IPsec SA status only but not used to config the policy, would that still weakens IPsec? In other words, the MIB is designed for GET function only, no SET allowed. Of course, some of the running status/statistics of a SA may be expose by SNMP, but without exposing the keys (keying materials), how big a threat will MIB pose? Thanks for any insight into this! cliff -----Original Message----- From: Ran Atkinson [SMTP:rja@inet.org] Sent: Thursday, May 28, 1998 3:11 AM To: Stephen Waters Subject: Re: IPSEC MIBs? Doing a useful MIB for IPsec would tend to reduce the security of an IPsec implementation to the min(IPsec security, SNMP security). The latter (SNMP Security) is generally accepted to be weaker (especially pre-SNMPv3, but even with SNMPv3 in place). I'd suggest that weakening the security of an implementation of a security protocol is probably not a good global optimisation. Ran From owner-ipsec Thu May 28 10:46:27 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA27489 for ipsec-outgoing; Thu, 28 May 1998 10:41:22 -0400 (EDT) Message-ID: <356D7A6A.18D92675@ire-ma.com> Date: Thu, 28 May 1998 10:53:30 -0400 From: Bronislav Kavsan X-Mailer: Mozilla 4.03 [en] (WinNT; U) MIME-Version: 1.0 To: Roy Pereira CC: ipsec@tis.com Subject: Re: mutiple phase 1 tunnel and proxy ID issues References: <319A1C5F94C8D11192DE00805FBBADDF124393@exchange.timestep.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-MDaemon-Deliver-To: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Roy, I understand the reason for sending destination's ID in the Phase 2 tunneling topology. I also understand the reason for sending source ID in host-GW-GW-host topology. But it is not clear to me why mobil user has to send its Phase 2 it's ID again when he already did it in Phase 1 in the Mobil-GW-Host situation? Roy Pereira wrote: > You always have to send IDs in phase 2 if you are tunneling. If we are > talking about a mobile user, then they are tunneling into a gateway, > thus they have to send their and the destination's IDs in phase 2. > Otherwise, the SA is between them and the gateway and not between them > and their destination behind the gateway. > > > -----Original Message----- > > From: Bronislav Kavsan [mailto:bkavsan@ire-ma.com] > > Sent: Tuesday, May 26, 1998 5:58 PM > > To: Roy Pereira > > Cc: Cliff Wang; kent@bbn.com; ipsec@tis.com > > Subject: Re: mutiple phase 1 tunnel and proxy ID issues > > > > > > Why mobil user has to send ID (IP address or anything else) > > in Phase 2? > > Isn't it already unquely identified (and policy-matched) by > > the gateway in > > Phase 1 by its e-mail, FQDN or DN? > > > > Roy Pereira wrote: > > > > > For a mobile client, its phase 1 ID will be something like an email > > > address since its IP address is not static. For its phase > > 2 ID though, > > > it will need to send an IP address. This IP address is its > > dynamically > > > assigned IP address that it recieved through PPP, DHCP, > > ISAKMP-CFG or > > > any other means. The trick is that the gateway must be > > able to remember > > > the phase 1 ID to get policy for the phase 2 negotiation. > > > > > > Although, not in any internet draft, I really don't believe > > that all ID > > > types are valid for phase 1 and phase 2. Phase 1, for > > instance, doesn't > > > really support subnets and ranges. While phase 2 doesn't > > really support > > > email, DN & GN. > > > > > > > I totally agree what you have replied in the mail. Actually > > > > my question is that if user name instead of IP address is > > > > used in the ID payload of phase 2 negotiation, even if > > > > a Phase 2 SA is negotiated successfully, we cannot > > > > create a SPD entry since user ID cannot be used to > > > > process packet. We need to turn that ID into address > > > > in order to create a SPD entry. But I am not sure how > > > > to map that ID into an IP address. This is a practical case > > > > when two mobile user logs into two different ISP box, > > > > get a dynamic address and they want to have their > > > > data traffic protected. The ISP boxes's policy can only be > > > > configured with the mobile user's ID, since their > > > > address are dynamically assigned. The ISP boxes > > > > can negotiate a Phase 2 SA with ID, but then they > > > > somehow need to exchange user ID to IP address > > > > mapping to each other. Otherwise SPD entry can not be > > > > created. > > > > > > > > -- > > Bronislav Kavsan > > IRE Secure Solutions, Inc. > > 100 Conifer Hill Drive Suite 513 > > Danvers, MA 01923 > > voice: 978-739-2384 > > http://www.ire.com > > > > > > -- Bronislav Kavsan IRE Secure Solutions, Inc. 100 Conifer Hill Drive Suite 513 Danvers, MA 01923 voice: 978-739-2384 http://www.ire.com From owner-ipsec Thu May 28 11:17:27 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA27721 for ipsec-outgoing; Thu, 28 May 1998 11:14:22 -0400 (EDT) From: Kai Martius Organization: Uniklinik TUD To: Stephen Waters Date: Thu, 28 May 1998 17:05:20 +0100 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: RE: SPI question Reply-to: kai@imib.med.tu-dresden.de CC: ipsec@tis.com In-reply-to: <250F9C8DEB9ED011A14D08002BE4F64C01959175@wade.reo.dec.com> X-mailer: Pegasus Mail for Windows (v2.54) Message-ID: <1813A72BF9@fltserv.imib.med.tu-dresden.de> Sender: owner-ipsec@ex.tis.com Precedence: bulk Steven, > Waters> Isn't this the wrong way round? If the initiator is setting up > an SA, it is probably because > Waters> there is a packet waiting to go OUT. > Waters> > Waters> It seems more logical to me that the initiator should specify > the SPI for the Initiator's OUTBOUND and > Waters> the responder's INBOUND, and that the responder should create > another SPI for the responder's > Waters> OUTBOUND and the initiator's INBOUND. > Waters> > Waters> This is all guess-work though - I haven't read it anywhere. I > know, you can tell :) > Waters> Cheers, Steve. You're right, this is the "common case" where I have a local policy in for outgoing packets in place (specified in the SPD). These "outgoing rules" are searched for a matching selector before a packet leaves the machine, and therefore the resulting SPI of I is "outgoing" and R's SPI is "incoming". However, a question which is still open (to me) is: if there is no former agreement between two systems to use IPSec, but one of them requires, say AH for every incoming packet (what is an "incoming rule"), every packet without AH will be dropped silently. The "ignorant" sender will never get a packet to this machine. On the other hand, if this packet would trigger an IKE exchange (where the SPI-inbound/outboud relation is opposite now) this could be an entry for DoS-attacks... Kai # Kai Martius # # Dpt. of Medical CS and Biometrics / Dresden University of Technology # # PGP Fingerprint: to be compared after download of my key # # Key and more info (especially IP-security related) see my Homepage # # http://www.imib.med.tu-dresden.de/imib/personal/kai.html # From owner-ipsec Thu May 28 11:33:21 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA27832 for ipsec-outgoing; Thu, 28 May 1998 11:31:21 -0400 (EDT) Message-Id: <199805281544.IAA07785@gallium.network-alchemy.com> To: Stephen Waters cc: ipsec@tis.com Subject: Re: ESP Qs In-reply-to: Your message of "Wed, 27 May 1998 23:39:07 BST." <250F9C8DEB9ED011A14D08002BE4F64C01959167@wade.reo.dec.com> Date: Thu, 28 May 1998 08:44:05 -0700 From: "Derrell D. Piper" Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi, > 1) Does IKE support indicating that anti-replay is not offered ( r to i > ), i.e. that the ESP sequence number will not be checked? The DOI includes a method for the responder to indicate whether or not he has chosen to do anti-replay. See Section 4.6.3.2 (REPLAY-STATUS). See also the archives for a whole lot of painful background on this issue... > 2) If the sender (same as initiator?) is told that there is no checking, > should it leave the sequence number at zero? The achitecture says that the anti-replay sequence is always present even when the receiver chooses not to perform anti-replay detection. > 3) In the case of manual-keying - when anti-replay SHOULD NOT be used, > should the value of Sequence number be left zero? No, it just means that the sequence counter is allowed to wrap... > 4) The IPSEC DOI seems to suggest that implicit IV is the ONLY MUST, > with explicit IV as the 'old way'. Most implementations I've seen only > support explicit IV. I'm not sure where you got this. ESP_DES is listed as the only ESP MUST and uses the cipher transform defined in: [DES] Madson, C., Doraswamy, N., "The ESP DES-CBC Cipher Algorithm With Explicit IV," draft-ietf-ipsec-ciph-des-expiv-02.txt. Derrell From owner-ipsec Thu May 28 11:46:12 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA27944 for ipsec-outgoing; Thu, 28 May 1998 11:44:23 -0400 (EDT) From: Cliff Wang To: Subject: SA sharing question Message-ID: <5040200015520088000002L082*@MHS> Date: Thu, 28 May 1998 12:05:33 -0400 MIME-Version: 1.0 Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk GW1 and GW2 are gateways negotiating IPsec SAs for hosts behind them. Suppose an IPsec SA has been set up between host a1 and b1. Later a2 and b2 need to have a SA for traffic protection. Of course a2 and b2 can negotiate a new SA through GW1 and GW2. If SA sharing is intended, can the first SA between a1 and b1 be used for traffic between a2 and b2 without a new SA? How to negotiate this SA sharing? a1 ---| |--- b1 |--GW1 ----------- GW 2--| a2 ---| |--- b2 Thanks! Cliff Wang IBM, cxwang@us.ibm.com From owner-ipsec Thu May 28 11:57:59 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA28047 for ipsec-outgoing; Thu, 28 May 1998 11:56:23 -0400 (EDT) Message-Id: <199805281611.JAA27345@dharkins-ss20.cisco.com> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: Cliff Wang Cc: ipsec@tis.com Subject: Re: SA sharing question In-Reply-To: Your message of "Thu, 28 May 1998 12:05:33 EDT." <5040200015520088000002L082*@MHS> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 28 May 1998 09:11:53 -0700 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk Cliff, Yes, it can share the SA. This is done by having GW1 specify phase 2 subnet identities. The packet from a1 to b1 will trigger an IKE negotiation and if the phase 2 identities were net-a to net-b (instead of address a1 to address b1) then when the packet from a2 to b2 reached GW1 it would use the existing SA. Dan. > GW1 and GW2 are gateways negotiating > IPsec SAs for hosts behind them. > > Suppose an IPsec SA has been set up between host > a1 and b1. Later a2 and b2 need to have a SA > for traffic protection. Of course a2 and b2 can > negotiate a new SA through GW1 and GW2. > If SA sharing is intended, can the first SA > between a1 and b1 be used for traffic between > a2 and b2 without a new SA? How to negotiate > this SA sharing? > > a1 ---| |--- b1 > |--GW1 ----------- GW 2--| > a2 ---| |--- b2 > > Thanks! > > Cliff Wang > IBM, cxwang@us.ibm.com From owner-ipsec Thu May 28 12:20:45 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA28276 for ipsec-outgoing; Thu, 28 May 1998 12:16:36 -0400 (EDT) Message-ID: <0171F2F8F9E5D011A4D10060B03CFB440EFCB3@scc-server3.semaphorecom.com> From: CJ Gibson To: Stephen Waters Cc: ipsec@tis.com Subject: RE: SPI question Date: Thu, 28 May 1998 09:38:00 -0700 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk Steven, the SPI value for an SA is always selected by the IPSec peer at the target end of the SA, no matter who initiates the key negotiation. When A does key negotiation with B, each sends it's chosen SPI value to the other who saves it. When A sends a packet to B, A includes the SPI chosen by B in the packet sent to B (and vice versa). When B receives a packet, it uses the received SPI (which was chosen by itself) along with other info to figure out who is the source of the packet and what algorithms, etc. are to be used to decrypt the packet. FYI - I use the SPI as an index into a table which then points to my control block which contains everything I know about the remote peer. -CJ -----Original Message----- > Waters> Isn't this the wrong way round? If the initiator is setting up > an SA, it is probably because > Waters> there is a packet waiting to go OUT. > Waters> > Waters> It seems more logical to me that the initiator should specify > the SPI for the Initiator's OUTBOUND and > Waters> the responder's INBOUND, and that the responder should create > another SPI for the responder's > Waters> OUTBOUND and the initiator's INBOUND. > Waters> > Waters> This is all guess-work though - I haven't read it anywhere. I > know, you can tell :) > Waters> Cheers, Steve. From owner-ipsec Thu May 28 12:22:45 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA28351 for ipsec-outgoing; Thu, 28 May 1998 12:22:25 -0400 (EDT) Message-ID: <319A1C5F94C8D11192DE00805FBBADDF1244E2@exchange.timestep.com> From: Roy Pereira To: Stephen Waters , ippcp@external.cisco.com, ipsec@tis.com Subject: RE: IPCOMP and IPSEC Date: Thu, 28 May 1998 12:25:17 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk IPComp may be added by a security gateway just like IPSec ESP/AH is added. It would probably look like this though: [IP2] [ESP spi+replay+iv] [IP1] [IPCOMP] [TCP] [data] [ESP padding+next protocol+auth] > -----Original Message----- > From: Stephen Waters [mailto:Stephen.Waters@digital.com] > Sent: Wednesday, May 27, 1998 6:19 PM > To: ippcp@external.cisco.com; ipsec@tis.com > Subject: IPCOMP and IPSEC > > > > Is IPCOMP restricted for use by Hosts (at packet origin), or can it be > appended by a Security Gateway as part of the process of > adding an IPSEC > tunnel header? > > e.g. > > Original host packet [IP1][TCP][data] > > After passing through a security gateway/IP tunnel: > > [IP2][ESP][IPCOMP][IP1][TCP][data][padding/next protocol][ESP auth] > > > If this is supported, is it detailed anywhere? For example, if an > Explicit IV is used, would it come after the ESP header or after the > IPCOMP header? > > > > > > Stephen Waters > DEVON, UK > > National: 01548 551012 / 550474 > International: 44 1548 551012 / 550474 > Stephen.Waters@Digital.com > From owner-ipsec Thu May 28 12:25:41 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA28383 for ipsec-outgoing; Thu, 28 May 1998 12:25:25 -0400 (EDT) From: Cliff Wang To: Cc: Subject: Re: SA sharing question Message-ID: <5040200015522057000002L072*@MHS> Date: Thu, 28 May 1998 12:46:14 -0400 MIME-Version: 1.0 Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk Dan, Seems to me it is a policy issue. When packet from a1 to b1 triggers the IKE negotiation, if IDci=a1 and IDcr=b1, that SA can never be shared by a2-b2. Only when IDci=SUBnet A IDcr=Subnet B, that SA can be used by any traffic between A and B. For that case, the SA is defined to be used for the whole subnet.. However, I guess whether to use host a1-b1 or subnet A -B in the IDci/IDcr for the first SA is a local policy issue. thanks, cliff dharkins@cisco.com on 05/28/98 12:07:02 PM Please respond to dharkins@cisco.com To: Cliff Wang/Raleigh/IBM@ibmus cc: ipsec@tis.com Subject: Re: SA sharing question Cliff, Yes, it can share the SA. This is done by having GW1 specify phase 2 subnet identities. The packet from a1 to b1 will trigger an IKE negotiation and if the phase 2 identities were net-a to net-b (instead of address a1 to address b1) then when the packet from a2 to b2 reached GW1 it would use the existing SA. Dan. > GW1 and GW2 are gateways negotiating > IPsec SAs for hosts behind them. > > Suppose an IPsec SA has been set up between host > a1 and b1. Later a2 and b2 need to have a SA > for traffic protection. Of course a2 and b2 can > negotiate a new SA through GW1 and GW2. > If SA sharing is intended, can the first SA > between a1 and b1 be used for traffic between > a2 and b2 without a new SA? How to negotiate > this SA sharing? > > a1 ---| |--- b1 > |--GW1 ----------- GW 2--| > a2 ---| |--- b2 > > Thanks! > > Cliff Wang > IBM, cxwang@us.ibm.com From owner-ipsec Thu May 28 12:32:49 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA28424 for ipsec-outgoing; Thu, 28 May 1998 12:32:25 -0400 (EDT) Message-ID: <319A1C5F94C8D11192DE00805FBBADDF1244E5@exchange.timestep.com> From: Roy Pereira To: Bronislav Kavsan Cc: ipsec@tis.com Subject: RE: mutiple phase 1 tunnel and proxy ID issues Date: Thu, 28 May 1998 12:36:24 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@ex.tis.com Precedence: bulk If the mobile client didn't send its ID again in phase 2, then only one ID would be sent (the destination's ID). This is illegal in the specification since it states that both IDs are sent (tunnel) or no IDs are sent (transport). Because the two ID payloads do not have any distinguishing fields to denote which one is the initiator and which one is the responder, except for their order, it would be difficult to introduce a rule that says not to include the ID payload if your source is the same in phase 1 and phase 2. I guess I don't understand what the problem is by sending two ID payloads in phase 2? Its only an extra 8 bytes isn't it? > -----Original Message----- > From: Bronislav Kavsan [mailto:bkavsan@ire-ma.com] > Sent: Thursday, May 28, 1998 10:54 AM > To: Roy Pereira > Cc: ipsec@tis.com > Subject: Re: mutiple phase 1 tunnel and proxy ID issues > > > Roy, > > I understand the reason for sending destination's ID in the Phase 2 > tunneling topology. I also understand the reason for sending > source ID in > host-GW-GW-host topology. But it is not clear to me why mobil > user has to > send its Phase 2 it's ID again when he already did it in > Phase 1 in the > Mobil-GW-Host situation? > > Roy Pereira wrote: > > > You always have to send IDs in phase 2 if you are > tunneling. If we are > > talking about a mobile user, then they are tunneling into a gateway, > > thus they have to send their and the destination's IDs in phase 2. > > Otherwise, the SA is between them and the gateway and not > between them > > and their destination behind the gateway. > > > > > -----Original Message----- > > > From: Bronislav Kavsan [mailto:bkavsan@ire-ma.com] > > > Sent: Tuesday, May 26, 1998 5:58 PM > > > To: Roy Pereira > > > Cc: Cliff Wang; kent@bbn.com; ipsec@tis.com > > > Subject: Re: mutiple phase 1 tunnel and proxy ID issues > > > > > > > > > Why mobil user has to send ID (IP address or anything else) > > > in Phase 2? > > > Isn't it already unquely identified (and policy-matched) by > > > the gateway in > > > Phase 1 by its e-mail, FQDN or DN? > > > > > > Roy Pereira wrote: > > > > > > > For a mobile client, its phase 1 ID will be something > like an email > > > > address since its IP address is not static. For its phase > > > 2 ID though, > > > > it will need to send an IP address. This IP address is its > > > dynamically > > > > assigned IP address that it recieved through PPP, DHCP, > > > ISAKMP-CFG or > > > > any other means. The trick is that the gateway must be > > > able to remember > > > > the phase 1 ID to get policy for the phase 2 negotiation. > > > > > > > > Although, not in any internet draft, I really don't believe > > > that all ID > > > > types are valid for phase 1 and phase 2. Phase 1, for > > > instance, doesn't > > > > really support subnets and ranges. While phase 2 doesn't > > > really support > > > > email, DN & GN. > > > > > > > > > I totally agree what you have replied in the mail. Actually > > > > > my question is that if user name instead of IP address is > > > > > used in the ID payload of phase 2 negotiation, even if > > > > > a Phase 2 SA is negotiated successfully, we cannot > > > > > create a SPD entry since user ID cannot be used to > > > > > process packet. We need to turn that ID into address > > > > > in order to create a SPD entry. But I am not sure how > > > > > to map that ID into an IP address. This is a practical case > > > > > when two mobile user logs into two different ISP box, > > > > > get a dynamic address and they want to have their > > > > > data traffic protected. The ISP boxes's policy can only be > > > > > configured with the mobile user's ID, since their > > > > > address are dynamically assigned. The ISP boxes > > > > > can negotiate a Phase 2 SA with ID, but then they > > > > > somehow need to exchange user ID to IP address > > > > > mapping to each other. Otherwise SPD entry can not be > > > > > created. > > > > > > > > > > > > -- > > > Bronislav Kavsan > > > IRE Secure Solutions, Inc. > > > 100 Conifer Hill Drive Suite 513 > > > Danvers, MA 01923 > > > voice: 978-739-2384 > > > http://www.ire.com > > > > > > > > > > > > > -- > Bronislav Kavsan > IRE Secure Solutions, Inc. > 100 Conifer Hill Drive Suite 513 > Danvers, MA 01923 > voice: 978-739-2384 > http://www.ire.com > > > From owner-ipsec Thu May 28 12:38:57 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA28487 for ipsec-outgoing; Thu, 28 May 1998 12:38:24 -0400 (EDT) Message-Id: <199805281652.JAA27460@dharkins-ss20.cisco.com> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: Roy Pereira Cc: Stephen Waters , ippcp@external.cisco.com, ipsec@tis.com Subject: Re: IPCOMP and IPSEC In-Reply-To: Your message of "Thu, 28 May 1998 12:25:17 EDT." <319A1C5F94C8D11192DE00805FBBADDF1244E2@exchange.timestep.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 28 May 1998 09:52:50 -0700 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk Roy, > IPComp may be added by a security gateway just like IPSec ESP/AH is > added. It would probably look like this though: > > [IP2] > [ESP spi+replay+iv] > [IP1] > [IPCOMP] > [TCP] > [data] > [ESP padding+next protocol+auth] Why would it look like that and not: [IP2] [ESP spi+replay+iv] [IPCOMP] [IP1] [TCP] [data] [ESP padding+next protocol+auth] I have a rule that says "for traffic from foo to bar apply IPCOMP then IPSec" so why would my IPCOMP be effectively a transport mode application while my IPSec would be tunnel. They're both part of the same rule so they're both done in the same mode. An intermediate gateway shouldn't muck with the inner packet. If you did what you propose the packet would be forwarded on to the destination address of IP1 who most likely doesn't have the IPCOMP SA to decompress it. The IPCOMP "SA" is negotiated along with the IPSec SA so they both have to be targeted to the same destination and be applied in the same mode. Dan. From owner-ipsec Thu May 28 12:41:39 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA28513 for ipsec-outgoing; Thu, 28 May 1998 12:41:24 -0400 (EDT) Message-ID: <356D95F1.451E3672@ire-ma.com> Date: Thu, 28 May 1998 12:50:57 -0400 From: Bronislav Kavsan X-Mailer: Mozilla 4.03 [en] (WinNT; U) MIME-Version: 1.0 To: Roy Pereira CC: ipsec@tis.com Subject: Re: mutiple phase 1 tunnel and proxy ID issues References: <319A1C5F94C8D11192DE00805FBBADDF1244E5@exchange.timestep.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-MDaemon-Deliver-To: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Roy, Thank you for clarification. Also, ID could my much longer than 8 bytes - consider Distringuished Name, for example. Roy Pereira wrote: > If the mobile client didn't send its ID again in phase 2, then only one > ID would be sent (the destination's ID). This is illegal in the > specification since it states that both IDs are sent (tunnel) or no IDs > are sent (transport). > > Because the two ID payloads do not have any distinguishing fields to > denote which one is the initiator and which one is the responder, except > for their order, it would be difficult to introduce a rule that says not > to include the ID payload if your source is the same in phase 1 and > phase 2. > > I guess I don't understand what the problem is by sending two ID > payloads in phase 2? Its only an extra 8 bytes isn't it? > > > -----Original Message----- > > From: Bronislav Kavsan [mailto:bkavsan@ire-ma.com] > > Sent: Thursday, May 28, 1998 10:54 AM > > To: Roy Pereira > > Cc: ipsec@tis.com > > Subject: Re: mutiple phase 1 tunnel and proxy ID issues > > > > > > Roy, > > > > I understand the reason for sending destination's ID in the Phase 2 > > tunneling topology. I also understand the reason for sending > > source ID in > > host-GW-GW-host topology. But it is not clear to me why mobil > > user has to > > send its Phase 2 it's ID again when he already did it in > > Phase 1 in the > > Mobil-GW-Host situation? > > > > Roy Pereira wrote: > > > > > You always have to send IDs in phase 2 if you are > > tunneling. If we are > > > talking about a mobile user, then they are tunneling into a gateway, > > > thus they have to send their and the destination's IDs in phase 2. > > > Otherwise, the SA is between them and the gateway and not > > between them > > > and their destination behind the gateway. > > > > > > > -----Original Message----- > > > > From: Bronislav Kavsan [mailto:bkavsan@ire-ma.com] > > > > Sent: Tuesday, May 26, 1998 5:58 PM > > > > To: Roy Pereira > > > > Cc: Cliff Wang; kent@bbn.com; ipsec@tis.com > > > > Subject: Re: mutiple phase 1 tunnel and proxy ID issues > > > > > > > > > > > > Why mobil user has to send ID (IP address or anything else) > > > > in Phase 2? > > > > Isn't it already unquely identified (and policy-matched) by > > > > the gateway in > > > > Phase 1 by its e-mail, FQDN or DN? > > > > > > > > Roy Pereira wrote: > > > > > > > > > For a mobile client, its phase 1 ID will be something > > like an email > > > > > address since its IP address is not static. For its phase > > > > 2 ID though, > > > > > it will need to send an IP address. This IP address is its > > > > dynamically > > > > > assigned IP address that it recieved through PPP, DHCP, > > > > ISAKMP-CFG or > > > > > any other means. The trick is that the gateway must be > > > > able to remember > > > > > the phase 1 ID to get policy for the phase 2 negotiation. > > > > > > > > > > Although, not in any internet draft, I really don't believe > > > > that all ID > > > > > types are valid for phase 1 and phase 2. Phase 1, for > > > > instance, doesn't > > > > > really support subnets and ranges. While phase 2 doesn't > > > > really support > > > > > email, DN & GN. > > > > > > > > > > > I totally agree what you have replied in the mail. Actually > > > > > > my question is that if user name instead of IP address is > > > > > > used in the ID payload of phase 2 negotiation, even if > > > > > > a Phase 2 SA is negotiated successfully, we cannot > > > > > > create a SPD entry since user ID cannot be used to > > > > > > process packet. We need to turn that ID into address > > > > > > in order to create a SPD entry. But I am not sure how > > > > > > to map that ID into an IP address. This is a practical case > > > > > > when two mobile user logs into two different ISP box, > > > > > > get a dynamic address and they want to have their > > > > > > data traffic protected. The ISP boxes's policy can only be > > > > > > configured with the mobile user's ID, since their > > > > > > address are dynamically assigned. The ISP boxes > > > > > > can negotiate a Phase 2 SA with ID, but then they > > > > > > somehow need to exchange user ID to IP address > > > > > > mapping to each other. Otherwise SPD entry can not be > > > > > > created. > > > > > > > > > > > > > > > > -- > > > > Bronislav Kavsan > > > > IRE Secure Solutions, Inc. > > > > 100 Conifer Hill Drive Suite 513 > > > > Danvers, MA 01923 > > > > voice: 978-739-2384 > > > > http://www.ire.com > > > > > > > > > > > > > > > > > > > > -- > > Bronislav Kavsan > > IRE Secure Solutions, Inc. > > 100 Conifer Hill Drive Suite 513 > > Danvers, MA 01923 > > voice: 978-739-2384 > > http://www.ire.com > > > > > > -- Bronislav Kavsan IRE Secure Solutions, Inc. 100 Conifer Hill Drive Suite 513 Danvers, MA 01923 voice: 978-739-2384 http://www.ire.com From owner-ipsec Thu May 28 13:46:08 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA28993 for ipsec-outgoing; Thu, 28 May 1998 13:44:23 -0400 (EDT) Message-ID: <250F9C8DEB9ED011A14D08002BE4F64C01959181@wade.reo.dec.com> From: Stephen Waters To: Roy Pereira Cc: ipsec@tis.com, ippcp@external.cisco.com Subject: FW: IPCOMP and IPSEC Date: Thu, 28 May 1998 18:55:40 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk Ah, so there is some confusion then. I think (thought) the right thing to do was put the IPCOMP header outside the original IP header though - that makes it obvious that the peer SG need to strip it off before forwarding the original packet. If the IPCOMP was inserted after IP1 by a SG, how would the receiving SG know whether to extract it again - it looks identical to a packet that has been compression by the original host. Steve. IPComp may be added by a security gateway just like IPSec ESP/AH is added. It would probably look like this though: [IP2] [ESP spi+replay+iv] [IP1] [IPCOMP] [TCP] [data] [ESP padding+next protocol+auth] > -----Original Message----- > From: Stephen Waters [mailto:Stephen.Waters@digital.com] > Sent: Wednesday, May 27, 1998 6:19 PM > To: ippcp@external.cisco.com; ipsec@tis.com > Subject: IPCOMP and IPSEC > > > > Is IPCOMP restricted for use by Hosts (at packet origin), or can it be > appended by a Security Gateway as part of the process of > adding an IPSEC > tunnel header? > > e.g. > > Original host packet [IP1][TCP][data] > > After passing through a security gateway/IP tunnel: > > [IP2][ESP][IPCOMP][IP1][TCP][data][padding/next protocol][ESP auth] > > > If this is supported, is it detailed anywhere? For example, if an > Explicit IV is used, would it come after the ESP header or after the > IPCOMP header? > > > > > > Stephen Waters > DEVON, UK > > National: 01548 551012 / 550474 > International: 44 1548 551012 / 550474 > Stephen.Waters@Digital.com > From owner-ipsec Thu May 28 14:03:07 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA29193 for ipsec-outgoing; Thu, 28 May 1998 14:02:25 -0400 (EDT) Message-ID: <319A1C5F94C8D11192DE00805FBBADDF12454A@exchange.timestep.com> From: Roy Pereira To: Daniel Harkins Cc: Stephen Waters , ippcp@external.cisco.com, ipsec@tis.com Subject: RE: IPCOMP and IPSEC Date: Thu, 28 May 1998 13:56:10 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk IPCOMP may be applied in either tunnel mode or transport mode just like IPSec. You are right, either way is equally correct. > -----Original Message----- > From: Daniel Harkins [mailto:dharkins@cisco.com] > Sent: Thursday, May 28, 1998 12:53 PM > To: Roy Pereira > Cc: Stephen Waters; ippcp@external.cisco.com; ipsec@tis.com > Subject: Re: IPCOMP and IPSEC > > > Roy, > > > IPComp may be added by a security gateway just like IPSec ESP/AH is > > added. It would probably look like this though: > > > > [IP2] > > [ESP spi+replay+iv] > > [IP1] > > [IPCOMP] > > [TCP] > > [data] > > [ESP padding+next protocol+auth] > > Why would it look like that and not: > > [IP2] > [ESP spi+replay+iv] > [IPCOMP] > [IP1] > [TCP] > [data] > [ESP padding+next protocol+auth] > > I have a rule that says "for traffic from foo to bar apply > IPCOMP then > IPSec" so why would my IPCOMP be effectively a transport mode > application > while my IPSec would be tunnel. They're both part of the same rule so > they're both done in the same mode. > > An intermediate gateway shouldn't muck with the inner packet. If you > did what you propose the packet would be forwarded on to the > destination > address of IP1 who most likely doesn't have the IPCOMP SA to > decompress > it. The IPCOMP "SA" is negotiated along with the IPSec SA so > they both > have to be targeted to the same destination and be applied in > the same mode. > > Dan. > From owner-ipsec Thu May 28 14:20:06 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA29306 for ipsec-outgoing; Thu, 28 May 1998 14:19:26 -0400 (EDT) Message-Id: <199805281828.LAA27629@dharkins-ss20.cisco.com> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: Roy Pereira Cc: Stephen Waters , ippcp@external.cisco.com, ipsec@tis.com Subject: Re: IPCOMP and IPSEC In-Reply-To: Your message of "Thu, 28 May 1998 13:56:10 EDT." <319A1C5F94C8D11192DE00805FBBADDF12454A@exchange.timestep.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 28 May 1998 11:28:08 -0700 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk Roy, Actually, I don't think the way you proposed is correct. While IPCOMP can be applied in either transport or tunnel mode it *has* to be applied in the same mode as the parallel IPSec SA. The way you proposed has IPCOMP in transport and IPSec in tunnel. That won't work. Dan. > IPCOMP may be applied in either tunnel mode or transport mode just like > IPSec. You are right, either way is equally correct. > > > -----Original Message----- > > From: Daniel Harkins [mailto:dharkins@cisco.com] > > Sent: Thursday, May 28, 1998 12:53 PM > > To: Roy Pereira > > Cc: Stephen Waters; ippcp@external.cisco.com; ipsec@tis.com > > Subject: Re: IPCOMP and IPSEC > > > > > > Roy, > > > > > IPComp may be added by a security gateway just like IPSec ESP/AH is > > > added. It would probably look like this though: > > > > > > [IP2] > > > [ESP spi+replay+iv] > > > [IP1] > > > [IPCOMP] > > > [TCP] > > > [data] > > > [ESP padding+next protocol+auth] > > > > Why would it look like that and not: > > > > [IP2] > > [ESP spi+replay+iv] > > [IPCOMP] > > [IP1] > > [TCP] > > [data] > > [ESP padding+next protocol+auth] > > > > I have a rule that says "for traffic from foo to bar apply > > IPCOMP then > > IPSec" so why would my IPCOMP be effectively a transport mode > > application > > while my IPSec would be tunnel. They're both part of the same rule so > > they're both done in the same mode. > > > > An intermediate gateway shouldn't muck with the inner packet. If you > > did what you propose the packet would be forwarded on to the > > destination > > address of IP1 who most likely doesn't have the IPCOMP SA to > > decompress > > it. The IPCOMP "SA" is negotiated along with the IPSec SA so > > they both > > have to be targeted to the same destination and be applied in > > the same mode. > > > > Dan. > From owner-ipsec Thu May 28 14:42:21 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA29462 for ipsec-outgoing; Thu, 28 May 1998 14:41:29 -0400 (EDT) Message-ID: <19980528135738.A37642@austin.ibm.com> Date: Thu, 28 May 1998 13:57:38 -0500 From: Will Fiveash To: ipsec@tis.com Subject: Re: mutiple phase 1 tunnel and proxy ID issues Mail-Followup-To: ipsec@tis.com References: <319A1C5F94C8D11192DE00805FBBADDF124101@exchange.timestep.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.92.4i In-Reply-To: <319A1C5F94C8D11192DE00805FBBADDF124101@exchange.timestep.com>; from Roy Pereira on Tue, May 26, 1998 at 04:29:03PM -0400 Sender: owner-ipsec@ex.tis.com Precedence: bulk On Tue, May 26, 1998 at 04:29:03PM -0400, Roy Pereira wrote: > For a mobile client, its phase 1 ID will be something like an email > address since its IP address is not static. For its phase 2 ID though, > it will need to send an IP address. This IP address is its dynamically > assigned IP address that it received through PPP, DHCP, ISAKMP-CFG or > any other means. The trick is that the gateway must be able to remember > the phase 1 ID to get policy for the phase 2 negotiation. This brings up a question I've had and haven't seen answered yet. Can IDii be used by the responder to determine which security policy to use in Phase 1 if aggressive mode is used? Note that in main mode, the source IP address in the header of the first message must be used by the responder to locate the security policy/proposal list with which to negotiate. This leads to ambiguity on the responder side when trying to create multiple P1 tunnels between the same two hosts (is this negotiation creating a new P1 tunnel or is it a SA refresh for an existing P1 tunnel?). If IDii can be used (are others doing this?) in aggressive mode and the IDii's are unique for each P1 tunnel then the responder can unambiguously determine which security policy to use and whether the negotiation is "refreshing" an existing P1 tunnel. -- Will Fiveash IBM AIX System Development Internet: will@austin.ibm.com 11400 Burnet Road, Bld.905/9551 Notes: will@austin.ibm.com@internet Austin, TX 78758-3493 Phone:(512) 838-7904(off)/3509(fax), T/L 678-7904 From owner-ipsec Thu May 28 14:51:12 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA29533 for ipsec-outgoing; Thu, 28 May 1998 14:49:33 -0400 (EDT) Message-ID: <0171F2F8F9E5D011A4D10060B03CFB440EFCBC@scc-server3.semaphorecom.com> From: CJ Gibson To: Robert Moskowitz-sec Cc: ipsec@tis.com Subject: Reasonable lifetimes for IPSec and IKE ?? Date: Thu, 28 May 1998 12:10:25 -0700 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@ex.tis.com Precedence: bulk Our product, as you know, is a gateway which uses only tunnel mode. I'm looking for any recommendations for the following: IKE lifetime limit IPSec lifetime limit (time) IPSec kbyte limit At the meeting in Vegas, I think you spoke of the IPSec time limit as being a multiple of the IKE time limit. Is it recommended that the IKE time (Main Mode) be less than the IPSec time (Quick Mode). If so, does one just re-initiate the MM & QM whenever a QM times out (assuming MM has already timed out) - so there is a new MM and a new QM ?? I do understand that these limits need to be tailored for the individual implementation but I feel we should give the customer some starting point. Is there any material that would give me an idea of what to use? For instance, info on how much time or how many packets would be needed for someone to break the keys when using a particular algorithm... Do you have a recommendation ? Does anybody out there have info on this ? Please let me know. Thanks a lot, CJ Catherine J. Gibson cjgibson@semaphorecom.com Digital Link - Semaphore 4000 Burton Drive Santa Clara CA 95054 From owner-ipsec Thu May 28 14:53:50 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA29608 for ipsec-outgoing; Thu, 28 May 1998 14:53:28 -0400 (EDT) Message-ID: <319A1C5F94C8D11192DE00805FBBADDF12457E@exchange.timestep.com> From: Roy Pereira To: Stephen Waters Cc: ipsec@tis.com, ippcp@external.cisco.com Subject: RE: IPCOMP and IPSEC Date: Thu, 28 May 1998 14:41:36 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk My appologies Stephen, you were correct. I got a little confused and wrote things backwards. Your original layout is the correct mechanism to use when the gateway is handling both IPSec and IPComp. [IP2][ESP][IPCOMP][IP1][TCP][data][padding/next protocol][ESP auth] To answer you question of where the explicit IV goes; it must go right after the ESP header (spi+replay), thus it is before the IPComp. This is because IPComp is really another protocol and not part of IPSec, thus it is treated as protocol data just like TCP/UDP to IPSec. > -----Original Message----- > From: Stephen Waters [mailto:Stephen.Waters@digital.com] > Sent: Thursday, May 28, 1998 1:56 PM > To: Roy Pereira > Cc: ipsec@tis.com; ippcp@external.cisco.com > Subject: FW: IPCOMP and IPSEC > > > > Ah, so there is some confusion then. I think (thought) the > right thing > to do was put the IPCOMP header outside the original IP > header though - > that makes it obvious that the peer SG need to strip it off before > forwarding the original packet. If the IPCOMP was inserted > after IP1 by > a SG, how would the receiving SG know whether to extract it again - it > looks identical to a packet that has been compression by the original > host. > > Steve. > > > IPComp may be added by a security gateway just like IPSec ESP/AH is > added. It would probably look like this though: > [IP2] > [ESP spi+replay+iv] > [IP1] > [IPCOMP] > [TCP] > [data] > [ESP padding+next protocol+auth] > > > > > -----Original Message----- > > From: Stephen Waters [mailto:Stephen.Waters@digital.com] > > > Sent: Wednesday, May 27, 1998 6:19 PM > > To: ippcp@external.cisco.com; > ipsec@tis.com > Subject: IPCOMP and IPSEC > > > > Is IPCOMP restricted for use by Hosts (at packet origin), or can it be > appended by a Security Gateway as part of the process of > adding an IPSEC > tunnel header? > > e.g. > > Original host packet [IP1][TCP][data] > > After passing through a security gateway/IP tunnel: > > [IP2][ESP][IPCOMP][IP1][TCP][data][padding/next protocol][ESP auth] > > > If this is supported, is it detailed anywhere? For example, if an > Explicit IV is used, would it come after the ESP header or after the > IPCOMP header? > > > > > > Stephen Waters > DEVON, UK > > National: 01548 551012 / 550474 > International: 44 1548 551012 / 550474 > Stephen.Waters@Digital.com > From owner-ipsec Thu May 28 15:01:06 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA29684 for ipsec-outgoing; Thu, 28 May 1998 15:00:30 -0400 (EDT) Date: Thu, 28 May 1998 12:15:26 -0700 From: mark@mentat.com (Marc Hasson) Message-Id: <199805281915.MAA00927@orna.mentat.com> To: rpereira@TimeStep.com, dharkins@cisco.com Subject: Re: IPCOMP and IPSEC Cc: Stephen.Waters@digital.com, ippcp@external.cisco.com, ipsec@tis.com X-Sun-Charset: US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk Jumping in here.... > Roy, > > Actually, I don't think the way you proposed is correct. While IPCOMP > can be applied in either transport or tunnel mode it *has* to be applied > in the same mode as the parallel IPSec SA. The way you proposed has IPCOMP > in transport and IPSec in tunnel. That won't work. > > Dan. I think Dan's packet format makes sense, for the described scenario of a SG that is applying both compression and encryption/tunnelling in one step on behalf of a naive host. (As a side tidbit though, from the SG receiver's perspective of your packet Dan, isn't ESP really in Transport mode with respect to IPCOMP and its IPCOMP, in turn, thats in tunnel mode with a next header of IP? I don't recall any mention in the IPCOMP document of tunnel vs. transport, it seemed to assume that only ULPs are its next header payload but I don't see why that has to be.) But isn't Roy's packet format OK for end-hosts that have a Compression Association between themselves (configured independently of IKE?) and there is an intermediate SG (based on its own policies and key negotiation) which is doing the tunnelling/encryption regardless whether the inner IP's payload is TCP or IPCOMP? I think Dan's scenario one that is likely to be widely deployed but Roy's format seems just as "correct" for host-based compression. -- Marc -- > > > IPCOMP may be applied in either tunnel mode or transport mode just like > > IPSec. You are right, either way is equally correct. > > > > > -----Original Message----- > > > From: Daniel Harkins [mailto:dharkins@cisco.com] > > > Sent: Thursday, May 28, 1998 12:53 PM > > > To: Roy Pereira > > > Cc: Stephen Waters; ippcp@external.cisco.com; ipsec@tis.com > > > Subject: Re: IPCOMP and IPSEC > > > > > > > > > Roy, > > > > > > > IPComp may be added by a security gateway just like IPSec ESP/AH is > > > > added. It would probably look like this though: > > > > > > > > [IP2] > > > > [ESP spi+replay+iv] > > > > [IP1] > > > > [IPCOMP] > > > > [TCP] > > > > [data] > > > > [ESP padding+next protocol+auth] > > > > > > Why would it look like that and not: > > > > > > [IP2] > > > [ESP spi+replay+iv] > > > [IPCOMP] > > > [IP1] > > > [TCP] > > > [data] > > > [ESP padding+next protocol+auth] > > > > > > I have a rule that says "for traffic from foo to bar apply > > > IPCOMP then > > > IPSec" so why would my IPCOMP be effectively a transport mode > > > application > > > while my IPSec would be tunnel. They're both part of the same rule so > > > they're both done in the same mode. > > > > > > An intermediate gateway shouldn't muck with the inner packet. If you > > > did what you propose the packet would be forwarded on to the > > > destination > > > address of IP1 who most likely doesn't have the IPCOMP SA to > > > decompress > > > it. The IPCOMP "SA" is negotiated along with the IPSec SA so > > > they both > > > have to be targeted to the same destination and be applied in > > > the same mode. > > > > > > Dan. > > > From owner-ipsec Thu May 28 15:31:16 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA29888 for ipsec-outgoing; Thu, 28 May 1998 15:28:42 -0400 (EDT) Message-Id: <199805281943.MAA27813@dharkins-ss20.cisco.com> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: mark@mentat.com (Marc Hasson) Cc: rpereira@TimeStep.com, Stephen.Waters@digital.com, ippcp@external.cisco.com, ipsec@tis.com Subject: Re: IPCOMP and IPSEC In-Reply-To: Your message of "Thu, 28 May 1998 12:15:26 PDT." <199805281915.MAA00927@orna.mentat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 28 May 1998 12:43:10 -0700 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk Marc, > Jumping in here.... > > > Roy, > > > > Actually, I don't think the way you proposed is correct. While IPCOMP > > can be applied in either transport or tunnel mode it *has* to be applied > > in the same mode as the parallel IPSec SA. The way you proposed has IPCOMP > > in transport and IPSec in tunnel. That won't work. > > > > Dan. > > I think Dan's packet format makes sense, for the described scenario of > a SG that is applying both compression and encryption/tunnelling in one > step on behalf of a naive host. (As a side tidbit though, from the > SG receiver's perspective of your packet Dan, isn't ESP really in > Transport mode with respect to IPCOMP and its IPCOMP, in turn, thats in > tunnel mode with a next header of IP? I don't recall any mention in the > IPCOMP document of tunnel vs. transport, it seemed to assume that only > ULPs are its next header payload but I don't see why that has to be.) I guess you could say that ESP is in transport mode, but what about the case where both AH and ESP are applied to the same packet: [IP2][AH][ESP][IP1][data] Is AH in transport mode? > But isn't Roy's packet format OK for end-hosts that have a Compression > Association between themselves (configured independently of IKE?) and > there is an intermediate SG (based on its own policies and key > negotiation) which is doing the tunnelling/encryption regardless > whether the inner IP's payload is TCP or IPCOMP? > > I think Dan's scenario one that is likely to be widely deployed but Roy's > format seems just as "correct" for host-based compression. Roy's would correct if the compression was being done by the host before passing the packet to the SG, but Stephen (in the original post that started this all) stated that the original packet received by the SG was: [IP1][TCP][data] In this case I don't think it's legal for a SG to add anything-- IPSec or IPCOMP-- in transport mode. Dan. From owner-ipsec Thu May 28 15:50:59 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA00023 for ipsec-outgoing; Thu, 28 May 1998 15:49:37 -0400 (EDT) Message-ID: From: "Davis, Terry L" To: ipsec@tis.com, "'Robert Moskowitz'" Subject: RE: Items for new charter Date: Thu, 28 May 1998 12:53:44 -0700 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk Robert Your note covers some of the issues I want to mention but I don't think restating them hurts. As you know, I tend to focus on operational use issues and concerns so I'll toss out a few issues to consider not necessarily as part of IPSEC II protocols but as the background that it will need to live in and support. As you begin to design IPSEC II perhaps consider: 1) Scaling to handle GigaPoPs with individual IPSEC connections/tunnels running near a gigabit and total flows through the PoP into the 10's of gigabits. 2) Scaling to handle 10's of thousands of active IPSEC connections/streams. 3) Methods to allow authentication of individual connections/streams to enter or leave an IPSEC tunnel. 4) Methods to allow connection flexibility for both security and provisioning (negotiation?); QOS, bandwidth of the tunnel, authentication type, etc. 5) Methods to tag/mark connections to allow a stream/connection/flow to be recognized as already authenticated/permitted/routed rather than individual packet inspection. 6) Debugging concepts and management techniques to insure IPSEC II supportability by the operators in a global environment; MIB's, tunnel wraparound, etc. IPSEC II will almost certainly be the one of the first security protocols for the 21st century, we should treat it as such, even in these early design phases, to insure it scales to support a global Internet. Take care, Terry L. Davis, P.E. Boeing > ---------- > From: Robert Moskowitz[SMTP:rgm-sec@htt-consult.com] > Sent: Friday, May 22, 1998 12:21 PM > To: ipsec@tis.com > Subject: Items for new charter > > Yes, i know that the current IDs are just dragging along. getting the > 'last' nits in so they can get published. Ted is doing a good job of > bird-dogging that effort, and it is past time to write the new > charter. > > To this end, I have put together a list of items that looks reasonable > to > tackle. > > I want people to review them, and comment/subtract/add. then I will > rough > out a new charter for the group. > > 1) fix broken but usable > > Tero's issue with IKE. > Rekeying (well not so much as broke, but do we have the > heuristic > right?) > > 2) desperately needed functionality > > Host bootstrap (config) > Extended Authentication > Policy/tunnel endpoint discovery > Attribute Certs? KX records? ICMP messages? > Something else? > ICMP messages (TTL exceeded, port/host unreachable, admin > denied, ipsec-specific). > > 3) wise things to do > > PMTU (Path MTU) for tunnels > Standardized error codes > MIBs > HMAC-RIPEM (EU wants THEIR standards included, reasonably > enough) > > 4) nice touches. > > MAC-DES > Other encryption algorithms > Other key exchange protocols > Simple and advanced crypto API > Dynamic discovery of complex ipsec topologies. > > > > Robert Moskowitz > ICSA > Security Interest EMail: rgm-sec@htt-consult.com > From owner-ipsec Thu May 28 15:52:52 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA00061 for ipsec-outgoing; Thu, 28 May 1998 15:52:36 -0400 (EDT) Message-ID: From: "Davis, Terry L" To: ipsec@tis.com, "'Robert Moskowitz'" Subject: RE: Items for new charter Date: Thu, 28 May 1998 12:53:44 -0700 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk Robert Your note covers some of the issues I want to mention but I don't think restating them hurts. As you know, I tend to focus on operational use issues and concerns so I'll toss out a few issues to consider not necessarily as part of IPSEC II protocols but as the background that it will need to live in and support. As you begin to design IPSEC II perhaps consider: 1) Scaling to handle GigaPoPs with individual IPSEC connections/tunnels running near a gigabit and total flows through the PoP into the 10's of gigabits. 2) Scaling to handle 10's of thousands of active IPSEC connections/streams. 3) Methods to allow authentication of individual connections/streams to enter or leave an IPSEC tunnel. 4) Methods to allow connection flexibility for both security and provisioning (negotiation?); QOS, bandwidth of the tunnel, authentication type, etc. 5) Methods to tag/mark connections to allow a stream/connection/flow to be recognized as already authenticated/permitted/routed rather than individual packet inspection. 6) Debugging concepts and management techniques to insure IPSEC II supportability by the operators in a global environment; MIB's, tunnel wraparound, etc. IPSEC II will almost certainly be the one of the first security protocols for the 21st century, we should treat it as such, even in these early design phases, to insure it scales to support a global Internet. Take care, Terry L. Davis, P.E. Boeing > ---------- > From: Robert Moskowitz[SMTP:rgm-sec@htt-consult.com] > Sent: Friday, May 22, 1998 12:21 PM > To: ipsec@tis.com > Subject: Items for new charter > > Yes, i know that the current IDs are just dragging along. getting the > 'last' nits in so they can get published. Ted is doing a good job of > bird-dogging that effort, and it is past time to write the new > charter. > > To this end, I have put together a list of items that looks reasonable > to > tackle. > > I want people to review them, and comment/subtract/add. then I will > rough > out a new charter for the group. > > 1) fix broken but usable > > Tero's issue with IKE. > Rekeying (well not so much as broke, but do we have the > heuristic > right?) > > 2) desperately needed functionality > > Host bootstrap (config) > Extended Authentication > Policy/tunnel endpoint discovery > Attribute Certs? KX records? ICMP messages? > Something else? > ICMP messages (TTL exceeded, port/host unreachable, admin > denied, ipsec-specific). > > 3) wise things to do > > PMTU (Path MTU) for tunnels > Standardized error codes > MIBs > HMAC-RIPEM (EU wants THEIR standards included, reasonably > enough) > > 4) nice touches. > > MAC-DES > Other encryption algorithms > Other key exchange protocols > Simple and advanced crypto API > Dynamic discovery of complex ipsec topologies. > > > > Robert Moskowitz > ICSA > Security Interest EMail: rgm-sec@htt-consult.com > From owner-ipsec Thu May 28 16:27:18 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA00308 for ipsec-outgoing; Thu, 28 May 1998 16:26:44 -0400 (EDT) Date: Thu, 28 May 1998 13:40:53 -0700 From: mark@mentat.com (Marc Hasson) Message-Id: <199805282040.NAA01397@orna.mentat.com> To: dharkins@cisco.com Subject: Re: IPCOMP and IPSEC Cc: rpereira@TimeStep.com, Stephen.Waters@digital.com, ippcp@external.cisco.com, ipsec@tis.com X-Sun-Charset: US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk Dan, > > I guess you could say that ESP is in transport mode, but what about the > case where both AH and ESP are applied to the same packet: > > [IP2][AH][ESP][IP1][data] > > Is AH in transport mode? Good point. I can hear people arguing it both ways and am sorry I raised that side tidbit. Whats more important is that we all understand how to process the above, which I think is pretty clear in the specs. > Roy's would correct if the compression was being done by the host before > passing the packet to the SG, but Stephen (in the original post that started > this all) stated that the original packet received by the SG was: > > [IP1][TCP][data] Agreed, and a later post of Roy's corrected his response to Steve. I had just wanted to confirm that Roy's packet description was correct *if* the original host had instead emitted: [IP1][IPCOMP][TCP][data] which the first SG turns into Roy's: [IP2][ESP][IP1][IPCOMP][TCP][data][ESP trailer] Your paragraph above confirms this, thanks. > > In this case I don't think it's legal for a SG to add anything-- IPSec or > IPCOMP-- in transport mode. You sound right to me. One would certainly complicate the SG's job as well as one is more likely to experience topology-related problems if this was permitted since the SG containing the SA (or CA) is not explicitly addressed. I believe the group has rejected this SG "transport mode addition" before. -- Marc -- From owner-ipsec Thu May 28 19:58:31 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA01007 for ipsec-outgoing; Thu, 28 May 1998 19:57:49 -0400 (EDT) Message-Id: <199805290005.RAA25717@proxy3.ba.best.com> From: "Saroop Mathur" To: "Eric Dean" , "Daniel Harkins" Cc: "Stephen Waters" , , Subject: Re: IPCOMP and IPSEC Date: Thu, 28 May 1998 17:02:18 -0700 X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1155 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Eric, The compression ration depends a lot on the type of data and the packet size. Using IPSEC will not change the compression ratio since compression is done before IPSEC. - Saroop ---------- > From: Eric Dean > To: Daniel Harkins > Cc: Stephen Waters ; ippcp@external.cisco.com; ipsec@tis.com > Subject: Re: IPCOMP and IPSEC > Date: Thursday, May 28, 1998 3:39 PM > > > Anybody out there want to test IPSec and IPCOMP together? Send me an > > email. > > > > Sure, we tried IPCOMP without IPSec and got about 1.05:1 compression ratio > though. I can't wait for after IPSec. > > _______________________________________________________________ > Eric Casey Dean > Supervisor: IP Product Engineering > Tel#: 703-689-5298 Fax#: 703-478-7852 Mobile#: 703-598-0962 > From owner-ipsec Thu May 28 19:58:31 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA00999 for ipsec-outgoing; Thu, 28 May 1998 19:56:49 -0400 (EDT) From: Pyda Srisuresh Message-Id: <199805290011.RAA23145@server.livingston.com> Subject: Re: Thomas Narten's DISCUSS vote To: kompella@us.ibm.com (Vach Kompella) Date: Thu, 28 May 1998 17:16:12 -0700 (PDT) Cc: ipsec@tis.com, gab@Eng.Sun.Com In-Reply-To: <5040200015408410000002L002*@MHS> from "Vach Kompella" at May 26, 98 09:22:23 am Content-Type: text Sender: owner-ipsec@ex.tis.com Precedence: bulk Gabriel is right about NULL-ESP not impacting NAT packets in tunnel mode ESP. This is because, the original packet (say, with net 10 src address) would have been subject to NAT translation already prior to being tunneled. If it wasnt NAT translated, then it is not a NAT packet. Secondly, as Vipul and Thomas Narten pointed out earlier, NULL_ESP in transport mode wont provide IPsec service for TCP/UDP NAT packets. But, NULL_ESP in transport mode does provide IPsec service for non-TCP/UDP pkts(ex: ICMP). I.e., protocols that do not indirectly embed IP address integrity within their header/payload can be NAT translated with NULL-ESP. cheers, suresh > > But you are trying to NAT the inner IP header. The outer IP header's src IP > address is the Security Gateway's IP address. That is an externally valid IP > address (otherwise it won't fly in the Internet). The address you need to NAT > is the src IP address in the inner IP header that belongs to some host inside > the enterprise that has the illegal/net-10 address. > > Vach Kompella > IBM Corp. > > > > owner-ipsec@ex.tis.com on 05/24/98 07:17:43 AM > Please respond to gab@Eng.Sun.Com > To: ipsec@tis.com > cc: > Subject: Re: Thomas Narten's DISCUSS vote > > > > "Vipul Gupta" wrote: > > >Date: Fri, 22 May 1998 14:42:38 -0700 (PDT) > > > > I think Tom's comment is valid. Even when used with NULL encryption, > > ESP's integrity check will include the TCP/UDP header and, > > Only assuming transport mode ESP. Tunnel mode ESP should work > fine. > > Perhaps this should be mentioned explicitly in the ESP_NULL draft: > > > >> >> The IPsec Authentication Header [AH] specification provides a similar > >> >> service, by computing authentication data which covers the data > >> >> portion of a packet as well as the immutable in transit portions of > >> >> the IP header. ESP_NULL does not include the IP header in > >> >> calculating the authentication data. This can be useful in providing > >> >> IPsec services through Network Address Translation (NAT) devices and > >> >> non-IP network devices. > ^^^^^^^^^^^^^^^^^^^^^^^, particularly if using tunnel mode. > > >> >> The discussion on how ESP_NULL might be > >> >> used with NAT and non-IP network devices is outside the scope of this > >> >> document. > >> > > > > -gabriel > > > > > From owner-ipsec Fri May 29 06:46:24 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id GAA02484 for ipsec-outgoing; Fri, 29 May 1998 06:43:52 -0400 (EDT) Message-ID: <250F9C8DEB9ED011A14D08002BE4F64C01A23E44@wade.reo.dec.com> From: Stephen Waters To: Saroop Mathur Cc: ipsec@tis.com Subject: RE: IPCOMP and IPSEC Date: Fri, 29 May 1998 11:56:33 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk Saroop, Well IPSEC does change the whole picture for compression. With encryption being performed at the IP layer, compression needs to happen there too (not at the datalink). The IP-layer compression (IPPCP) calls for zero-history compression - for which the performance can be bad. When we did LZS zero-history support for X.25 links, we used a minimum packet size of 500bytes, i.e. we would not even try to compress the packet if it was smaller than that. On my office link (ISDN/PPP/LZS with history), I average 2:1 compression. I suspect this would reduce noticeably for zero-history. Steve. -----Original Message----- From: Saroop Mathur [SMTP:saroop@cylan.com] Sent: Friday, May 29, 1998 1:02 AM To: Eric Dean; Daniel Harkins Cc: Stephen Waters; ippcp@external.cisco.com; ipsec@tis.com Subject: Re: IPCOMP and IPSEC Eric, The compression ration depends a lot on the type of data and the packet size. Using IPSEC will not change the compression ratio since compression is done before IPSEC. - Saroop ---------- > From: Eric Dean > To: Daniel Harkins > Cc: Stephen Waters ; ippcp@external.cisco.com; ipsec@tis.com > Subject: Re: IPCOMP and IPSEC > Date: Thursday, May 28, 1998 3:39 PM > > > Anybody out there want to test IPSec and IPCOMP together? Send me an > > email. > > > > Sure, we tried IPCOMP without IPSec and got about 1.05:1 compression ratio > though. I can't wait for after IPSec. > > _______________________________________________________________ > Eric Casey Dean > Supervisor: IP Product Engineering > Tel#: 703-689-5298 Fax#: 703-478-7852 Mobile#: 703-598-0962 > From owner-ipsec Fri May 29 07:15:37 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA02567 for ipsec-outgoing; Fri, 29 May 1998 07:14:52 -0400 (EDT) Message-ID: <250F9C8DEB9ED011A14D08002BE4F64C01A1BD66@wade.reo.dec.com> From: Stephen Waters To: ipsec@tis.com, ippcp@external.cisco.com Cc: Stephen Waters Subject: Compression, encryption and authentication at a Security Gateway Date: Fri, 29 May 1998 12:26:32 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk The hunch/findings that folk seem to have when running IPPCP is that the performance is poor and if IPPCP is done in series with encryption, compression is probably not worth bothering with (I'm assuming that you would be using IPPCP because you wanted to use IPSEC encryption). Host hosts have IPSEC/IPPCP, there is the option that Security Gateways won't need to do encryption either, for example, a remote-worker who tunnels to a Security Gateway for authentication and then encrypts to a mail-server with transport mode : [IP2][AH][IP1][ESP][upper][pad/np][icv] The Security gateway does packet-level authentication and the target node (say, a mail server) does the decode. I see that the [IP1] header is no longer confidential, but the alternative is to have the SG re-encrypt the entire packet. What I'm coming to is that Security Gateways are likely to want to be VERY sharp at doing per-packet authentication. (hiding under table time) Steve. Stephen Waters DEVON, UK National: 01548 551012 / 550474 International: 44 1548 551012 / 550474 Stephen.Waters@Digital.com From owner-ipsec Fri May 29 07:55:10 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA02724 for ipsec-outgoing; Fri, 29 May 1998 07:51:50 -0400 (EDT) Date: Thu, 28 May 1998 18:39:37 -0400 (EDT) From: Eric Dean To: Daniel Harkins cc: Stephen Waters , ippcp@external.cisco.com, ipsec@tis.com Subject: Re: IPCOMP and IPSEC In-Reply-To: <199805272306.QAA26796@dharkins-ss20.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk > Anybody out there want to test IPSec and IPCOMP together? Send me an > email. > Sure, we tried IPCOMP without IPSec and got about 1.05:1 compression ratio though. I can't wait for after IPSec. _______________________________________________________________ Eric Casey Dean Supervisor: IP Product Engineering Tel#: 703-689-5298 Fax#: 703-478-7852 Mobile#: 703-598-0962 From owner-ipsec Fri May 29 11:19:23 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA03569 for ipsec-outgoing; Fri, 29 May 1998 11:12:52 -0400 (EDT) Reply-To: From: "Bob Monsour" To: "Stephen Waters" , , Subject: RE: Compression, encryption and authentication at a Security Gateway Date: Fri, 29 May 1998 08:22:09 -0700 Message-ID: <000301bd8b15$8cb52de0$832c13ce@bmonsour.hifn.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: <250F9C8DEB9ED011A14D08002BE4F64C01A1BD66@wade.reo.dec.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-ipsec@ex.tis.com Precedence: bulk At the Munich IETF meeting (first meeting of the IPPCP wg), Cisco presented their experience of implementing IPPCP. The presentation can be found at: http://www.tgv.cisco.com/public/shacham/ipcomp.ppt This was using an IP-in-IP approach to the compression header. After the current compression header approach was adopted, Avram re-ran his results and later posted the following on 9/15/97: The I-D was written after implementing the WG resolutions into my code in Cisco Stack 100 v2.1 for Win95, which is based on an IPv4 stack and static keys. The bonus from the new header is a better compression ratio - the Calgary files now compress at the ratio of 1.81:1, in comparison to the ratio of 1.782:1 when IP-over-IP was in use. Also, there are three things to recall when implemeting compression and the potential benefits of it prior to IPSec encryption. First is the bandwidth improvement; second is that for highly cpu intensive encryption algorithms like 3des, in some cases (about a 2:1 compression ratio) the cost of compressing plus encrypting can be "cheaper" than encrypting alone. Lastly, with the per-packet overhead of IPSec due to AH and ESP, even a modest compression ratio gain can reduce the liklihood of packet fragmentation. This is an issue with packets at or near the MTU which is where the compression ratio is likely to be best. In the LZS compression draft, we recommend a 120 byte packet size as the minimum size to begin considering compressing the packet. Lastly, as you are all aware, compression results are data dependent and your mileage may vary. Regards, -Bob > -----Original Message----- > From: Stephen Waters [mailto:Stephen.Waters@digital.com] > Sent: Friday, May 29, 1998 4:27 AM > To: ipsec@tis.com; ippcp@external.cisco.com > Cc: Stephen Waters > Subject: Compression, encryption and authentication at a Security > Gateway > > > > The hunch/findings that folk seem to have when running IPPCP is that the > performance is poor and if IPPCP is done in series with encryption, > compression is probably not worth bothering with (I'm assuming that you > would be using IPPCP because you wanted to use IPSEC encryption). > > Host hosts have IPSEC/IPPCP, there is the option that Security Gateways > won't need to do encryption either, for example, a remote-worker who > tunnels to a Security Gateway for authentication and then encrypts to a > mail-server with transport mode : > > [IP2][AH][IP1][ESP][upper][pad/np][icv] > > The Security gateway does packet-level authentication and the target > node (say, a mail server) does the decode. > I see that the [IP1] header is no longer confidential, but the > alternative is to have the SG re-encrypt the entire packet. > > What I'm coming to is that Security Gateways are likely to want to be > VERY sharp at doing per-packet authentication. > > (hiding under table time) > Steve. > > > Stephen Waters > DEVON, UK > > National: 01548 551012 / 550474 > International: 44 1548 551012 / 550474 > Stephen.Waters@Digital.com > > From owner-ipsec Fri May 29 13:31:40 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA04036 for ipsec-outgoing; Fri, 29 May 1998 13:27:55 -0400 (EDT) Message-Id: <3.0.2.32.19980529103610.006b4914@airedale.cisco.com> X-Sender: shacham@airedale.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.2 (32) Date: Fri, 29 May 1998 10:36:10 -0700 To: Stephen Waters From: Avram Shacham Subject: RE: IPCOMP and IPSEC Cc: ipsec@tis.com, ippcp@external.cisco.com In-Reply-To: <250F9C8DEB9ED011A14D08002BE4F64C01A23E44@wade.reo.dec.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk Steve, At 11:56 AM 5/29/98 +0100, Stephen Waters wrote: >The IP-layer compression (IPPCP) calls >for zero-history compression - for which the performance can be bad. Tests show different results. Sure, an IP datagram with payload that has been previously compressed tends not to compress any further, regardless of the protocol-layer the compression is applied in. In other words, compressed data will not compress further in V42.bis, PPP, or IPComp. Therefore the IPComp protocol recommends implementation of an adaptive algorithm to avoid the performance hit. Using the Calgary files benchmark with LZS algorithm, the compression ratio of IP datagrams with MTU of 1500 octets was 1.82:1, not that far from the max the algorithm can offer 2.2:1. Stateless compression is a must in IP, so the overall performance gain is pretty significant. And, stateless compression has its implementation advantages. >When we did LZS zero-history support for X.25 links, we used a minimum >packet size of 500bytes, i.e. we would not even try to compress the >packet if it was smaller than that. My measurements of LZS with MTU of 576 show a compression ratio of 1.5:1. MTU of 256 gave a similar ratio, but 41% of the packets failed to compress, so overall performance got a hit. The IPComp protocol does recognize that small datagrams are likely to expand as a result of compression. Therefore, the protocol suggests that 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. The algorithms drafts (DELATE, LZS) suggest using a threshold of ~90 bytes. My implementation uses the value of 256. >On my office link (ISDN/PPP/LZS with history), I average 2:1 >compression. I suspect this would reduce noticeably for zero-history. You may be surprised, and - again - for the better. On my home-office link (IPComp/ISDN) I got 1.82:1 compression ratio - with or without ESP encryption. Regards, avram From owner-ipsec Fri May 29 14:47:51 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA04492 for ipsec-outgoing; Fri, 29 May 1998 14:43:53 -0400 (EDT) Message-ID: <250F9C8DEB9ED011A14D08002BE4F64C01A23E57@wade.reo.dec.com> From: Stephen Waters To: ipsec@tis.com Cc: Stephen Waters Subject: Inbound processing Q Date: Fri, 29 May 1998 19:55:50 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk I have a Q related to the description of inbound processing in the IPSEC architecture: When a responder processes an IKE/ESP phase-2 from a remote peer, the SPD can be search for a policy that matches the peer's IP address and supports one of the cypher-suits being proposed. No other selcotor can be used to select the best SPD entry at this point. Once the inbound ESP-SA is in place and data starts arriving, the packets are de-tunneled (say) and decrypted. At that moment, if we are down to a packet that needs forwarding, the selectors fields from the packet and the cypher-suit are matched against the inbound SPD entries, and if no match is found, the correct action appears to be to discard the packet! It seems that Inbound-specific SPD entries may need to include more 'any' and 'wildcard' selector values than the outbound SPD entries. This suggests that phase-2 should allow negotiation of selector fields so the the responder can then find a policy that fuller covers the remote peer's selector ranges/explict values/wildcards. Steve. From owner-ipsec Fri May 29 16:30:21 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA04804 for ipsec-outgoing; Fri, 29 May 1998 16:28:53 -0400 (EDT) Message-Id: <3.0.2.32.19980529133701.006b1dd8@airedale.cisco.com> X-Sender: shacham@airedale.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.2 (32) Date: Fri, 29 May 1998 13:37:01 -0700 To: Eric Dean From: Avram Shacham Subject: RE: IPCOMP and IPSEC Cc: Stephen Waters , ipsec@tis.com, ippcp@external.cisco.com In-Reply-To: References: <3.0.2.32.19980529103610.006b4914@airedale.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk Eric, At 04:20 PM 5/29/98 -0400, Eric Dean wrote: >Streaming a contiguous file through a compression device is not >indicative of real Internet traffic. Packets of various application are >interleaved within flows. The Calgary files may be a good benchmark for >comparing different compression algorithms in a stateful environment; ^^^^^^^^ how comes? >however, they do not represent the stateless environment that the >Internet represents. In my tests, I ftp-ed and http-ed random collection of files, with identical results, so it seems that the Calgary Files are a pretty good indication for non-pre-compressed files. avram From owner-ipsec Fri May 29 17:00:34 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA04905 for ipsec-outgoing; Fri, 29 May 1998 16:58:13 -0400 (EDT) Date: Fri, 29 May 1998 16:20:43 -0400 (EDT) From: Eric Dean To: Avram Shacham cc: Stephen Waters , ipsec@tis.com, ippcp@external.cisco.com Subject: RE: IPCOMP and IPSEC In-Reply-To: <3.0.2.32.19980529103610.006b4914@airedale.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk > > Using the Calgary files benchmark with LZS algorithm, the compression ratio > of IP datagrams with MTU of 1500 octets was 1.82:1, not that far from the > max the algorithm can offer 2.2:1. Stateless compression is a must in IP, > so the overall performance gain is pretty significant. And, stateless > compression has its implementation advantages. Streaming a contiguous file through a compression device is not indicative of real Internet traffic. Packets of various application are interleaved within flows. The Calgary files may be a good benchmark for comparing different compression algorithms in a stateful environment; however, they do not represent the stateless environment that the Internet represents. -eric From owner-ipsec Sat May 30 05:29:16 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id FAA06190 for ipsec-outgoing; Sat, 30 May 1998 05:26:49 -0400 (EDT) Message-ID: <250F9C8DEB9ED011A14D08002BE4F64C01A23E5D@wade.reo.dec.com> From: Stephen Waters To: Avram Shacham Cc: ipsec@tis.com, ippcp@external.cisco.com Subject: RE: IPCOMP and IPSEC Date: Sat, 30 May 1998 10:38:53 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk I guess time will tell. For remote-access VPN stuff (over the Internet), there is no doubt that stateless compression is what you use. For some of the newer VNP-focused providers offering QOS for LAN-to-LAN, it may be possible to use a history - even for IPPCP. I've worked full-time from home for a few years now - using a direct dial ISDN link over which the average compression seems to stay stubbornly on 2:1. I'll load up the IPPCP image and share the results once I have a decent sample. Not a bad case study considering the use of IPPCP in the short term - i.e. remote-access for laptops/SOHOs. Cheers, Steve. > ---------- > From: Avram Shacham[SMTP:shacham@cisco.com] > Sent: Friday, May 29, 1998 9:37 PM > To: Eric Dean > Cc: Stephen Waters; ipsec@tis.com; ippcp@external.cisco.com > Subject: RE: IPCOMP and IPSEC > > Eric, > > At 04:20 PM 5/29/98 -0400, Eric Dean wrote: > > >Streaming a contiguous file through a compression device is not > >indicative of real Internet traffic. Packets of various application > are > >interleaved within flows. The Calgary files may be a good benchmark > for > >comparing different compression algorithms in a stateful environment; > > ^^^^^^^^ how comes? > > >however, they do not represent the stateless environment that the > >Internet represents. > > In my tests, I ftp-ed and http-ed random collection of files, with > identical results, so it seems that the Calgary Files are a pretty > good > indication for non-pre-compressed files. > > avram > > From owner-ipsec Sun May 31 11:53:20 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA08098 for ipsec-outgoing; Sun, 31 May 1998 11:42:50 -0400 (EDT) From: suresh@livingston.com (Pyda Srisuresh) Message-Id: <199805311557.IAA15764@kc.livingston.com> Subject: Comments on the latest Security architecture draft To: kent@bbn.com, rja@corp.home.net Date: Sun, 31 May 1998 08:57:30 -0700 (PDT) Cc: ipsec@tis.com, suresh@livingston.com (Pyda Srisuresh) X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-ipsec@ex.tis.com Precedence: bulk Steve and Ran, Below are my comments on . I would appreciate your responses. Thanks. 1. Section 3.2 - Last paragraph Is there a recommendation for key-encryption keys? 2. Secion 4.1. Defintion of an SA A Security Association(SA) is a triple of (Dest_Addr, SPI, security_protocol). Yet, the SPI number is fixed by the initiator and selected by the responder (refer ISAKMP and IKE documents). There is a problem with the above two statements to work together. Suppose there are 2 secure gateways (called SGW1 and SGW2) talking to the same target dest. Address (hereafter called target), using the same SPI number and same security protocol (say ESP). Surely, the target node should maintain 2 SAs with different sets of attributes (such as keys, SA lifetime etc..), one for traffic from SGW1 and another for traffic from SGW2. Yet, the triple of both these SAs on target is identical. When a packet arrives at the target node (from SGW1 or SGW2), how does the target know to distinguish which of the two SAs the packet belongs to? Comment: (a) The target needs to use Source address to find the right SA, in which case the SA would be 4-tuple. (A correction required to this draft) or, (b) The SPI number should be allowed to be fixed by the target, instead of SGW1 or SGW2. (This would require a correction to IKE/ISAKMP drafts) 3. Section 4.4.1. The Secure policy data base Outbound: You state that an SPD entry could spin off one or more SAs, depending on whether the source of the selector value is SPD entry or the packet itself. But, you do not mention the possibility of multiple SPD entries refering the same SA. ex: Say, the SA selector value is set to SPD entry (as opposed to pkt). And, say, you had the following 2 policies to set up an SA on a VPN node. 1. All TCP packets originating from Address X to Address Y 2. All UDP packets originating from an address range inlcuding X to Address Y I dont see why a single SA could not be used to securely tranfer packets matching either one of the above policies. Inbound: Likewise, I dont believe, you could make the assumption that a matching SA will have a single SPD entry that could be verified against for selector values. For the same reason I stated above, one ought to assume there could be a series of policies applicable to the same SA. 4. Section 4.4.2 - Selectors The "name" selector (in particular, the User ID) seems appropriate for an ISAKMP SA negotiation and not relevant to an IPsec SA negotiation. If so, I think, it would be a good idea to state this explicitly in the document. Also, where would you find a Data sensitivityy label on a V4 packet? Are you talking about the TOS field being used for this purpose? 5. Section 4.6.2: Automated SA and Key management: You say, IKE is a default key management protocol and mentin others such as kerberos and SKIP as a may be (elsewhere in the document). Is IKE a MUST or manadatory key management protocol? 6. Section 5.0 - Last sentence of the first paragraph: You state that a packet MUST be discarded, if no policy in SPD matches the packet, inbound or outbound. Why is this a MUST? This should be left to local administrator to determine the local default policy. For example, the local site could choose to send pakcets in clear, by default, if there is no matching policy in SPD. Thats all for now. have a nice day. cheers, suresh From owner-ipsec Sun May 31 13:45:57 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA08259 for ipsec-outgoing; Sun, 31 May 1998 13:43:46 -0400 (EDT) Message-Id: <199805311757.NAA06983@tecumseh.altavista-software.com> X-Sender: ljopop@ranier.altavista-software.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 Date: Sun, 31 May 1998 13:55:39 -0400 To: suresh@livingston.com (Pyda Srisuresh) From: Matt Thomas Subject: Re: Comments on the latest Security architecture draft Cc: ipsec@tis.com, suresh@livingston.com (Pyda Srisuresh) In-Reply-To: <199805311557.IAA15764@kc.livingston.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk > 2. Secion 4.1. Defintion of an SA > > A Security Association(SA) is a triple of (Dest_Addr, SPI, > security_protocol). Yet, the SPI number is fixed by the initiator > and selected by the responder (refer ISAKMP and IKE documents). > There is a problem with the above two statements to work together. No there isn't. > Suppose there are 2 secure gateways (called SGW1 and SGW2) talking > to the same target dest. Address (hereafter called target), using > the same SPI number and same security protocol (say ESP). Surely, > the target node should maintain 2 SAs with different sets of > attributes (such as keys, SA lifetime etc..), one for traffic from > SGW1 and another for traffic from SGW2. Yet, the triple of both > these SAs on target is identical. Only if the target is broken. It should have generated a different SPI for each of the security gateways. If it did not, it's implementation of IPsec is broken. -- Matt Thomas Internet: matt@ljo.dec.com Internet Locksmith WWW URL: AltaVista Internet Software Disclaimer: This message reflects my own Littleton, MA warped views, etc.